Gas station without pumps

2015 August 16

Arduino-compatible software for FRDM-KL25Z board

Filed under: Circuits course — gasstationwithoutpumps @ 10:13
Tags: , , , ,

As many of you have realized, I’m finding that doing multiple-platform support for the PteroDAQ system is a bit annoying.  One irritation is that the mbed.org compiler for the FRDM-KL25Z board is not integrated with the other compilers—not even sharing the same file system.  So every time I make a change, I need to transfer all the files between my laptop and the mbed website—I can’t use mercurial or git to keep things in sync.

All the other boards I’m using can be compiled for locally and downloaded to with the Arduino IDE.  It is not a particularly powerful IDE, but it is dead simple to use, and it runs on my old Mac OS 10.6.8 (at least, if I use Arduino 1.0.6—the newer versions seem to assume new Macs).  A lot of the “professional” IDEs assume that you replace your computer every year and have the latest OS installed, or that you use nothing but Windows.

Since the FRDM KL25Z board is currently one of the best price/feature microcontroller boards on the market, I figured that someone must be working on an Arduino plug-in for the hobbyist market.  So I did some Google searches and found something that initially looked promising: Arduino-compatible software library for FRDM-KL25Z board – CodeProject.

FRDM-KL25Z is an interesting ultra low cost board with 32-bit microcontroller. What makes it interesting for the Do-It-Yourself community is low price (about $13) and also the compatibility with the Arduino pinout. If you are Arduino user like me, you will probably also feel interest if you hear about a board which could, for less than half the price of standard Arduino board, give you a 32-bit ARM MCU running at 48 MHz with 128 KB of FLASH and 16 KB of RAM memory, on-board accelerometer and more. But as you might have expected, there is a “catch”. The  FRDM board has the same layout of pins, so you can connect the Arduino shields to it, but there is no software compatibility. You cannot use the Arduino API functions such as digitalRead, delay, etc. and you cannot program the board from the Arduino IDE. I was thinking it would be nice if you could… And this article is my first step in this direction.

Digging deeper, though, disappointed me.  They are trying to provide the trivial parts of the Arduino API, but they do their compiling with Kinetis Design Studio (which doesn’t run on Mac OS 10.6.8, and which is supposedly a bit of a bear to learn to use).  I’m more interested in the opposite combination—using the Arduino IDE, with only minimal use of the Arduino API (which I find a bit too inefficient for my tastes), except for a couple of difficult things (like the USB stack).

They’ve also licensed their code with a contagious LGPL license, which is too restrictive for the PteroDAQ code.

What I’m looking for is something like the Teensyduino implementation, but for the FRDM KL25Z board. I’ll have to look at how the Teensy loader is integrated into the Arduino IDE—if I can figure out how to put in copying a .bin or .s19 file to an emulated flash drive instead, then I can probably program for the KL26Z board, and possibly for the KL25Z board.

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).

 

2015 July 30

New dimmer software

Filed under: Uncategorized — gasstationwithoutpumps @ 15:46
Tags: , , , , ,

Based on the success of the stroboscope software, I rewrote the dimmer software for my desk lamp (see LED lamp projects for more about the lamps).  The new software provides smoother control of the light levels (having 256 levels plus off, rather than 63 levels plus off) and now has a 256:1 brightness range rather than the approximately 256:6 range of the previous code.

I removed a lot of the general-purpose crap that was inherited from core13 (which was in turn stripped down from the Arduino core software).  I did not get rid of all of core13, so I could probably take out another 50–100 bytes, but the code is down to 222 bytes (and the ATtiny13A has 1kB of flash, so I’m way below the limit).

The actual brightness range of the new dimmer is a bit more than 256:1, because on the shortest pulse the FET doesn’t turn all the way on.  The pulse duration from the ATtiny13A is approximately 3.4µs times the brightness level (9.6MHz clock divided down by 4 and by 8), but I had deliberately slowed the FET transitions by adding a series resistor to the gate, so that nFET doesn’t finish turning on for 5.2µs (as judged by the end of the Miller plateau on the gate).  So at the lowest brightness level, the nFET does not turn all the way on and the voltage on the drain only gets down to 3.5V, which leaves 5.5V across the LED board—enough to turn on the LED, but with only about 10mA, not 118mA. At this low level, the LEDs sometimes flicker, perhaps as a result of some thermal feedback effects. The all flicker together, so the effect is probably in the dimmer’s nFET, not on the LED boards.

ATtiny output (green) and gate voltage (yellow) at 2V/division and 2µs/division for the shortest pulse length.   The gate voltage has not quite reached the end of the Miller plateau before being discharged again.

ATtiny output (green) and gate voltage (yellow) at 2V/division and 2µs/division for the shortest pulse length. The gate voltage has not quite reached the end of the Miller plateau before being discharged again.

ATtiny output (green) and drain voltage (yellow) at 2V/division and 2µs/division for the shortest pulse length.  The BitScope BS-10 oscilloscope clips the voltage to 5.5V—it actually goes to 9V.

ATtiny output (green) and drain voltage (yellow) at 2V/division and 2µs/division for the shortest pulse length. The BitScope BS-10 oscilloscope clips the voltage to 5.5V—it actually goes to 9V.

At the next brightness level, the drain voltage does drop to 0V for at least 2.4µs and stays low enough for the LED board to be at maximum current (below 2.5V) for at least 5.5µs.  There is an enormous difference in brightness between length 2 and length 1 pulses (more like 1:20 than 1:2), because of the low current for pulse length 1, but for length 2 and longer the steps in brightness are pretty much as one would expect from the pulse lengths.

ATtiny output (green) and gate voltage (yellow) at 2V/division and 2µs/division for the shortest pulse length.   The gate voltage has gone past the end of the Miller plateau and started charging past that point. The Miller plateau is also visible on the discharge as the nFET turns off.

ATtiny output (green) and gate voltage (yellow) at 2V/division and 2µs/division for the shortest pulse length. The gate voltage has gone past the end of the Miller plateau and started charging past that point. The Miller plateau is also visible on the discharge as the nFET turns off.

ATtiny output (green) and drain voltage (yellow) at 2V/division and 2µs/division for the  second shortest pulse length.  The BitScope BS-10 oscilloscope clips the voltage to 5.5V—it actually goes to 9V.  The longer pulses allow the nFET to turn on fully.

ATtiny output (green) and drain voltage (yellow) at 2V/division and 2µs/division for the second shortest pulse length. The BitScope BS-10 oscilloscope clips the voltage to 5.5V—it actually goes to 9V.
The longer pulses allow the nFET to turn on fully.

The conversion from the linear 10-bit analog-to-digital reading (0–1023) to pulse lengths is done by the following method:

expon = ADC>>7
frac = 0x80 + (ADC & 0x7f)
pulse_len = ADC < 0x20? 0:  ADC < 0x40? 1: 1+ (frac>> (7-expon))

The stepwise nature of the brightness at low levels is apparent in a plot of the conversion function:

The steps in brightness are quite visible at the low end, but after the first 10 steps, the differences are small enough not to be easily noticed.

The steps in brightness are quite visible at the low end, but after the first 10 steps, the differences are small enough not to be easily noticed.

Overall, I’m pleased with the rework of the dimmer code. I’ll probably have to solder up another of the dimmer boards this summer, since I’ll want one for the light fixture that I haven’t started building yet and one for the Halloween stroboscope.

2015 July 29

LED strobe using dimmer board

Filed under: Uncategorized — gasstationwithoutpumps @ 23:49
Tags: , , , , , ,

In the evenings this week, I soldered up another PWM controller for the LED lamp projects, and programmed it with the ISP cable I made.  The intent was to use this dimmer either with the breakfast-room lighting fixture (which I’ve not made yet) or reprogram it to act as a strobe rather than a dimmer, to replace the Xenon-tube-based Velleman strobe kit that failed last Thanksgiving.

This project took me much longer than expected, because of stupid mistakes I made:

  • I forgot that there was a silkscreen error on the dimmer boards that I had designed.  The outline for the voltage regulator is flipped, because I had not noticed when reading the spec sheet shows the device from the bottom—I’m used to chip views being from the top.  This is the second time that I’ve soldered a voltage regulator on one of the boards backwards, and had to cut it off and replace it with a new one.  I guess I’d better take a permanent felt-tip marker and draw the correct orientation on the remaining boards, so that I don’t make that mistake a third time.
  • When playing with new code for the strobe, refamiliarizing myself with the ATtiny13A processor, I changed the prescaling on the system clock from the default 1.2MHz down to about 75kHz.  What I had not realized is that the on-chip clock is used during the reprogramming also, and the Arduino ISP is not set up for slowly clocked chips.  I found code for TinyISP, which has code for 128kHz clocks, but even when I modified it for 75kHz clocks I couldn’t reprogram the chip (always getting the “Yikes! invalid device signature” message with a signature of 0). Eventually, I gave up, unsoldered the ATtiny13A and put in a new one.  I’ll be very careful in future not to slow down the system clock so much.
  • I got the strobe working this morning, but when I looked at the output pin that was driving the FET gate, it was only going up to 1.3V, not 5V, and the pulse was much longer than I expected.  This mystified me for a while, but I finally realized that I had forgotten to turn the pin on as an output, so I was driving the output just through the built-in pullup resistor, resulting in a very large RC time constant.  The flat top I was seeing on the pulse was probably the Miller plateau.  Enabling the output pin correctly got me back to crisp 5V pulses of the designed duration.
  • The designed duration for the pulses was a bit too short, resulting in a somewhat dimmer than desired flash.  Lengthening the pulse to 1ms was fine for the slow strobes, but at high flash rates the strobe got too bright. So I reprogrammed the flashes so that the on-time was 1/64th of the off-time, but with a maximum on-time of 1.6ms. (I also tried on=off/128 with a maximum of 1ms, but I liked the 1/64 better).

