Forums

Commuication Protocols and RAM

Started by criders November 28, 2009
Hello all,

Caution I AM A NEWBIE!!!
Be gentle, ever so gentle!!!

I am currently trying to create a communication protocol that will connect
several microprocessor devices together.  The devices do not exist yet,
because I have not designed them yet.  In order to keep my sanity, I would
like to store all the data in the same memory location for each of the
devices such as firmware number, process variables, digital inputs and
digital outputs, etc.

I have several questions...

1.) Is there a why to allocate a large portion of the RAM so the micro does
not use it for other processes or threads? 

- Currently I write some data to the first 255 bytes in RAM.  When I call a
specific function,  the variables in the function overwrite the data in
RAM.
I have came up with a work-around this, use an EPROM or Flash to store the
data in.  At time elapses slowly, this seems like the correct approach to
take considering I would need to have some of the data not to be erased
when the system is powered down.

2.) Is there a standard communication protocol between microprocessor
devices?
- At my last job, we were trying to to develop a new one.  This did not
seem to go very well.  So I am inclined to to try to use one that already
exist.
As of now, I am playing around with Modbus.  Since my knowledge over the
subject extends as far as my arms will reach, I figured I would ask.

3.) I2C or UART?
- Since I already know how to use SPI and I like complicating my life, I
would like to use to either I2C or UART.  From what I seen at my last job,
I2C does not seem the way to go if there was a lot of bytes being
transferred.  I think that it ended up being limited to about 128 bytes per
transfer.  This is not knowing at what speed the clock rate is set.  

Any help would be cool.

Regards,
criders

Quote: what is your raison d'être?




	   
					
---------------------------------------		
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com
Food for thought follows...

