search

hexagon5un / AVR-Programming

Code examples for the book "Make: AVR Programming"
http://littlehacks.org/AVR-Programming
MIT License
725 stars 340 forks source link

Serial output from CapSense example in Chapter08 is garbage #12

Closed paelzer closed 8 years ago

paelzer commented 8 years ago

Hi Elliot I'm currently working with your AVR-Programming book. All examples until now did just work fine. But now I stuck in the CapSense example in chapter08. The serial output from this code is just garbage. Only strange symbols. I use the ATmega168P with WinAVR and I already downloaded the latest zip file with the code examples here to make sure that I have the latest version and all code is untouched. But still there is nothing but garbage comming from serial output. The serial output from the programs in all chapters before worked just fine. Do you have an idea what the problem could be here?

Thanks a lot for any kind of help and for this great book!!

BR Boris

Hi again :-) After some experimenting with the code I now found out, that I get readable results from the serial output, if I remove the "full speed" command: clock_prescale_set(clock_div_1); /* full speed */. But then I only get results about 80 or 85 counts. This can't be correct I guess?

BR Boris

hexagon5un commented 8 years ago

That's hilarious. (Or as hilarious as a horrible bug can be...) I just ran into this problem myself a couple days ago.

What's happening is that the compiler builds up the serial library, you change the processor speed, and the compiler doesn't re-build the serial functions again to match the new speed. This glitch crept in when I switched over to a (better? more general-purpose?) version of the Makefile.

The quick fix is to delete any old copies of USART.o. In particular, if you're using the stock setup, it should be in the AVR-Programming/AVR-Programming-Library/ directory unless you've moved it anywhere else.

Delete USART.o and recompile. It will make it with the right F_CPU value (in the Makefile) and you'll be good to go. You'll probably have to delete it again if you switch back to a low-speed program. Sigh.

I'll fix up the Makefile too, which'll squish the bug for real.

Thanks for catching this!

paelzer commented 8 years ago

Hi Elliot

Awesome, that was fast man! It works :-D Thank you very, very much man!! I'm so happy to see this self made touch sensor working :-) Now I'll have a beer.

I wish you and your family a very nice christmas and also the best for 2016!! And good luck with your next projects!!

Greetings from the Saarland Boris

2015-12-20 23:18 GMT+01:00 Elliot Williams notifications@github.com:

That's hilarious. (Or as hilarious as a horrible bug can be...) I just ran into this problem myself a couple days ago.

What's happening is that the compiler builds up the serial library, you change the processor speed, and the compiler doesn't re-build the serial functions again to match the new speed. This glitch crept in when I switched over to a (better? more general-purpose?) version of the Makefile.

The quick fix is to delete any old copies of USART.o. In particular, if you're using the stock setup, it should be in the AVR-Programming/AVR-Programming-Library/ directory unless you've moved it anywhere else.

Delete USART.o and recompile. It will make it with the right F_CPU value (in the Makefile) and you'll be good to go. You'll probably have to delete it again if you switch back to a low-speed program. Sigh.

I'll fix up the Makefile too, which'll squish the bug for real.

Thanks for catching this!

— Reply to this email directly or view it on GitHub https://github.com/hexagon5un/AVR-Programming/issues/12#issuecomment-166158950 .