small bug in RHHardwareSP1I.cpp/h regarding Teensy LC

sukandar

Member
Hi,
I've found a small bug in RHHardwareSP1I.cpp/h
In order to make RadioHead work with the second SPI port on the Teensy LC I had to modify line 8 resp. 9 from

#if defined(__arm__) && defined(TEENSYDUINO) && (defined(KINETISL) || defined(__MK64FX512__) || defined(__MK66FX1M0__) )

to

#if defined(__arm__) && defined(TEENSYDUINO) && (defined(KINETISL) || defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(__MKL26Z64__) )

best,
Sukandar
 
Hi,
I've found a small bug in RHHardwareSP1I.cpp/h
In order to make RadioHead work with the second SPI port on the Teensy LC I had to modify line 8 resp. 9 from

#if defined(__arm__) && defined(TEENSYDUINO) && (defined(KINETISL) || defined(__MK64FX512__) || defined(__MK66FX1M0__) )

to

#if defined(__arm__) && defined(TEENSYDUINO) && (defined(KINETISL) || defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(__MKL26Z64__) )

best,
Sukandar
Not sure why you would need to change this?
The define for: KINETISL
Is defined when a Teensy LC is used.
 
interesting
well, I got this error message before I made the modification:

/var/folders/5_/smbzv34x2ln1_tkxw_2qgzc80000gn/T/arduino_build_769466/sketch/BasicRX.ino.cpp.o: In function `_GLOBAL__sub_I_rf95':
/Users/glui/Proj/musiClock/MKII/Arduino/BasicRX/BasicRX.ino:105: undefined reference to `hardware_spi1'
collect2: error: ld returned 1 exit status
Error compiling for board Teensy LC.
 
fwiw, if I put these lines in my sketch I get an error message

#ifdef KINETISL
not a valid statement
#endif

However, if I put them in RHHardwareSP1I.cpp I don't
 
fwiw, if I put these lines in my sketch I get an error message

#ifdef KINETISL
not a valid statement
#endif

However, if I put them in RHHardwareSP1I.cpp I don't

That is due to the fact that Arduino processes the .ino/.pde files to add forward references (and any other processing it does), and it doesn't understand #ifdef. Files in the library with .cpp suffix, are just passed straight to the compiler without doing pre-processing.
 
That is due to the fact that Arduino processes the .ino/.pde files to add forward references (and any other processing it does), and it doesn't understand #ifdef. Files in the library with .cpp suffix, are just passed straight to the compiler without doing pre-processing.

I don't get that.
If I put these lines into my sketch it does not throw an error message

#ifdef SCOOBYDOO
not a valid statement
#endif

Likewise there's a ton of files inside the Arduino package as well as my installed libraries that are full of #ifdefs
 
I don't get that.
If I put these lines into my sketch it does not throw an error message

#ifdef SCOOBYDOO
not a valid statement
#endif

Likewise there's a ton of files inside the Arduino package as well as my installed libraries that are full of #ifdefs

read careful Michael's statement
he says ONLY the '*.ino' preprocessor does not understand the #ifdefs, The c/cpp compiled DOES understand #ifdefs
 
read careful Michael's statement
he says ONLY the '*.ino' preprocessor does not understand the #ifdefs, The c/cpp compiled DOES understand #ifdefs

he wrote "Files in the library with .cpp suffix, are just passed straight to the compiler without doing pre-processing."
So to me "without doing pre-processing" means that directives like #ifdef are ignored.

Also, if my .ino sketch can't handle #ifdefs how come there's no error message for the example I've given?

Again, this (in my .ino sketch) throws an error message

#define SCOOBYDOO
#ifdef SCOOBYDOO
not a valid statement
#endif

This doesn't

#ifdef SCOOBYDOO
not a valid statement
#endif

How is that possible if #ifdefs are ignored?
 
because the #ifdefs in c/c++ files are are handled by the c/c++ compiler.
(just passed straight to the compiler)

The ino files are pre-processed by Arduino and converted to a c++ file.

This process is useful for beginners but may generate problem with complicated files.
For this reason my ino files are empty and my program is in a cpp file, obviously with proper #include statements and declaration sequence
 
Pre-processor fundamentals aside, the real issue to me seems to be why KINETISL is not defined when it comes to pre-processing RHHardwareSP1I.cpp
 
Pre-processor fundamentals aside, the real issue to me seems to be why KINETISL is not defined when it comes to pre-processing RHHardwareSP1I.cpp

yes,
I assume you have the latest libraries and only one installation, right?
 
yes,
I assume you have the latest libraries and only one installation, right?

I just noticed that the filenames are kinda weird

higgs:RadioHead glui$ ls -l RHH*
-rw-r--r--@ 1 glui staff 4418 Nov 14 19:59 RHHardwareSP12.cpp
-rw-r--r--@ 1 glui staff 4492 Nov 15 14:31 RHHardwareSP1I.cpp
-rw-r--r-- 1 glui staff 10302 Nov 14 19:59 RHHardwareSPI.cpp
-rw-r--r-- 1 glui staff 2819 Nov 14 19:59 RHHardwareSPI.h
-rw-r--r--@ 1 glui staff 3050 Nov 14 20:15 RHHardwareSPI1.h
-rw-r--r-- 1 glui staff 2997 Nov 14 19:59 RHHardwareSPI2.h
higgs:RadioHead glui$


shoudn't that be RHHardwareSPI1.cpp and RHHardwareSPI2.cpp ?

That's from a fresh Arduino 1.8.5 patched with Teensyduino 1.40
 
OK,
I have no radio available but I tried the following

-open fresh empty sketch
-set board to Teensy LC
-include manager to include radiohead library
-verify
and got following error
Code:
 #error ("RadioHead SPI2 only supported on Teensy 3.5, 3.6")
I understand this error and it makes sense in the first moment
but it indicates also that the RadioRead library is simply written badly.
it should not generate a compile error when file is present but CPU is not the right one.
Consequently I would be not surprised that there are other issues with that library.
so I gave up.

IMO, the file naming should not make a difference, the include files and function names count
 
Hi WMXZ...

Yep - The include library should not include those two header files. They were a HACK to allow other SPI ports.
The HardwareSPI.h corresponds to using SPI, HardwareSPI1.h is a copy of it with SPI1... Likewise for SPI2

Yes that part is not as clean as it could be, but did work... Again part of the testing of the 3.5/6 in beta... Probably could clean up some. Never tested using the include manager, which creates a semi nonsense. That is it includes the header files of ever RadioType it supports, which is very unlikely to work.
 
Back
Top