1. Home
  2. Embedded Programming
  3. Re: Commuication Protocols and RAM -criders

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

formatting link

Reply to
criders
Loading thread data ...

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.

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

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

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

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.

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.

But dead.

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

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

Reply to
Mel

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.