Author Topic: using communication hardware on the ATMega  (Read 9240 times)

0 Members and 1 Guest are viewing this topic.

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 28740
  • Country: nl
    • NCT Developments
Re: using communication hardware on the ATMega
« Reply #25 on: July 02, 2014, 08:20:06 pm »
Actually you don't need to implement ASCII to text and vice versa routines. These are available in the standard C library and usually these are written pretty efficient. They stem from an era where they could only dream of the programming space available in an Atmega  ;)
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline rob77

  • Super Contributor
  • ***
  • Posts: 2087
  • Country: sk
Re: using communication hardware on the ATMega
« Reply #26 on: July 02, 2014, 08:31:58 pm »
have you considered rs485 multidrop ? nice 2 wire bus - multiple nodes. it's robust , immune to noise...etc...
you just need to write a "few" lines of code to implement the communication protocol of yours.
 

Offline Kremmen

  • Super Contributor
  • ***
  • Posts: 1289
  • Country: fi
Re: using communication hardware on the ATMega
« Reply #27 on: July 02, 2014, 08:40:12 pm »
All AVRs (that i know of) have "Multi-processor Communication Mode" which is a hardware feature so the MCU can ignore serial data not intended for it when there are many serial devices on the same bus.
It uses an extra bit to indicate if a frame is an "address frame" or not. If the address matches the MCU it will receive all bytes until a new address frame comes along.
I've never actually used this feature but it looks quite useful for multi-node communications.

So to answer your question yes, you can have multiple serial devices connected together.

There's a few different ways to do it though....

If you plan to do multihost communications one of the first things you must specify is what they call the "access method". Put in simple terms, there are at least these simple alternatives:

- point-to-point where A and B communicate using separate data lines A -> B and B -> A

- single master, multiple slave where Master A communicates with a number of slaves 1...n. There is one transmit line from A -> 1...n and one receive line from 1...n -> A. This means that only A can hear 1...n and 1...n can only hear A. There must be a way to tell which of 1...n is the intended recipient. It can be done in hardware (chip select type thing) or an adress field in the frame header data. The latter means that all slaves must lift every frame at least until the address frame is received, to see if they must bother further.

- peer-to-peer partyline access method. Stations A...N communicate using a shared transmit/receive line (often RS485). There is no master/slave relationship. This option requires the use of a _media access protocol_. It can be implemented either in software or supported by hardware. I2C is a typical example. The idea is that any station is free to communicate with any other station. To do so it must somehow check that the media (line) is available an nobody else is transmitting. To do this you need some kind of _collision detection_ because it is always possible that 2 stations start a frame exactly at the same time. Usually the collision detection selects one station as the collision arbitration winner and it can continue while the loser withdraws and starts a resend delay. Classical Ethernet works this way as do many other shared media protocols. You probably do not wish to start from this alternative nor should it be necessary.

The human interface CLI is clearly point-to-point.
The inter-MCU link is most likely master/slave but reading your earlier posts it looks like you need to build in a master status renegotiation protocol in case you ever actually switch the roles. Or else plan how to restore the initial status outside the protocols. To clarify, the problem is this:
- somehow the 2 MCUs have been started "normally" and one is master, the other slave.
- the master crashes or something. The slave is supposed to be alerted by some mechanism and it assumes the role of master (doing the stuff the master did earlier)
- when the orignal master is restored there is a potential point of conflict. There is a new master in operation and the restored one should not barge in just like that because there will be issues. Instead the 2 MCUs should negotiate their new status somehow. I have been there and the strategy i suggest is to minimize the role changes. It works like this:
  -- the unit that is master, stays master until it is shut off or crashes.
  -- when a unit boots, it opens a link with its partner and arbitrates the startup role. If the partner is running it will indicate status of active master which would make the booting unit a slave. But if there is no response from the partner or it indicates problems, the starting unit assumes the role of master and communicates this to the partner. It is then supposed to revert to slave status.
Nothing sings like a kilovolt.
Dr W. Bishop
 

Online Psi

  • Super Contributor
  • ***
  • Posts: 10475
  • Country: nz
Re: using communication hardware on the ATMega
« Reply #28 on: July 03, 2014, 01:41:55 am »
These are available in the standard C library and usually these are written pretty efficient. They stem from an era where they could only dream of the programming space available in an Atmega  ;)

It's still quite cpu cycle intensive compared with not doing it and using the raw value with no conversion.
You're talking maybe 2 cpu instructions to copy a value from ram to the uart data register
Compared with 100's of instructions to divide down the integer with remainder into multiple values and then offset them to an ascii value. Plus the overhead of the limit checks and other misc stuff imposed by the function itself and the calling of it.
« Last Edit: July 03, 2014, 01:47:30 am by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 28740
  • Country: nl
    • NCT Developments
Re: using communication hardware on the ATMega
« Reply #29 on: July 03, 2014, 10:54:02 am »
You'll need limit checks anyway. Just look at your C library for the atoi function and see what it does with just a few (5 or so) lines of code. Besides that just copying bytes from ram to a UART doesn't solve byte order (endianess) issues. And if you ever need to alter or update the packet format you'll be seriously screwed. It will take a lot of time and effort to change so what is gained by using a cheaper/slower processor is lost 10 times by having to do more development work. Besides all that: how many commands need to be send per second? Probably less than 0.00001 so the extra overhead from ASCII conversion routines is near zero anyway.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf