I have a couple of projects where I want to use the ARM mbed platform on the inexpensive FRDM-KL25Z board, which features the Freescale Kinetis KL25Z ARM Cortex-M0+ processor. This requires a firmware update on the board and I have done this previously without trouble while I was still running Windows 7. Now however, I have moved to Windows 10 and this caused a bit of trouble.
This post describes the problems I ran into and how I solved them. In essence, I was forced to use a computer running Windows 7 to do the actual update.
Failed attempt
The firmware upgrade process is described on this page. While there are some hints on that page that the upgrade might not work if the host computer runs Windows 8 or Windows 10, this is not entirely clear, so I tried it anyway. This is what I did and what happened:
Hold down the reset button on the FRDM-KL25Z board while plugging in the USB cable in the right (SDA) USB connector.
The board now appears as a disk called BOOTLOADER.
Drag the .s19 file to the BOOTLOADER disk.
Unplug and replug the FRDM-KL25Z.
If everything had worked as it should, the board would now have shown up as a disk called MBED. What instead happened was that the computer did not at all react to the board. No disk showed up.
Reading a bit more on the firmware upgrade page and in the discussions at the bottom of the page, it seemed like there was no way forward using only a Windows 10 computer.
Successful attempt
The reason it did not work with Windows 10 seems to be that my FRDM-KL25Z board had too old bootloader firmware. It has to be 1.11 or higher to work on Windows 10 (or Linux and Mac it seems). To check the bootloader version, one can hold down the reset button while plugging in the USB cable into the SDA port. This makes the board show up as a BOOTLOADER disk where there is a file called SDA_INFO.HTM. Double clicking on this file brings up a web page that says among other things what the bootloader version is. In my case it was 1.09.
To remedy this, the following steps are required:
Get hold of a computer running Windows 7 or Windows XP.
Hold down the reset button on the FRDM-KL25Z board while plugging in the USB cable in the right (SDA) USB connector.
The board now appears as a disk called BOOTLOADER.
Unzip the OpenSDA_Bootloader_Update_App_v111_2013_12_11.zip (or similar) file from inside the big zip file.
Drag and drop the resulting BOOTUPDATEAPP_Pemicro_v111.SDA (or later version) file to the root directory of the BOOTLOADER disk.
Unplug and replug the board to initiate the bootloader update. This typically takes just a few seconds.
Once the update is complete the board will automatically reappear as a disk called BOOTLOADER.
Double click on the SDA_INFO.HTM file in the root directory of the BOOTLOADER disk to see that the bootloader version now is 1.11 (or higher).
Drag the 20140530_k20dx128_kl25z_if_opensda.s19 (or whatever the latest version of the mbed firmware is) to the BOOTLOADER disk.
Unplug and replug the board. It should now show up as a disk called MBED.
After this, the board showed up as a disk called MBED and worked on Windows 10.
To upload and run a .bin-file (the output of the mbed online compiler) to the board one drags the .bin file to the MBED drive and then presses reset on the KL25Z board.
This post describes a circuit that can detect a mains frequency AC current and translate it into a voltage that is proportional to the current. It does this while being electrically isolated from the AC current.
One way of measuring the current to a single phase AC load, like a motor or a heater, is to use a current sense transformer around a wire that conducts the current. One kind of current sense transformer is the Rogowski coil, which is basically an air-core toroidal coil where one of the leads is routed back inside the coil to end up on the same side as the other lead. The absence of an iron/ferrite core makes the Rogowski coil immune to saturation, so it can handle large currents while still being linear.
The output voltage of the coil is proportional to the rate of change of the current to be measured, so in order to get a voltage proportional to the current itself, one has to use an integrator. If the current is known to be a sinusoid of a fixed frequency, it is not necessary to integrate the voltage as a simple factor determines the relationship between the current and the coil voltage, but such a design would make the circuit very sensitive to high-frequency overtones. The circuit discussed here contains an integrator so that it gives accurate outputs for a wide range of frequencies.
Below is a schematic of the integrator circuit I came up with.
Rogowski-based AC sense amplifier.
The components in the box to the left is a simulation model of the Rogowski coil PA3208NL. This device has an internal resistance of 37.6 ohm (R1) and gives an output voltage of 383 µV for a 1 A 50 Hz current. I1/L1 provides a voltage that is proportional to frequency and reaches 1 V RMS at 50 Hz, which is converted to 383 µV at 50 Hz by E1.
C1 provides some high-frequency (EMI) attenuation while R2 makes sure the input of the amplifier circuit is biased to GND even if the coil is not connected. These components have little effect on the simulations.
R3/C3 is partly another EMI low-pass filter, but the values are also chosen so that it takes over the integrating function from the amplifier around 15 kHz. C2 AC-couples the GND-referred signal at the input to the half-supply point used by the amplifier.
R4/R5 biases the amplifier input at half supply to maximize the available signal swing.
U1 approximates an integrator over the frequencies of interest. In this range C4 acts as a short and R7 has much higher impedance than C5. The frequency response is thus determined by C5/R6 and the gain is (1 + 1/(s*R6*C5)). The 1/(sR6C5) becomes shrinks to become equal to the 1-term at about 15 kHz, so well below this frequency the response is close to that of an integrator, which would be 1/(s*R6*C5). As mentioned above, R3/C3 are chosen so that they take over the integrating business (low-pass filtering) at this point, so the total circuit response is close to that of an integrator to frequencies quite a bit above 15 kHz, to around 100 kHz or so.
For low frequencies, R7 starts dominating over C5 around 3.3 Hz. The same cutoff frequency has been chosen for C4/R6, so 10 times this frequency (33 Hz) is approximately the lower point at which the circuit behaves as an integrator.
For very low frequencies, well below 3 Hz, C4 and C5 acts as open circuits and R7 provides DC feedback to establish the operating point. This takes care of a problem that ideal integrators have, namely infinite gain at DC, which would sooner or later rail the output of U1. By having C4 in series with R6 and R7 in parallel with C5, the gain at DC becomes 1 and since the input is AC-coupled (through C2), the only DC term at the output is one times the amplifier input offset.
Below is a frequency response plot of the most interesting nodes in the circuit.
Frequency response at some of the nodes.
The green curve shows the voltage linac inside the Rogowski model. Note that it reaches 1 V at 50 Hz and increases linearly with frequency.
The blue curve is the green curve scaled so that it has a value of 383 µV at 50 Hz.
The red curve is the input of the amplifier. It follows the blue curve up to just below 10 kHz, where the low-pass action of R3/C3 kicks in and flattens the curve. As mentioned above, this knee is chosen to coincide with the opposite knee of the amplifier caused by R7/C5 so that the total response, the grayish-green curve, is flat from 30 Hz to 100 kHz. The gain is just above 0.1 V/A, which makes this design suitable for applications with up to at least 10 A of maximum current.
One caveat when testing or using this circuit is that it takes a pretty long time for the 100 µF capacitor to charge up via the 2.2 megohm resistor after power up. The time constant here is more than three minutes (220 seconds), which means it will take a long time from power up until the circuit is operational. If this is a problem in any given application, one could consider placing a CMOS switch (like 4066) across the 2.2 megohm resistor and let it be closed for a short period after power up.
The 10 µF capacitor at the input of the amplifier will also take some time to charge. Here the time constant is 5 seconds, so this is less of a problem than the 100 µF cap. This can be improved by reducing the 1 megohm bias resistors to 330k, which will have little effect on the overall response. Even 100k might be acceptable, although this will cause some unevenness in the response above 10 kHz.
In the schematic, the amplifier LTC6088 is present. I chose this as it was a suitable opamp available in the default LTSpice library. There are however many other amplifiers that would do well in this position. Important characteristics are:
Operation at 5 V
Preferably rail-to-rail output
Reasonably low input bias current, preferably below 50 nA or so
Enough gain-bandwidth for the application, at least a few MHz
In this post I describe some code I wrote to handle the input from an incremental rotary encoder connected to a Teensy. The code should work well also on an Arduino, provided the rotary encoder signals are connected to pins that have interrupt functionality.
A rotary encoder is great for many kinds of user interfaces. It physically looks like a potentiometer, but it is not limited to less than one turn. The output is digital, so it can relatively easily be interpreted by a micro controller, even one without a built-in analog to digital converter.
A rotary encoder. Looks like a potentiometer, but it is digital.
The number of pulses per rotation can vary, but between 12 and 24 is common. An encoder contains two switches and if it is rotated clockwise, switch A closes before switch B for each “click” and if it is turned counter clockwise, switch B closes before switch A. This is called quadrature encoding since the two square waves are 90 degrees out of phase from each other.
By looking at the order in which the switches close, it is possible to determine in which direction the knob is turned. The figure below illustrates the waveforms, assuming the switches connects their pins to ground and that the two signals are otherwise pulled up to a positive voltage by pull-up resistors.
Quadrature waveforms from a rotary encoder. “D” marks a detent or click state.
Below is a diagram showing how a rotary encoder and a push button (which is often integrated into the encoder) can be hooked up to a Teensy 3.1.
Encoder and button connected to pull-up resistors and a Teensy 3.1.
A problem when trying to use a rotary encoder as part of a user interface in an embedded application is that the pulses can be pretty short and it is important to not miss any, as that would mean missed rotations or even rotations detected in the wrong direction. Furthermore, like for almost all switches, there is also contact bounce that one must handle in some way. Typically, the processor has to do other things while also responding to input from the rotary encoder.
This means that it is often very hard or impossible to robustly interpret the signals from an encoder by polling the signals from within the main loop of the program. To get around this problem, one can instead use interrupt routines that are triggered when a signal from the encoder changes level. This is precisely what the code below does. It was written for a Teensy 3.1 (or 3.2), but should work on other platforms as long as the encoder signals are connected to pins with interrupt capability.
sets up an the function “ISRrotAChange()” to be called every time the rotAPin changes state. This function in turn looks at the pin and sets the rotAval variable accordingly before calling the more complicated function UpdateRot() which contains a state machine that keeps track of what the rotary encoder is doing and increments or decrements the rotAcc (rotary encoder accumulator) variable when it has determined that the encoder has moved a notch. No debounce timer is necessary since it is pretty safe to assume that the bounces of one switch will have died out before the next switch will be activated.
The rotAcc variable is changed only after the second signal becomes activated (low) while the first signal is still active since it is pretty common that one signal is activated and later deactivated without the second signal becoming active. This happens when the operator rotates the knob a fraction of a notch and then lets it return to the original position without going all the way to the next notch.
The main loop must not look directly at the rotAcc variable since it can be changed at any point within the program by an interrupt. It is only safe to access it while interrupts are disabled, so accesses have to be surrounded by cli() (clear interrupt enable bit) and sei() (set interrupt enable bit) function calls. This is done in the GetRotAcc() function which thus provides a convenient way of safely looking at the value of the accumulator. The interrupt service routines (ISRs) themselves do not need to mess with cli() and sei() when accessing the interrupt state variables since interrupts are automatically temporarily disabled while servicing an interrupt.
Since the global variables used by the interrupt routines can be changed at any point within the course of the main program, they have to be be declared with the keyword “volatile” to prevent the compiler from making optimizations that assume that they behave like normal variables that will never magically change under the feet of the main program code.
Written by Per Magnusson, http://www.axotron.se
v 1.0 2015-11-15
This program is public domain.
*/
// Rotary encoder push button pin, active low
static const int pushPin = 16;
// Rotary encoder phase A pin
static const int rotBPin = 17;
// Rotary encoder phase B pin
static const int rotAPin = 18;
#define DEMO 1
// Rotary encoder variables, used by interrupt routines
volatile int rotState = 0;
volatile int rotAval = 1;
volatile int rotBval = 1;
volatile int rotAcc = 0;
void loop()
{
static int oldRotAcc = 0; // Remember previous state
int newRotAcc;
// Do not look directly at the rotary accumulator variable,
// it must be done in an interrupt safe manner
newRotAcc = GetRotAcc();
if(!digitalRead(pushPin)) {
// The button was pushed.
// Button detection is not interrupt driven, but detection of the
// rotary encoder movements goes on also in the busy way below.
Serial.println("Button down");
delay(10); // Debounce
while(!digitalRead(pushPin))
;
delay(10); // Debounce
Serial.println("Button up");
} else if(newRotAcc != oldRotAcc) {
// The encoder was rotated at least one step.
Serial.println(newRotAcc);
oldRotAcc = newRotAcc;
}
}
// Return the current value of the rotaryEncoder
// counter in an interrupt safe way.
int GetRotAcc()
{
int rot;
// Update rotary encoder accumulator.
// This function is called by the interrupt routines.
void UpdateRot()
{
// Increment rotAcc if going CW, decrement it if going CCW.
// Do not increment anything if it was just a glitch.
switch(rotState) {
case 0: // Idle state, look for direction
if(!rotBval) {
rotState = 1; // CW 1
}
if(!rotAval) {
rotState = 11; // CCW 1
}
break;
case 1: // CW, wait for A low while B is low
if(!rotBval) {
if(!rotAval) {
rotAcc++;
#ifdef DEMO
// Remove this when not in demo mode
Serial.print(" right ");
#endif
rotState = 2; // CW 2
}
} else {
if(rotAval) {
// It was just a glitch on B, go back to start
rotState = 0;
}
}
break;
case 2: // CW, wait for B high
if(rotBval) {
rotState = 3; // CW 3
}
break;
case 3: // CW, wait for A high
if(rotAval) {
rotState = 0; // back to idle (detent) state
}
break;
case 11: // CCW, wait for B low while A is low
if(!rotAval) {
if(!rotBval) {
rotAcc–;
#ifdef DEMO
// Remove this when not in demo mode
Serial.print(" left ");
#endif
rotState = 12; // CCW 2
}
} else {
if(rotBval) {
// It was just a glitch on A, go back to start
rotState = 0;
}
}
break;
case 12: // CCW, wait for A high
if(rotAval) {
rotState = 13; // CCW 3
}
break;
case 13: // CCW, wait for B high
if(rotBval) {
rotState = 0; // back to idle (detent) state
}
break;
}
}
[/cpp]
In this demo version of the code, status information is sent back over the USB serial port so that a terminal window (e.g. the one in the Arduino environment) can display it. The texts “left” or “right” are printed by the ISR when it changes the value of rotAcc and the main loop prints the value of rotAcc when it detects that it has changed.
The main loop handles the push button. This is done through normal polling. A delay is used to filter out contact bounces. While the button is held down, the main loop is stuck and cannot print updated rotAcc values, but the ISR routines happily execute if the encoder is rotated, so the “left” and “right” strings can still appear while the button is pressed.
Here is an excerpt from a terminal session:
right 1
right 2
right 3
right 4
right 5
left 4
left 3
Button down
right right right right left right Button up
7
right 8
right 9
left 8
left 7
The encoder was rotated clockwise (CW) five steps (right 1 to right 5) and then counter clockwise (CCW) by two steps (left 3). Then the button was pushed and held down (Button down) while the encoder was rotated four notches CW, one CCW and one CW before the button was released. After this the main loop resumed and detected that the rotAcc value had changed to 7. Then the encoder was rotated two more notches CW and two CCW.
When not using this to demo the functionality of these specific routines, the Serial.print() statements in the interrupt routines should be removed, either by not #defining DEMO or by removing those lines of code completely.