"criders" <cridersal@aol.com> writes:
> 1.) Is there a why to allocate a large portion of the RAM so the > micro does not use it for other processes or threads?
Yes, but it involves modifying the linker control scripts for your cross-development tools to not use that memory, or allocate it to a separate section. You can then allocate variables to that section manually, or use hardcoded addresses.
> I have came up with a work-around this, use an EPROM or Flash to > store the data in.
Yes, a small eeprom is usually where such configuration data is stored.
> 2.) Is there a standard communication protocol between > microprocessor devices?
Depends on what you're sending and whether you need multi-master or not, and if you have a full addr/data bus available. I2C can do multi-master but is limited to 400 Kbaud, although if you control all the nodes you can run it as fast as the nodes allow, perhaps even many MHz. SPI isn't multi-master but it's faster. Shared memory is fastest but most expensive and complex. You could use a memory-mapped FPGA as a communications hub, like a simplified ethernet network. Or use a CPLD to negotiate bus mastering between the micros and let them DMA to each other. A lot of communications protocols are built on the standard few, like CBUS is built on I2C.
> 3.) I2C or UART?
I2C doesn't have a built-in per-packet data limit, but there is a limit of 128 devices on the bus by default (7-bit address) although there's an extended version that uses 10-bit addressing at the cost of an extra byte transmitted per packet. The official I2C runs at 100kHz or 400 kHz, some new chips run at 1 MHz. If you're only connecting your own chips and you know they can go faster, you can go faster. For example, in a multi-master MCU bus, you might be able to run at nearly the MCU's full clock speed (clock and data edges need to be separate, so usually some fraction of the clock is used to get the needed clock phase timing). For UART, you could use a CPLD to negotiate control of the bus, with each MCU getting a Tx/Rx pair and a request/grant pair Set request, wait for grant, send at full speed. You'd layer a packet protocol on top of it. Use synchronous serial for faster baud rates, if your MCU can switch between master clock (MCU generates) and slave clock (external device generates) - then you can let the CPLD switch the master clock around too and get even faster baud rates. I.e. whoever has the "grant" signal active, generates the clock and transmits the data, which is relayed to everyone else. You could avoid the CPLD by using open collector on everything, with pullups, and just making it a shared bus like I2C. That only works if the idle state for each signal is HIGH.
criders wrote:
> I am currently trying to create a communication protocol that will connect > several microprocessor devices together. The devices do not exist yet, > because I have not designed them yet. In order to keep my sanity, I would > like to store all the data in the same memory location for each of the > devices such as firmware number, process variables, digital inputs and > digital outputs, etc. > > I have several questions... > > 1.) Is there a why to allocate a large portion of the RAM so the micro does > not use it for other processes or threads?
You've not mentioned if you have an operating system, etc. Nor what language you are writing in. All you need to do is "tell" whatever might want to use that memory that it simply isn't available. E.g., if you are writing a program in assembly language, you can create a module that is little more than a block of reserved memory. (actual mnemonics used vary from assembler to assembler) So, you might do something like: MY_BLOCK_OF_MEMORY: DS 255 (DS being "Define Space/Storage"... it just reserves N locations of UNINITIALIZED storage in your address space -- N = 255 here) Or: MY_BLOCK_OF_MEMORY: DB Version ;Version is a constant you might use to let ; your software know what "layout" this ; block of memory uses -- in case you later ; revise the format (a new "Version"). DW Year ;Maybe you need to note the date on which DB Month ; the data was last updated in this special DB Day ; block of memory DB FingersL ;Number of fingers on your left DB FingersR ; and right hands DL TimeStamp ;Number of seconds after midnight ... ;etc. (B=Byte, W=Word=16bits, L=Long=32bits... YMMV) If you are writing in a HLL (e.g., C), you can do the same by defining a static struct that encapsulates the data that you want to preserve and arrange for the linkage editor to put it where you want: typedef struct { uchar Version; ushort Year; uchar Month; uchar Day; uchar FingersL; uchar FingersR; ulong TimeStamp; ... ;etc. } my_type_t; static my_type_t { /* actual values go here */ }; If you have an OS, you can allocate this struct on the heap (assuming you don't care where it ends up residing) and then count on the system to prevent it from being reused by other consumers.
> - Currently I write some data to the first 255 bytes in RAM. When I call a > specific function, the variables in the function overwrite the data in > RAM.
Think about what is overwriting them? Your explicit "stores" (when your code writes to an explicit variable)? Temporary variables that your code is using? The stack? etc.
> I have came up with a work-around this, use an EPROM or Flash to store the > data in. At time elapses slowly, this seems like the correct approach to > take considering I would need to have some of the data not to be erased > when the system is powered down.
Yes. But if moving the data to UNWRITABLE MEMORY is fixing the problem, you aren't *really* fixing it! You've just prevented the problem from altering the data (even though it still is *trying* to!). Think about what is really happening, first. But, you are correct in that if you want the data to be *persistent*, you need to put it in some form of memory that will survive a power outage (EPROM, FLASH, NVRAM, etc.)
> 2.) Is there a standard communication protocol between microprocessor > devices?
What is their *physical* configuration? Are they colocated on the same PCB? Are they at opposite ends of a large warehouse? etc. What data rates are required? What sort of traffic *volume*? How reliable is the communications medium and how robust must the transfers be?
> - At my last job, we were trying to to develop a new one. This did not > seem to go very well. So I am inclined to to try to use one that already > exist. > As of now, I am playing around with Modbus. Since my knowledge over the > subject extends as far as my arms will reach, I figured I would ask. > > 3.) I2C or UART? > - Since I already know how to use SPI and I like complicating my life, I > would like to use to either I2C or UART. From what I seen at my last job, > I2C does not seem the way to go if there was a lot of bytes being > transferred. I think that it ended up being limited to about 128 bytes per > transfer. This is not knowing at what speed the clock rate is set.
Any packet-oriented mechanism will have this "problem". So, you transfer more than one packet! :> E.g., one can consider a simple EIA232 serial port as having a packet size of 8 bits (assuming it is configured for 8 bit characters). If you want to send more than 8 bits, you send more than one packet (character). You build a *protocol* on top of that technology that tells all parties that use this protocol how to interpret a *message* (which typically consists of multiple packets). The complexity of that protocol is governed by the needs of your application. E.g., does it need error correction? Does it need to support multiple physical or logical targets (addresses)? etc.
> Any help would be cool. > > Regards, > criders > > Quote: what is your raison d'&ecirc;tre?
Penser.
On Sat, 28 Nov 2009 12:35:51 -0600, "criders" <cridersal@aol.com> wrote:
> >1.) Is there a why to allocate a large portion of the RAM so the micro does >not use it for other processes or threads?
As others have mentioned, a serial EEPROM is what is often seen for this purpose.
>2.) Is there a standard communication protocol between microprocessor >devices?
Again, as has been mentioned, it depends on how much, how often, how fast, and how reliable. Without knowing those, any answers would be just guesses. But ... one that hasn't been mentioned already is CANbus. Reasonable data rates both within a box and between boxes tens or hundreds of meters apart.
>- At my last job, we were trying to to develop a new one. This did not >seem to go very well. So I am inclined to to try to use one that already >exist.
Existing protocols (the whole OSI layer from top to bottom) are not application specific and so may have more complexity and 'stuff' than a bespoke protocol.
>3.) I2C or UART? >- Since I already know how to use SPI and I like complicating my life, I >would like to use to either I2C or UART. From what I seen at my last job, >I2C does not seem the way to go if there was a lot of bytes being >transferred. I think that it ended up being limited to about 128 bytes per >transfer. This is not knowing at what speed the clock rate is set.
See above. How much, how often, how fast, and how reliable? UARTs are just async serial. You'll still need to decide on addressing, framing, checksum/CRC, etc. -- Rich Webb Norfolk, VA