Gas station without pumps

2015 August 16

Teensy LC support for PteroDAQ working

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 09:08
Tags: , , , ,

Despite what I claimed in Teensy LC support for PteroDAQ written but not tested, adding support for the Teensy LC board to the PteroDAQ data acquisition system also took a day of effort, not just a couple of hours.  The board arrived in Saturday’s mail, so I tested the code immediately. My initial attempt did not work, and debugging took an embarrassingly long time.

The first problem was that the KL25Z code had used the SysTick timer to do the interrupts for the periodic sampling, but the Teensyduino usb_serial code uses the SysTick timer for other timing purposes (it uses SysTick as a timestamp).  On the Teensy 3.1, I’d used one PIT (periodic interrupt timer) for the periodic sampling, and two others for keeping a high-resolution timestamp, but the Teensy LC does not have that many PITs.

I ended up using the LPTMR (low-power timer) for the sampling frequency, which gives a wide range of frequencies with the precaler (allowing a very long sample period of 268s).  Unfortunately, the LPTMR is only a 16-bit counter, so the resolution of frequency is not great—about 15ppm at low frequencies (with counter values between 32k and 64k), and period step sizes of 62.5nsec at sampling frequencies above 244Hz.  I can’t hit 60Hz exactly, but the 10ppm that it is off is less than the error of the crystal oscillator and far less than the error of the line frequency of the power lines.

Getting the LPTMR to work correctly took a long time, mainly because of spelling errors (sometimes the name needed is LPTMR, sometimes LPTIMER, sometimes LPTMR0).  The inconsistency seems to come mainly from the kinetis.h file provided in the Teensyduino code.

The SysTick timer we used on FRDM KL25Z implementation is a 24-bit counter running at 48MHz, so it has a resolution of  20.83 nsec for frequencies above 0.35Hz, and 333nsec at lower frequencies. The Arduino implementations use the same timer for both timestamps or periodic interrupts (which I could also have done on the Teensy LC, using the same pair of PITs for either) since the timestamps are not used directly with periodic interrupts.

I looked at the size of the different implementations of the firmware for PteroDAQ with the current implementations as well as the longest sampling periods:

board bytes longest period
Teensy 3.1 12,536 119.3046 s
Teensy LC 12,632 268.4355 s
FRDM KL25Z 26.6k 5.592405 s
Arduino Leonardo 9,908 4.194240 s
Arduino Uno 7,350 4.194240 s

The Teensy 3.1 implementation could easily be modified to get ridiculously long sample times, as there is a spare 32-bit PIT to get times up to 512Gs (over 16000 years) with a resolution of 27.8ns, but the other implementations would be harder to change.  Using the 2-PIT approach on the Teensy LC or the FRDM KL25Z could easily get up to 384Gs, with a resolution of 41.7ns.

I think I may switch all the ARM boards over to using 2 PITs for timing, for both the timestamps and for the periodic interrupts, as this seems to provide the best tradeoffs of period and resolution.

 

2015 August 13

Teensy LC support for PteroDAQ written but not tested

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 19:29
Tags: , , , ,

Adding the Teensy 3.1 board to the PteroDAQ data acquisition system only took a day of effort (see PteroDAQ supports Teensy 3.1), extending that support to the Teensy LC, took only a couple of hours, since it just meant adding another board description to boards.py and merging the KL25Z and Teensy 3.1 code that was already written.

The Teensy LC board I ordered from the PJRC store) has been shipped, but probably won’t arrive until Monday, so I’ve not been able to test the code yet.

I looked at the size of the different implementations of the firmware for PteroDAQ with the current implementations:

board bytes
Teensy 3.1 12,528
Teensy LC 12,544
FRDM KL25Z 26.6k
Arduino Leonardo 9,840
Arduino Uno 7,310

The MBED USB stack used for the FRDM KL25Z board seems to bloat the code there enormously, but even the Teensy code seems a bit bloated compared to the Arduino code (which is already much more bloated than really needed).

If the Teensy LC code works (and I see no reason it shouldn’t, after tiny amounts of debugging to remove any bugs that the compiler hasn’t already caught), I’ll probably look into using the Teensyduino setup for programming the FRDM KL25Z board also.  If I can get that to work, I’ll probably give up on the MBED toolchain entirely—their software is way too deeply layered with way too many dependencies.  It looks like it was developed by computer scientists who drank too much of the “layered abstraction” kool-aid.

