Pure C Arduino

It's time to do something useful with our small 8-bit computer. Music box is a fun and easy project. It's not demanding from the hardware point of view but it can be a little bit tricky from the software point of view itself - ideal project to learn a lot and not to spend the whole day soldering. What we will need:  an Arduino (of course)  Piezo buzzer  ... and that's all. Now a couple of words of what we want to achieve.  Requirements  Let's point them out: play monophonic melodies by generating tones (1 channel MIDI instrument) the notes will be send by the PC through the serial port  our musicbox should be visible to the PC as a MIDI port  be able to use MIDI player of choice on PC to play MIDI files on our musicbox  The requirements are specified. Unlike most of the simple projects around which play the same melody everytime, which most of the times is hardcoded in the program memory and in order to change it...

A word of warning, this post will be kind of long. I will try to cover the binary communication over serial port basics in 2 languages (C & perl), but I hope every one will bare with me until the end. I'm almost ready to go into some of my "real" projects. In order to do that all that needs to be done is to talk a little about SLIP protocol. SLIP protocol is used to synchronize data between receiver and transmitter on a serial line (not only RS232 , ethernet as well and many other mediums). SLIP is one of the most commonly used option, the other one is Modbus RTU , which describes some timing constraints and requirements during the data transfer. I haven't tried Modbus RTU yet, since SLIP is doing pretty good job for me.  First of all why do we need to synchronize the data at all and what does it mean in details in the first place ? The reason for that is simple (maybe not so obvious in the first place). Consider the following situations: We want ...

In previous post I covered the basics of configuring and using the Atmega's USART as a standard RS232 port. This post will be more a little addendum to the previous one. In our program of course we can manually send strings using the serial_send/serial_poll_send routines, but we can use the serial port in more convenient and transparent way. If our application implements only some kind of CLI system or basically treats the serial IO as a Serial Console we can configure libc to use our serial IO routines for stdio functions like printf . What we have to do is to create an input output file streams and instruct avr-libc to use those. Let's have a look at the code bellow: The code refers to the serial IO routines implemented by libpca. First of all _serial_putc/_serial_getc are just a wrappers, interface adapters sort of speak, to adapt our serial IO API to the library's one. In serial_install_stdio() we simply create two file streams, one to be used as STDOUT...

It is essential to have a convenient functions allowing quick serial port setup and usage. In this post I'll try to cover the basics of using the serial port, data reception & transmission + using interrupts. Serial driver routines are very similar to supervising a NIC . Of course they are much more simpler and the speeds are lower as well, but the general approach is very similar. In the simplest model we can realize serial transmission/reception directly - by simply sending the data byte by byte waiting for the hardware to finish each transmission and poll the hardware status register before queuing/dequeuing new data. Although this approach will work, it's not very elegant and it requires constant CPU attention which consumes a lot of processing power. Using interrupts provides a lot more flexibility and save some processing power since we don't need to constantly check the USART's registers in order to know whether we have any pending data or not. As u...

Previously I presented a basic way of using timers in order to generate delays. At this time, we'll learn how to use timers and piezo buzzer to generate tones (beeps). The code for that won't be very different from what we were doing previously. Let's start with defining the requirements of our implementation. Our "beeper" function should allow us to generate a beep of given frequency and duration. Simple as that. Just to quickly summarize, when using timer for delay purposes we configured it in CTC mode and configured the prescaler and OCRXA register value so the timer "overflowed" with a 1 kHz frequency (1 ms period), the delay duration was specified by the number of "overflows". Previously, as long as counting the 1 ms cycles was good enough to determine the duration, now the duration depends on both parameters, the actual duration specified as an input parameter as well as the frequency itself.  Let's list steps that our "be...