Building a VPlotter

A couple of months ago I decided I needed a project I could finish as the watering system seems like it will be forever on the horizon. I’ve wanted to make a vplotter for a while + seemed like it would be something fairly easily finished while giving me experience I could carry forward to the other projects on my plate.

VPlotters are a type of computer controlled drawing device, where the pen is hung vertically from two motors against a wall, resulting in a ‘v’ from the two control points to the pen. An early example is hektor, a graffiti bot that draws using spray paint on walls. These types of drawing machines, due to their simplicity compared to cnc-esque plotters, are fairly common projects. A quick non-authoritative list includes –

Using this as a starting point, my design has a couple of key aspects. First, I’m not going to have any sort of pen-up feature. Any drawing I make will have to be one continuous line. My rationale is to minimize the complexity and the types of drawings I plan on making don’t require it (more on this later…). I also plan on making it wireless, with the controlling computer not physically connected to the controller. Two reasons here – for some of my plans, I expect this to run continuously and my ‘always-on’ computer is not near where I hope to hang the plotter. Also, it should help develop some rf experience I can carry forward to other projects.

I’m fairly far along with this project already (just quite behind on blog updates). Next post to come will be on the math and some theory.

MSP430 Clocks (Part1)

[Editor’s Note] I started this post months ago, but a stressful bit of time at work led to me putting this on the back burner. It has already proven its worth as I remembered none of what I’ve written here + managed to quickly get back up to speed. Hope it proves worthwhile to you!

MSP430 Clock SystemOne of the challenging aspects of moving to programming microprocessors is managing the multiple clocks available. The MSP430 documentation refers to this as a “Flexible Clock System” which we can take as a “steep learning curve clock system,” that I butted heads with last time when I tried to get 1-wire up and running. This post is an attempt to better understand the complexity of the architecture and save myself issues in the future.

The first challenge is getting through the acronyms. Each component of this detailed system has its own acronym which all sound pretty similar. I’ll throw out the acronyms + basic definitiens first before we dive into each piece.

Clocks:

  • ACLK – Auxillary Clock. Low frequency, used for standby mode + wakeup.
  • MCLK – Master Clock. For processor and high speed peripherals
  • SMCLK – Sub-system Master Clock.

Oscillators:

  • DCO – Digitally Controlled Oscillator. Internal oscillator. High frequency, quickly stable
  • LFO – Internal low frequency oscillator. Sub 12kHz, very low power
  • LFXT1 – Low Frequency/High Frequency External Oscillator – this sources a watch crystal on XIN/XOUT.
  • XT2 – An external Oscillator that can go to high frequencies.

Now some nomenclature notes. CLK means the actual signal. What this means is that you often run into DCOCLK and LFXT1CLK which refers to the clock signals coming out of the DCO or LFXT1. Now with that in mind, lets see where each of the clocks can be sourced. Each row represents a clock that powers some part of the system which may be sourced from one of the oscillators in each column.

Clock DCOCLK VLOCLK LFXT1CLK XT2CLK
ACLK Yes Yes
MCLK Yes Yes Yes Yes
SMCLK Yes Yes Yes Yes

Each of the ‘Yes’ boxes is actually adjustable by ‘/1, /2, /4 or /8.’

Wait, what is with the “/1, /2, /4, /8?” Well, there are dividers in the chain. Lets say that the VLOCLK is configured to run at 12kHz for MCLK, the ACLK could be set to 3kHz (12kHz/4) if needed. Why would would we want to do this? (Why so many rhetorical questions?) Well, if we’re sourcing a counter to ACLK and don’t need more accuracy than 3kHz, this keeps our register from filling up and overflowing too quickly, allowing longer timers.

A discussion of clocks can’t really happen without a discussion of power consumption. A full discussion on power saving will have to wait for another time, but there are some high level concepts we can consider now. First, we want to spend most of the time in low power with a slow clock to conserve power. Then, when required, we want to be able to quickly do a bunch of processing with a high frequency clock so a minimum of time is spent in the high power mode. This aligns well to the clock options – ACLK can be sourced to a low frequency source for low power sleeping and MCLK to DCO or another high frequency source for moments of high activity.

