A couple of months ago I managed to find a used DSLR body for a very good price at a local flea market. I had been thinking of getting a proper DSLR for some time now (so far I’ve been using a “bridge” camera, the Fujifilm S9500), so for only £30 it was worth the risk. What I got was a Nikon D100. This is a fairly old, 6 megapixel DSLR, which cost about $2,000 when it came out in 2002. I primarily got the camera to use it together with my telescope for astrophotography, and for that it didn’t need to do much. However, now that I had the camera body, I also wanted a lens. With Nikon being one of the two big DSLR manufacturers (Canon being the other one), it didn’t take long to find an inexpensive used lens on ebay. When I tested the lens with my camera body, it became clear that something didn’t work properly. While autofocus worked fine with the lens, whenever I wanted to use even a slightly smaller aperture (with F-numbers as low as 5 or 6) the camera displayed an error, and depending on how high an F number I had dialed in, the image tended to over-expose. I decided to investigate.
A few weeks ago I bought a record player for a few quid at the local flea market. Even though we already have a nice vintage Marconi record player that’s in great shape and sounds fine, it has two disadvantages: 1) There are no external connectors, so all the sound comes from the built-in speaker. That’s fine, but it prevents you from either listening to your records with headphones, or to record them somehow (unless you use a mic at the speaker, of course). 2) The player is a mono player only. Again, that’s fine for playing both mono and stereo records, but of course you won’t hear any left-right differences when listening to stereo records. This second record player was supposed to fix both of these problems. It did, however need a few modifications.
A little while ago I got one of the fairly common “Nokia 5110” LCD modules, a 84×48 b/w graphic LCD screen, thinking it would be handy to have in current or future projects. One of the things I especially like about this module is that it is using a serial protocol (SPI) to send data and control messages. This reduces the number of pins required tremendously. When I finally got around to playing around with it, I managed to get it to work with my STM32F4-Discovery board fairly quickly. I could have left it at that, but the code I was using during my initial tests was rather crude and inefficient, and I thought this module would be a good reason to finally get my hands dirty with the DMA controller on the STM32F4.
After the flurry of activities in recent weeks on a previous post (thanks guys!) I finally went back and worked on the synth project some more. Some time ago I had already created a simple MIDI input and output circuit on a stripboard that the Discovery board could sit on. This would allow me to play notes or adjust parameters from any standard MIDI controller or the PC. The hardware setup for this was quite simple using a 6N137 optocoupler, which gets its 5V supply voltage directly from the 5V rail of the Discovery board. Since the output of the optocoupler is just an open drain, I didn’t even have to worry about any level shifting and directly connected it to the USART2 RX input on pin PA3, which I configured with an internal pull-up. (I have yet to test the output side, which is coming from USART2 TX on PA2 and goes to an external MOSFET.)
I recently got a cheap 20×4 LCD module on ebay and started playing around with it this weekend. Of course, given that I paid less than 5 pounds for it (incl. shipping from China) it came with no documentation or other information, but I hadn’t expected any. Since most LCD modules use the same protocol as the ubiquitous Hitachi HD44780 controller, that was my first line of attack. However, all of my attempts to initialize the display via the standard HD44780 procedures failed. After a bit of searching I found this site (in German, Google translation here). Towards the bottom of this page the author mentions a few methods of identifying an unknown display, and more importantly, a number of alternative controller chips that are being used and some of their known quirks. I downloaded the datasheets of those controllers and started to take a look.
One thing that’s noticeably different between the chips is their pinout. This, I thought, might be another way of identifying the controller. The Samsung KS0066U and the Sitronix ST7066U have identical pinouts, but the Samsung KS0073 is different, and the Sitronix ST7036 has an entirely different shape and more pins.
The backside of my LCD module looks like this:
The pins on the top are (from right!), 1 = GND, 2 = VDD, 3=V0, 4=RS, 5=RW, 6=E, 7-14 = DB0-7, 14=LEDA, 15=LEDK. Given its proximity to the pins, the device named U1 is most likely the main controller, so let’s take a closer look!
In this image, I labelled the vias which connect directly to the pins above. What’s immediately clear is that RS, RW, E and the data bus lines seem to connect directly to the chip in a straight forward, anti-clockwise manner. Clockwise from RS there are two unknown traces, followed by a connection to VDD (the thick trace), two more unknown traces, and then a number of traces that connect to the 5 identical 2.2k resistors and to V0 at the top, and VDD at the bottom. The next two traces connect to a 91k resistor labelled RF, and trace next to it connects to the ground plane. If we compare this to the pinout of the KS0066U, for instance, we will notice that the arrangement of the traces would match the arrangement of the traces almost perfectly:
RS, RW and E are pads 36-38, DB0 to DB7 are pads 39-46. The two unknown pads next to RS are D (35) and M (34), followed by VDD, two pads labelled CLK1 and CLK2, 5 pads labelled V5 through V1, and then two pads OSC1 and OSC2 (pads 24 and 25). Lastly, pad 23 is a GND pad. The order of the pins therefore seems to match well onto the traces on the module. One apparent inconsistency however is that, according to the traces, DB0-DB2 should be on one side of the IC, and DB3-DB7 on the other, while according to the pinout only DB0 and DB1 are on the same side and DB2 is already on the other side with the rest of the data pins. While it’s not 100% sure that my controller is a KS0066U or a ST7066U it seems to be at least very close to it in design. And once I tried the initialization described in the KS0066U datasheet my module started to work just fine.
One thing I want to do, now that I know a little bit more about the controller, is change the “RF” resistor. The module is sold as a 5V supply voltage device, but the datasheet says it works from lower voltages as well, which I would prefer to use (as I plan to use the display either with my STM32F4-Discovery, or a TI MSP430). It already works with only a 3.3V supply voltage, but the data sheet recommends a 75k resistor between the oscillator pins instead of the 91k resistor currently installed when running it below 4.5V. However, before I do that I think I want to actually do some measurements before and after to see what changes.
What made the STM32F4-Discovery board so attractive for me was the fact that it comes with a nice on-board Audio-DAC with integrated amplifier, the Cirrus Logic CS43L22. However, getting the combination of STM32F4 and CS43L22 to produce any sound is anything but trivial for someone just starting out with ARM microcontroller development (like me). After having spend quite a few hours in the last week making it happen, and I finally did, I thought it might be worthwhile writing it down here in case others want to follow along.
This tutorial assumes that you set up your development environment already, and have at least managed to get an LED to blink. If not, there are several tutorials on the web that should be able to show you how to do this. This tutorial will make heavy use of the “Standard Peripheral Library” that ST provides for it’s microcontrollers. It is integrated into the IDE I am using (CooCox CoIDE), and I found it incredibly useful, especially in combination with the documentation that comes with in in form of a .chm (compiled HTML help file).
One way in which it’s easy to tell that I’m still relatively new to the whole electronics and microcontroller hobby is by the amount of new developments in this area I tend to miss until much later. One of those is the release of the STM32F4-Discovery evaluation boards from ST Microelectronics. While I was aware of some of their other STM32 ARM based boards (and had considered buying one of them), this particular one had escaped my notice until a few weeks ago. But why is this such a big deal, you will ask. Well, the big deal, for me at least, is that the STM32F4-Discovery comes with a microcontroller and a few peripherals that fit perfectly with my particular interests.
So what do you get with an STM32F4-Discovery board? At the heart of the board is an STM32F407VGT6 microcontroller. That’s a 32-bit ARM Cortex-M4 based microcontroller with 1MB onboard Flash and 197kb RAM, which can run at up to 168 MHz. Importantly for me, it is classified as a “Digital Signal Controller”, because the Cortex-M4 core is essentially a Cortex-M3 core with added DSP instructions. While it certainly wont be able to compete with dedicated DSP devices, it should still provide a decent amount of computing power for moderate DSP applications. What’s also nice is that every single one of the 100 pins of the LQFP100 packaged device is routed to two headers on the board, although only about half of them are still unused. The other pins are already connected to some of the onboard peripheral devices.
The other devices on the board are the ST-LINK/V2 section at the top, which is used to program the device, but can also be used stand-alone to program and debug external devices. This alone makes the STM32F4-Discovery a very interesting board. Even more important for me, however, was the fact that it includes am onboard DAC with headphone amplifier (a Cirrus Logic CS43L22) and a headphone jack of course. It also includes a digital microphone (ST MP45DT02), a MEMS accelerometer (ST LIS30DL) and a few LED’s, 2 push-buttons and a micro-AB USB connector. This should make it very easy to try out some sound-related applications and other little things (how about changing cutoff frequency and resonance of an audio filter by tilting the board?)
So last weekend I ordered the STM32F4-Discovery from Farnell/Element14 for just under 10 Pounds (+VAT). I filled my 20-Pound minimum order with a few 8/16-bit micros (several TI MSP430’s and an Atmel AVR), which should come in handy as support chips for slightly more complex prototypes. The order arrived 2 days later, but I haven’t had much time to play with the board yet (partly due to extreme weather conditions here). However, I’m very excited to get my proverbial hands dirty with this little board.
I like taking stuff apart, especially stuff with electronics in them, so when I saw an old VCR next to a trash bin in the alley behind our house, I had to take it in. There are obviously quite a few interesting bits inside a VCR, both mechanical and electronic. One of the things I was mostly interested with the VCR was the different electrical motors in it. Altogether there were at least two: one to operate the mechanism to load and unload the video cassette and the so-called capstan, the part that actually pulls the tape. The video drum also seems to have some sort of motor like components (permanent magnets and coils), but I haven’t figured out yet if they actually produce rotations, or if they are used for the reading and recording of the video tracks on the tape.
The capstan motor was placed on its own little module and was therefore very easy to take out. It came with a small PCB with a few surface mount components, most notably a 34-pin QFP. The part number LB1952 identified it as a brushless motor driver specifically for VCR capstans. The datasheet for the device was very easy to find.
The pins on the connector on the board were also nicely labelled so it was fairly easy to identify which of the connector pins connected to which pins on the IC. I only mixed up the two voltage pins. I had falsely assumed that VCC1 would be the controller voltage supply, as it was next to S-GND (=signal ground?), whereas VCC2 would be the output, i.e. motor supply voltage (since it’s next to M-GND =motor ground?). It turned out to be the opposite, which I found out after I measured the voltage at VREF, which if unconnected should show a level of approx. 0.43 x Vcc. Besides the supply voltages, the three important signals are F/R, CONT and LIMIT. F/R specifies the direction of rotation (forward/reverse), so can either be tied to ground or Vcc. CONT is the main speed control voltage, in the range VREF to Vcc. LIMIT is a current limiting control. As mentioned, VREF can be left unconnected. FG seems to connect to the FG-OUT pin on the device, the “FG amplifier output pin”. I have yet to learn what that means and how to use it – it seems to related to some sort of feedback mechanism, so may very well be quite useful. However, for now I left it unconnected.
To control the speed I decided to make use of the Boarduino I had laying around. I still use the default bootloader it came with, but wrote the program for the ATmega328P in AVR Studio to have tighter control over the timing of things. To generate a variable control voltage I used one of the 16-bit capture/compare timer modules to generate a PWM signal. I set the module up for 10-bit “fast-PWM” mode, and have the counter running at the main clock frequency (16Mhz), i.e. without a clock prescaler. I set it up to turn off the timer output pin on compare match and to turn it on when the counter overflows (in this case, reaches the maximum possible with 10 bits). Adjusting the compare value therefore sets the duty-cycle directly. This should give me a main PWM frequency of approximately 15.6kHz (=16MHz/2^10). I implemented a simple 2-pole RC low-pass filter to smooth the voltage. This probably wouldn’t be necessary, as the momentum of the motor itself should act as a filter, but I figured it couldn’t hurt.
For my first tests I connected two push buttons to increase and decrease the duty cycle via the comparator value. I used pin-change interrupts and one of the other timer modules (this time with heavy prescaling and overflow counting) to implement a simple software button bounce algorithm. This had the neat side effect that main() ended up being an empty while(1) loop. I could have probably even put the micro into a sleep mode – I’ll have to look into this.
The whole setup seemed to work quite well, though it was fairly clear that the relationship between the control voltage and the speed isn’t a simple linear one. The next step will be to actually measure the rotational speed with the microcontroller so it can dynamically adjust the control voltage(s) to maintain a set target speed.
A few weeks ago I did what I had wanted to do for a long time: take the old computer power supply I had laying around and convert it to a simple bench power supply. There are plenty of instructions on the web on how to do this. The idea behind all of them is quite simple: Since a standard computer power supply provides several different voltage levels to the motherboard and the built-in peripherals (hard drives, graphics card, etc.), it would be useful to make these outputs available via standard connectors (often banana plugs). You can then use these voltages during prototyping of any of your electronics projects. This is especially useful when you need multiple voltages. The two main voltage levels provided are +12 Volts and +5 Volts, but often you also have a +3.3 Volt output and a few negative supplies (-5, -12). For my conversion I used the three positive outputs only, though I may connect the negative outputs in the future as well. In my supply, the red socket provides the 5V output, blue the 3.3V and yellow the +12V. The two black sockets are ground.
The switch came from an old hot air gun that had stopped working. Even though the PSU has a power switch on the mains input side, I wanted a switch on the ‘user’ side as well. I also added a red LED, which I connected to the “power good” signal (via an appropriate resistor).
When I first opened the PSU, I was shocked to see the poor quality of the device. It came from a fairly cheap old PC, so I didn’t expect great quality, but I was surprised by all the exposed mains connections and the giant solder blobs on the bottom (I should have taken a picture!). I also had to replace two of the capacitors – the ones that where in there had blown. That at least wasn’t a surprise. The one positive surprise was that the fan still works flawlessly, and is probably one of the quietest fans of that size I had ever heard. When I first turned it on after my conversion, I thought the fan wasn’t working any more because I could hear nothing. But a quick look showed that it was spinning happily.
So, all in all the conversion seems to have gone well, and I can now stop using wall-wart supplies or batteries when I want to try out a new circuit. If you are considering doing such a conversion yourself, be sure to follow the appropriate safety precautions. Remember that you are dealing with mains voltages in parts of the circuit, so there are all kinds of real dangers! More so if you have a cheaply constructed design such as I had!
This was posted on Hack A Day today, and it seems an appropriate first post for this blog. It clearly captures one of my interests, namely digital processor technology (and a little bit of their history).
Today ARM (now standing for Advanced RISC Machines) processors can be found in huge variety of different products, such as smart phones, tablets or similar devices. Interestingly, the company itself does not actually produce the processors itself, but rather licenses the design of the processor cores to the various chipmakers such as Freescale, Atmel or Texas Instruments.