Shop OBEX P1 Docs P2 Docs Learn Events
RAM expander?? — Parallax Forums

RAM expander??

mirrormirror Posts: 322
edited 2007-04-06 14:07 in Propeller 1
If a COG is started which runs an assembly process, then 512 longs are copied from the main memry to the COG. Assuming the COG gets started but never stopped - does that mean that I can then use that 512 longs of main memory for some other purpose? Does the propeller in actual fact have 48kbytes of RAM to use?

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2007-04-06 04:16
    Theoretically, you could use the 512 longs for something else. They're normally assembled as a block of constants as part of a Spin object, but there's no reason why they couldn't be read from an EEPROM into a buffer, loaded into a cog and the buffer reused for something else or the block of constants overwritten with something else.

    The propeller has 9 completely separate blocks of RAM, a 32K byte block called HUB memory or main RAM and 8 identical 2K byte blocks organized as 512 longs that are each part of what makes up a cog. The cog memory is only accessible from the associated cog. The HUB memory is accessible from any of the cogs and is treated somewhat like an I/O device in that it's not an extension of the cog's memory. There's also a 32K byte ROM that is part of the same address space as the HUB memory and is accessed the same way.
  • mirrormirror Posts: 322
    edited 2007-04-06 04:38
    Thanks for the reply.

    The application I'm working on will have the COGs doing specific high speed jobs, but I'm expecting to need a couple of FIFO buffers to join the COGs together, so all the RAM I can get will help. In particular, one of the COGs will be servicing a Ethernet UDP connection using an ENC28J60 on an SPI interface. Another COG will be connected by another SPI interface to an SD Card. To retrieve information from the SD card and over the Ethernet port as quickly as possible I'll need to have both COGS running in an almost DMA style of operation.

    As I said, spare RAM is good, because the Propeller will be able to anticipate the next Ethernet request, and have the data from the SD card ready to go - or at least ready enough to start filling the Ethernet transmit buffer.
  • rjo_rjo_ Posts: 1,825
    edited 2007-04-06 06:03
    mirror,

    I don't know how close you are to a deadline. But you seem to have the communication thing down to a science.
    If you run out of either bandwidth or fast memory... I have an idea for you. There may be a huge flaw in this... which I would expect either you or Mike to spot immediately... but it makes sense to me... so either it is a good idea or there is a simple fact that I glossed over.

    Inter-cog communication on a single Prop almost invariably has to go through the Hub... because I think there is one cheat available.

    But if you tie two Props together at their pins... then you could have cogs talking to each other without going through the Hub... They would need a common clock... which I think is either a device or another prop. So, in theory, you could use cog ram in a parasitic fashion... and you could direct memory access to another Hub through "siamese-paired" cogs.

    I have a piggy-back prop... but right now ... limited time and understanding.

    I've been dying to get that off my chest.

    Thanks,

    Rich
  • mirrormirror Posts: 322
    edited 2007-04-06 07:51
    Rich,

    Now that's an interesting thought! I don't quite think I need it though.

    Realising that at worst case scenario you get a hub access every 24 cog clocks. So, running at 5Mhz x 16PLL = 80mips, I should be able to get about 13.3MBytes of transfer per second. The Ethernet connection handles at most 10Mbps (less because of the overhead), and I suspect that it's going to be a full time job getting the SD card to keep up. In reality, I think that even going through the HUB you'd be able to keep a 100Mbps Ethernet connection reasonably full to the brim.

    The aim is to have some decent FIFO buffering between the various processes, as the best case scenario in this design is when none of the processes gets starved of its data feed. That's the primary reason I've decided to go UDP instead of TCP/IP over the Ethernet chip - the connection is reasonably direct. I'd rather have a connection that's fast and a little bit buggy than slow and reliable.

    I'll see how I go actually implementing this lot - it should be fun.
  • Mike GreenMike Green Posts: 23,101
    edited 2007-04-06 12:00
    The notion of using I/O pins to communicate from cog to cog either between two Propellers or even between two cogs in the same Propeller has been discussed before. If you've got the spare I/O pins, it's a great idea. Have a look at Rokicki's high speed SPI routines in his SD card FAT file system package (in the Propeller Object Exchange). He's been able to get very high transfer rates using the cog counters to generate the clock and shift out the data.
  • rjo_rjo_ Posts: 1,825
    edited 2007-04-06 14:07
    Mike,

    SPI is definitely on my list. My problem is that there are real engineers doing that stuff... So for now, I just take those kinds of objects for granted. I'm not going to be able to get away with that approach for too much longer.

    There is absolutely no better feeling than having you confirm a vague suspicion.

    Thanks,

    Rich
Sign In or Register to comment.