Commuication Protocols and RAM

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

formatting link

Reply to
Loading thread data ...

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.

Yes, a small eeprom is usually where such configuration data is stored.

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.

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.

Reply to
DJ Delorie

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:


(DS being "Define Space/Storage"... it just reserves N locations of UNINITIALIZED storage in your address space -- N = 255 here)


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.

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.

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.)

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?

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.


Reply to
D Yuniskis

As others have mentioned, a serial EEPROM is what is often seen for this purpose.

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.

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.

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
Reply to
Rich Webb


1.) I would like the flexibility to create several different types of electronic instruments without having to redesign everything. The cost of microprocessors are rather low. I can't see a reason not to dedicate one micro to just collecting input data and another one to just displaying the data. Naturally sometimes this approach will not make sense at to use (i.e. if the data I was collecting was one foot away.). Other times it would (i.e. if the data I wanted to collect had to be collected remotely.) But to have that flexibility implemented into my process of design will hopefully mean that sometimes all I have to do is grab several modules and connect them up and start developing. 2.) I also want the experience. I am still in the beginning stages of my career. I don't want this thing to be overly complicated where it is impossible to get anything accomplished, but I do want it to cover as many aspects of embedded design that I can cram into. I figure breaking things apart and having the smaller parts completed, I can spend more time focusing on the bigger picture. 3.) Speed I just want things to go as fast as I can make them without anything crashing.

I used to have this same conversation with my fellow co-workers. In my personal opinion, if it moves faster that I can see it, then its fast enough.

And I usually get bored trying to tweak stuff to their maximum performance. Sooner or later, you have to cut the cord and hope for the best.

4.) Shooting the moon I remember hearing a story about some kids who tried to do something very similar. They used a red radio flyer wagon. It flew. It has to be true. They make a movie about it! Movies don't lie!



--------------------------------------- This message was sent using the comp.arch.embedded web interface on

formatting link

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.