Prop as I/O handler? Via shared memory ?
Fernand
Posts: 83
A) Seems like the Prop would make an ideal "soft" I/O device for a Linux or other host,
if there were a really simple, non-proprietary and transparent way to pass data back
and forth.
Since the limited and specialized memory layout of the Prop gets in the way of larger
C/C++ programs, seems like delegating all the bigger memory stuff to, say, a Linux
that boots from a flash drive might be a good pairing.
Depending which side you're focused on, the Prop either gets I/O oriented tasks
delegated to it from the host side (A), or the Prop delegates crunching to the host
side (B).
Has anyone developed a shared memory subsystem for/with a Prop? It sure would
be lovely not having to deal with any protocol, and just bang memory from either side.
Sort of an extension of the Hub sequencer?
I haven't seen the details yet, but the Arduino Yun is a board that seems a bit like
that: Linux + Arduino. Their paradigm seems to be that the Arduino coder gets a
library of Web functions that are handled by the Linux side. But for a wider range
of applications, the Prop would make a much more powerful MCU "partner". Maybe
a Prop on a Rasberry Pi board? These sorts of (open source) hybrids are bound to
appear, and flourish if some standards take hold. Large potential volume?
Has any work been done on shared memory in this context? From the host side,
having all the functionality in OBEX to delegate to the "I/O handler" would be pretty
powerful. For the Prop developer, having all the network functions and protocols of
a Linux distro would be great too.
if there were a really simple, non-proprietary and transparent way to pass data back
and forth.
Since the limited and specialized memory layout of the Prop gets in the way of largerC/C++ programs, seems like delegating all the bigger memory stuff to, say, a Linux
that boots from a flash drive might be a good pairing.
Depending which side you're focused on, the Prop either gets I/O oriented tasks
delegated to it from the host side (A), or the Prop delegates crunching to the host
side (B).
Has anyone developed a shared memory subsystem for/with a Prop? It sure would
be lovely not having to deal with any protocol, and just bang memory from either side.
Sort of an extension of the Hub sequencer?
I haven't seen the details yet, but the Arduino Yun is a board that seems a bit like
that: Linux + Arduino. Their paradigm seems to be that the Arduino coder gets a
library of Web functions that are handled by the Linux side. But for a wider range
of applications, the Prop would make a much more powerful MCU "partner". Maybe
a Prop on a Rasberry Pi board? These sorts of (open source) hybrids are bound to
appear, and flourish if some standards take hold. Large potential volume?
Has any work been done on shared memory in this context? From the host side,
having all the functionality in OBEX to delegate to the "I/O handler" would be pretty
powerful. For the Prop developer, having all the network functions and protocols of
a Linux distro would be great too.
Comments
Dual Port memory is available, but it is not cheap, or in very friendly packages, and most is fading out.
There was some serial Dual port SRAM, but that seems to have gone.
There is mention of Dual port EEPROM, but that too looks no longer current.
It is likely better to just do an AutoBaud high speed serial handler : Allocate a cog for each way, and some local largish data buffering, and you would get performance above low speed USB, and above many std speed USB links.
1) It's going to eat all the Prop pins, you won't have much Prop left for doing those juicy "soft I/O device" things.
2) It's going to require host (ARM or whatever) board specially designed to interface to it.
You could alleviate much of that by, say, restricting your data bus to 8 bits and only using a few pins to decode a handful of addresses. That reduces your system to using the Prop more like a traditional byte wide peripheral port.
At that point though you are better off attaching a Prop via a standard serial protocol which can then easily be attached to any embedded ARM or such system, We are doing that with Prop boards for the Raspberry Pi.
there is really fast serial
http://forums.parallax.com/showthread.php/149534-Propeller-Serial-with-Tight-Byte-Spacing
so you only need 2 IOs and have 30 IOs + 6 or 6.5 COGS free.
This sounds similar to something we are doing. The idea is to delegate the realtime portion regarding control of actuators and monitoring sensors to the prop; The prop also does prefiltering and immediate response activities. The linux box does long term and stability processing (i think thats the right way to say that) using the preprocessed data. The linux box says which way to go and the prop gets us there. This is the only I/O we have been addressing so far. But it doesn't use shared memory, the prop doesn't have so much to share. This is just uses I/O streams. Mulitple channels share the same physical connection, usually two I/O pins on the prop and on the RPi. The non-proprietary and transparent method is the low level portion of GO channels (similar to CSP channels but different). Is this close to what you are after?
@jazzed, can you clarify pls?
And @prof-braino, where can I read about what you're doing?
You know, as I was looking at the info available on the Prop 2, it struck me
that it's still tied to that specific memory model, with its fast memory being
very very small. That would seem to limit it to the "getting us there" portion
of a design, and require a "host" system to "say which way to go".
So why not build that interface in at the chip level? I realize you can dedicate a
cog to handling it, and maybe that's the solution, but maybe some sort of hard
wired super fast serial transfer with dual ported RAM would be faster? Or one of the
latest and greatest blindingly fast protocols, Thunderdump or whatever, and better
yet all of the above.
In any event really putting some thought into a niche for the Props based on that
relationship, not as "one more thing you could do", but as THE I/O solution for
everybody, nailing the standards, handing out reference designs that are ready to
go with just a handful of chips. Embracing Linux, writing the host side drivers,
with an eye to dominating that market. A marketing campaign like "I think
therefore I am, but when I need to DO stuff, I need a Prop". Or "when spirits
want to listen in and rattle tables, they need a Prop".
My initial question was along the lines of "what is the Prop community doing
to cover that?" I can't help thinking that Parallax should be building it in.
I see a market here for the Propellers. Am I nuts?
Increasing that fast COG space would require instructions wider than 32 bit. Or a different instruction set to handle bigger address ranges, which will need multi-long instructions. The later solution means the Prop is no longer a Prop.
There is of course the purely physical limit that the chip is full, there is no more space for bigger COG memory. Many here were arguing the case for dedicated serializer/deserializer hardware on the Prop. To be inline with the Prop philosophy it would have to be simple, it would have to be configurable (So that i could help with any serial bit stream protocol). It would have to be available on all COGs. Like the video hardware is now.
As far as I know nothing like that made it into the PII.
Of course this has all been discussed to death over the years and it's to late now. The PII die is cast. (Literally) I could of sworn you question was about using memory shared between a Prop and
some other "host" machine.
Seems to me the Prop can communicate pretty rapidly with a host processor via serial or acting as an I2C or SPI device. That is how I intend a Prop and Raspberry Pi to work together. Probably no new Linux drivers are required for this. Just write your app at both ends and away you go.
Of course, that's the Linux/Unix way of doing things with shared memory. The underlying hardware could be a string and two soup cans with a protocol (the transport layer). Another more generic option is to use sockets which could also encapsulate the transport layer.
shmem, mmap and such are ways of sharing memory between processes on a Unix/Linux system. Of course a "process" might actually be running on a different core or CPU or even some weird hardware that has access to your main memory. Even simple things like the registers that control GPIO on ARM chips are memory mapped.
On the other hand there is the actual physical sharing of memory between an ARM, say, and a Propeller.
If you want that much of an intimate connection between Propeller and host that's when you find you have used a lot of Prop pins and the speed gains over a serial interface may not be as great as you think.
The OP might be able to answer that with a little more research.