Ok, some details. First, if an external clock is being used (LFXT1) the internal low-frequency oscillator won’t be (VLO). Just happens to be that’s where the switch happens. A crystal would be a more stable source while the internal VLO is liable to drift with temperature.

The MCLK is the easiest piece to understand. That’s the speed the CPU runs at and is a direct analog to what you’d think of as processor speed in a full computer. MCLK typically runs off of DCO

ACLK and SMCLK are used to drive peripherals – i.e. Timer, A2D, etc. The difference is that ACLK is only sourcable from the low frequency sources while SMCLK can come from any of the clocks.

While the DCO is configurable over a wide range of frequencies, configuration is imprecise. The internal resistor and capacitor used in the DCO are on silicon, so there is a variation between otherwise identical processors. To work around this limitation, MSP430 series has one or more ‘calibrated’ frequencies with configurations burned to ROM. For the value line processors, they only have 1MHz calibrated. This doesn’t mean you can use a different frequency, just that you can’t expect it to be precise or function the same over different chips.

Now the question rapidly becomes how to configure these bits + pieces to do what we want. The traditional way is to play with a bunch of registers, play with code, then change it into hard-coded strings to save on program space. When I started writing this all up, that was how things went, but now there is Grace. Grace is a graphical tool that integrates into CCS allowing you to configure peripherals (including the clocks) using a simple graphical interface. It then generates the registry strings for you. I have yet to play with it, but expect it to be a valuable tool, particularly in the beginning as I develop further confidence and understanding.

Next up, playing with 1-wire on the MSP430.

References:

About that MSPGCC Problem

I’ve got a long technical post coming on the clock system of the MSP430, a topic that I ended up having to become an expert in to get 1-wire working properly, but in the meantime there have been developments in the mspgcc world.

You may recall that I abandoned doing 430 development on Linux in part due to incompatibilities with TI’s compiler (IAR) and the sample code they provided. I’m happy to say that progress has been made, as reported by 43oh. MSPGCC now includes header files directly from TI. What this means is no more choosing an equivalent processor with a different model number and hoping it works.

While I’ve now aligned my development to using CCS and IAR, I’m glad to see this progress and may return once I have more experience overall.

A Side Trip Into 3d Printing

Between holidays and travel, I haven’t managed to put too much time into my watering project, so here’s a wander into the world of 3d printing to keep your attention.

3d MenorahI travel to Israel for work a few times a year and have thought for a while that I should own a menorah. It being the season for jelly doughnuts, I put in quite a search but everything I came across either seemed tacky and tourist bait or overpriced. “I’m a bit of a DIY guy,” I told myself “I should be able to make one myself!” Why I didn’t immediately think of 3d printing and instead mulled over smelting at home is beyond me. Recently Sparkfun partnered with Ponoko, a fabrication service, and that announcement exposed me to the world of on demand 3d printing.

The process is fairly simple. Create a 3d model following some guidelines based on the material you want to use, upload it to the service pick your finishes and send them money! While initially these services only offered plastics, you can get objects printed in metal or ceramic as well, which is what made this idea so interesting. I’ll prototype in the cheapest plastic then once I’ve got the design to my liking, run it in stainless steel.

Ponoko isn’t the only game in town, but they seemed reasonable & I was interested in a quick and dirty project. I grabbed Google Sketchup after deciding it said “quick and dirty” more to me than Blender and after a small learning curve churned out the design pictured above. A quick disclaimer – this is more about testing the process than designing something perfect – it still needs some iteration.

Memory ErrorHere’s where I ran into a minor speed bump. Even after fixing some mesh issues, Ponoko’s site had a bug that caused it to throw a nasty error when I tried to upload my model. Off went an email to their support and I spent some time looking into other services.

