Installing STM32CubeMX on Linux

STMicroelectronics has a nice little tool to plan out your pin mapping for their STM32 microcontrollers, called STM32CubeMX, but unfortunately they packaged it in to an .exe file. I first tried running the exe under wine but I was greeted with a message that it requires Java. I know a lot of these installers are really just executable zip files so I just ran unzip on it.

mkdir stm32cubemx
cd stm32cubemx
unzip ../SetupSTM32CubeMX-4.3.0.exe

Taking a look at "META-INF/MANIFEST.MF" you'll see it want's to run "com.izforge.izpack.installer.bootstrap.Installer" so I did that next.

java -cp . com.izforge.izpack.installer.bootstrap.Installer

Looking at the install directory we find another exe. Lets unzip again. This time in place (zip bomb, but that's ok).

cd <install location>
unzip STM32CubeMX.exe

Looking at "META-INF/MANIFEST.MF" we now see "com.st.microxplorer.maingui.IOConfigurator" so I ran that.

java -cp . com.st.microxplorer.maingui.IOConfigurator

Seems to work just fine.

Telepresence Robot Video

After seeing a commercial for a Telepresence robot on TV, I knew I wanted to play with one, but after looking at prices I didn't want to pay for one.

I used an Android Nexus 7 tablet for the video conferencing. A custom PCB with an STM32 ARM processor and an FTDI USB chip to connect the Android tablet with the motors.

All the code and design files can be found here: Telepresence Robot GitHub Repo

First Run of my Air Motor

Using two air solenoids and an ATmega328 I was able to get my air motor up and running. The timing was a little touchy but I got it to work. This project is based off of one I saw over at Nuts and Volts. Next up, tuning the motor to get maximum efficiency. I also want to rewrite the algorithm to take target RPMs and calculate the necessary timing to get there.



As always the code can be found in google code.

Hacking a Scale to Add ZigBee Goodness

My idea is to take this scale

and add ZigBee wireless so that I can automatically capture my weight on my computer without having to remember it.

OK lets backup. Why did I choose the scale above? The first reason I chose this scale is because it has an LED display. I knew this would make the task of hacking much easier because the chances would be good that the display would be 4 - 7 segment displays that I could easily read. The second reason is (after opening the box in the aisle at Target) it looked easy to disassemble, just a couple of screws holding the back on. The third reason, it was cheap, I didn't want to waste a bunch of money on something I could easily break in the process. Finally it needed to have room for the electronics so I found a scale that wasn't glass or super thin. By the way its a Taylor model 9856 if you care.

On to the hacking...

After popping off the back (yes it really was just a couple of screws) I saw the following...


Flipping up the LED I saw this...


It was almost too easy, the chips were clearly marked and the board didn't have much mystery at all except for the black epoxied MCU on the right. But, I didn't need that. I had everything I needed exposed right where I could get at it. I had two options: tap into the EEPROM or read the LEDs. I chose the later. Why? Well, after scoping the EEPROM I couldn't make heads or tails out of what was being sent, on the other hand scoping the HC164 and the four transistors it made complete sense.

Basically here is how it works. Each of the four transistors drives one digit of the LED (actually they enable the LED by switching the cathode or ground side). The HC164 receives the 7 bits that make up the digit along with 1 bit for the decimal point (see Seven Segment Display). So the process goes like this: all four transistors are turned off. The HC164 is loaded with the data for digit 1. The first transistor is then turned on for 3.5ms. It is then turned off and the next digit is shown. Over and over again. Because this is all happening in roughly 20ms per refresh it looks to our eyes that all digits are lit at the same time (persistence of vision).

So how do we know when it has the final weight? The scale I have displays a little night rider effect. "o" in the first spot, followed by "o" in the second, then third, then forth, and repeat for 3 iterations. In the firmware as soon as I see an "o" in any spot I take the last good decimal reading and send that over my ZigBee network.

Here is a shot of my prototype. I'm using an ATmega 328P (same chip used in the Arduino) to read the signals.


Here is the schematic of whats happening...


I wanted to fit everything back into the scale so I didn't have any external components so I needed to design a circuit board that would fit into the very cramped case. This is what I ended up with...


Finally a photo with everything in place...


So where do all these readings go? My computer of course. I have a ZigBee coordinator to USB adapter on my computer. I wrote a simple windows service that listens for the ZigBee traffic and if it receives a new weight it stores it in a MSSQL database. It also handles multiple users by looking at the previous weights of each user and picks the closest match. To display the data I wrote a .NET MVC web site to display pretty graphs and such, but that was trivial compared with the rest.

Schematics, Firmware, Web Site, etc. can be found here

Enabling 32MHz Operation on the AVR XMEGA

I received an AVR XMega100 Breakout from SparkFun in the mail yesterday and I've started doing some experimenting with it. The first problem I ran across was getting into 32MHz clock mode. The XMegas have a internal oscillator but by default they are set to 2MHz operation. What's kind of neat about the XMegas though is that you can switch the speed at runtime. What tripped me up was the fact that the registers that control the oscillator and clock are both protected registers. I'm not really sure what the benefit of this is but in any case here is the code to enter 32MHz mode.

void setClockTo32MHz() {
    CCP = CCP_IOREG_gc;              // disable register security for oscillator update
    OSC.CTRL = OSC_RC32MEN_bm;       // enable 32MHz oscillator
    while(!(OSC.STATUS & OSC_RC32MRDY_bm)); // wait for oscillator to be ready
    CCP = CCP_IOREG_gc;              // disable register security for clock update
    CLK.CTRL = CLK_SCLKSEL_RC32M_gc; // switch to 32MHz clock
}

A couple things to note. Check that you set the clock speed (F_CPU) in your compile to 32000000. And since the clock can be modified at runtime, anything that relies on the F_CPU constant may be effected, this includes the build in delay functions. For what I'm doing I'm not concerned with switching back and forth but some low power applications may find that useful.

Populated PCB

Soldering is all done. I tested the board and everything seems to work well. I did discover a little mechanical errors with my board, the ICSP header and IMU are a little too close, and I have to remove the IMU to use the ICSP. Overall I'm quite happy how things turned out. The final board weighs in at 50g.

PCBs Arrived

After patiently waiting 3 weeks, I finally received my PCBs from BatchPCB. These are the first PCBs I have ever sent out to be manufactured. Pricing models, gerber files, board thickness, etc. have always seemed so intimidating but, BatchPCB and a tutorial at SparkFun made the process easy. With shipping, it came out to be less than $50. I just hope it works.

If you noticed in the photo above I received two PCBs but I only ordered one. I've heard this happening with BatchPCB. I'm not really sure if it's an artifact of how they build their panels but I'm not complaining.

Now I'm off to a fun night of soldering all the parts. The board has three ATmega328 that are in TQFP32 packages and since I have never soldered anything with a pitch that small it should be interesting. After watching numerous surface mount soldering tutorials on YouTube it doesn't look to be all that hard.

Here are some more pictures of the board...

Front



Back