Tag Archives: PIC

Everyone plays guitar…

It has dawned on me that whilst I don’t pay a lot a month for hosting, I do actually pay something and so not keeping this blog up-to-date could be construed as a waste of money.

With that in mind I have an update – hooray.

I built my first guitar more than 10 years ago, whilst still at secondary school. I had only been playing for a few years, and I wanted something that would stand out both visually and aurally.

I started with a strat body, and a random neck I bought off eBay. I cut the scratch plate out of some clear acrylic, and mounted combination of a P-90, humbucker and single coil pickups. These were all wired together through a vast array of switches to enable me to switch any combination of pickups in both parallel or series, and either in or out of phase. Looking back it was a hideous rats nest of wiring, but that was nothing compared to the paint job.

I sat in the garage with my sister, who was 5 at the time, and we painted it with all the paints I could find. It was gloss, matte, and metallic, with a crackled finish in areas.

Since then I’ve bought 2 more guitars, and modified the wiring each time, but now I am more selective over the components. I try to select parts that match the current hardware, or add functionality without adding to the part count. All of this is leading to the real point of this post. I am designing a guitar pedal.

I have been meaning to design a pedal for a number of years, and I had no real reason to not do it. Every time I would sit down and work out what it needed, but I would always be put off by one aspect or another. There are hundreds of questions that stop me from progressing. What do I want the pedal to do? How do I control the modification to the sound? Is a 12bit ADC and DAC going to be enough? Do I have an analogue front end to mix the effect in, or deal with it in digital? Do I want a “true bypass” pedal, or is all the signal going into the processor at all times? Do I stick with what I know and use Microchip’s PIC32, go for a multi-core Parallax Propeller, or try my hand at one of Freescale’s DSP chips? Instead of letting the questions buzz around, I took the plunge and started the design of my pedal.

The signal is first passed through a capacitor, effectively removing the DC component. The signal is the biased at Vcc/2, and pass through an op-amp – TI’s LMV321. This will apply some gain to the signal, before feeding into the ADC – Microchip’s MCP3202; a 12bit ADC. It’s not the best ADC on the market, but it’s pretty cheap and will do the job for now. The digital data is then read in by Microchip’s PIC32MX764F128H. With a core frequency of 80MHz, this should be more than enough to perform some basic effects. Following manipulation, the data is then sent to the DAC – Microchip’s MCP4822; a 12bit DAC. Again, it’s not the best DAC around, but I am not aiming for that yet. Finally, I used a unity gain buffer to match any impedances, remove any DC component, and allow the next device in the chain to handle the signal. The parts selected were spares left over from previous projects. The only new purchases were the 6.35mm jacks and metal 1590A enclosure. It should be obvious that this is not going to be the best pedal in the world. I’m sure that any analogue aficionado will berate me for my choice of op-amp, and any audiophile will say that the minimum number of bits to consider would be 24. But they would be missing the point.

This pedal is my start line. It will allow me to see the weak points in the design. I should have mapped the control rotary encoders to an “Interrupt-On-Change” pin as the are a bit slow to respond, or sometimes appear to run in reverse. I should have use a codec IC with build-in 24bit ADC/DAC. I should have used analogue switches to bypass the circuit when disabled. By this time next week, I will have some answers.

After antagonising over this pedal for years, I have finally started. I spent around 2 days drawing a schematic and laying out a PCB. There’s some code still to be done, but a lot of it was written in the 2 weeks waiting for PCB’s to arrive. I’ve got PCBs from iTeadStudio for $27.59 (under £20), and all my components for around £25. For under £50, I have designed a programmable multi-fx guitar pedal. And I have no doubt that I’ll be doing the same next week.

Stereotypical beginners electronics project

The In-Laws have just moved house. I say move house, but what I mean is sold their old self-build, bought a field in deepest darkest Norfolk and are planning to self-build again. This is great news because it means they’ve got a blank canvas to fill with numerous eco-build projects. The first of which is a criminal deterent. I’m sure the working ip-camera will be used at some point but until then a decoy camera will have to suffice. Decoy cameras work fine so long at they remain believable, and so this decoy camera needs that little extra bit of polish; a flashing LED.

The flashing LED project is the “Hello World” for those whose programming language is solder. Any time you learn a new microcontroller, you will face the flashing LED tutorial. This is designed so that you can set up all the important registers and interface with the outside world. When you talk about flashing LED projects without using a mcu, people will generally offer the 555 timer as a solution. I’m going to look at three options, and hopefully have a working flashing light at the end.

The main design considerations are the need for a long battery life, and a fairly cheap design. I’m going to be using the LPKF Protomat C60 at work to cut the board out, and I’ll be trying to use components I have in my bits box, or can get free samples of. I am aiming for the design to fit on the back of my selected battery solution, and have a suitable mounting fixture integrated into the PCB design.

