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