I am working on redesigning a pcb I did previously. The overall size is not much bigger than a nRF24L01 transiever module which is made to plug into the top of my board. It is for a wireless sensor node. Dimensions are just under 1.5 inches by 0.75 inches.
Anyways I am redesigning the board to fit an external clock source. I am looking for an external clock source (crystal, resonator, etc) that will work with the Attiny841 and not take up too much space.
I was looking at a HC49 8mhz crystal but it takes up a lot of space on the board, almost 2/3 of the width of my board. I was wondering if a oscillator or resonator (in smd form) would work. How do I which one to go with.
Riva:
Do you really need an external clock? AFAIK the Attiny841 can use its internal clock to generate 8MHz
It can. Not sure if I am missing something but I believe I am having issues getting SPI to work on the internal clock. My current wireless node board does not use an external clock, its using the internal set at 8mhz, powered by 3.3v. I have not been able to get the 841 to communicate to the nRF24L01 module. I bought a Attiny841 development board which uses an external 8mhz crystal and everything works as intended. The only difference between the 2 boards is that mine does not have the external crystal.
Is the pro mini using a resonator or a oscillator. I am going to dig around to see if I can come up with a part number. The size would be perfect.
I believe I am looking for part # CSTCE8M00G but I am not sure what to pick for the tolerance or the load capacitance. I was thinking 1% and 33pF but I really don't know what I am doing. 10pF and 33pF seem to be the most common and I am not going into production with these but 5% save like 20 cents/each.
What makes you suspect the problem is the clock source? Problems with internal clock come from it not being accurate enough, and typically impact only serial and other timing-sensitive things (like outputting pwm at an exact frequency) - and even so, the attiny841 at 3.3v is calibrated to within 2%, making it fine for serial.
Triple-check all wiring (make sure you're not getting it mixed up with the pinout of the ATTiny84).
Also, you often need additional capacitors for decoupling/filtering with the NRF24's - many of the modules don't have sufficient decoupling and when they try to transmit, the current spike puts a glitch on their power rail sufficient to hang the NRF24. A quick bit of googling will get suggestions for the capacitor values.
You did do burn bootloader first, so it's running at 8MHz not 1MHz?
DrAzzy:
What makes you suspect the problem is the clock source? Problems with internal clock come from it not being accurate enough, and typically impact only serial and other timing-sensitive things (like outputting pwm at an exact frequency) - and even so, the attiny841 at 3.3v is calibrated to within 2%, making it fine for serial.
Triple-check all wiring (make sure you're not getting it mixed up with the pinout of the ATTiny84).
Also, you often need additional capacitors for decoupling/filtering with the NRF24's - many of the modules don't have sufficient decoupling and when they try to transmit, the current spike puts a glitch on their power rail sufficient to hang the NRF24. A quick bit of googling will get suggestions for the capacitor values.
You did do burn bootloader first, so it's running at 8MHz not 1MHz?
Just a guess really. I don't know what it could be. Just figured I'd try making a board with an external clock to see if it makes a difference. Not using a bootloader. Uploading sketches via a USBtinyISP (Sparkfun AVR pocket programmer). I did select the 8mhz internal clock setting and other options through the arduino IDE and select to burn the bootloader to set the fuses before using my board for the first time. Said it was successful.
The development board I got is your Attiny841 board you have for sale on Tindie. 3.3v, external 8mhz crystal. Used jumpers from the nRF24 module to the dev board. No additional caps for the nRF24 and it worked flawlessly. Plug the nRF24 into my board, and it doesn't work. I coded in a heartbeat pulse on one of the spare digital pins just so I could check that its executing and it is. 2 second pulse on then off looks to be about 2 seconds.
I have a 0.1uF capacitor for both the attiny and the nRF24 module and a 10uF located between them both. In my final design the nRF24 module is soldered directly to my board. The 4x2 socket is just for testing. I made up a couple of these boards, some are soldered directly.
srnet:
The el-cheapo Pro Minis mostly use a reasonator.
Sparkfun's pro mini looks to use a ceramic resonator.
I have a number of these pro mini's that I got off eBay that I used initially for my wireless nodes. These worked without any problems as well but I wanted a small board that the nRF could plug into and be as compact as possible. These have the ceramic resonator as well.
Well interesting development. I decided to try burning the 8mhz internal optiboot bootloader to my board and low and behold IT WORKS!!!. That was the only other thing that was different between the development board and my board besides the crystal.
But if you go back to 8mhz internal (no bootloader) and burn bootloader, then upload via ICSP, it doesn't work?
Also, how did you upload the sketch after doing that, via serial or via ICSP?
That represents a serious defect in my core if this is reproducible... Any sketch that works with the bootloader should work without it! (and any sketch that works without the bootloader should work with it, unless it uses the WDT as an interrupt source).
I did just as you said, went back into the IDE, selected ATtiny441/841 (no bootloader), selected Chip: ATtiny841, Clock: 8 MHz (internal). Hooked up the USBtinyISP and clicked burn bootloader. Finished successfully.
Proceeded to upload my sketch via the USBtinyISP programmer. It was executing my code (heartbeat on output pin was pulsing) but it was not communicating with the nRF24.
Burned the bootloader back onto the chip, uploaded my sketch via serial, and everything was back to working as intended.
Hmmm - wait, did you completely power cycle it between the ISP upload and testing it?
If not - try it (unplug the running-sketch-but-not-working unit from all power, wait a minute or so to make sure the caps are discharged, and plug it back in.
If it does work, that means the problem was that the ISP programming process confused the NRF24. Which wouldn't be terribly surprising, since the NRF24's CS (the line you drive low to select the device) lines would be floating, and they'd be seeing piles of garbage fly by whenever CS floated low..... Solution is to add a pullup resistor on the CS line in this case.
I remove power and unplug the nRF24 whenever uploading the sketch via ISP. Have to in order to access the ICSP pins. Upload sketch, unplug programmer from board (I use Pogo pins), plug in nRF24 module and then apply power from a separate 3.3v supply capable of providing the juice the nRF24 module requires.
drummin89:
I was looking at a HC49 8mhz crystal but it takes up a lot of space on the board, almost 2/3 of the width of my board. I was wondering if a oscillator or resonator (in smd form) would work. How do I which one to go with.
Thanks!
The way to locate components is go to the website of an electronics supplier (Mouser, Element14, DigiKey, etc),
and use their parametric search facilities... Plenty of 7mmx5mm, 5mmx3mm and even smaller ones about
drummin89:
I remove power and unplug the nRF24 whenever uploading the sketch via ISP. Have to in order to access the ICSP pins. Upload sketch, unplug programmer from board (I use Pogo pins), plug in nRF24 module and then apply power from a separate 3.3v supply capable of providing the juice the nRF24 module requires.
Now this is weird!
Try putting a delay(1000) in setup before the first call that talks to the NRF24 - I'm trying to think of ways it could make a difference, and the only one I can think of is that the sketch is trying to talk to the NRF24 before it has finished booting up, and it's not ready to accept commands. And when the bootloader is present, there's a short delay on startup while the bootloader runs, before the sketch starts.
Well I tried the delay. Even put it up to 5 seconds and still was not getting any communication out of the nRF24 when uploading my sketch via ISP. Then it dawned on me. When I've been using the bootloader and uploading my sketch via serial, I was powering my board via the 3.3v FTDI basic from SparkFun because then I would enable the serial print messages. For some reason I didn't think to do this (enable the serial print messages) when not using the bootloader. So I did and this time my board was powered by the FTDI basic and everything was working just fine.
Switch to my separate 3.3v power supply and the nRF communication would stop. I feel really stupid because on my other thread, Robin2 mentioned that they had heard of issues powering the nRF modules with a buck converter. I even tried a different 3.3v power supply with the same failed result so that is what lead me to believe it was not power related. I was using the recommended caps as well located as close to the nRF port on my board as possible.
My original plan was to use a 1 cell lipo, but I wanted to be able to supply the board with a constant 3.3v across the lipos usable voltage output (3v-4.2v) so I was trying to use a 3.3v buck-boost converter. Then when it was mentioned about the power supply, on the bench I was trying to use one of those adjustable output power supplies . I just found it hard to believe both would not provide clean enough power for the nRF module, but I guess I was wrong.
Now I am looking at just powering my board with 2 AA or AAA batteries.
So I am sorry for making you question if there are issues with your core. Thank you for your help, if it wasn't for you asking these questions I probably wouldn't have thought to try what I did and still would of been getting frustrated. Now I can continue on with my project!