I know I need to use battery power, and once installed the batteries can’t really be changed. The build should take 2 years, and so I am aiming for more than that. I’m going to overengineer this aspect horendiously as my professional integrety is at stake. Obviously, a car battery would be a rediculous solution, and although space is not at a premium I’d still like to make the package small. My options consist of a single PP3 battery, a single CR2032, or a pair of AA batteries. The CR2032 only has a capacity of around 200mAh, with the PP3 only doubling that. The AA has to be the victor at well over 1000mAh. Thankfully, the AA battery holder is a also almost half the cost of a CR2032 holder. Lastly, is the actual flashing LED. A flashing light project without a flashing light simply isn’t. The minimum current draw I can reasonably expect to look at is 1mA. Any lower and I dont think the LED would be bright enough to see at a distance. The human visual cortex holds onto an image for about 1/15s, or approx 66ms, so I think that 100ms is a reasonable on time for the circuit.

I’ve mentioned the 555 timer as a possible solution so lets examine that a bit closer. Normally, the 555 doesn’t output a duty cycle of less that 50% which is bad for a low power design. The duty cycle issue can be addressed with a 1N4148 in parallel with the resistor between the discharge and trigger pins. Alternatively, you can reverse the LED and connect to Vdd instead of Vss, sinking current through the 555. The ICM7555 is Maxim’s low power derivative of the 555, having a typical supply current of 60uA. Assuming a battery capacity of 1000mAh, the 555 would run for 16666.67 hours (a month less than 2 years) without flashing an LED. The 555 just doesn’t cut it.

The next obvious solution would be a low power microcontroller. This is great as the LED can do more than just flash. It can reverse bias the LED to work as a light detection circuit, and the LED can do a double flash for extra realism. The PIC18LF13K22 has a low power sleep current consumption of only 460nA. This would be 34nA but I need to keep a timer running to wake the thing up. Even a draw of 460nA  gives a run time of 248 years on a 1000mA battery, which is just crazy. Adding the LED gives a battery life of 5 and a half years. With a BOM of only 5 components this ticks every box, but using a microcontroller feels like cheating. I think this will be my backup plan if the next idea falls through.

My final option is an op-amp. The op-amp in question is Linear Technology’s LMC7215. By using positive and negative feedback and a crafty 1N4148, the LMC7215 can be made to oscillate with a definable peroid and duty cycle. I used LTSpice to simulate the actual circuit and can extract the predicted current draw (tutorial to follow), giving a battery life of just over 5 years. Using my parts box, I managed to get a on-time of 92ms, and a period of 4 seconds.

 

 

 

 

 

 

 

 

The op-amp circuit does give a higher parts count, but this still ticks every box, and I think it is more elegant than the PIC solution. Next article, I will be showing how to use LTSpice to come up with the appropriate values, and importing SPICE definitions into the circuit. I will also lay out the PCB in CAD, and start the enclosure design. See you then.

Free Day recap and blasted Android

This post will be a shadow of the one that I had originally composed using the WordPress for Android app that I installed last night. It had wit aplenty, but my phone decided that it had a better idea – and managed to lose every character. With that aside, let me get started.

I completed my children’s toy. I designed in about 6 games that managed to please the youngest through to eldest, and have only used around 10% of the program memory. I wasn’t affected too much by feature creep, and I’ve started looking at a NiMH charging circuit so I shouldn’t have to open the box to charge the batteries. I clearly have a lot to learn about toy design, as the power connector has broken. I used some 100 thou pitch header pins to act as the power connector, and I forgot to close the box after a late night adding the scoring functionality leading to two snapped pins. This wouldn’t be so bad apart from the fact they snapped inside the female header pins. I ran into another hitch when water got spilt on the toy. I had used some fibre washers (instead of nylon) and even once the spillage had been mopped up I still had a 7ohm short across my power rails.

Part of the design brief was to build something to teach my children about electronics in one form or another. Every time I meet up with my family, I get reminded about things I did when I was younger; including sticking coat hangers in plug sockets, taking TV’s apart, and electrocuting my little brother with my bedroom light. The response to escapades was receiving a 100-in-1 electronics workbench. Whilst this was a great idea, I didn’t learn anything from it. Not because I already knew how the circuits operated, but because I followed the instruction booklet until the circuit worked. Schools answer to electronics was Ohm’s Law and logic gates. It wasn’t until university that I began to lean how circuits worked. I don’t want this for my children. I don’t want my children to be part of the throw-away culture that I grew up during, and I don’t want them to have to put up with toys where batteries last a day because the designer had to save a penny on a power switch. I’ve designed power saving features into this toy; the PIC sleeps whenever it can, and everything sits behind a LDO voltage regulator with a shutdown pin. I’ve not worked out what the battery life should be, but they lasted a month before the pins snapped. I designed the case with a clear front, and tried to minimise the number of tracks on the bottom layer. The idea behind this was so that it was possible to see how everything connects together. Of course this led to embarrassment when the lack of sleep and a silkscreen meant that a couple of chips were soldered the wrong way round. This shouldn’t have been a problem apart from when I delaminated one of the pads and had to solder in a jumper wire.

Yes, I did say pads. This board was primarily surface mount. Despite working on PCB’s daily, I still consider myself to be a hobbyist and unlike a number of hobbyists I prefer surface mount components. I am fortunate to have access to a PCB cutting machine at work, and so UV light boxes and PCB pillar drills are a thing of the past. The board is easy enough for a child to manufacture, but I wouldn’t trust my 6 year old with hand soldering a 0.5mm pitch TQFP chip. All I have taught my children is that they can write firmware for toys. I decided to supplement this was some soldering on another product, just to hammer home that the can create usable things. Whilst growing up, my grandfather made an electronic die. I wanted to go beyond this, so foolishly bought an electronic die kit. This was only £6 from Maplins (similar to RadioShack), but it meant having the kit straight away. The circuit consisted of a PPL chip, binary counter, LEDs and a load of passive electronics. The PCB has a solder mask and so was relatively simple for said 6 year old to assemble under intense supervision. I was tempted to make a case for it, and include a power switch to make it a finished product – but I am not happy with the design.

I know hundreds, if not thousands, of people dislike using microcontrollers to flash LEDs. An electronic die is a flashy light project, and one that is clearly doesn’t need a microcontroller. Using PLL and binary counter chips give a pretty simple circuit, but uses 30 components – and will eat through the PP3 battery. I am planning on designing a replacement circuit using the PIC18F14K22 as the brains. I want to use the minimum number of components whilst retaining the feel of a die. This means I need to use 7 LEDs as die pips instead of a single 7 segment display. The remainder of my circuit will consist of a piezo-transducer and CR2032 coin cell. As I’m powering the circuit from a 3.0v cell, I should be able to ignore the requirement for current limiting resistors on the LEDs. Failing that, it should be possible to use PWM to help limit the current. A diode and resistor are needed to protect the PIC from the voltages generated by the piezo, and a resistor is needed to bias the MCLR pin. This gives a total of 13 components.

I have no experience of cost analysis, or cost reduction. It is immediately obvious that there are fewer components. This means a cheaper PCB as the PCB is smaller and requires less processing. Smaller PCB and fewer components mean cheaper shipping. Fewer components means less warehouse utilisation and the board is quicker to assemble. On the other side, the PIC costs slightly more than the PPL and binary counter chips, and time is spent programming the device. An additional overhead cost would be the time developing firmware for the die. I haven’t touched on the “running cost” of the die as battery life needs to be considered. And finally, there is the case of perceived value, “coolness”, and appropriateness.

Functionally, the bought kit performs adequately. Once the button is pressed, a 100nF capacitor is charged and used to trigger the PLL. As the voltage decays, the PLL slows down and eventually stops. The effect is that the LEDs flash as the numbers roll round and stop on a particular value. This value is effectively random, as the numbers roll round quicker than human perception. My version would use the PIC’s ADC to convert the piezo-transducer voltage to a binary representation. Additionally, I will keep the PIC in a low-power sleep mode to be awoken by the piezo voltage spike. My chosen PIC is a 20pin device, so I don’t need to resort to Charlie-plexing to light the LEDs. Both designs would have a suitably random roll rate, but in my opinion the PIC method has an overall higher perceived value.

I want this to look like a quality product. To this end, I am considering using iTeadStudio for PCBs and some of the tools at work for an acrylic case. We will see how that turns out, but for now I’ve got to wait for my Sparkfun freebies. I say freebies, but I’ve already paid form shipping, and I’m fairly sure I’ll need to stump money for VAT. Oh the joys of living in the UK.

Excuses

I made a promise that I would have some extra info on stepper motors, and clearly this isn’t it. I got very distracted with the parallel port work. Parallel port stuff used to be easy in Win98 and earlier, but got more difficult in XP. By more difficult I mean I had to install “inpout32.dll” and do some funky stuff in C#. But to use “inpout32.dll” you have to know the I/O start address, so I started blindly running towards what I thought the solution was.

To find out your start address you can simply head to Device Manager, open up the LPT tab, and click on Resources. For me, the I/O range starts at 0378. This is not the value you want, as it is the HEX representation of the address. As it turns out the integer address is 888. To save the user from going through these steps I had to dip into WMI and extract the information from there. Now there is no one place where you can tie together “LPT” and port address, so I had to connect them together using the PnPDeviceID. This took me ages to figure out as I had never used WMI before. Long story short, I have got the stepper turning controlled from the parallel port and also from a PIC from RS232.All I need to do is write the article, and generate some usable schematics.

However, I got distracted by designing something for my kids to play with. As an engineer I can’t help but be critical of a large number of children toys. I am not including things like Mindstorms, but I guess you get what you pay for. I want to show my children that electronics isn’t magic. They all use technology in one form or another, but I don’t want them to take it for granted. I want to show how a TV remote works, and how they can use something instead of the remote to change channels.

At the moment I have specced out some features, and it has already suffered from significant feature creep:

  • Fit inside a dual gang back box (850x1470x35mm)
  • Clear acrylic lid to show electronics
  • Attempt to route everything on top layer
  • 16 red/green LEDs
  • 16 tactile switches
  • 16×2 LCD display
  • Rotary encoder
  • Powered from 4 rechargeable batteries
  • Small prototype area

I want to make sure this will grow as they do, and have features so it will entertain all of them (20months – 6 years). There is little doubt that it will remain interesting for all of 5 minutes, but that is no different from any of their toys. Currently I am deciding whether I should include any IR LEDs for controlling the TV, or  Sparkfun’s 3-axis gyroscope. I’ve even got a small touchscreen digitizer that could make its way inside. And of course there is always room for a little speaker.

Clearly, there is some more feature creep to go.

 

Hello Caller, You Are Through To The Helpdesk Part1

I was getting ready to have an enjoyable weekend catching up on my free Stanford University courses when I received a phone call from my father-in-law. This usually means that some piece of technology has gone wrong and I take the role of helpdesk.  Before you all start drawing conclusions from this; he is fairly technical and so this call means something has gone seriously wrong, and I actually enjoy these challenges. Today’s challenge was a no-name pan/tilt IP Camera.

 

The first step to troubleshooting a problem is to isolate and repeat it. Normally upon power-up the camera would perform a single sweep on both axes, and sit in a centre position. This was not happening – so either the thing wasn’t powered, or the firmware wasn’t running. Plugging a network cable in lit up the status and activity LED’s so at least we knew that it was getting power. I didn’t really want to open the camera yet (purely as it wasn’t mine), so opened up AngryIPScanner and Wireshark. I couldn’t find the device on any subnet despite the activity light flickering. There was no other option, I had to crack this bad boy open.

 

There are a number of chips on the PCB (# ESTESPCB613M136) , including a Nuvoton W90N745CDGARM (main ARM processor), Winbond W9812G6JH (2M SRAM), DM9161 (phy chip), and a WM8731 (audio codec). The other side included a Stansion S29GLO32 (another Flash chip) and a WiFi daughter-board. All in all, not an overly complex board. Due to a poor design choice, the threaded mounting hole is directly above the ARM chip. There was a light witness mark on the ARM, but I was more concerned by the marking on a number of pins – almost as if the solder was squashed. Unfortunately, I don’t have a decent iron at home, so a fix will have to wait until I get back to work. I turned to Google to get more information on the camera. I didn’t have access to the box, so I had no idea who the manufacturer was, but I found out that Foscam used to OEM extremely similar looking cameras in the past, and the likelihood is that this is either one of the OEM variants or a clone thereof.

A typical feature of the Foscam camera range is the presence of a UART header connection, and this was no exception. Although it wasn’t labelled, a quick check of the N745 chip datasheet identified the pins as thus. This enables a terminal connection to the ARM’s bootloader upon power-up. I was using my only remaining Max232 in a different project so I took the opportunity to revive my Open Bench Logic Sniffer. It needed updating to bring it to the current revision, but once that was done I could start on the hard stuff. And here we hit a snag. I updated the Logic Sniffer, and now the USB won’t enumerate. Clearly I am not having a very good day.

 

So before I could start fixing the IP Camera I had to now fix my Logic Sniffer. This was as easy as soldering some header pins to the ICSP and use my PICkit3 to reprogram the PIC. And by easy, I meant I gave up and hit the forums. I had to resort to hunting down my old PICDEM 2 PLUS board (circa 2002) and use the MAX232 onboard. I had to use the same trick to get the keys off my 360 DVD-drive, but that is another story. With fresh wires soldered onto the camera board, and plugged onto the PICDEM2 board, I loaded up RealTerm. Powering up the camera board revealed that the ARM is working (at least part of it), as I get a nice serial interface.

 

Routing around in the terminal revealed that only the bootloader is present, and there is no sight of the linux.bin or romfs.img files that I was expecting. Given this I can draw one of two conclusions; either the data on the flash chip has become corrupt, or the pins with witness marks are actually broken and the ARM can’t talk to the flash chip.

Stay tuned for Part2, where we find out if the camera can be recovered.