Question on avr_emulation.h for RFM22 lib replacement RadioHead

Status
Not open for further replies.
S

stevech

Well-known member
I'm working to get the replacement for the RF22 library working.

The replacement is called RadioHead (see http://www.airspayce.com/mikem/arduino/RadioHead).
It supports radios other than just the RFM22, including other RFM22-alikes such as from Dorji, and the RFM69, and other radios. For platforms such as AVR-Arduino families, Uno, Leonardo, Yun, Maple, Flymaple, MPS340, and Teensy2,3. RF22 works well on Teensy.

RadioHead for Teensy 3 is what I'm working to test/validate, first with some RF22's in a star network. Then RFM69's.

What I am stuck on: How does a T3 compilation where SPI.h is used in conjunction with avr_emulation.h. This permits SPI I/O code for an AVR to run without change on the Teensy 3. Again, this works fine for the RF22 lib, but not so yet for the RadioHead lib, due to avr_emulation.h classes' operator overloads not being applied in the new library. This is a very clever set of classes/code but hard to grasp (for me).

In the new library, there's something simple and subtle missing in the inheritances from the generic driver on to it's derived classes for SPI and the the radio interface which is also generic with virtual methods so it's easy to swap out a radio driver and leave the protocol stack unaffected. (the stack includes optional datagram, reliable datagram, router, mesh router, etc.)

thanks in advance.
 
Last edited:
I have narrowed this problem to the following:
I have RadioHead compiling without error for RH_ReliableDatagram uses.
As you know, RadioHead is a new organization of the RF22 library and I/you are probably the first to try this new version. Mike, the author in the UK, doesn't have a Teensy3, plus he's away this week.

I had earlier told Paul about the compiler errors for the On/off keying module RH_ASK.cpp ... because it too was somthing subtle. Perhaps same root cause as below...
If you don't need On/Off keying for now, just remove that folder from the library.

In trying to get RadioHead to compile for my test program of Reliable Datagrams among 4 nodes - that runs OK with the RF22 lib. I have no compiler errors but something's wrong in the ARM setup code because the following code traps with an exception when accessing a CPU register. This code is from avr_emulation.cpp for SPI where Paul's amazing classes with operator overloading makes AVR SPI and GPIO code run without changes, on the ARM. Here's the line of code of which I speak:
Code: 
		if ((val & (1<<DORD)) && (SPI0_CTAR0 & SPI_CTAR_LSBFE)) ret |= (1<<DORD);
at line 935 of avr_emulation.h
When the operator overload for "SPCR &" runs in SPI.cpp, this line of code runs, and the access to SPI0_CTAR0 is trapping. Something esoteric about the initialization being done differently by RadioHead than RF22.

(Note: I double-posted this same commentary in the thread where a user was on the same track as me but a day or two behind me. This is at
http://forum.pjrc.com/threads/25606...-TIMER1_COMPA_vect-not-declared-in-this-scope)
 
Last edited:
I downloaded RadioHead 1.1 and tried one of its many examples. I'm hitting a different error...

Which examples are you compiling? Are you using version 1.1, or some other copy? I can try to help, but only if I can reproduce the problem here...
 
The problem appears in the code for RadioHead as well as LowPowerLab's code.
Both have the problem that the first access to the K20's SPI0_CTAR0 causes a trap in the avr_emulation.h code for the "=" operator overload. As if that register isn't enabled.
The library routine setDataMode() is where it starts. That is used once at startup to set the same mode as is the power up default so we just commented that out and no longer do we get the trap.
I suggest that analysis of why that register would not be enabled in the address given by the CPU .h definitions is the fastest way to fix this. The specifics are in post #2 above.

You can cause this to happen using one of Mike's examples, e.g., ReliableDatagram. But just analysis of why there could be a trap on SPI0_CTAR0 access is suggested.

The ASK modules don't compile but since few of us use these, I/we simply removed those source .cpp and.h from the library for now.

With the call to setDataMode() commented out, my current problem with RadioHead is that the first interrupt from the radio on pin 0 crashes the CPU. I put an LED-on line of code in the ISR and it never gets there. The ISR vectoring isn't working right. It did, with the RF22 lib which uses similar code. It's a bit of a mess trying to follow attachInterrupt(pin, functionpointer, mode) from the library into all the ARM/AVR code.

Cheers
Steve
 
Status
Not open for further replies.
Back
Top