Zaethira Progress.

I've been doing a lot lately. Often, when I've had a choice between posting something, and working on something, I've chosen the latter. I noticed recently that I missed the month of November entirely, my bad! To top it off, my last post was a bit of a crotchety vent about haters, and we all know haters are gonna hate.

I've been working a lot on my robot autonomous vehicle, Zaethera. I've also got a ton of other projects in various stages of planning, that I'm keeping mum about for now.

In my last post, I posted a color-coded high level view of the architecture. There's a lot more green now, I'll post an updated chart in my next post. I don't think I dropped any subsystem from the original, and much of the left-hand side is built assembled, and ~50% coded.

I'm beginning to enjoy this electronics hobby thing.
The parts in the Sparkfun box in the back are the rear/side
IR proximity sensors, and the compass module. Near the top,
on the red, black, and blue wires is the IR remote control receiver.

Rant time, a very special episode of Bytecruft.

It's rant time..

I know it's so usual for us nerd/engineering types to get cranky online about something, so this may come as a shock....

I came across a post today on Hack a Day today about a guy who got the .Net Micro Framework running on a STM32F4 Discovery Board, something I have done, and briefly mentioned here.

Original link.

Mr [Singular Engineer] did a fantastic write up by the way, I wish that had existed when I was trying to get up and running, it sounds like his experience was slightly smoother than mine.

Anyways, as I read the comments section on the Hack a day article, I felt compelled against better judgement, to reply to some of the general criticisms against the .Net Micro framework. As my reply grew in the volume of prose, I thought, maybe it would be better presented on my blog. So here ya go:

Robot update.

I haven't posted in a while. The lulls usually happen when I'm busy. I've failed you, my adoring fans, and for that I blame... um squirrels..

I have been happily jamming away for the past couple months on my robot, Zaethira. (Which is a concatenation of my kids' and wife's names, and happens to sound geek awesome, the geekiness of the whole is greater than the geek sum of the parts).

Anyway, I could have written a 20 page blog post about how things are coming along, but I think a diagram does a much better job. I made the below because I needed to get a handle on where I needed to focus and what I planned to do. This diagram made me realize how flipping complex this project is.

Introducing Zaethira - One word: Robots

So I've finally gotten around to one of my dream projects. I'm making a robot.

I'm relinquishment a little bit on my must-do-everything-myself approach I've taken to many of my projects, and I'm using some kits and some pre-fabricated circuit boards. After my experience on my Bench Power Supply, I wanted to boost my odds of getting results and focus on the fun stuff. I really think for this project, despite being something very physical, the software is going to be the most fun part, I am a software guy at heart, after all.

Shortest post ever.

I'm not sure why I have not tried to build a robot sooner. Already the most fun I've ever had on an electronics project, and it's still very early in development.

That is all.

--P

Rudimentary benchmarks for the Parallax Propeller.

I'm in the early stages of a big new, ambitious project, that I've wanted to do for a long time. I've got some Propeller chips from Parallax that I've had sitting around for quite a while, so I thought I'd try to incorporate the 'Prop' as one of the many microcontrollers this project will have.

The Propeller is quite a unique processor, I'd even so far as to say it's design is exotic. What it lacks in specialized hardware found in most other MCU's it makes up for with having 8, that's eight, cores. You want I2C, you just dedicate a core to doing it in software. One of the few exceptions is something not found on many other MCU, it's has dedicated video generation circuitry.

A custom language, "Spin" has historically been the primary high level language used on the chip. Parallax has designed into the ROM a byte-code interpreter. You can also use assembly, especially for performance-critical code. C/C++ had for years been an experimental language on the chip, but that has changed in the past year or so. There is a full fledged GCC port for it. I decided I'd give it a try.

Seeeduino Stalker Waterproof Solar kit review PART 2

In my last post, I covered the Seeeduino Stalker board itself, I wanted to get into some of the other aspects of the kit.

The hardware (continued)

