MCU Series, 2: Sometimes MCU choice doesn’t matter

This article was originally posted on Microcontroller Central, which is no longer on the air. Much of the content is as it was when I originally posted it, with updates when necessary to correct errors in the original articles or reflect more current information. The following first appeared February 22, 2012.

In an earlier post, I discussed taking a 555 timer-based oscillator out of a high-voltage supply and replacing it with a PWM signal from a microcontroller. The design, an open-source Geiger counter, already has an Atmel ATTINY2313 MCU, but I had read someplace that it couldn’t handle both PWM and the other processing required for the circuit. That didn’t and doesn’t make any sense to me, but because it came from the Internet, it has to be true. Right? Relying on my Internet information source, I was going to use a PIC MCU to provide the PWM signal in my design. However, rather than leaving the Atmel stone unturned, I decided to try out its PWM first and see for myself if the chip could handle the whole task. The Geiger counter firmware already uses two timers: Timer0 for PWM chirp tone generation and Timer1 for actual timing duties. I’ll need a third PWM to feed the LC part of the HV supply.

The Atmel chip has four PWM channels, but the clock setup is a little different from the PIC chips I normally use. My first interpretation of the ATTINY data sheet revealed only two timers on the chip: an eight-bit and a 16-bit. That didn’t seem to be enough to drive the four PWMs that the chip offers. Fortunately, a little more research uncovered that the chip has two eight bit timers, and that each half of the 16-bit timer drives a PWM independently. All four channels are covered, after all.

That question being answered, the next step is to generate a PWM signal and mod-wire it in to replace the 555-based oscillator. Pin 9 of the ATTINY2313, OC0B/T1/PD5, is unused in the open-source design, so I’ll use that pin for the feed to the HV supply. I need 4-5KHz for the power supply’s LC circuit.

Deciding to try the Atmel part instead of a PIC MCU gave me an opportunity to explore the differences between the two parts by comparing the code needed to configure the PWMs. First, here’s the PWM setup for my PIC16F1825:

  • // Set HV power supply CCP2 to 4.9KHz, ~20% duty cycle
  • CCPTMRS = 0b00010000; // Select timers for PWM. CCP2 = Timer 2, CCP3 = Timer 4
  • PR2 = 0x65; // PWM period 4.9KHz (With 8MHz system clock)
  • T2CON = 0b00000101; // Timer 2 on, Prescaler = 4
  • CCP2CON = 0b00001100; // Turn CCP2 (RA5) on
  • CCPR2L = 0x33; // Set to 20% duty cycle
  • TRISA5 = 0; // Clear pin direction to enable

