A couple of years ago I ordered 4 of those boards for $10.40, that's $2.60 each, and now they cost $0.81...
Wednesday, September 9, 2015
How do they do it?
Just got some more parts in the mail:
10 nRF24L01+ boards for a whopping $8.12 and free shipping. Seriously, how do they do it and make a profit? I wouldn't be able to send an empty envelope to China for that kind of money...
A couple of years ago I ordered 4 of those boards for $10.40, that's $2.60 each, and now they cost $0.81...
A couple of years ago I ordered 4 of those boards for $10.40, that's $2.60 each, and now they cost $0.81...
Tuesday, September 1, 2015
First prototyping board assembled!
Got the last pin headers in the mail today!
It's annoying that I still have to rely on wires for this to work properly, but that's the price I pay for not double checking the footprints. The next version (almost done) will have a nice socket header to plug the nRF in.
Monday, August 31, 2015
Colorful pin headers
White pins are signal pins, connecting directly to the Nano. Red pins connect to the 5V rail. Yellow to the 3.3V rail. Black pins are ground. Blue pins connect directly to the nRF and turquoise-ish pins are used for whatever is left. Hopefully this will mistakes during wiring. The remaining four rows of connections will receive a 15 pin female header. The inner two rows receive the Nano, while the outer two rows can be used to connect jumper wires. The three large holes were supposed to hold a DC jack connector.
Friday, August 28, 2015
Arduino Nano + nRF24L01+ prototyping board and epic FAIL
I've been working on a prototyping board to connect the Arduino Nano and nRF24L01+ reliably. Bad breadboards and clumsy jumper wires have caused me a fair share of headaches and lost hours already, so I wanted something easy to use and reusable. So I designed a small prototyping board that will do just that, and a bit more.
The board not only connects the two devices, but it also breaks out all of the Arduino's pins, and adds ground and 5V pins next to those as well. So micro servos and three wire analog sensors can be connected directly to the board.
The board also lets you choose to which pin you want to connect the CS and CE pins of the nRF, although the choice is limited to digital pins 4-9. The IRQ pin can be connected to digital pin 2 or 3. And last, but certainly not least, the board has various SPI pin multiplexing options aboard which can be selected. It puts both Nerd Ralph's two wire and three wire solution at your disposal to experiment with :)
Today the first few boards arrived from OSH Park and they look gorgeous.
And the bottom features some nice schematics which explain the multiplexing options:
Nearly all the parts needed to assemble the boards have arrived as well. Of course I couldn't wait and stuck in a Nano to see how it looks.
Pretty neat eh? But. Wait. What? Noooooooooooooooooooooo. I messed up the footprint of the Nano :( I accidentally swapped the rows of pins. Now I need to stick the Nano in the back of the board...
See how the power pins align correctly now?
FAIL
If only I had messed up the nRF footprint as well :( Good thing I only ordered three and not a dozen. Oh well, back to the drawing board. Looks like I'll probably have to layout the entire board again...
I'm really happy with the quality of the boards by the way, the silkscreen is aligned perfectly and the purple board with gold finish looks wonderful. I was a bit worried that the small text would be impossible to read, but it turned out fine.
The board not only connects the two devices, but it also breaks out all of the Arduino's pins, and adds ground and 5V pins next to those as well. So micro servos and three wire analog sensors can be connected directly to the board.
The board also lets you choose to which pin you want to connect the CS and CE pins of the nRF, although the choice is limited to digital pins 4-9. The IRQ pin can be connected to digital pin 2 or 3. And last, but certainly not least, the board has various SPI pin multiplexing options aboard which can be selected. It puts both Nerd Ralph's two wire and three wire solution at your disposal to experiment with :)
Today the first few boards arrived from OSH Park and they look gorgeous.
And the bottom features some nice schematics which explain the multiplexing options:
Nearly all the parts needed to assemble the boards have arrived as well. Of course I couldn't wait and stuck in a Nano to see how it looks.
FAIL
If only I had messed up the nRF footprint as well :( Good thing I only ordered three and not a dozen. Oh well, back to the drawing board. Looks like I'll probably have to layout the entire board again...
I'm really happy with the quality of the boards by the way, the silkscreen is aligned perfectly and the purple board with gold finish looks wonderful. I was a bit worried that the small text would be impossible to read, but it turned out fine.
Thursday, August 27, 2015
AVR Watchdog timer and Arduino Nano issues
In the past couple of day's I've tried to get the watchdog timer on my Arduino Nano to work properly. With success, eventually, but it took some time.
The watchdog timer is a stand alone timer, available in pretty much every 8 bit AVR, that has its own low power, low precision oscillator (clock) and it runs at about 128 KHz, give or take 10%. The watchdog timer can generate a reset signal after a set amount of time, ranging from 16 milliseconds to 8 seconds. You can reset the watchdog timer from your code using a special instruction ("wdr"). The idea behind this is that when your code gets stuck in a loop, or takes too long to execute for various reasons, the micro controller will reset itself, without needing any human interaction.
The watchdog timer in the more recent AVR microcontrollers (including the ones in the Arduini Nano/Uno) have the ability to generate an interrupt instead of resetting the device. Or to generate an interrupt before resetting the device, giving you a chance to store some valuable parameters.This also means you can use the watchdog timer to wake the AVR from idle/standby/power-down mode, perfect for low power applications! Let's look at the datasheet of the ATtiny13A for a second, chapter 7.1, sleep modes:
There are two sleep modes we're interested in here, the idle mode and power-down mode. The first mode has a lot of ways to wake up from, but also keeps the main clock running, meaning more power is used. The latter mode shuts down nearly everything, but can only be woken up from using an external interrupt or the watchdog timer. Now let's have a look at the supply current. Let's assume we're using the 9.8 MHz internal oscillator as clock source and use a 3.3V supply. That's chapter 19.2:
So we're looking at a bit over 2.5 milliAmps at room temperature. Not bad at all, but too much. That's what we'd be looking at if we'd just use a loop and count sheep until we had something to do again. The idle mode is a bit better, chapter 19.3:
About 0.65 milliAmps, that's a major improvement over just burning clockcycles. We'd have to use a timer to wake up though, adding about 0.1 milliAmp (chapter 19.1). Let's look at the power-down mode with watchdog timer enabled, chapter 19.4:
A bit over 4 microAmps, yes, that's MICRO amps. So in power down mode we're drawing less than 1% of the current we'd be drawing in idle mode, that's definitely worth using.
But programming an ATtiny can be a pain. To be more specific: testing and debugging can be a major pain. There's no serial port on those devices, and there are usually no spare pins left anyway. That is why I usually write and test my code with an Arduino before testing it on an ATtiny.
As with any part of the AVR I never used before, I started out simple: set up the watchdog to generate an interrupt every four seconds and toggle the LED pin on the Arduino. That worked, sort of. After four seconds the LED came on, and then turned off, and on, and off, and on, about ten times per second... What's even more annoying is that I couldn't upload any new code while it was doing that. I'd have to pull the USB cable out and plug it back in right before the new code would be uploaded. I double checked and triple checked my code, tried various stuff but couldn't get this simple bit of code to work properly. Finally I started to expect something was wrong with the fuse setting on the AVR, but the Arduino wouldn't let me read or write the fuse bits.
So after a bit of googling I found out I wasn't the only one having this problem. Apparently the fuses on the Nano have been set to always reset on a watchdog timer overflow. And to make matters worse: the bootloader doesn't handle a reset caused by the watchdog timer properly.
The solution (to both problems) is to burn the optiboot bootloader (used by the Uno) to the Nano. For this you'll need a second Arduino, in my case a Mega2560. You'll need to write the sketch "ArduinoIsp" to that Arduino.
Keep it plugged in, it will now act like a programmer. Next you'll need to wire the Nano to your programmer Arduino as described here. Now select the "Arduino as ISP" as programmer.
As target board, select "Arduino Uno", this will make sure the optiboot boatloader and correct fuse settings will be burned.
Finally, select "Burn Bootloader". It will burn the optiboot bootloader to the Nano and set the correct fuses!
Now disconnect the programmer Arduino, plug the Nano back in, and set the programmer setting back to "AVRISP mkII". Your board will now look like an Arduino Uno to the IDE, so remember to select that as board whenever you send a sketch to it.
As a side effect, code is now uploaded twice as fast. Yay! Oh, and the watchdog timer now works correctly: the LED now turns on and off every four seconds :)
The watchdog timer is a stand alone timer, available in pretty much every 8 bit AVR, that has its own low power, low precision oscillator (clock) and it runs at about 128 KHz, give or take 10%. The watchdog timer can generate a reset signal after a set amount of time, ranging from 16 milliseconds to 8 seconds. You can reset the watchdog timer from your code using a special instruction ("wdr"). The idea behind this is that when your code gets stuck in a loop, or takes too long to execute for various reasons, the micro controller will reset itself, without needing any human interaction.
The watchdog timer in the more recent AVR microcontrollers (including the ones in the Arduini Nano/Uno) have the ability to generate an interrupt instead of resetting the device. Or to generate an interrupt before resetting the device, giving you a chance to store some valuable parameters.This also means you can use the watchdog timer to wake the AVR from idle/standby/power-down mode, perfect for low power applications! Let's look at the datasheet of the ATtiny13A for a second, chapter 7.1, sleep modes:
But programming an ATtiny can be a pain. To be more specific: testing and debugging can be a major pain. There's no serial port on those devices, and there are usually no spare pins left anyway. That is why I usually write and test my code with an Arduino before testing it on an ATtiny.
As with any part of the AVR I never used before, I started out simple: set up the watchdog to generate an interrupt every four seconds and toggle the LED pin on the Arduino. That worked, sort of. After four seconds the LED came on, and then turned off, and on, and off, and on, about ten times per second... What's even more annoying is that I couldn't upload any new code while it was doing that. I'd have to pull the USB cable out and plug it back in right before the new code would be uploaded. I double checked and triple checked my code, tried various stuff but couldn't get this simple bit of code to work properly. Finally I started to expect something was wrong with the fuse setting on the AVR, but the Arduino wouldn't let me read or write the fuse bits.
So after a bit of googling I found out I wasn't the only one having this problem. Apparently the fuses on the Nano have been set to always reset on a watchdog timer overflow. And to make matters worse: the bootloader doesn't handle a reset caused by the watchdog timer properly.
The solution (to both problems) is to burn the optiboot bootloader (used by the Uno) to the Nano. For this you'll need a second Arduino, in my case a Mega2560. You'll need to write the sketch "ArduinoIsp" to that Arduino.
Keep it plugged in, it will now act like a programmer. Next you'll need to wire the Nano to your programmer Arduino as described here. Now select the "Arduino as ISP" as programmer.
As target board, select "Arduino Uno", this will make sure the optiboot boatloader and correct fuse settings will be burned.
Finally, select "Burn Bootloader". It will burn the optiboot bootloader to the Nano and set the correct fuses!
As a side effect, code is now uploaded twice as fast. Yay! Oh, and the watchdog timer now works correctly: the LED now turns on and off every four seconds :)
Wednesday, August 19, 2015
I love OSH Park
This evening I ordered a board I designed at OSH Park. A few hours later I received the following E-mail:
Hi! We had some free room on one of our Super Swift Service panels,*does a little dance* (using super swift service usually costs $89)
so we took the opportunity to give you an upgrade.
Your affected orders are:
* xxxXXXXX - xxxxxxxxxxxxxxxxxxxxxx
The Super Swift Service drops your expected fabrication time from 12
calendar days to just 5 business days. The same fabs manufacture the
Super Swift panels as our normal panels, so you can expect the same
excellent quality.
Only fabrication time is affected, so the shipping times and method will
remain the same.
Thanks for using OSH Park!
Sunday, August 16, 2015
Sensor module - shrinking
After finishing the initial design for the wireless sensor modules I realized the placement of the connectors was far from optimal. Having the sensor connector in the middle of the board would mean I wouldn't be able to attach a socket and stick a sensor right in; I'd rather have the sensor connector on a far end of the board.
I also wanted the nRF module to stack onto the board, but as it turned out, I had placed the connector upside down, so the nRF module would stick out instead of hang over the board. So time for revision 2!
I decided to place the ICSP header on the side of the board, just like the USBASP dongles. A few components have moved to the back of the board, including the 3.3V regulator and pull down resistor for the sensor. All in all the board has shrunk about 20% in length, lowering the cost even further, although adding a shrouded connector offsets that saving... Total component cost is now down to less than $2 excluding the sensor and nRF module.
Meanwhile I've started programming some bits and pieces, trying out a few new techniques to keep the memory footprint to an absolute minimum. It's going to be a challenge to fit everything in 1 KiB of ROM (just 512 instructions). Interestingly enough, the code is a mix of assembler and C++ templates.
Subscribe to:
Posts (Atom)