Bench Power Supply

I decided to mothball my power supply project. I may come back to it one day, I may not. I sort of had a rage-quit moment this week-end, when I blew one of the channel's regulator circuits. The thing is, I didn't do anything I didn't think it could handle. Now, the voltage output is always 2 volts higher than what I set it for, and the current-limiting seems to never kick in, it goes to 1 full amp (or at least that's the max I'm capable of measuring) when I short it. Meh. I thought it was more robust than it appeared to be, and I didn't want to spend more time to complete it, only to run into more issues. It needs some re-design.

The Bench Power Supply (Powerbug 6000), in its
open casket, the mothballs are in my head.... and my heart.

So as a wrap up, I'm just going to post some pictures I (and my wife, player with an in-law's camera) took of the project.

Seeeduino Stalker Waterproof Solar kit review

I had a little extra scratch recently, so I decided to geek out on some new toys without  a specific purpose in mind. One of the nuggets I picked up was the Seeeduino Stalker waterproof solar kit. From Seeed Studios in Shenzhen, China.

At the time of writing the kits go for $59.50 US, which, as you'll see in minute, is a pretty good deal, for what you get. I live in North Carolina, and the free shipping via Hong Kong post/registered airmail took about two weeks, give or take a day or two. As an aside, it boggles my mind that I can get something shipped out of Shenzhen *for free*, (my package was several pounds too), and I order something that ships out of a neighboring state and get socked with a $10 shipping fee.

I'm going to take a stab at doing a proper review for the kit, maybe it will inspire me to figure out what to actually do with the thing.

Slowly I turned...

It's been a slow summer. I'm still making progress on the bench power supply. It's in the "just get it done so I can move on" phase.

I've got the regulator part of the circuit finalized. I don't think it's perfect, but I think if I ever want to work on something else, I need to move ahead. Since the powersupply has three channels, I plan to have 3 discrete boards.

Here is one of the boards, pre-soldering:

One channel regulator board.

On the left side of the board, there are two PWM'ed input for the voltage and current settings, and two "Vsense" and "Isense" analog outputs that will run directly to ADC inputs on the Atmega 644. The top of the board will have inputs from the ATX power supply at 12 and 5 volts. A variable 0-9V output will come form the bottom-right side.

Bench Power Supply - Progress Update

Here's a little video I shot of my power supply in action. I think it is very close to being workable. I have a bunch of placeholder parts, since I'm holding off on placing an order for final parts until I do more testing.

One thing I've been working on recently is the current-limit-mode indicator LED's. It's a little but harder of a problem than I thought it would be. My current limit comes from Q1 in the schematic. As the current flowing through R1 rises, it causes the voltage on the "+" input of the U2 op-amp to eventually exceed the ISET voltage. This drives U2's output high which in effect ties U4's output close to ground. My idea was to connect the "+" side of U4 to a spare input on my IO expander, and sample it's value in code. My initial thoughts were that a low value indicates that the circuit is in "current limit" mode. It turns out there are numerous reasons that this wont work. The face palm moment was realizing a low VSET value will also trigger the current limit logic regardless of the actual current! The other major problem was that I was using a digital input to estimate what is really an analog voltage.

Anyways here's the video:

Bench Power Supply - Point of no return

Just  a quick(not really) update.

I've got a lot of the code side of things worked out. I had a lot of "fun" doing software debouncing for my rotary encoders. After hooking up a logic analyzer, I realized that using the I2C IO expander for the encoders was not going to work. The I2C chip I'm using, an MCP23018, has a couple interrupt lines, one of which I used to alert my ATmega that the expander needed attention. Since the expander is an I2C "slave", this is the only way it can initiate communication with the microcontroller. An interrupt handler in my code would set a flag and exit. When my "main update loop" got around to checking that flag it would then issue a series of I2C commands to query the expander for the encoder line change that triggered the original interrupt. All of this turned out to be way too slow to process encoder input. The main culprit was the fact that it depended on the main code loop getting around to checking that flag. From my logic captures, I could see that encoder edge transitions could happen sometimes 5ms apart. When there was a lot going on, such as heavy LCD updates, my main loop could sometimes take 20-30ms to complete one loop. Ouch.