Now the comparable code in the ATTINY2313:

  • // Set HV power supply OC0B to 4KHz, ~20% duty cycle
  • DDRD = _BV(PD6) | _BV(PD5); // Set PD5 as output for PWM
  • TCCR0B = (0<(0<OCR0B = 0x33; // Set to 20% duty cycle

The ATTINY version seems simpler to program, though it’s entirely possible that I’m missing something, or that other parts of the initialization are done someplace else in the open-source code I’m starting with. As far as function is concerned, though, the two devices are effectively the same.

The more familiar I get with Atmel chips, the fewer functional differences I see between them and their Microchip counterparts. Microchip seems to have more varieties, but each Atmel variety covers a broader feature set.

In the end, they’re pretty much the same in my book. Before I started using Atmel chips, I really didn’t see what the big argument between the two MCU camps was all about. Now I see it even less. The differences just don’t matter.

NOTE: Since this was originally published, Microchip purchased Atmel, so it may soon matter even less.

Raspberry Pi I2C dual motor driver

My Raspberry Pi dual motor driver has evolved quite a bit since I last wrote about it. In the original incarnation, I had planned on using the PWM capability straight from the Raspberry Pi to drive the TB6621FNG motor driver. That didn’t work so well due to the fact that Linux on the Pi isn’t a real-time OS, and there is only one hardware PWM.

To get around that, I added a PIC16F1826 to directly drive the motor. The Pi will send commands over I2C to the PIC, which will control the motor driver. It’s almost identical to an older (pre-Raspberry Pi) design I have.

Once I figured out how to reliably use I2C on the Pi, it turned out to be a good route to take. The PIC is inexpensive and plenty capable of doing the job. The Pi doesn’t need to worry about real-time control.

Below, I’ve got the almost complete robot stack: Motor mounting board, USB hub with WiFi adapter, Pi Zero, LiPoly supply, and I2C motor driver board. It’s also got a Sparkfun IMU board that will soon be replaced by my own.

3-20160810_173509

Raspberry Pi dual motor driver

This is only sort of a new design. I’ve used this TB6621FNG dual motor driver chip on a number of my boards prior to this one. I basically just took one of my existing boards and shuffled things around a bit to fit the Raspberry Pi Zero form factor.

In this photo, I’m using it with a Pi A+ while writing some Python code to test it out. Eventually (when I can get more than one Pi Zero), I plan to use this in a stack, with a Pi Zero, my LiPoly battery board, and my USB hub board for WiFi.

SImblee Breakout Shield, Part 3

When we last heard from out intrepid Simblee Breakout Shield, it was found to be using and open drain linelevel converter without pull-up resistors, and that’s against the law. Or, at lease against good judgement.

After a dual face palm, I found the TXB0108PWR chip, again from Texas Instruments. This one is a push-pull line level converter, so no pull up resistors are needed on the GPIO. The pin-outs are close between the two chips, but not exact. Too bad. It would have been nice to just drop in the different chip. But, the I2C still needs pull ups anyway. ,I gave it a TXS0102 open-drain converter, and pull-ups and ordered the revised boards.

After I build and test this one, I’ll move on to the next version. I want to dispense with the breakout, and put the Simblee chip directly on the shield. I’m also going to use Silego chips for the line level converters. If you haven’t heard of the Silego chips, they’re very small mixed-signal programmable logic. I’ll write more about them later.

 

Run Fourier, run

Simblee Breakout Shield, Part 2

I stumbled, and made progress on my Simblee breakout shield. If you didn’t see the first installment, check it out first.

Since the first post, I built up a non-shorted board. It seemed mostly okay, except that it gave me 3.9 volts on the 3 volt side, and the same on the 5 volt side. The answer to the puzzle lead me to one of the downfalls of open source hardware (well, it’s only a downfall in combination with poor practices). That is, not knowing what the original designer had in mind.

I took a look at the Arduino 101, which uses a 3 volt Intel Curie module. The Arduino 101 uses a Texas Instruments LSF0108PWR line level Arduino 101converter chip. Works for them, so I designed it in. Folly me, I didn’t read the data sheet close enough. It’s an open drain device and needs pull-up resistors on the I/O lines.

The 101 didn’t use pull-up resistors. It gets by because most 5 volt devices are fine with the 3 volt “1”. They’re really just using the chip as a5 volt to 3 volt done converter and not worrying about going up to 5 volt line levels.

 

Why not push ups?

Final Pi Zero LiPoly mod

I solved the final issue with my LiPoly board. It was a minor one. The yellow LED is supposed to indicate whether the LiPoly battery is on or off. It was always on. In a Captain Obvious moment, I discovered that it was always on, because I told it to. I had connected both sides of the DPDT switch together. Why? I don’t know.

But, with a lifted pin, one cut trace, and a short mod wire, it’s all set.

I already have the next set of PC boards on the way, so they’ll still require this mod. It’ll be easier to deal with before there are parts on the board. I may not order any more boards, with this fixed. I’ll have plenty for my own uses, so unless I decide to sell it, there won’t be a need. I’m thinking about a Kickstarter for this though…

 

Poly want a… Poly want a… Poly want a Lithium?

Beagle Blues

I’ve been having a lot of fun with my Raspberry Pi boards lately, as I’ve described in a few of my prior posts. With that under my belt, I decided to get out my BeagleBone Black and put it to use.

Unfortunately, I did something terrible to it – or just made a simple undiscovered error. When I plugged it in, my PC recognized it as as drive, as it’s supposed to. However, after downloading and installing the latest version of the drivers, that situation changed. I can no longer see it as a drive, I can’t see it on wired Ethernet, and I can’t see it on WiFi. I get te same results when trying to boot natively, and with a micro SD the most recent Ubuntu distribution. Yyargh

Update – I got it working. I just flashed Ubuntu onto the BBB instead of boothing from the SD or the old eMMC image. I’m thinking about putting ROS on it now and see what I can do with it.

 

BengalBreakBlue

Raspberry Pi Zero stack-up

Not stack-up, as in PC board layer stack-up, but add-on board stack-up…

The LiPoly board is working fine, as detailed in my prior posts. The USB hub board is also working. The stack shown here has the Pi Zero and both boards. As shown the D+ and D- lines from the USB hub aren’t connected to the Pi.

For the moment, I connect them with a cable, but I’ve got a small interconnect PC board on the way. With that, I won’t need extra cables and won’t need to hard solder the boards together. I’ll post pictures when it comes in.

 

She’ll be coming ’round the mountain when my boards come in

Raspberry Pi UPS

I built up two more of my Raspberry Pi LiPoly battery back up boards today. After doing so, it occurred to me that, in addition to allowing for portable use of a Raspberry Pi Zero, as I had originally intended, the board, with a few minor modifications, will work quite well as a UPS (uninterruptible power supply).

I wired the output from the comparitor to GPIO 21 on the Pi expansion header. I’ll be able to monitor it to detect when the external power is off. I can then gracefully shut everything down.

Without anything else running, a small 150 mAh battery will give me about 40 minutes run time with a Pi A+, and about 20 minutes with a Pi 3. Add in peripherals, and it will go down a bit from there. Regardless, it will have plenty of time for a clean shut down, or to wait out a short power outage.

The cover image here shows my Pi A+, and my Pi 3 with their UPS integrated. I still need to drill a hole in the case lids so I can flip the power switch. Otherwise, I’ll have to pop the lid off if I want to completely shut it down. Not a big deal, but still something I should do.

 

Pi Zero LiPoly – Final

Pi with my LiPoly board

My Pi Zero LiPoly board was working, but not exactly in the way it’s supposed to. Charging was fine. Powering the Pi from the battery, fine. Th problem came on the net MCP_IN, in the schematic below. I was reading voltage at the test point for MCP_IN, JP4.

Schmatic v1.2Either the comparitor wasn’t comparing properly, or the MOSFET wasn’t blocking all current when shut off. Or, something else was wrong.

That “something else” was a pretty rookie mistake. See if you can find it before looking below…

Error in v1.2Long enough. My comparitor was wonky, because it was unpowered, as you can see in the image below. +5 volts doesn’t actually connect to the +V pin on the comparitor chip.

Fixed that and it works exactly as expected now.