The biggest problem with the Teensyduino environment for developing for the FRDM KL25Z is that they’ve not set up any of the macros for the KL25Z, which is almost (but not quite) identical to the KL26Z that they have set up.  I do have a FRDM KL26Z board, though, so maybe I should develop for that.  The difficult parts will be

  • Setting up macros that allow different compilation for FRDM KL26Z and Teensy LC, even though both are using KL26Z processors.  I can probably handle that with a new entry in the boards.txt file.
  • Setting up the download using the MBED downloader on the FRDM KL26Z board rather than the Teensy loader. I’m not sure that the Arduino environment provides any way to set up a download as “create a bin format file and write to fake flash drive”.  Even just getting the bin file created and put in an easy-to-find place may be difficult without manual intervention.

Since the Teensyduino development is supported by the sale of Teensy boards, it is unlikely that Teesyduino will ever be officially extended to support the boards sold by Freescale.

2015 August 11

PteroDAQ will support Teensy LC

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 07:49
Tags: , , , ,

Adding the Teensy 3.1 board to the PteroDAQ data acquisition system only took a day of effort (see PteroDAQ supports Teensy 3.1), and it looks fairly straightforward to extend that support to the Teensy LC, which at $11.65 looks like the cheapest ARM development board available.  The KL26Z chip on the Teensy LC is very similar in its capabilities to the KL25Z chip on the FRDM KL25Z boards that I’ve been using with PteroDAQ for the last couple of years, though the Teensy LC uses one with less RAM, so the boards may be more limited in handling bursts of high sampling rate.

I just ordered a Teensy LC board this morning (direct from the PJRC store) and will probably do the coding and testing for the board this weekend.  I’m now leaning towards using the Teensy LC for the class, as it will provide a lower-cost option than the FRDM KL25Z boards, especially once the cost of headers is included (we can use the Teensy LC with mostly male headers and just a couple of small female headers, which cuts about $2/board off the price of the headers).  The maximum sampling rate will be a little lower than on the Teensy 3.1, but PteroDAQ is currently more limited by the ability of the laptop to accept the data than by the board’s ability to generate it.

If I can figure out a good way to get the Teensyduino code onto a FRDM KL26Z board, I might be able to do some debugging even before the Teensy LC arrives, because I have a FRDM KL26Z board that I bought some time ago but never used.  The Teensyduino uses the GCC ARM compiler, so I think all I’ll need to do is figure out where all the compilers, linkers, and format conversion routines are kept, and all the flags that get passed to them, and I should be able to get things in the right format for the MBED download firmware on the KL26Z board.  Running the Arduino IDE with “verbose” output should provide all this information.

All the Teensy boards have their schematics online, so the pin mapping can be set up now.  I’ll have to merge some of the code we wrote for the Teensy 3.1 and for the FRDM KL25Z boards to get the rest, after checking to see what registers are different between the KL25Z and the KL26Z. All the analog-to-digital conversion and timing is being done with bare-metal manipulation of the peripheral registers, to avoid the overhead of the APIs of the MBED, Arduino, or Teensyduino systems.

I think that we may end up reusing (or modifying) the usb-serial code from the Teensy LC for the FRDM KL25Z board also, so that we can get rid of the use of MBED code.  Moving code onto and off of the MBED site is a big pain, and it would be good to have everything compilable on the laptop without needing internet access.  The MBED USB stack is about all we’re really using of the MBED code, and the Teensyduino USB stack seems to work as well (comparing Teensy 3.1 and FRDM KL25Z, which is not really a fair comparison).

2015 August 10

PteroDAQ boards

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 17:50
Tags: , , , , ,

I took a photograph this afternoon of three of the boards that can be used with the PteroDAQ data acquisition system:

On the left is the Arduino Leonardo, the slowest and most expensive of the boards here.  In the middle is the KL25Z, which I've been using in my class for a couple of years—it is the cheapest and most featureful of the boards.  On the right is the Teensy 3.1 (without headers yet), which is  the fastest and smallest of the supported boards.

On the left is the Arduino Leonardo, the slowest and most expensive of the boards here. In the middle is the KL25Z, which I’ve been using in my class for a couple of years—it is the cheapest and most featureful of the boards. On the right is the Teensy 3.1 (without headers yet), which is the fastest and smallest of the supported boards.