You can't easily, if at all do I2C in an interrupt handler, you can not be sure of what state the I2C line is in when the interrupt fires. In the end, rather than figuring out a way to do I2C in an interrupt, or doing more flag checking (which would have been a hack, sometimes most of the CPU time is spent deep in the LCD bit bang code), the simpler solution was to move the encoders to the AVR itself. I had to give up UART functionality that I was planning, since I'm tight on allocated pins, but I was leaning toward doign that anyways.

Bench Power Supply: Power Control

In this truly awful video, you can see my bench power supply at work.

For testing, I coded a function to cycle the voltage between 0-5.0V.  In reality, 0-100% duty cycle is the parameter the code changes. A "PWM'ed"  square wave(yellow trace) is fed to an RC filter, which is then buffered with an op-amp(the op amp output is the blue trace).

You can also see the LCD updating in realtime. The voltage reading is coming from the ADC on the ATmega 644. It's has a hard time keeping up with the displayed "SET" value, but there probably several factors, the biggest of which purely software related, I simply don't refresh the "widget" that displays the voltage reading any faster than 3Hz. 

(Ignore the Amperage settings/reading, they're not coded yet, the analog portions of that have me the most intimidated)

Anyways, crappy quality aside, this is a great demonstration of how PWM signals can be used to generate analog voltages from a digital MCU pin, and how "duty cycle" affects what comes out of a simple low-pass RC filter.

--P

JSIL

Just a short post:.

I think JSIL:

Is the bees knees.

It's a .Net bytecode (CIL, "common intermediate language") to JavaScript compiler.

Despite the fact that I don't blog about it often, .Net, its frameworks, libraries, tool, and the C# programming language are safely #1 at the top of tech things I love. My .Net Micro Framework project (still in progress, but on temporary hiatus), is my attempt to blend C# with my enthusiasm for embedded development.

Keep an eye on JSIL, I think it will go places. It's the way Silverlight should have been done.

--P

Bench PSU: AVR JTag update #4 (I think I can stick a fork in it now)

I've slowly but surely made progress on my bench power supply. I think my JTAG issues are a thing of the past. I've done a couple things to ensure reliable communications, and I've now got the AVR Dragon running at 2 MHz with 0 errors so far. First, I put the 20pf capacitor on the JTAG clock line, at the breadboard side. I know I derided the lowly 20pf cap in the past as a pawn of the Capacitor Cartels, but I'm eating crow now.

The second thing I did was to create a JTAG "Bread Head", so named in and inspired from this post on Blondihacks: Bread Head. I'm not a great photographer, and macro shots seem to be even harder, but here it goes:

My Atmel 644 (and pin compatible DIP 40s) JTAG
Breadboard adapter. I could probably trim a little more
perfboard off the top.

Bench PSU: AVR JTag update #3

In my last post, I reported that I got my AVR Dragon to work in a 5V circuit by creating what I called a "shielded JTAG cable":

I speculated that "cross talk" interference might have been causing my un-reliable JTAG when running my circuit at 5V. (It worked fine at 3.3V, but some components in my final circuit are 5V parts, I also noticed that many 20 Mhz AVRs are only rated to run at a full 20Mhz above about 4.5V)

I got my DSO Quad hobbyist class digital scope last week, and I was all set to write up a really scientific post documenting my construction and testing of a shielded AVR cable, then something strange happened. I switched to another 2x5 "unshielded" JTAG cable to reproduce my original problem. When I hooked up my DSO to the JTAG clock line, the programming functionality worked flawlessly at 5 Volts! Curse you, Heisenberg! (Yes, I know that this is not really the meaning of the Uncertainty Principle, but any time I run across a case where the act of measuring something alters the quantity I'm trying to measure, I think it it).

Windows Installers - Having it your way.

Despite being my blog about "software and electronics", I've been sparse on posts about what's historically been my bread and butter - the Windows Desktop platform, still the best thing to happen to computing since sliced bread ... and butter. It's just not as sexy as the exotic embedded stuff or the mobile platform du jour.

Aynways I've been meaning to compile and post a list of windows tools that I think rock. I'm always surprised when I find out someone whos been using windows for a long time doesn't knwo about some particular tool I've been using forever and think is essential, "what, you mean you've never heard of SciTE?".

7-zip is definitely a tool in that category. It can open just about anything considered an "archive" format, zip, gzip, tar, rar, iso, and one that I find handy when something's gone wrong: msi and cabs.

I recently got my atmel cpld JTAG programmer, and wanted to install the AtmelISP software. For some reason only known to my PC, the installer refused to complete, and performed a lat minute cancel/rollback at the end of the install.

While the fail dialog was up, I used Sysinterals procmon (another rockin tool, by the way) to find out the installer wrote some temp files that happened to be "msi" (Microsoft installer packages). I copied the msi files and opened with 7zip, which allowed me to extract the atmel isp software. This worked in this case becasue there were no critical scripts run by the installer other that to install ftdi drivers, which I already had installed.


--P

Bench PSU: AVR JTag update #2 (it's alive!)

I think I figured out the noise issue on my ATmega setup.

After I posted my ATDH1150 teardown yesterday, I got to thinking about the "JTAG-X" port on the device:

It's a 2x7 JTAG port that looks to be wired to the same lines as the 2x5 "JTAG-A", except that one of the two rows is almost, if not all, connected to GND. I'd seen this done other ribbon cable type connections, but I never really thought much about why this was done. The effect of it is to make every other wire in the ribbon a GND line. I'm probably butchering terminology here, but I think this is a form of shielding. It helps to reduce electromagnetic interference, or cross-talk(is that the right term?) between the signal lines.

My experiments so far with my AVR Dragon-breadboard setup lead me to strongly suspect that noise was the culprit, and contrary to my initial intuition, many types of noise can become more of  problem with higher voltages.

ATDH1150USB mini tear down.

Last month I mentioned the ATDH1150USB Atmel CPLD JTAG programmer, and my efforts to home-brew my own programmer based on some ancient code I found on Atmel's website.

The escalating level of effort required to make my own programmer outweighed the $45 it cost to just buy the Atmel programmer. Slightly annoying, since I already own an Atmel branded JTAG device, the AVR Dragon.

There's scant information on the web about the 1150, unlike it's popular Altera cousin the "USB Blaster".

Here's the hardware that came in the box:

Box contents: mini USB cable, a loooong (I estimate 18") 2x5 JTAG ribbon cable,
and a 6" 'JTAG-X" 

The first thing I did was immediately void my warranty(does this thing even have one? I have no idea, I'm guessing that the folks at Atmel would be laid back if I ever ran into issues, this isn't a consumer device. )

Bench PSU: AVR JTag update

I did some more experimenting with my AVR Dragon JTAG woes today, despite not really having the time (I was supposed to file my taxes, but thanks to the District of Columbia, I get one more day. Why put off until tomorrow what you could easily do the day after tomorrow?

To summarize my last post:

ATmega 644 in a breadboard, JTAG functionality only seems to work reliably when powered at 3.3V vs 5V.

I was a little distraught that I had to spend time with dumb issues like this, and not on to cooler stuff. In building this power supply though, I'm sure that I'm going to face a lot of noise issues. I felt dumb.

Well, I'm an Engineer, and what do Engineers do when they feel dumb? They get empirical. Hypothesize, Measure, Test, Rinse, Repeat. Through process of elimination, I knew I could come up with a list of things that were not the cause of my problems. I made a list of random notes as I tried various things that might show a different behavior.