Pure C Arduino

Continuing with the nokia 3310 display experiments, I wanted to try out if visualizing signals with this display could be any useful. For that purpose I wanted to build a simple scope with Arduino. I simply configured the ADC, used the internal 1.1 V reference voltage, configured the analog comparator as a trigger and tried to visualize the incoming samples. All of this has been done using the libpca and the following simple sketch.  So far, with enough accuracy I did some experiments with signals up to 8 kHz. I don't want to go into details at the moment especially that I consider this project as a work in progress. The ADC has been fed with a sine signal generated using Audacity. The quality of the measurement strictly depends on the ADC frequency. A couple of pictures bellow: 1kHz, sampled with prescaler = 4 2 kHz, prescaler = 4, visible trigger jitter ... same signal, bigger amplitude   4 kHz, prescaler = 4   6 kHz, prescaler = ...

Recently I wrote a driver for a nokia 3310 (pcd8544 based) lcd display which I had lying around.Again, I decided to create my own driver just to learn something about it and to see how much effort it will require - turned out that this driver is pretty easy to handle. Despite the fact that it's suggested to use 3V3 logic (maximum accepted voltage accordingly to the datasheet it's 7V), it works great with arduino powered with 5V and using 5V logic outputs. Adafruit's Library I had a look on Adafruit's library for that display just as a reference ( github ) and it seems very primitive to be honest - it allocates a huge display buffer without asking the user whether it is really needed (it consumes more than 25% of available RAM on Arduino) and what's even worse it uses bit banged SPI to communicate with the display. Why ? Why bother when there is fast & reliable hardware bus available on that MCU (and of course like all Arduino IDE libraries it's writte...

A(rduino)OS (AOS) is an attempt to write a simple pre-emptive scheduler - mostly to learn about how such system works but it's a fully functional implementation which can be used in a practical way good as well. First of all, if you have no theoretical background about context switching I would recommend to have a look on a great description regarding schedulers published by avrfreaks: Multitasking on an AVR AOS depends on libpca - it uses some routines from it in order to avoid code duplication. It is completely written in C from scratch with a little of assembler (in order to realize context switching). It comes with a documentation and some examples as well, which is hosted along with the repository on github: AOS Doxygen documentation Overview Most of the pre-emptive schedulers (besides cooperative schedulers) is implements and is driven around a "tick" - an interrupt which happens periodically with a programmed frequency and which is responsible fo...

I would like to share my project with you. It's an RTC clock with thermometer powered by atmega328p. Clock, displaying current time, date & day of week. It took me a while to finish this project since I wanted to polish the software. I wanted to implement a couple of features which will make my clock more interesting than any other similar device like that build before. I'll try to go through all the details now so, if you find this project interesting you can build it yourself (everything. including the software, is available for free). Hardware  The hardware itself is pretty simple. I used a ds18b20 digital One-Wire temperature sensor as a thermometer, a DS1307 RTC module which comes with a battery and a classic hd44780 LCD 16x2 display. Everything is pretty generic in that matter. There's a diode as well used to indicate that the clock is running and a couple of buttons. Besides that I use a couple of transistors in order to be able to control the LCD'...

It's often very useful to have some sort of interface through which a basic management can be done of our application. Whether you're designing a giant Marquee with a LED display or a plotter or you simply need to get some diagnostics from your device occasionally, a simple CLI system can come very handy.  Of course, designing something similar to "bash" or any other unix shell is completely out of scope since those applications are huge and are simply an overkill for our needs. It's pretty simple though to create some basic, yet flexible & easilly extensible CLI system. First thing needed is a command type definition. This will bind a keyword with an actual underlying routine executed for that keyword typed in the CLI . typedef struct _t_cmd { const char *cmd; void (*fh)(void*); } t_cmd; The command type is pretty simple. There's the CLI command/keyword pointer, it holds a pointer to the execution function and that's it. OK, so...

Practically with every project, I buy a new device - with which I need to familiarize myself. Most of the time those are devices using already very well known buses like I2C , OneWire or SPI . But from time to time it's a parallel device with a very specific interface. There's a need for the driver then. There are two ways: the easy one - get the driver from the internet and use it - now don't get me wrong that's a perfectly good way to solve the problem - your device is up and running pretty fast and you do not have to worry about it, since most of the problems have been already taken care for you. The hard way is to write the driver yourself. Now a question arise why to do it in the first place ? The are a couple of reasons for that. First of all - you want to learn something - most obviously you will, since you will have to learn about the device thoroughly. Second - you want to make it smaller/faster - that's more pragmatic reason, since the downloaded driver...