I’m considering switching to the Teensy 3.1 for the class, despite its higher price than the KL25Z board, because adding male headers to the bottom of the board makes it possible to plug the Teensy 3.1 into a bread board, which makes for more secure wiring than running separate wires to the KL25Z board.  We don’t really need the 64 pins of the KL25Z board, we’re not mounting Arduino shields, and we’re not using the accelerometer or the touch sensor, so the main question is whether it is better to have the data-acquisition board be standalone or be inserted into a bread board. The RGB light on the KL25Z board is a nice feature for providing feedback that is missing from the other boards (which only have a single-color LED).

I’ve also thought about usefulness to the students after the course, though few of the students will go on to do anything other than PteroDAQ with the boards.  The Arduino IDE is much easier to deal with for beginners than any of the development environments for the KL25Z, and Teensyduino is pretty easy to install on top of the Arduino environment.  So if students are going to go on to do hobbyist-level programming on the boards, then an Arduino board or the Teensy 3.1 might be a better choice. Given how much more powerful the Teensy 3.1 is than the old ATMega-based Arduinos, I see no reason to recommend buying Arduino boards (though clones from China have gotten down to about $3).

Erich Styger, in a comment, mentioned that he is frustrated by the Teensy’s lack of a SWD (serial wire debug) connector, which he is used to using for debugging. Since I’m from an older generation of programmers, I don’t miss it—I’ve not used the SWD connector on the KL25Z boards (though my son has, to use the OpenSDA chip as a programmer).  For me, it is a luxury to have a serial port for getting print messages from the board—I started microprocessor programming in the days when having one or two LEDs was about all the information you got back from the board. Having debuggers like GDB was a luxury available on computers that cost thousands of dollars.

Of course, the ARM processors on the Teensy 3.1 and the FRDM KL25Z boards are very much more complicated than the old 8080A, Z80, and 6800 8-bit processors I started with, and people are writing much larger programs for them, so I can see the advantage of having a debugger. But there is a large startup cost to learning to use a debugger and setting up the complicated software development tools they expect you to use, so I’m happy recommending the very limited, but easy-to-use Arduino interface for bioengineering students who want to go a bit further.

I’m curious what my readers think about the choice between a FRDM KL25Z board and a Teensy 3.1 board for the Applied Electronics class, given that most of the students will only use the boards for that class.  What tradeoffs might I have missed?  If you were in the class, which board would you rather work with?

PteroDAQ supports Teensy 3.1

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 00:25
Tags: , , , ,

In one day my son and I added support for the Teensy 3.1 board to the PteroDAQ data acquisition system that previously supported the Freedom KL25Z board and the ATMega-based Arduino boards.

We ended up using the Teensyduino development system, but really only for the downloading and for the usb-serial library, since the K20 ARM chip on the Teensy 3.1 is quite similar to the KL25 that we originally based things on.

The Teensy 3.1 is a lot easier to install the software on than the Freedom boards, and runs a little faster (72MHz instead of 48MHz), but has essentially the same ADC.  Actually, it has 2 analog-to-digital converters, but most of the pins can only be read by ADC0, so we’ve not set up ADC1 to read anything but the internal 1.2V Vref (which is conveniently provided as an output on the AREF pin).  We had originally planned to use just ADC0, but the code for reading the Vref signal on ADC0 never worked—I suspect an error in the reference manual, since changing to reading Vref with ADC1 worked fine.

The Freedom boards are cheaper, are easier to unplug the USB cables from, can deliver more power at 3.3V, have RGB LED, and have a lot of neat features missing from the Teensy boards, but the Teensy boards can be configured to plug directly into a bread board (if you give up a lot of the connections and just use 26 pins), and have more RAM (so can run for longer at high sampling rates before the buffer overflows).

I’m going to have to rewrite part of my book to talk about the possibility of using the Teensy 3.1, and I’ll have to decide whether the extra $6–$7 is worth the simpler setup for my Applied Electronics lab course. We’d sacrifice being able to get much power from the board (probably only about 100mA instead of 500mA at 3.3V), but that is a relatively minor loss, since we have bench power supplies at every station.

I’m not sure what I’ll recommend in the book for people trying to learn on their own—I’ll probably have to play with the Teensy a bit to see how useful it is.  I have at least one other program that the students have been using in the lab (the frequency detector for turning a relaxation oscillator into a touch sensor) that I’ll have to port to Arduinos and the Teensy 3.1.

For home hobbyists who aren’t planning to dive deep into embedded-system programming, the Teensyduino IDE is a lot friendlier than the MBED.ORG tools (and I hear that the Kinetis SDK has a very, very large learning curve), so it might be a better board despite the lack of peripherals (no accelerometer, RGB LED, or capacitive touch slider).

 

« Previous PageNext Page »

%d bloggers like this: