nRF24L01 with AtTiny861A

Other Hardware 3rd Party Boards
1

Hello,

I am using SpenceKonde's attiny core for the 861a and nRF24L01 modules with the RF24 library.

I want to get 2 nRF24L01's connected. I have done this when the nRF's are each connected to arduino Uno's. I adapted the GettingStarted code provided with the RF24 library to do this. Then, I modified that example to send button data, and potentiometer data through the nRF24's. It worked great, but I need to shrink my project, and I have a bunch of attTiny 861s. However, when I adapt my Uno code for the t861s( all I need to change are pin numbers), the nRF's don't connect to each other at all.

So, I'm going as simple as I can to establish how to use a t861 with the nRF: I wrote bare-bones code for a Uno to transmit to a 861. No extra features, the only things that happen are theUno sends a payload, then the 861 reads the payload and sends it right back to the Uno. The 861 has no serial monitor, but if I send the data back to the Uno, I could confirm that the 861 was receiving correctly.

I'm confident in my circuit. I'm a bit scared that there are no other examples of the 861 being used with the nRF24. So maybe the trick to using a t861 with an nRF24 hasn't been found. Importantly, the RF24 library does not have pin defines for the ATTINY861, as it does the t85 and 2313. I am no expert but that seemed the case, and may mean this project is dead in the water. Additionally, the 861 has a USI not hardware SPI. This the MOSI/MISO pins are actually DO/DI pins. These pins definitions can change which one is MOSI/MISO. Luckily, it seems this happens when the RF24 is a slave, and that never happens for me. EDIT: Rookie mistake here, when the t861 gets programmed through ISP, it is a slave. And, the 861 pinout diagram in the datasheet shows the slave ISP connections. So, the pinout diagram's labels of MOSI and MISO is for slave mode. Thus, when my sketch used the t861 as a master, I was using the wrong pins. I permanently switched them. See post below for the second error that had me stuck.

So that has been in the back of my mind. I switch MOSI/MISO when I flash a new sketch, but it never works. Finally, I'm worried that the DO/DI defines would need to be switched in the RF24 library for that swap to work, not just at the pin header.

I cannot get the radios to give even a hint of connection when I use the 861. Hopefully, someone out there knows about this? I got in over my head :confused:

Finally, I will post a circuit if you request it. The UNO hooks up to the nRF through the ICSP header(setup worked when i used 2 Uno's) and the 861 has MISO,MOSI,SCK, CE, and CSN plugged in, as well as VCC/GND. Reason I didn't, is because the 861 doesn't have a fritzing schematic.

AtTiny861Rx.ino (2.17 KB)

UnoTX.ino (2.78 KB)

2

SPI works just fine on devices without specific SPI hardware, it just may be a tad slower in some implementations.

For forum help, you need to post a schematic along with your code embedded with code tags, not attached, so that people with mobile devices can see it. And please, no Fritzing finger paintings. A schematic done with paper and pencil is just fine.

https://forum.arduino.cc/index.php?topic=652235.0
And
https://forum.arduino.cc/index.php?topic=148850.0

3

There may be an issue specific to the 861 USI in my core - I don't have time to investigate it currently. (in other words, anythingyou can do to narrow this down is helpful, because if you wait for me, you will be waiting until the sun grows cold, since the time until I expect to be able to work on this has been increasing over time as more important issues come up faster than I can close them; to further clarify, anything that requires me to work with actual hardware is automatically deprioritized because it takes 3-5x as long to close)

4

DrAzzy:
There may be an issue specific to the 861 USI in my core - I don't have time to investigate it currently. (in other words, anythingyou can do to narrow this down is helpful, because if you wait for me, you will be waiting until the sun grows cold, since the time until I expect to be able to work on this has been increasing over time as more important issues come up faster than I can close them; to further clarify, anything that requires me to work with actual hardware is automatically deprioritized because it takes 3-5x as long to close)

Bugger. Not what I was hoping to hear but I guess thats life and you do have one too.

5

Life? What are you talking about?

I've got to get a huge PCB order placed for my Tindie store, and then get the lights in my room fixed and the trash off the floor so I can find the parts I was going to use in a new product I've got in the works!

This issue is one of 68 issues open on my cores - NOT TO MENTION the coding effort needed to extend micronucleus support to the 861 and 1634 (related to that I also need to write the script to create the ~60 configuration files needed to build all the versions of Micronucleus. And for ATTinyCore, I also need to add several new variants.... And I've got people screaming at me over the fact that the digispark USB libraries don't work right.

And there's some dumbass problem with the EEPROM configuration on the tinyAVR 0/1-series - I'm pretty sure it's actually something really stupid...

And then there's the tinyAVR 2-series coming around thanksgiving and that needs to be added to megaTinyCore. It's mostly straight-forward... exceeeept that new ADC, which makes my head spin just reading the specs, never mind the registry summary.

Plus we desperately need a new DxCore release - I've got a MASSIVE rework of the boards.txt in the works over there, including support for external clock and crystal (and with this done, mocking up support EA and DD support....

And don't forget the OPAMP library for DxCore

Life? This IS my life - there just aren't enough hours in the day to do it all....

And of course, there's this tantalizing mirage in the distance, of the code I REALLY want to write, which involves modifying some hand tuned assembly to work on the AVRxt (the post2016 parts), since it's all timing critical, but they changed the timing of sbi, cbi, push, maybe some of the ST variants? And what was it, RCALL and CALL? Or RET/RETI? One of the two - that part is easy peasy, because they all got faster... the fact that LDS gained a clock cycle, well that's a bit trickier.... But so much more fun than any of the other tasks, but I can't work on that until I get the rest of this stuff sorted.

And.... yeah, you see the problem.

So, instead of asking me to do this, I have a suggestion: Go figure out what's busted and fix it, or at least narrow it down, ideally to something where I can fix it WITHOUT having to wore any hardware up. As I said, anything that hasn't been figured out to where I don't have to do hardware work is automatically bottom priority.

First, try it in the github version, and in the 1.4.1 release. Did the changes I pushed to github version a few days ago help? Did they break other things?

Second, try it with something normal, but which also has a USI, like an ATTiny84. This goes for both github and 1.4.1 release.
Before I poked at it last weekend, I am almost certain the behavior of the USIWire library was WRONG - not that it might not have worked for some cases... but it hasn't been tested on any real hardware, so I am not going to do a release until someone tests it.... Of course if it broke something on the attiny84, then that update needs to be reverted...

Where does it work? Where doesn't it work? Does flipping the USIPP to change the pin positions fix it? Put your scope on some of those pins - is it trying to flip them or no? Read out the DDRx/PORTx registers, are th pins correctly configured or is the library missing that?

That kind of thing. If you get it to the point where you can say something like "It's busted on the 861 on all versions, but you fixed it on the 84" or "Well the 84 worked in release, but you must have busted something this weekend" that would do a great deal towards resolving this.

Another issue is that quite frankly, I haven't a CLUE which USI functionality does and doesn't work on which parts.... Basic research here would be of great use. I've been asking people for reports of what they've tried on megaTinyCore and ATTinyCore and what didn't seem to work right for MONTHS, and I might as well be talking to a postal box. I certainly have a beef with the one I used to ship my packages from - all the postal boxes around got modified so they can only take envelopes, not any sort of package (thanks DeJoy... )

6

Thanks for replies, I will do some paper drawings and get back to you-- had new developments, some problems were from me failing to read the core documentation properly, but others still persist. Will update in two days or so I expect.

7

I was doing two things wrong, both related to the USI

  1. I DID have wrong MOSI/MISO pin placement. My confusion arose because, in the 861 datasheet, there is a pinout diagram that labels PB0/PB1 as MOSI/MISO, respectively. However, this config is for when the t861 is programmed via ISP. In that mode, the t861 is a slave. Paired with an nRF24 chip, however, the t861 is the master, and you have to swap MOSI/MISO to get them on the right pins. (This is because the t861 only has a USI, not hardware SPI. Section 13 in the datasheet)

  2. Looking at that same pinout in the datasheet, you can see that there are 2x sets of USI pins. There is a DI,DO and USCK on both pins PB[0:2] and pins PA[0:2]. I had been putting the nRF24's CE and CSN pins on PA1 and PA2, and the adc pin on PA0. But I suspected they were being driven by the USI, so I moved them off those pins and suddenly it worked! I did some tests with CE/CSN, If one of them was on one of the 3 USI pins, the radios wouldn't connect. So I'm not using PA0, PA1 or PA2 anymore, for anything, just to be safe.

I was sending a plain, unchanging integer great. So I moved to implement sending a potentiometer value. In SpenceKonde's core documentation, it mentions when using analogRead() you CANNOT use the PIN_Pxn macro, but you can use the Ax pin name or ADC channel names specified in table 15-5 in the datasheet. That was another error on my part. I fixed it, and... Something new went wrong.

RX_UNO.ino (3.86 KB)

TX_861.ino (6.08 KB)

8

The sketch reads a pot value, and two button values. Using bitmath, they are combined into one packet and sent through the RF24 to an arduino UNO. The UNO puts the received data out to the Serial Monitor so I can see it. However, the sketch ONLY works when the adc is turned to 0 or 1023. At 0 or 1023, I can press one or both buttons and see on the serial monitor that the radio sent that data over correctly in real time. When the pot is turned anywhere but MAX or MIN, the serial monitor shows the values are frozen, and won't work until the pot is all the way up or down again.

The ADC itself never "freezes" and works at all times. I know because there's a led that uses PWM to light up in proportion to the potentiometer, and it works no matter where the potentiometer is, just as it should.

I think the data is "frozen" at the transmitting 861 chip. I know the nRF24 chips are both capable of working, I think that the USI somehow gets messed up when the ADC is reading non MAX or MIN values. I looked at the adc and USI chapters of the datasheet carefully, and nothing leapt out that would link them together. I hoped maybe they shared a resource and couldn't both use that resource simultaneously. Maybe that actually is the case, and I hope someone will be able to point that out.

The question becomes: Why does an ADC reading of MIN or MAX not affect the data, while an intermediate ADC reading results in failure?

Tips, ideas, troubleshooting directions are appreciated.

Wiring_and_data.jpg
Wiring_and_data.jpg2886×3793 1.94 MB

Wiring_and_data.jpg
Wiring_and_data.jpg2886×3793 1.94 MB

9

Huh! Iiinteresting!

So wait, is it running the USI on PA0:2 by default instead of PB0:2?

10

Ok. I need to ask. What is USI?

11

USI = Universal Serial Interface

Section 13 of the ATTINY861A datasheet explains all about it.

12

Of course. Brain has been asleep for weeks now.

13

The "Universal" Serial Interface... if one's interface universe consists of only SPI and I2C? (UART? Isn't that the kid from the simpsons?)

Otherwise known as "halfassed hardware interface with an almost-spi mode and almost-I2C mode" - which despite the word "halfassed" is one of the more polite ways to characterize it...

If it's running on the PORTA pins... well, then, I suppose I should figure out if I'm setting it that way or what...

14

TL;DR, plugging RF24 CE/CSN into PA1:2 means radio does not connect, while plugging them in elsewhere equals working radio connection. Reason why, unknown, but USI is suspected.

DrAzzy:
Huh! Iiinteresting!

So wait, is it running the USI on PA0:2 by default instead of PB0:2?

That could be the case, because when I had an ADC on PA0, and the nRF24's CE(chipenable)and csn(chipselectNot) pins on PA1:2, the nRF radio wasn't connecting. Then I tested just CE and just CSN on those pins, and the radio still didn't work. THen, I took both CE and CSN off those pins, (moved to PB4/5) and all of a sudden my radios connected. After that, I decided to totally abandon PA0:2 outright, even for my ADC.

I did not plug the nRF24's MOSI/MISO/SCK into PA0:2 to see if those pins could interface with a SPI device. I will try to remember to test this. (Well, I did, but that was b4 I knew to switch MOSI/MISO around(see above posts), so it should not have worked because my connections were wrong)

However, looking though the pins_arduino.h library, you DID specify portB as USI. I noticed this after I tested the above. Still, it seemed to me that PA0:2 weren't working, so the mystery stands. I superficially scanned the datasheet's USI chapter, didn't see anything mentioning the USI hogging both sets of USI pins.

Anyone following, there is a pins_arduino.h file for every type of board. The attiny861's file is in the "variants" directory, took me a bit to find, here is its path(for me) "C:\Users(USER_NAME)(ARDUINO)\portable\packages\ATTinyCore\hardware\avr\1.4.1\variants\tinyX61"

#define USI_DDR_PORT DDRB
#define USI_SCK_PORT DDRB
#define USCK_DD_PIN DDB2
#define DO_DD_PIN DDB1
#define DI_DD_PIN DDB0

define DDR_USI DDRB

define PORT_USI PORTB

define PIN_USI PINB

define PORT_USI_SDA PB0

define PORT_USI_SCL PB2

define PIN_USI_SDA PINB0

define PIN_USI_SCL PINB2

15

RockSanchez:
The sketch reads a pot value, and two button values. However, the sketch ONLY works when the adc is turned to 0 or 1023. At 0 or 1023, I can press one or both buttons and see on the serial monitor that the radio sent that button data over correctly in real time. When the pot is turned anywhere but MAX or MIN, the serial monitor shows the values are frozen, and won't work until the pot is all the way up or down again.

...

The question becomes: Why does an ADC reading of MIN or MAX not affect the data, while an intermediate ADC reading results in failure?

Do you guys know anything about this issue? Only troubleshooting I did was test voltages with multimeter on every 861 pin of the transmitter, and they always checked out for every pot position... Maybe I'll give up on troubleshooting and just throw some unworthy 861 chips into a fire, hope the silicon gods bring clean adc readings.

16

More debugging effort is needed here.

First thing I'd try is replacing the ADC reads with a constant value so you know where to look.