RAM expander??
mirror
Posts: 322
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
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.
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.
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
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.
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