Buggy uses 08M for IR Remote Control

[exartemarte]

This is not strictly a Picaxe project, nor is it finished. It does, however, include a Picaxe, and that part of it is complete, hence its mention here.

Wanting IR remote control for an AVR-based project, it occurred to me that using a small Picaxe to receive and decode the IR signal would be quicker and easier than developing routines to do it all on the AVR. I tried it using a Picaxe-28X2 Module - I have one that lives more or less permanently on an experimental breadboard. It worked, eventually, and a version was transferred to a Picaxe-08M, which was what I had to hand, for inclusion in the project. The circuit is simple, the program is very short, and both are more or less directly from the Picaxe manual. The picture below shows the Picaxe / IR receiver section outlined in blue.

In my experience things involving serial communication rarely work first time, and this was no exception, but once the communication protocols were sorted it worked satisfactorily. It is worth noting that the AVR expects a signal which idles high, hence the T---- version of the Picaxe baudrate setting is needed rather than the N---- version. This is the 08M version of the program:

main:

infrain2
serout 1, T2400_4, (infra)
goto main
​

Although I chose an AVR controller for this project I haven't abandoned Picaxes. I have two current projects using Picaxe-28X2, both of which will, I hope, appear here in the fullness of time. The current state of this project is described at length on my website, here.

 

[hippy]

Wanting IR remote control for an AVR-based project, it occurred to me that using a small Picaxe to receive and decode the IR signal would be quicker and easier than developing routines to do it all on the AVR.

An absolutely perfect case for using a PICAXE as a 'smart peripheral' to take workload off the master controller, be that another PICAXE, PC or other microcontroller, and well done for going down that path.

I'm a great fan of using PICAXE as such 'smart peripherals', both for handling inputs and outputs, as the modularisation will usually make each program required simpler and easier to write, test and make work, and the whole system likely easier and quicker to develop.

Though it does add extra cost there are savings elsewhere in allowing the main controller code to be more simple; in particular not having to block or deal with specific timing which will get increasingly complicated the more one needs to do.

It's always tempting to try to do everything on a single chip to achieve minimum cost when a better solution can be to spend a little more and save costs elsewhere; whether in complexities, time or effort. What sometimes seems more complicated can turn out to be less complicated, though, as you note, it's not always plain sailing in ether case.