I have a problem with EmonTx shield v2.4. I added RFM69CW radio and followed wiki + spent whole weekend doing fault finding unsuccessfully if shield is connected to Arduino UNO - everything works fine but if connected to Arduino Leonardo it simply wonât work I have tried older version JeeLib and all sorts of pin swaps but sketch (CT1234)always hangs here ârf12_sleep(RF12_SLEEP);â. I know that easiest thing to do would be just use UNO with EmonTX shield but Iâm sort of obsessed now about it. If someone would find few minutes to help I would be very grateful.
This weekend I went even further with debugging and this is what I found:
fresh install of win7x64 and latest arduino + fresh libraries (so far all my work was done under Ubuntu) - no change
using Bus Pirate as a SPI sniffer I see that there is nothing transmitted to FRM69CW module when shield is connected to Leonardo.
in the same time when shield is connected to UNO there is a lot transmitted to RFM69CW (I donât have to understand SPI protocol - all I wanted to see is there anything going on on SPI)
I programmed Leonardo as a ArduinoISP and used Leonardo to upload sketches to UNO - that works as it should so ICSP header on Leonardo is not the problem here
I uploaded blink sketch to Leonardo and verified where pins are mapped (D14, D15, D16, D9, D10 and D3) so itâs not pins_arduino.h for Leonardo being wrong.
The only thing that is left is JeeLib.h but debugging that is beyond my skills. Itâs worth highlighting that if anyone is to follow wiki, even step by step, emontx shield will not work with Leonardo
If you wish, you could âstealâ the file ârfm.inoâ from the 3-phase PLL sketch (on Github) and try that, instead of JeeLib. It is a stripped-down version that only transmits, and it is slightly different, so youâll need to look at the 3-phase sketch itself to see the exact way to use it - youâll need to include in your sketch some pins and some definitions as well as the function calls.
Where are you picking up /CS (aka SS) for the Bus Pirate? If youâre seeing "nothing transmittedâ on the Bus Pirate, that makes me think youâre seeing no transitions on /CS.
I started with soldering cable to leg/pin 7 of the RFM69 module (NSS) there was nothing there to trigger data capture so I moved to digi10 on the shield itself - still nothing there. Re attached shield to UNO ant there was SPI transmission. So taken Lonardo back uploaded blink sketch, changed LED pin to 10 connected an LED to pin 10 just to check is the pin 10 working with different sketch and LED was blinking Of course I also have used different jumper to link leg 7 of RMF69 to digi10 on the shield (as you can choose between digi10 and digi5).
I read your question again. When I say no transmission I mean nothing is happening on either of the pins 10/14/15/16 which are (in my understanding) SPI bus pins. And this is only true for leonardo where for uno there is a lot going on on those pins.
Theyâre doing direct port/pin manipulation to drive that, and they go to some effort to calculate that based on cpu type in
// function to set chip select pin from within sketch
void rf12_set_cs (uint8_t pin) {
#if defined(__AVR_ATmega32U4__) //Arduino Leonardo
cs_pin = pin - 4; // Dig10 (PB6), Dig9 (PB5), or Dig8 (PB4)
#elif defined(__AVR_ATmega168__) || defined(__AVR_ATmega328__) || defined (__AVR_ATmega328P__) // ATmega168, ATmega328
cs_pin = pin - 8; // Dig10 (PB2), Dig9 (PB1), or Dig8 (PB0)
#endif
}
And the shield wiki tells you to edit that to do it slightly differently, although I suspect that was written when jeelib didnât handle the different cpu types. Some Serial.print()s in there to see which pin itâs actually driving should narrow it down.
What do you mean by pins 14, 15 and 16? The Uno and the Leonardo use different pins for the SPI bus, but shields can pick them up at a common place via the ICSP header.
I think the best approach would be to get your /CS (aka SS) up and running first.
Iâve tried wiki version & unmodified latest version of JeeLib.h. Iâve read somewhere that issue with CS pin itâs all sorted for mega32u4 after library update but I canât find reference at the moment.
If you check PCB:
RFM69CW
UNO
LEONARDO
MISO
D12
ICSP1 (D14)
MOSI
D11
ICSP4 (D16)
SCK
D13
ICSP3 (D15)
SEL (SS) can be connected (by jumper) to D10 or D5
IRQ can be connected (by jumper) to D3 or D2
MISO/MOSI/SCK are connected on PCB with D12/D11/D13 so shield would work on both UNO and Leonardo.
Work out why thatâs not driving the pin you want it to drive (I think you said you confirmed that thereâs no activity on /CS with the Leonardo?).
bitClear() and bitSet() are pretty fundamental operations so they must be changing some pin (or thereâs a conflict on the pin that prevents it from changing). With your logic analyser and some Serial.prints to determine the value of SS_PORT and cs_pin it should be pretty easy to get to the bottom of it.
I started this thread in hope that there is something simple that Iâm missing. I spent a lot of time debugging without any success. In the same time I have learnt a lot but that wasnât my original target Thank you for all help and support but I cannot spend any more time on something that should work anyway I wanted to leave something in writing if someone else will run into similar problems in future. My guess is that at some point JeeLib library was changed/updated and since then shield wonât work with Leonardo. My original plan is to move from my custom breadboard copies / modifications of yours great products and just standardise everything and move away from ESP8266 to RFM69 which I have never used before also get rid of raspberry PI and run emoncms on my VM. Itâs not going great at the moment but I need to have this finish before I move from my rented property to my 1st home. So please donât get me wrong but shield works with Uno so Iâll stick with that. Thanks again for your time.
I think you are right there, whilst I do not know the answer to your problem, I do recall some changes being made in JeeLib that might or might not be related.
The discussion I recall is this one from Nov '17 that questions the changes made in May '17.
That discussion seems to have led to those changes being reverted and these changes being made
Prior to that there were some earlier changes too in Feb '14 , Mar '15 and Oct '16, which pins are correct, current or compatible with the OEM emonTx shield I wouldnât like to guess, but perhaps you, or someone else reading this if itâs too late for your project, might be able to make head or tail of it.
Iâve tried all variants of the pin configuration that you mentioned above. None of them worked. There must bee more changes in the code. There also were some changes in Arduino pins configuration for mega32u4. At some point D17 was used as a SS in JeeLib.h but same pin is used for RX LED so that was quickly changed to D10. Iâm willing to donate my Leonardo to anyone who wantâs to have a go at it