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

Thread: Teensy 3.5 sd logging HELP!

  1. #1
    Junior Member
    Join Date
    Feb 2018
    Posts
    2

    Teensy 3.5 sd logging HELP!

    I'm using the Teensy 3.5 with a very popular project called Speeduino. Works very well. I wanted to implement the sd card slot for data logging the real time variables while the engine is running. I've got the sd card slot working and writing. But when it writes to the sd card all the other functions that are running, tach input, coil outputs, injectors and so on, flicker as if they are being interrupted. I'm not the best programmer in the world. That's why I chose the Arduino platform for this. But something is just not working right. I can post the code if needed. But there is a lot of it. LOL.

  2. #2
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,646
    The easy answer for me is to suggest to move all the polling in the 1000+ lines of loop() into timed interrupts and keep only disk operation in the loop().
    As I have no understanding what this speeduino requires as timing, I cannot say more.

  3. #3
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,719
    SD cards contain their own micro controller, so have a tendancy to halt writing while they shuffle stuff around to wear balance. So you always have to design for semi random latency in your SD card reads. as WMXZ says the right answer is to have all other timing critical functions interrupt capable and write logs to a RAM buffer and leave a low prority SD card write function to dump data from the buffer to SD card and let the other functions interupt it as needed.

    You may be able to get close enough without refactoring all the code by doing things like:
    Looking at the logging process and makeing sure you write in efficiently sized blocks
    Making sure no overhead with the SD card is happening (reading files system etc)
    Make sure you are using the Teensyduino SD card library if you are using the internal SD card
    Check if the SD card library is blocking interrupts, and if it will work (slowly) without them

    Ugly hack option is to add another micro controller and keep your primary doing all the real time stuff that gets expensive if it hangs up and move all the less critical stuff off to the other CPU where a slight pause does not impact anything mechanical. Primary streams system state via serial, and takes a fixed format input message packet for any user input/adjustment that is smaller than the hardware buffer.

  4. #4
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,646
    Quote Originally Posted by GremlinWrangler View Post
    Ugly hack option is to add another micro controller and keep your primary doing all the real time stuff that gets expensive if it hangs up and move all the less critical stuff off to the other CPU where a slight pause does not impact anything mechanical. Primary streams system state via serial, and takes a fixed format input message packet for any user input/adjustment that is smaller than the hardware buffer.
    Well, I would not call this Ugly, but Smart (Divide and Conquer). One thing I learned in RT DAQ, never-ever mix data acquisition with display and logging. Only if multiple CPU architecture gets too complicated or too slow use SW.
    [Rant]I know someone some time ago said on this forum, why using HW if you can do it in SW. I would replay, why should SW always solve poor or faulty HW design? [\Rant]

  5. #5
    Definately not Ugly. Standard practice in Motorsport and Automotive industry - one controller for engine, one for gearbox, one for dash/instruments, one for logging.

    All core ECU functions are timing-critical, an SD card can occasionally easily take 100ms to write. ECU's use non-volatile Flash for internal logging, and cables or bluetooth for log download.

    You do not need 32GB. My 1000 off-the-shelf ECU has 2Mb which is enough to debug short periods at high speed, or long periods at slower speeds. I would look for the fastest largest serial FRAM and write little and often

    You could implement a 'copy to SD' at initial start-up or even better during a controlled power-down, if you want the flexibilty that removable storage gives.

    Best solution is for 'debug' logs to flash with critial high speed error flags (ie engine speed, load, Crank sync, cam sync) and stream out 'normal' logs on RS232 or Can Bus. You can then log the RS232 or Can bus with a dedicated home-made or Industry standard off-the-shelf logger.

  6. #6
    Had a quick glance at Speeduino Project.
    Looks like you have Canbus already implemented.
    I would use the teensy 3.6, (ignoring 5v tolerance issues that might need to be addressed) as it has dual Can. Then build a datalogger with another T3.6. You can then allocate a big buffer to most of the RAM and log at ~14000 CanBus messages a second (7000 from each bus if @ 1Mbaud) without having to worry about a misfire caused by a bad SD card.

Posting Permissions

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