soundcard serial comm snippet

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

Since my ATtiny lacks a UART I made a simple and short (100 bytes) serial transmission routine. Great for debugging/development when you don't want to include a 2KB USB stack. Instead you can add sprintf. I transmitted 250 bytes/s.

License: GPL

It toggles a pin on the avr. Between two edges there is a peak. Single width peaks code a 1 bit. Double width peaks code a 0 bit. Triple width peaks code end of byte. LSB transmitted first. Trailing 0 bits not transmitted.

The avr output pin connects to to the sound card via a voltage divider. I used 220ohm:2200ohm with 5V levels to get .5V to the line in input of the sound card.

On the PC side I use the linux command line

brec -s 44100 -b 8 -r|./comm2

brec records 8 bit samples at 44100 Hz, pipes it to comm2 which decodes and prints the data.

The delay loops are for use with a 1 MHz avr. You may tweak them for higher clock speeds or transmission rates. brec might also do 96000 Hz. However, there is a limit because the edges are sloped.

Uncomment the '// printf("%4d %2d %3d\n",sum,age,t);' line to see edge height, edge width and peak width when you tune your voltage divider, sound card input gain and decode timings. The peak height should be no more than 1/2 the sound card input range (256/2=128). Input gain should be mid to high, to avoid excessive input voltages. Probably you must set your line in as recording device with some mixer app. Try the other stereo channel if one does not work.

Have fun.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There was a delay loop missing at the end of transmission, so the pulse between successive transmissions might code a 1/0 bit or end of byte.

I found out, my soundcard does 200,000 samples/sec, so I gave it a try and decreased the delay loops to 1/3. I adjusted the receiver, and transmission at both 96,000 samples/s and 200,000 samples/s goes with a few (0 to 3, so far) errors per 10,000 bytes. Fine for me. I rather want shorter transmissions for debugging which fit in time critical gaps. The transfer speed is now at about 700 bytes/s. Dunno what causes the errors. Maybe glitches in the sound card.

The receiver now has slightly improved edge detection.

Attached is the 96,000 samples/s receiver as this causes slightly lower CPU usage and I could not see a difference to using 200,000 samples/s.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Darsie,

I don't really understand your reasoning for building this sort of debug communication protocol. I think it is usually much user friendly to use a somewhat bigger AVR (with a uart or maybe even JTAG) for debugging. After debugging is (almost) complete it is usually easy to change the target to a small AVR.

Greetings Paul.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Tue. May 5, 2009 - 04:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Darsie, while sound cards can sample at 96 or 192 kHz, it does not mean the analog filters go beyond 22 kHz. They may, but you really don't know until you measure it.

Paulvdh, any debug interface is a plus, sometimes sound card is used but with a speaker which beeps out bits instead of straight wire. Straight wire is just more reliable and faster and less annoying than beeping bits out. Another option would be to blink a LED, and pick it up with a optical receiver and feed it to serial port. Or to a sound card as electrical signal.

Most laptops and PCs nowadays don't have real serial ports and people only have USB serial ports, but any computer has a sound card, so it is a great debug interface. I agree, not a standard for bit serial transmission or fast, but doable.

Edit: Okay so bit-banging software UART would also be an option. But it still requires level translation for connecting to a PC. Or actually if you just invert the transmitted data in software, AVR can be directly connected to a PC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
I don't really understand your reasoning for building this sort of debug communication protocol. I think it is usually much user friendly to use a somewhat bigger AVR (with a uart or maybe even JTAG) for debugging. After debugging is (almost) complete it is usually easy to change the target to a small AVR.

Hi Paul!

I do have an ATmega, too, but frankly, I didn't think about developing on it for my ATtiny project. Now that you mention it ... I think porting the code to the smaller uC might cause enough bugs that this interface may well be useful. Especially if one does not have a lot of uC experience. For instance, at one point I started getting weird malfunctions. Turned out I had used up my memory and data and stack had collided. This would not have happened with the ATmega at that time.

Also I think this small code may even be useful as standard output in a finished project. It might collect data which would then be uploaded to a PC.

ATtinys are also cheaper. They are smaller. Save space on a PCB/breadboard.

Bernhard

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The timing parameters are tuned for code optimised to minimize size with 'avr-gcc -Os'. If you use something else you may have to retune.

BTW, I have cranked up the speed to ca. 1800 bytes/s @ 200,000 samples/s. Or maybe that is actually 192,000 samples/s, as Jepael mentioned. Still with occasional errors, but ok for me.