After some time on google I came across Shapeways which is currently processing an order for my model. Not only do they appear to be cheaper than Ponoko, they have a wider range of materials available – sandstone and glass jumped out at me as good options for menorah-making. Great thing about it also was the model file I had generated for Ponoko worked without modification and uploading was a breeze. The cheapest material option also happened to be their sandstone which interested me also as a potential final material, so if I like the result I may be done.

Pricing is by the cubic centimeter for 3d printing, not by the overall size or level of detail. As a result with careful planning you could have a huge relatively cheap model by judiciously hollowing out areas where it doesn’t matter. As I’m dealing with cheap materials at first, I haven’t done any optimization so my model weighs in at 23.5 cc’s. With sandstone being $1/cc plus a setup fee, my total came to $25. Now metals with metal at $10/cc and glass at $6/cc, I’ll want to do some carving before printing in something more expensive.

Build time is 10 days + shipping and I’ll post a follow-up once it arrives.

Linux + Launchpad Fail

I put the punchline in the title, so let me provide some justification and explanation. One of the things that initially excited me about the prospect of using the Launchpad was the presence of support on Linux. While not officially supported by TI, there is a project to add the msp430 family as a target for cross-platform gcc compilation. As an unsupported endeavor though, there exist some hiccups, both in compilation and communication with the launchpad under Linux.

On the surface, everything looks like it should be straight forward. Hack a Day has an article getting people started and while there is a bunch of compiling tools from scratch, the process is easy enough to follow. All the samples work as expected, but then you start coding and discover that nothing is so simple. I immediately noticed that the target processor you’re compiling for doesn’t match the chips included with the launchpad. Turns out that one of the limitations of the mspgcc project is that it lacks headers and support for every chip in the msp430 line. The project is aware of this shortcoming, but the product line is too expansive for them to maintain with the current system. Fortunately the MSP430G2231 (the more powerful of the two chips included with the launchpad) is functionally equivalent to the MSP430F2031 which has headers available. Simply changing around the header file linked gets past this bump in the road.

Next hurdle, compiler differences. A lot of MSP430 sample code relies on ics (ti’s compiler) specific compiler declarations and macros which GCC doesn’t replicate or emulate. For instance, this pattern

pragma vector=PORT1_VECTOR
__interrupt void PORT1_ISR(void)

is fairly common in the MSP430 literature and gcc doesn’t use the same syntax. Instead, you have to do something like

#include "signal.h"
.
.
interrupt (PORT1_VECTOR) PORT1_ISR(void)

It is important to note that these definitions (for the most part) are not part of the language specifications, so it is not that case that gcc isn’t a fully compliant compiler. Rather, compilers are free to implement their own directives at will so it is just the case that these are un-agreed to changes that TI made.

The community understands these differences, but they aren’t well documented in any central place. Instead of finding this information on the Launchpad wiki, I tracked it down by extensive googling on a thread in a launchpad discussion group. I was also pointed towards a simple perl program (you have to scroll down) someone wrote to convert code between CCS (TI’s compiler) and mspgcc. Using what I learned from these sources, I was able to successfully load all the demos I found online.

So now we can compile code examples intended to be run under Windows by changing the target processor and rewriting code. I’m ok so far – as a Linux user I’m used to things being possible but not necessarily easy. These relatively trivial issues I take as the cost of my OS choice. What pushed me over the line to doing this experimentation on a Windows computer was the instability of the serial connection.

One thing I got used to working with the Arduino was the ability to easily dump information via serial using

Serial.write(str)

Particularly since at the moment most of my exploration is testing sensor configurations, being able to watch the collected data live helpe. Having that communication channel available is also how I’ve been handling logging. Until I have a data storage and transfer system implemented, I’m reliant on having that communication channel. Which doesn’t work reliably on my linux system.

I’m not the first person to run into this issue, but have yet to find any sort of solution. I’ve found some posts that suggest flaky linux drivers or potentially bugs in the demo program. I’ve tinkered with it a bit, but haven’t had any luck getting it working. As a result, I’ll be doing my development on windows until I figure out a solution.

Now I’ve gotten some frustrations out of the way, it is time for some actual progress, so stay tuned for fun with solenoid water valves.