Shop OBEX P1 Docs P2 Docs Learn Events
PASM.. Just wondering... — Parallax Forums

PASM.. Just wondering...

QuadrtrFlyrQuadrtrFlyr Posts: 73
edited 2011-03-08 22:22 in Propeller 1
Hello, I am not too familiar with PASM so I was wondering...

I am currently working on a Quadrotor and was hoping to maximize the speed of my real time control floating point math calculations. Using assembly language offers quite an increase in speed/performance (39microseconds to 4.7microseconds for addition I believe, etc.). So my questions are:

1. When I start coding in assembly, will I be able to jump between spin and PASM? For example, get the sensor values using the MCP3208 spin code and then calculate the degrees/second and acceleration values with assembly code.. Or would it be better/necessary to program completely in assembly?
2. Is there a way to debug values to the parallax propeller serial terminal window when coding in assembly?
3. How reasonable is coding a quadrotor entirely in assembly sound?

What it comes down to is: Will it be worth my efforts to learn/understand/code in assembly?

Thank you
Robert

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2011-03-07 22:51
    When you use the assembly floating point routines, you're normally still calling them from Spin. Look at the examples and documentation provided with the assembly version.

    1) You can't normally jump back and forth from Spin to assembly. The assembly floating point routines work somewhat like a floating point coprocessor in that they pick up a command and any operands from shared (hub) memory, do the operation, and report back to the Spin routine when done.
    2) Your assembly routines can deposit characters in the buffer used by the serial I/O driver and these will eventually get transmitted to the PC.
    3) You'd gain much more speed by converting your control algorithms to scaled integer arithmetic. Most programs spend most of their time in very small sections of their code. If you identify those sections of your control program, you could easily optimize them and convert what portions you need to assembly language. I think you'll find that most of the code will work fine in Spin and be easier to write and debug.

    You might look at Catalina which provides a C compiler and run-time library for the Propeller. Catalina code runs about 4 times slower than PASM and much much faster than Spin.
  • bsnutbsnut Posts: 521
    edited 2011-03-07 23:35
    You can program your Spin part of the program with Prop Basic. Prop Basic converts the basic into assembly. This means the whole program runs at the same speed.
  • Heater.Heater. Posts: 21,230
    edited 2011-03-07 23:39
    QuadrtrFlyr

    To expand on what Mike said a bit:
    When I start coding in assembly, will I be able to jump between spin and PASM?

    Unlike other languages, C for example, it is not possible to mix assembly language code in with your Spin code. Neither is it possible to link in functions written in PASM to be called from Spin.

    Rather what one does is set a COG running some PASM code. The Spin, running in the original COG, and the PASM now running in a second COG can interact by passing commands, data and results between each other via an area of memory in HUB. For example the PASM can loop around watching a HUB location until sees a command there. The command is placed there by the "calling" Spin. When the PASM sees the command it can pick up any parameters that have been placed in HUB by the calling Spin and return results back to HUB at which point it clears the command.

    I suggest having a look at the single COG floating point routines in PASM by Lonesock, F32 in OBEX, to see how this can work.
    Is there a way to debug values to the parallax propeller serial terminal window when coding in assembly?

    Again not directly. What I have done in the past is arrange for my PASM under test to write the contents of variable of interest out to HUB. Then a Spin process picks them up and sends them off to the serial port for display.

    There are a couple of PASM debuggers around that help with this, hopefully someone will chip in and tell you where they are.
    How reasonable is coding a quadrotor entirely in assembly sound?

    Keep in mind that you can only put 496 LONGS into a COG. That must contain your PASM instructions and the variables.
    So if your application is big it will need splitting over many COGS and become rather complicated. Or you will need to employ some "overlay" technique or will need to use LMM.

    Generally the programming model with the Prop is to have things like device drivers, small, fast and time critical, written in PASM and running in thier own COGs. Then the main, larger, program logic which need not be so fast and ties all this together is written in Spin.

    If Spin is not fast enough and your program to big for PASM in a COG I would check out the Catalina C compiler. Are you familiar with the C language?

    In general I would try and avoid floating point, it's a speed killer as it must be done in software on the Prop. Most times if you arrange your calculations wisely you can get by with fixed point arithmetic using integers.
  • RS_JimRS_Jim Posts: 1,768
    edited 2011-03-08 11:40
    Robert,
    Welcome to the forum. Several things you want to look for, first PSAD is an assembly debugger that allows you to run the debugger in one cog and have other functions running in the background. You might look for other threads for quadcopters, I know that cluso99 started one that has had a vast mount of information exchanged. As far as running a quadcopter in PASM go for it. Use assembly routines in different cogs for motor control, servo control, sensor reading etc. You can then write your top leval program in spin to tie it all together. Have fun!
    RS_Jim
  • QuadrtrFlyrQuadrtrFlyr Posts: 73
    edited 2011-03-08 19:50
    Thank you all for your detailed and thought out responses. From what I have researched and read I believe that I should look into the following:
    1. take a look into scaled integer arithmetic
    2. run time intensive tasks in a separate COG with PASM and then transfer data/calculations via the HUB memory.
    3. I have downloaded PSAD and have begun playing with it, looks like a very nice debugger.

    The full and utmost control aspect of PASM makes it a very addicting path indeed! When I work on a project I want 101% control, especially this one. I will be performing high altitude aerial photography with my quadrotor at heights close to 5 miles above sea level. This is the ultimate goal. I have been planning and designing a craft that could attain this height for the past year.

    Quick overview of quadrotor:
    Will ascend destination point at speeds up to 40 miles an hour.. Descent will be based on free fall with carefully designed airfloil.. quadrotor will resume tracking and flight to home base at about .5 mile up. Emergency shoots will be employed if needed. First and foresmost! Before it goes up even 100ft, every single aspect of the craft has to be rock solid. So i'm hoping you folks won't get to tired of my crazy questions anytime soon :smile:

    Regards,
    Robert
  • JasonDorieJasonDorie Posts: 1,930
    edited 2011-03-08 22:22
    While assembly will get you the most speed, period, it's worthwhile to consider how much speed you actually need, then decide if PASM is required. In my current quad, I was originally going to write the gyro interface code in PASM, but decided to see how fast I could get it to go in Spin first. After a few optimization passes, it updates at 250hz, which is 50hz faster than I need (and allows for some variation in the timing of things like multiplies).

    I'm in the process of converting it to PASM now because I want to put the code to read the accelerometer on the same cog. It flies fine without it, but I need a project. :)
Sign In or Register to comment.