Shop OBEX P1 Docs P2 Docs Learn Events
Pasm calling SPIN OBJ interfaces? — Parallax Forums

Pasm calling SPIN OBJ interfaces?

TriCoachTriCoach Posts: 2
edited 2010-12-21 13:36 in Propeller 1
Hi All,

I think I know the answer (no), but just want to check. Is there any way to have pasm code access the SPIN routines in an OBJ?

background - I've got:
1 cog running Propeller Serial Terminal at 250K baud (pasm)
6 cogs running custom code (pasm)
1 cog running SPIN code taking data from the PST, massaging the data and distributing it to the other 6 cogs.

Alas, my SPIN code is too slow. I'm looking for ways to speed up the SPIN code, but I believe I will end up re-writing it in pasm. But that means I loose all the nice SPIN interface routines to the code in the other cogs. So now I think I have to re-write the interfaces to the other cogs in assembler.

Am I missing anything here?

Tks.

Comments

  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-12-20 14:49
    Yes, I think there are a few people here who have found the same problem. I'm trying to do similar things with Catalina, and I think there are people also trying to do this with Zog.

    What is needed is PASM code that does not have any Spin. Then some way of those cog routines to talk to each other - eg via fixed locations in hub ram. If you can get everything to fit in 7 cogs then that is great. If not, then it gets more complicated if you want to load and reload cogs from within code. Catalina can do this, though it is very early stages.

    The qZ80 simulation has gone some way to solving this problem, based on external memory access code by Cluso99. Pass a long to the cog that contains some data and an instruction and a flag. The data might be 1 byte. The instruction might say 'write to this address' or 'read from this address'. The flag is set when the cog has done its task.

    In a roundabout way, pasm can then access Spin routines. The flag can go both ways, eg set up a Spin routine to check a long in a particular location in hub ram and one bit of that long is a flag. The spin routine checks that regularly. The cog then sets the flag to say there is some data for the spin routine to process.

    Not simple but it is possible.
  • ericballericball Posts: 774
    edited 2010-12-20 15:04
    TriCoach wrote: »
    Alas, my SPIN code is too slow.
    What is taking too long? With SPIN it is important to minimize the number of operations (especially loops) as much as possible. Use built-in operators as much as possible.

    Can some of the data massaging be moved down to the PASM cogs?

    Finally, take a good look at the SPIN code. The PST interface is HUB RAM based, so could be invoked via PASM. How difficult would it be to code the SPIN routines in PASM?
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-12-20 15:39
    TriCoach: Firstly, welcome to this fantastic forum - I see this is your first post.

    How slow is too slow? I have a version of the spin interpreter that is ~ 20% faster. Others (Dave Hein?) have slightly modified the spin interpreter to also run LMM pasm routines (pasm executing out of hub - each instruction is loaded into cog one at a time and executed). This is slower than pasm but faster than spin.

    Perhaps you can describe what you are doing in spin that is too slow.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-12-20 17:08
    What are your PASM cogs doing? Are they 100% busy? If, not, I think my first approach would be to look at the two least-busy PASM cogs and try to combine their activities into one cog. You can use the jmpret instruction to facilitate tight coroutine execution, which may help in this endeavor.

    -Phil
  • TriCoachTriCoach Posts: 2
    edited 2010-12-21 09:28
    Thanks all for your input. A bit more detail:

    The 6 "customs" pasm cogs are running full out (well, they have to be ABLE to handle worst case operation). So I cannot add any functionality to them.

    The PST cog is also running at capacity (if I believe the header comments) just to keep up with 250K baud bidirectional serial data. I don't *think* I can add any of the packet handling code here, but that is a possibility to look at. The incoming data is "bursty", but the bursts are larger than the largest buffer that the current PST code can handle (I would need a 1024 byte buffer and the current PST is limited to 512 bytes 'cause it uses immediate data for buffer size and masking). An easy mod would be to add cog RAM variables to hold the buffer size and mask.

    As to "how slow is too slow"? Something like this: Data packets from serial port are approx 19 bytes. At 250K baud this is one packet every 760us. It takes the current (non-optimized) SPIN code 1.3ms to process a packet and send the data to the 6 other cogs. So I need a speed boost of just about 2x on the SPIN code. I do have the luxury of being able to control both ends of the serial link, and I think I can change the packet structure to put less load on the SPIN code. And certainly I need to go back over the SPIN code. Its current code is written more like I would in C and I stopped when I reached the "whew, it works" stage (well, works with short packet sequences).

    And, no it is not difficult to re-write the SPIN OBJ interface routines in pasm for the main cog. Just wondering if there was another answer before doing that. Nothing like writing a message to other people (and seeing their hints) to get your brain to think about OTHER solutions.

    Now I've got some ideas to try.
  • max72max72 Posts: 1,155
    edited 2010-12-21 13:36
    I second SpinLMM.
    It could help you with little trouble.
    Massimo
Sign In or Register to comment.