 |
| RFM12B shield for Raspberry Pi, with integrated in-circuit serial programmer. Click on the image for an annotated version. |
I recently described the preliminary design of a RFM12B shield for the Raspberry Pi, which used an Atmel ATmega328 to interface between the Raspberry Pi's UART and the RFM12B's SPI interface. The design also included a buffered two-channel in-circuit serial programmer (ISP) using the Raspberry Pi's general purpose I/O. The first channel is for programming the on-board ATmega328 whilst the second channel can program external microcontrollers.
The boards have now been manufactured and the first one assembled and tested. The interface to the RFM12B and the built-in AVR ISP programmer both work as designed. I have been using the Arduino environment to compile and upload the firmware to the ATmega328. The microcontroller pin mapping is identical to the Arduino Uno although the activity LED is wired to D9 since D13 is normally in use by the SPI interface. The ATmega328 operates at 3.3V and is clocked by the internal 8MHz RC oscillator. No bootloader is needed. The Github repository contains
boards.txt and programmers.txt files for use with the Arduino IDE, the standard Arduino core is used.I have been using the first board to replace a Ciseco URF radio module. The firmware for the ATmega328 incorporates my transparent serial emulation layer. This provides a
Stream object to which data can be read, and written (or printed), in just the same way as HardwareSerial and SoftwareSerial objects. The same emulation layer can then be used on remote Calunium, Arduino or JeeNode boards to provide a bi-directional data stream, allowing the user to interface to the RFM12B as easily as an XRF or XBee radio module. The emulation layer transparently uses acknowledgements and retries to provide a robust channel, which is an improvement over the Ciseco XRF and URF radio modules. Alternative firmware for the RFM12B shield is easily uploaded to provide different functionality.ISP programmer
The avrdude configuration file contains details for two GPIO programmers;gpio0 is connected to the on-board ATmega328 and gpio1 is for programming external microcontrollers. By fitting a jumper to the JP1 header the external microcontroller can be powered from the Raspberry Pi's 3.3V supply. Be sure to observe the maximum current rating for the 3.3V supply and never fit the jumper if the remote microcontroller is self-powered. The 74LVC244 buffer ensures that MCUs operating at 5V can be safely connected. Typically the high output level from the 74LVC244 buffer will be recognised as a high but it doesn't meet the worst-case specifications when the external MCU is powered from 5V.
Is there a set PCB files with the missing track fixed?
ReplyDeleteThe Eagle files can be found at https://github.com/stevemarple/RPi_RFM12B_ISP/tree/master/hardware/v1.1
DeleteI haven't generated the Gerber files yet but that is easy to do. I just noticed that the design rule file (.dru) that I used previously isn't in the project directory. I'll correct that omission and add the Gerber files when I get time; might be a few days.
I've uploaded the Gerber files for the version which fixes the missing reset line. If you have any boards made please let me know how they work since I haven't sent this version off to production.
DeleteThanks for updating the files.
ReplyDeleteI try to read the serial port: "sudo mini com -b 115200 -o -D /dev/ttyAMA0". I get garbage data. Baudrate of sketch vs Pi has been checked and are the same. Also disabled Hardware flow control. All to no avail. Any hints or someone with the same experience how resolved this? Many thanks!
ReplyDeleteCan you give more information about the hardware you are using, and what sketch is running on the ATmega328? What value are the fuses set to? With this design the ATmega328 runs at 8MHz using the internal RC oscillator, which differs from the standard Arduino (16MHz crystal oscillator).
DeleteHi Steve, sure. I run the RF12DEMO sketch from jeeLabs with serial port set to 57600 baud. Ofcourse I use your board on top of a Raspberry Pi model B with one of the latest Raspbian images. I've modified the /etc/inittab and /boot/cmdline.txt files to disconnect /dev/ttyAMA0 from console. I've used the ATMEGA328P-PU as controller chip and using the programmer through gpio with the modified avrdude works flawless. Fuses are set: lfuse:E2, hfuse:DA, efuse:FF Thanks for your help! Great board you've developed here!
DeleteThat baud rate contradicts with the minicom command you posted earlier.
DeleteYour fuse settings will have the ATmega328P using its 8MHz RC oscillator - are you sure you had the processor speed set to 8MHz when compiling the RF12DEMO sketch?
One thing I noticed with your fuse settings is they indicate a 1KB bootloader. That's fine if you are using a bootloader and uploading programs via the serial port. If you're not you should adjust the fuses otherwise program execution will jump to the wrong place after reset. My boards.txt file is intended to upload sketches via the ISP interface. That avoids the problem of rebooting the ATmega328P just before sending serial data so that you can talk to the bootloader. You can find the correct fuse settings in the that boards file. I also enable brownout detection since I've had bad experiences of not using it (see http://blog.stevemarple.co.uk/2013/02/the-importance-of-brown-out-detection.html)
Thanks Steve. The minicom example I wrote was wrong but used the right baud rate in the actual exercise ;-) I'm not sure what you mean setting the right processor speed at compile-time. Never done that nor seen that. But will investigate. I use avrdude to program the processor and don't need the boot loader; I will reset the fuses indeed. Thanks for the hints, will report back as soon as I have results.
ReplyDeleteIf you use the Arduino IDE to compile and select the standard Arduino DueMilanov or Uno then the compiler will use 16 not 8MHz as the CPU clock speed. Having the speed set right is essential for the correct calculation of delays and for initialising the UART to set the baud rates.
DeleteReset the fuses to E2,D1,05 as mentioned in the boards.txt. Reprogrammed the chip with -e erase option through avrdude. And... still garbage on the serial port. Only thing I couldn't figure out was setting the clock-frequency at compile time as you mentioned... Will google further ;-)
ReplyDeleteHi Steve, all's fine now. Took same time to investigate why de board.txt did not do anything in the IDE as that seemed to be the clue to the right clock speed compile setting... I've IDE version 1.5.6 and googling learned me that the right folder structure should be: /hardware/raspi/avr/. Compiling wight the right board did the job! Thanks for your help!!
ReplyDeleteSteve, wanted to send you a big compliment on a great product you've created. The board has been in use at my site for a few weeks now and I'm loving it! Many thanks.
ReplyDeleteHi, using the JeeLabs RF12demo sketch works fine except it doesn't hold the configuration changes it writes the eeprom after a power-cycle. Sketch works fine on other boards like Moteino and JeeNode with the same ATMEGA328p-pu. Any clues on how to investigate this further and what specifics of this board could be causing this behaviour? Thanks!
ReplyDeleteIt sounds like you need to activate the "Preserve EEPROM memory through the Chip Erase cycle" (EESAVE) fuse to get the behaviour you desire. See the AVR fuse caclulator, http://www.engbedded.com/fusecalc/.
DeleteHi Steve, thanks for your consideration.
ReplyDeletefuses are set as follows lfuse: 0xe2, hfuse: 0xd1, efuse: 0x05
This gives a positive on EEFUSE... I'm not going through a chip erase cycle rather a reboot cycle. So still confused as to what causes this behaviour.
Sorry, I misread your comment about the power-cycle. I don't see why the cycling the power should erase the EEPROM, are you sure it was actually written correctly, can you please check that is the case? The board is powered from the Pi's 3V3 output, which has a low current limit (50mA?). I don't think that should be a problem but it might depend what else is taking current when the EEPROM writing occurs. Is the RFM12 in standby mode when writing to the EEPROM, that might help.
Delete