Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 15 of 15

Thread: small bug in RHHardwareSP1I.cpp/h regarding Teensy LC

  1. #1
    Junior Member
    Join Date
    Jan 2013
    Posts
    13

    small bug in RHHardwareSP1I.cpp/h regarding Teensy LC

    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

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,653
    Quote Originally Posted by sukandar View Post
    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.

  3. #3
    Junior Member
    Join Date
    Jan 2013
    Posts
    13
    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.

  4. #4
    Junior Member
    Join Date
    Jan 2013
    Posts
    13
    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

  5. #5
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,786
    Quote Originally Posted by sukandar View Post
    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.

  6. #6
    Junior Member
    Join Date
    Jan 2013
    Posts
    13
    Quote Originally Posted by MichaelMeissner View Post
    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

  7. #7
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,878
    Quote Originally Posted by sukandar View Post
    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

  8. #8
    Junior Member
    Join Date
    Jan 2013
    Posts
    13
    Quote Originally Posted by WMXZ View Post
    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?

  9. #9
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,878
    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

  10. #10
    Junior Member
    Join Date
    Jan 2013
    Posts
    13
    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

  11. #11
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,878
    Quote Originally Posted by sukandar View Post
    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?

  12. #12
    Junior Member
    Join Date
    Jan 2013
    Posts
    13
    Quote Originally Posted by WMXZ View Post
    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

  13. #13
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,878
    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

  14. #14
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,653
    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.

  15. #15
    Junior Member
    Join Date
    Jan 2013
    Posts
    13
    OK, well then I guess I'm glad that I got it working with my little "fix"
    Thanks for all your efforts

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •