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

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'être?

Penser.

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.

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