I timed the strobe pulses from the board (looking at the output of the ATtiny13A pin 6, which is also connected to the MISO pin of the ISP header, so is easy to connect a jumper wire to) with PteroDAQ (through a voltage divider, to drop the voltage from 5V to 2.75V).  By triggering the PteroDAQ on edges of the signal, and averaging many measurements, I got very precise timing measurements:

setup on-time off-time
slowest setting, 1:64 1.63745ms 1.52372s
fastest setting, 1:64 104.958µs 6.98761ms
slowest setting, 1:128 955.277µs 1.55881s
fastest setting, 1:128 51.3123µs 6.99286ms

The difference in the “slowest” settings is probably just from my inability to set the knob identically—it has to be just above a threshold below which the strobe doesn’t flash at all. In any case, I have a period from 7.1ms (141Hz) to 1.525s (0.6556Hz), which is a pretty useful range.  I also made the range very smooth, by taking the 10-bit ADC range and converting it to this 215:1 range sort of exponentially with just a few instructions:

if adc<40, then OFF
exp = adc >> 7
frac = 0xff - (adc & 0x7f)
on_time = (frac << 8) >> exp
The tiny number of instructions provides a surprisingly smooth and strictly decreasing approximation to the desired exponential.

The tiny number of instructions provides a surprisingly smooth and strictly decreasing approximation to the desired exponential.

The transition is smooth because every time an increment increases the exponent, the frac part is doubled (from 0x80 to 0xff).I use a 16-bit word for the on_time and count it down with an interrupt once every 26.67µs (256 of the approximately 9.6MHz clock ticks). I think that I’ll do a similar thing for controlling the duty cycle of the dimmer, rather than the table of bytes that I currently use, though the duty cycle is limited to a single byte, so I’ll only have 256 levels, and not 1024, and I’ll want the duty cycle to increase exponentially, rather than decreasing, but those are easy fixes.

I also reduced the size of the program in flash, by getting rid of some of the overly general code from core13 and just manipulating the peripheral control registers directly.  I didn’t need to do this, as the ATtiny13A has 1kB of flash, but I got down to 364 bytes (and could probably strip out another 50–100 by getting rid of even more of core13).  The old dimmer code, which doesn’t have much more to do, currently takes 806 bytes, so I might try tightening that up tomorrow.

I also tried powering the strobe off a 9V battery.  The LED board takes about 117mA when turned on (see LED board I-vs-V curve), and if I keep the duty cycle below 1.5%, then the average current is dominated by the ATtiny13A’s worst-case 6mA current, and the total current for the board is probably less than 8mA.  According to Duracell’s data sheet for their 9V alkaline battery, I should be able to get about 50 hours of life before the voltage drops below 6.7V (at which point the LED board no longer maintains the constant current, but I could run the strobe a bit longer getting dimmer).  The 6.7V is also about the voltage where the LDO voltage regulator starts being unable to supply 5V to the ATtiny13A, though that is less of a bottleneck, as the chip can run with the 9.6MHz internal clock down to 3V with no problems.

The battery does not have to provide a full 117mA for the pulses, as there is a 470μF polymer electrolytic capacitor on the dimmer board.  Delivering 117mA for 1.6ms is only 187μC, so the voltage on the capacitor would dip at most 0.4V during the pulse, even without the battery.  The 9V battery has an internal resistance of 2Ω–4Ω, so it could provide 117mA with about a 0.35V drop, so the capacitor isn’t really necessary for one LED board.  It probably increases the efficiency slightly, as the I2R power loss in the internal resistor is reduced if the current is spread out (half the current for twice as long is only half the I2R loss).

I could put more LED boards on the strobe, as the dimmer is designed to handle 5A or more, but battery  operation would limit me to about 10 boards before the voltage drop was large enough to cause problems for the current regulation.  One LED board is bright enough for a Halloween pumpkin, but I could run wires between pumpkins to power several off the same controller.  (I could also keep the controller in the house, powered by a wall wart, and run wires out to the LED boards—I could then power 40 or 50 LED boards off the strobe, though I’d have to watch out for IR drop in the wiring.)

I might try wiring up 10 boards tomorrow, and see whether a battery really can power that many.

Next Page »

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 318 other followers

%d bloggers like this: