Re: Commuication Protocols and RAM -criders

Thanks for all of the responses.  I was not sure that the message posted so
I think I posted another.  I apologize about the lack of information....

First off, I am currently prototyping using a Z8 Encore! Development Kit
from when I was is school.  I am also using their C compiler.  I think that
I am still a novice at programming.  I would like to use other micro
controllers perhaps an MSP430 or something from Atmel for some of the other
devices.  I know that each micro has their own procedures on how to set
things up.  But once the basic initialization for each micro has been done
along with a couple of interrupts for stuff, the main body of code should
function seamlessly.

The devices I was thinking about making would do specific task
exclusively.
One device would do just digital inputs while another one did just digital
outputs.  Another one would handle communications to a PC.  One would
display stuff onto an LCD screen, etc.  Multi-master is a definite with
this.


Address Space:
It does look like I can change address space in the compiler.  

I was thinking about doing something like this:
#define Data1    (*(unsigned char volatile far*)0x006)              

But the memory map that I have started is getting rather large and that is
way too much typing for me. So I wanted to define the address spaces in one
lump sum.

My reasoning behind trying to use address space is so that if I am having
an issue down the road, I can look at the data quicker. My experiences with
different types of micro controllers and compilers is limited, but I can
get  the data from ram and stream it somewhere if I can't view it any other
way.  
And lastly I wanted to line up the data with a communication protocol.  


Communication Protocols
I think my terminology is off.  Or perchance I need clarification.
I was under the assumption that the physical layer is stuff like RS232,
RS485, USB, Ethernet, etc.  I have written some programs that used some of
these mediums to talk to electronic devices.  But before I could do that, I
needed to know how to assemble the data so the electronics would recognize
it.  I would assume that this agreed upon arbitration is a communication
protocol.  I am familiar with ModBus.  And I heard about CANbus and
ProfiBus but never used them.  I will look into CANBus.  I just wanted to
know if any more existed.  I tried asking my friend Google, but he wasn't
much help.  Knowing my luck, I didn't type in the question correctly.  With
my project though, I would like the flexibility of within a box and between
boxes tens or hundreds of meters apart with reasonable data rates.  But
since I am still in development, I have all the time in world to learn new
protocols.  If  anybody knows more, feel free to let them fly!!! 

I2C or UART?
I believe aiming for the moon.  If one misses, then they will be farther
than where they started.  Having said that, I would like everything to as
fast as possible, as much as possible, and as many times as my devilish
mind can conjure.  As stated earlier, I2C seemed to have its limitations,
but I am hoping to get personal opinions and knowledge over the subject. 
And I was not disappointed!!  





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

On Sun, 29 Nov 2009 01:04:13 -0600, "criders" <cridersal@aol.com> wrote:

>Thanks for all of the responses.  I was not sure that the message posted so
>I think I posted another.  I apologize about the lack of information....
>
>First off, I am currently prototyping using a Z8 Encore! Development Kit
>from when I was is school.  I am also using their C compiler.  I think that
>I am still a novice at programming.  I would like to use other micro
>controllers perhaps an MSP430 or something from Atmel for some of the other
>devices.  I know that each micro has their own procedures on how to set
>things up.  But once the basic initialization for each micro has been done
>along with a couple of interrupts for stuff, the main body of code should
>function seamlessly.

Be aware that you might need some glue between the main body, runs
everywhere, section and the backend, processor specific code if you plan
on using the same main body with a variety of processors. 

>The devices I was thinking about making would do specific task
>exclusively.

Which is a good approach. But why, given this, do you need ...

>I was thinking about doing something like this:
>#define Data1    (*(unsigned char volatile far*)0x006)              
>
>But the memory map that I have started is getting rather large and that is
>way too much typing for me. So I wanted to define the address spaces in one
>lump sum.

... this rather large address space that, from the description, seems to
be common to all devices, given that you have nodes doing ...

>One device would do just digital inputs while another one did just digital
>outputs.  Another one would handle communications to a PC.  One would
>display stuff onto an LCD screen, etc.

... such different things? Why would the digital I/O node need to share
much (or anything?) with the LCD screen?

>My reasoning behind trying to use address space is so that if I am having
>an issue down the road, I can look at the data quicker. My experiences with
>different types of micro controllers and compilers is limited, but I can
>get  the data from ram and stream it somewhere if I can't view it any other
>way.  

Getting and streaming aren't unique to RAM. While RAM does tend to be
faster (orders of magnitude) than some other storage, it does have that
nasty property of going away when power is removed.

>And lastly I wanted to line up the data with a communication protocol.  
>
>
>Communication Protocols
>I think my terminology is off.  Or perchance I need clarification.
>I was under the assumption that the physical layer is stuff like RS232,
>RS485, USB, Ethernet, etc.

Well, the physical layers are the electrical and signaling
characteristics. Higher level protocols, like Ethernet, can include a
wide (very wide) array of organization, cooperation, etc.

It still depends on how much, how often, how fast, and how reliable,
which remain undefined. If you need to stream real-time video to the LCD
display, that drives towards one solution that may be overkill to turn
on the lights in the garage.

The reason there *are* so many different protocols is that there are so
many different needs. I2C, for example, is great for relatively slow,
low overhead comms between devices on a single board, e.g., temperature
sensing, fan speed control, save/read configuration data. CAN is great
for nodes that don't need to say, or be told, much at any given time,
that are not co-located, and that need fairly fast and very reliable
communications, like diesel engine monitoring and control on a rig
moving at 80 MPH down a highway. 422/485 can do arbitrarily long
messages at a slower speed but over greater distances, however, they'll
need end-point protocols if you want addressing or error checking.
Finally, Ethernet can, in theory, replace everything else but at the
cost of added complexity, if you write your own stack, or material cost
if you go with canned Ethernet modules.

>I believe aiming for the moon.  If one misses, then they will be farther
>than where they started.

But dead.

>  Having said that, I would like everything to as
>fast as possible, as much as possible, and as many times as my devilish
>mind can conjure.

IMHO, that's not good engineering. Everything should be as small and
slow as it can be while still meeting specs. There's a reason that hard
drives use a 3 Gb/s channel while PC fans are on a 100 KHz bus.

-- 
Rich Webb     Norfolk, VA

Rich Webb wrote:
> On Sun, 29 Nov 2009 01:04:13 -0600, "criders" <cridersal@aol.com> wrote:

>>  Having said that, I would like everything to as
>>fast as possible, as much as possible, and as many times as my devilish
>>mind can conjure.

> IMHO, that's not good engineering. Everything should be as small and
> slow as it can be while still meeting specs. There's a reason that hard
> drives use a 3 Gb/s channel while PC fans are on a 100 KHz bus.

"Fast as possible" is so open-ended.  I remember reading in Elektor in the 
'80s or so about a new intra-equipment bus called Taxi bus.  It provided 8-
bit TDM slots on a serial bus, a bit like daisy-chained serial/parallel 
shift registers on SPI, only with blazing speed (and a self-clocking 
signal.)

I was appalled to find that the interface chips were going to cost $75 each.  
That level of spending seemed strictly military.

	Mel.