AVR-Chat

First I want to thank everyone for their help with the software SPI, I
managed to interface with the HM55B compass successfully. For that
solution, I ended up just writing shiftin/shiftout routines. If anyone
wants to see my code it is here:
http://docwiki.gumstix.org/Robostix_and_HM55B_Compass

I now am trying to interface with the following I/R distance sensor:
http://www.hvwtech.com/products_view.asp?ProductID=91

It has a synchronous protocol that I've already bit-banged in similar
fashion to the compass. This works ok, but I'd like to try and get the
asynchronous protocol working. Essentially the sensor will
continuously send out a sync pattern byte (10101010) and then the
reading byte. The example is written in pbasic and essentially
performs a SERIN at 4800 bps with a wait on the sync pattern.

My question is this: Is there example code out there for a C
implementation of SERIN and SEROUT? I see these "bit-bang" functions
all over the place in pbasic examples and would like a C equivalent.

SERIN: As a guess I would think I could start polling the pin for the
first low-high transition and then spin (according to my processor's
clock) for the appropriate time for the specified baud (4800). In this
fashion I could start looking for the sync pattern, restarting my
search if the pattern is incomplete. I would probably need to find the
pattern twice (with a byte between) before I could be certain I've
found it. Then I can just read the next eight bits. 

SEROUT: This would be the easy part, since I can just push out my bits
based upon the baud timing. If there needs to be a sync pattern, then
I just send it first.

In each case, I would need to account for MSB or LSB.

Any thoughts from the group? Thanks in advance...

--- In AVR-Chat@yahoogroups.com, "briangregory82" <bgregory@...> 
wrote:
> SERIN: As a guess I would think I could start polling the pin
> for the first low-high transition [...]
What you've described would suffice for a primitive serial input 
function.  It would, of course, suffer from the same shortcomings as 
does PBasic's SERIN function, namely, that it doesn't cope well with 
unsolicited serial input.

A more general solution is to implement what is commonly called 
a "software UART" that is driven by a timer interrupt.  Typically, 
the timer interrupt has to occur at some multiple of the bit 
frequency, the higher the better, for best serial input results.  
(Hardware UARTs typically sample the input line as many as 16 times 
per bit time in order to accurately locate the center of the bit 
window.)  As you have recognized, serial output is simple in 
comparison.

I have successfully implemented (in assembly language) a 4 channel 
full duplex software UART that is capable of running up to two 
channels at 9600 baud and up to four channels at 4800 baud with a 
CPU clock speed of 14.7MHz.

A software UART implementation requires some sorting of queuing 
mechanism in which input characters are placed as they arrive.  The 
processor can then check the status of the queue and remove the 
received characters when it is able to do so.

The Atmel application note AVR305 describes how to implement a half 
duplex software UART.  The ideas there may be useful to you.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

--- In AVR-Chat@yahoogroups.com, "Don Kinzer" <dkinzer@...> wrote:
> 
> A more general solution is to implement what is commonly called 
> a "software UART" that is driven by a timer interrupt. [...]
>

Thanks for the advice. Apparently avrlibc has a software UART
implementation. Are you familiar with it?

Brian Gregory

--- In AVR-Chat@yahoogroups.com, "briangregory82" <bgregory@...> wrote:
> Apparently avrlibc has a software UART
> implementation. Are you familiar with it?
I suspect that you're referring to the Procyon avrlib as opposed to 
avrlibc that comes with avr-gcc.  I've only looked at it briefly.  It 
is limited in that the serial input must be applied to the AVR's input 
capture pin.  Serial output, however, can be on any I/O pin.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

--- In AVR-Chat@yahoogroups.com, "Don Kinzer" <dkinzer@...> wrote:
>

> I suspect that you're referring to the Procyon avrlib as opposed to 
> avrlibc that comes with avr-gcc.  [...]

Yes, you are correct and closer inspection does reveal that it is tied
to the capture pin. Oh well. I'm looking at AVR305 and it might be
exactly what I'm looking for.


Brian Gregory

Yes, you are correct and closer inspection does reveal that it is tied
to the capture pin. Oh well. I'm looking at AVR305 and it might be
exactly what I'm looking for.
Brian Gregory
=====================================================
Software uarts can trade off complexity and cpu used vs error detection.... a hw uart
divides a bit into 16 slices, samples on bits 7,8 and 9, takes the best 2 out of 3 votes.
You can write the sw uart to only sample once in the middle of the bit, or 2 or 3 times...
this can be based purely on timing, or on edge detect. So you should be able to tailor the 
sw uart for any level of performance vs robustness.




________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free from AOL at AOL.com.


[Non-text portions of this message have been removed]

--- In AVR-Chat@yahoogroups.com, "briangregory82" <bgregory@...> wrote:
>I'm looking at AVR305 and it might be exactly what I'm looking for.

One aspect of the AVR305 method that may be unpalatable is that it 
utilizes the external interrupt functionality for start bit 
detection.  This means either that the serial input pin must be one 
that has external interrupt functionality or that you must use an 
external interrupt input in addition to the serial input pin.

In my original response to your post I alluded to an alternate 
technique for detecting the start bit.  Specifically, you can run the 
software UART timer at a multiple of the bit rate and sample the input 
pin often enough to ensure that you can guarantee sampling the 
subsequent bit windows somewhere near the middle.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

Maybe I'm kind of late here, but have you looked at the Procyon AVRlib? I
believe it has all the stuff you're looking for.
http://hubbard.engr.scu.edu/embedded/avr/avrlib
 
Phillip
 

  _____  

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of briangregory82
Sent: Sunday, June 03, 2007 9:00 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] SEROUT and SERIN



First I want to thank everyone for their help with the software SPI, I
managed to interface with the HM55B compass successfully. For that
solution, I ended up just writing shiftin/shiftout routines. If anyone
wants to see my code it is here:
http://docwiki. <http://docwiki.gumstix.org/Robostix_and_HM55B_Compass>
gumstix.org/Robostix_and_HM55B_Compass

I now am trying to interface with the following I/R distance sensor:
http://www.hvwtech. <http://www.hvwtech.com/products_view.asp?ProductID=91>
com/products_view.asp?ProductID=91

It has a synchronous protocol that I've already bit-banged in similar
fashion to the compass. This works ok, but I'd like to try and get the
asynchronous protocol working. Essentially the sensor will
continuously send out a sync pattern byte (10101010) and then the
reading byte. The example is written in pbasic and essentially
performs a SERIN at 4800 bps with a wait on the sync pattern.

My question is this: Is there example code out there for a C
implementation of SERIN and SEROUT? I see these "bit-bang" functions
all over the place in pbasic examples and would like a C equivalent.

SERIN: As a guess I would think I could start polling the pin for the
first low-high transition and then spin (according to my processor's
clock) for the appropriate time for the specified baud (4800). In this
fashion I could start looking for the sync pattern, restarting my
search if the pattern is incomplete. I would probably need to find the
pattern twice (with a byte between) before I could be certain I've
found it. Then I can just read the next eight bits. 

SEROUT: This would be the easy part, since I can just push out my bits
based upon the baud timing. If there needs to be a sync pattern, then
I just send it first.

In each case, I would need to account for MSB or LSB.

Any thoughts from the group? Thanks in advance...



 


[Non-text portions of this message have been removed]