August 2013 Archives

August 27, 2013 @ 22:27 EDT

cw1200_spi now works properly, and is in backports!

I just submitted two patches to the cw1200_spi driver; hopefully they'll make it into 3.11-final, but if not, they'll go into 3.11.1 instead.

A user (Dave Sizeburns) was trying to get this driver working on a Beagleboard xM, only to discover near-immediate BUG() triggers when the driver was loaded. This was due to the the driver attempting to perform a SPI transfer in interrupt context -- ironically, trying to disable the interrupt in the hardware.

Apparently some (most?) SPI controllers use asynchronous calls -- which can sleep, which is a no-no in interrupt context. The hardware I used to develop this driver (an ancient Sagrad Kraken board based on a Samsung s3c2440) used synchronous, non-sleeping calls.

The solution was to disable the interrupt via the linux disable_irq() call instead of masking it on the hardware itself.

The second problem was a hang (not a deadlock) caused by improper locking in the SPI driver's attempt to emulate the semantics of the SDIO layer's claim/release_hardware API. When there was lock contention, nothing actually tried to wake up the lock requestor when the lock was eventually freed. This bug never presented itself on my hardware, more out of dumb luck than anything else.

Several days and a dozen or so e-mail exchanges later, Dave had a working cw1200_spi driver. His patience in this endeavour was apprecited, especially since I didn't have any SPI-capable hardware handy.

The known bug list is back down to zero, just where I like it. But it's the unknown ones that get ya.

Meanwhile, the small pile of patches I've submitted to the linux backports project have been merged, so the next backports release will include support for the cw1200 driver going back to the 2.6.34 (SPI) and 2.6.32 (SDIO) kernels. With a little more effort, support should be possible going back several more releases, providing there's sufficient interest.

Since there are still some out-of-tree patches (unmerged fixes and regulatory-approval-type stuff) for the cw1200 driver, I'm considering releasing my own set of backports tarballs if there is sufficient interest.

"Sufficient interest" basically means it's not going to happen unless someone asks, because I have other projects to keep me busy. :)


Posted by Solomon Peachy | Permanent link & Comments | File under: Free Software

August 27, 2013 @ 21:59 EDT

305/365: Old Faithful

206084:294099

This is the classic IBM Model M keyboard that's seen me through my entire professional career -- Fourteen years and five employers, across four cities and two states, always plugged into a machine named lunchbox.

Manufactured back in 1988, I purchased it eleven years later for $5. Aside from needing the occasional cleaning, it's still going strong, 25 years after it came off the line in Lexington, Kentucky.

I have another Model M on my workstation at home, and two more safely stashed in a trunk. They just don't make them like they used to. Oh wait, they still do.

These are the most bestet keyboards evar.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

August 27, 2013 @ 07:14 EDT

Wikileaks are teases

450 or so gigs worth of encrypted "insurance" files supposedly full of embarassing stuff to those in power. Or not.

Come on, Wikileaks, release the decryption key so I can find out if this was worth the download time.

(As an aside, this is one month I'm reallllly glad I'm paying for commercial-tier service.. even discounting this wikileaks dump it has been a very, very heavy data month..)


Posted by Solomon Peachy | Permanent link & Comments

August 26, 2013 @ 22:21 EDT

No more fotomoto links..

All it really seemed to accomplish was slowing down page loads, and I think in the years of running with it, I had two e-card referrals and that was it.

If I ever get around to doing a proper glamor/portfolio site I'll revisit an integrated ordering system, but until then.. ciao.


Posted by Solomon Peachy | Permanent link & Comments

August 25, 2013 @ 18:22 EDT

304/365: Not much to look at

206079:294093

But it's damn tasty!


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

August 24, 2013 @ 12:42 EDT

Another milestone!

Thursday a set of four 2TB hard drives arrived on my doorstep. They were intended to replace a 4.25-year-old 4x1TB RAID5 array. I'd intended to plug them in this morning, initialize the array, create the filesystem, then copy over the existing ~2TB of data. The prolonged pounding from all of that activity would also serve as a burn-in test. Or at least that was the plan.

One of the three drives was Dead on Arrival. Well, strictly speaking it failed when it first powered up, but it's now as dead as a proverbial doornail.

In all of the years I've been dealing with hard drives, I've never had one fail immediately out of the box. Sure, I've had them fail relatively quickly (ie the classic bathtub curve failure model) but never right off the bat like this.

Rather than deal with a return-and-replacement via Newegg in California (~2 weeks), Toshiba offers a cross-shipped warranty service from their facility in Texas, which means I should be able to pick this back up again on Wednesday.

I'd hoped to get all of this drive swapping done this weekend since I have folks coming to visit next weekend, but such is life.


Posted by Solomon Peachy | Permanent link & Comments

August 24, 2013 @ 09:24 EDT

Okay, that was wierd.

Apparently some time between 21:25 and 22:48 last night my public web site was blown away -- As in the 'public_html' directory was completely gone. I have no idea what could have done this, and there's nothing in the server logs (console or http). The most likely culprit is my blog rsync script, but I last tweaked it more than seven months ago, and it's been running error-free for nearly as long as this blog has been online.

I restored the site from the previous night's backup and re-synced the latest content. Yay for backups!


Posted by Solomon Peachy | Permanent link & Comments

August 23, 2013 @ 21:25 EDT

303/365: Lady in Waiting

206078:294089

Was at work pretty late. She kept me safe.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

August 23, 2013 @ 18:11 EDT

Changes in plumbing after nine years?

This blog is powered by nanoblogger, which basically amounts to a glorified shell script. I'm actually pretty happy with it, with one exception -- it is s l o w.

While the speed wasn't so bad when there wasn't much posted, over the past oh, ten or so years I've been using nanoblogger it's progressively slowed down as the reality of parsing everyhing with shell, grep, sed, and awk has crept up. And that was before I turned on tidy and markdown so I didn't need to write straight html.

With no meaningful ability to represent real data structures or cache intermediate data, it takes longer to process what I write than it does to actually write it, while pegging the processor the whole time.

I've been casting around for a better alternative, but I kept coming back to the status quo due to the PITA factor of migrating things over.

So, what am I looking for? Here's a short list:

  • Static site generation
  • Sane templating
  • Markdown entries (for sane importing of what I have)
  • Generates RSS feeds (a master feed plus one per category/tag)
  • Supports non-blog/timestream content
  • Incremental (and fast) generation

I'm currently looking most favorably at ikiwiki, but other alternatives include nikola and pelican. Then there's utterson -- which is interesting because it takes an approach similar to where I wanted to see nanoblogger go -- basically, use make for dependency and parallelization.

Anyway. Part of me wonders why I'm bothering with this exercise because in the end, I'll probably still stick with nanoblogger. But even if I don't migrate away, even discounting the speed issues there are some useful low-level things to improve.

So today I finished migrating the entire 1051-entry archive from mostly html over to pure markdown, and cleaning up the inconsistent date formats I've used over the past nine years of using nanoblogger. Having the data in a sane, consistent representation is the first step towards anything else.

Aside from older stuff I've slurped in here, I've been using nanoblogger for a little over nine years. My, how time flies.


Posted by Solomon Peachy | Permanent link & Comments

August 22, 2013 @ 10:20 EDT

I made it onto LWN.net's top kernel contributor page!

This week's Linux Weekly News kernel page has information on the upcoming Linux 3.11 release. (Note that this page will be opened up for non-subscribers next week. Subscribe to LWN. They are awesome. Just do it. I'll wait)

I came in at #7 on the top contributor list, with 15,510 lines of code added/changed thanks to the ST-E CW1200 driver getting mainlined. This represents a whopping 1.6% of the overall churn for this kernel release.

While I wasn't the original author of the cw1200 driver (credit for that goes to Dmitry Tarnyagin), over the past couple of years I've rewritten large chunks of its core and substantially tweaked the majority of what's left -- and this mainling effort has taken the better part of a year to accomplish.

But I digress. Getting onto that "top contributors" list was one of those personal/professional milestones that I never expected to attain, especially now that $dayjob has taken me out of the WiFi/802.11 and Linux kernel hacking realms in favor of WPAN ICs with a healthy dose of microcontrollers on the side.


Posted by Solomon Peachy | Permanent link & Comments | File under: Free Software

August 22, 2013 @ 00:11 EDT

linuxaldl hacking continues

My linuxaldl fork now supports bitfield and lookup table data types, though I'm still quite a ways off from testing anything. Further digging into the Pin-E (aka 160bps) signalling shows that it doesn't use RS232-compatible framing:

160bps pin-E serial interfacing

To make a long story short, a viable solution is to clock the serial port to 10x the actual bit rate, and treat each "byte" received as a single bit, which we'd then translate into 9-bit sequences to decode.

Unfortunately this is completely incompatible with how linuxaldl handles the pin-M (ie 8192baud) protocol, so it looks like I'll need to figure out the best way to do this and probably throw away a couple of prototypes. So it looks like the plug-it-in-and-see-what-happens test is further off than I'd hoped.

Anway, time for bed. Tomorrow I need to put this on hold so I can hunt down a BUG trigger with the cw1200 driver on some SPI hardware. That and I may have some $dayjob work to take home with me too.


Posted by Solomon Peachy | Permanent link & Comments | File under: Free Software

August 21, 2013 @ 15:39 EDT

Stand-up philosopher

Just as eating cow-meat doesn’t turn you into a cow, studying philosophy doesn’t make you wiser. -- Nassim Taleb


Posted by Solomon Peachy | Permanent link & Comments | File under: Life and other BS

August 21, 2013 @ 15:11 EDT

302/365: Tropical Paradise

This past weekend I did a lot of biking and ate a lot of sushi, but I didn't like any of the photos enough to post them just for the sake of posting something.

However, I liked this one from Monday.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

August 21, 2013 @ 00:08 EDT

ALDL hackery, oh my!

One of the upsides to my truck's recent woes is that I ended up with a cable capable of interfacing to its onboard computer. Unlike the "modern" mostly-standardized OBD2 spec (that all 1996+ vehicles were mandated to support) this thing utilizes a GM-specific interface called Assembly Line Diagnostic Link, or ALDL.

General Motors used ALDL between 1982 and 1995, through two major revisions -- 160 baud unidirectional, and 8192 baud bidirectional.

Unfortunately, the physical interface is where the standardization ended -- The logical datastream could be specific to a particular computer, year, model, and drivetrain combination. Oh, there were sometimes additional streams (on physically different pins) for the antilock brake and transmission computers.

All in all, it is quite a mess to deal with, and one that not even General Motors cares about any more. The old Tech1 testers they used to use (and the even rarer data cards) command a pretty steep premium on eBay these days. Cue the aftermarket!

The CD that came with the data cable included various windows-based tools and a pretty comprehensive list of datastream definitions. Initially I used WinALDL to decode the ALDL stream out of my truck. It is fairly old and no longer maintained, which was a problem given that it didn't support the exact datastream my truck spat out. More advanced tools exist (such ass TunerPro), but they target an entirely different audience -- folks trying to reprogram the PROMs in the PCM.

But that's enough background information. Not wanting to have to fire up a Windows instance to talk to my vehicle, I got to thinking that someone out there had to have written an open-source ALDL tool, I did a little poking around and came across LinuxALDL. Unfortunately it turned out to be woefully incomplete -- Its author got things to the point where they WorkedForHim(tm) on his re-engined '88 Fiero, then pretty much abandoned things as they stood.

LinuxALDL was written for the newer 8192 baud bi-directional interface, and while some effort was made to support multiple stream definitions, it wasn't quite completed. It also lacked support for all data types that the ALDL interface exposed.

So, I picked up the code and started hacking away. I've already completed a pile of code cleanups (with more to come), partially implemented support for the low-speed 160-baud interface, and am currently improving the data stream support so I can get niceties like decoded coolant temperature and open-/closed-loop operation flags.

These two things are my main motivation for this work, since the dashboard's temperature gauge isn't linear and I need to know what the actual temperature is, and if the computer is transitioning to closed-loop operation. Even though the PROM I have in there now is tuned for lower temperatures, the truck may actually be running too cool with the electric fans I put in after the radiator blew out last summer. We shall see.

I hope to have things in shape to plug it into the truck tomorrow and see if anything useful comes out. Given that my truck uses the old 160-baud interface, I'll never be able to do anything other than watch/log the data coming out, so once I have both the GUI and command-line datalogging working, I'll probably walk away once I fully expose/decode the my truck's datastream.

Oh yeah, the code. If anyone is intereted, here's my work-in-progress fork of LinuxALDL:

http://git.shaftnet.org/cgit/users/pizza/public/linuxaldl.git/

Posted by Solomon Peachy | Permanent link & Comments | File under: Free Software

August 11, 2013 @ 21:31 EDT

301/365: The culprit

This toothed wheel thingey is the pickup coil, aka the crank angle sensor, and was responsible for all of my truck's woes.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

August 11, 2013 @ 14:43 EDT

300/365: Death Grip


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

August 11, 2013 @ 13:47 EDT

I am the MAN.

I just got back taking my truck on an errand.

Yep, my truck is moving under its own power. I successfully diagnosed and solved the problem in a single (long) morning. With the right tools (and a little more experience on how these these engines are put together) it would have taken half the time.

The problem turned out to be a bad pickup coil on the new distributor the mechanics put in. Apparently they never actually tested it when things started going awry, assuming "swapped" meant the same thing as "tested". This was likely the problem with the original distributor too.

To top it all off, their model of how the ignition module worked was off; if they'd read the manual, they would have not spent all that time tracing wires and swapping computers. So, let's describe how the ignition system on this truck (1994 Chevy/GMC K1500 with the 5.7/350 motor) works:

  • Turn ignition switch on. Ignition Control Module (ICM) is energized. Ignition coil is energized. The Powertrain Control Module (PCM, aka "the computer") turns on the fuel pump for two seconds to pressurize the system.
  • Crank motor. Pickup coil in distributor sends AC pulses to ICM, which in turn sends digital pulses to the PCM. Cranking signal sent to the PCM too.
  • ICM signals the ignition coil to start sparking based on pickup coil input. PCM signals fuel injectors to pulse based on digital signal from ICM.
  • Motor (presumably) starts, and rapidly accelerates to idle.
  • Once engine reaches 400 RPM, PCM signals ICM that it is taking over timing. By this point oil pressure is sufficient to trip the fuel pump switch and the fuel pump is turned back on as long as the engine is running.
  • PCM, operating in open loop mode, sends ICM signals to advance or retard timing as needed.
  • Once engine warms up, PCM transitions to closed loop mode to minimize emissions, utilizing inputs from sensors to maintain optimal fuel-air ratio.

Without a working pickup coil, the ICM won't generate a spark and the computer won't know to pulse the injectors, since from their perspective, the engine isn't actually turning.

Armed with this knowledge, the very first thing I checked this morning was the ignition and pickup coils. According to the factory service manual the pickup coil should register between 500 and 1500 ohms resistance. This one was out of range of my meter, effectively an open circuit.

In other words, a bad pickup coil. Hence nothing else working. Oddly enough, the coil did register an AC voltage when rotated, albeit a couple orders of magnitude less than expected.

The rest of the morning was spent removing the old distributor and installing the new one, including a new distributor cap since the old one had some serious pitting going on. In the process I managed to gouge the back of my left ring finger with a deep gash about an inch long -- but a blood sacrifice is an important part of any mechanical repair. Once the truck and I were put back together, it started right up. It may have idled pretty roughly, but by golly, it ran!

Since the distributor was swapped (twice), the timing was likely off. Out came my handy timing light, which I haven't used in something like eight years. This was complicated by the service manuals pointing to the wrong location of the "timing bypass" connector -- it turned out to be under the A/C motor in the cab, rather than next to the power distribution panel under the hood. I eventually dialed the base timing to the proper 0 degrees BTDC (Beyond Top Dead Center) -- from something in excess of 20. Yikes.

So now, the truck's back on the road, with a new distributor, cap, and rotor, plus a high-performance PROM from Ed Wright at Fastchips(.com). Per Ed's recommendation, I also swapped out the original 195-degree thermostat for an 180-degree model, and consequently the truck runs MUCH cooler.

Not counting my time or the mechanic's labor charges, this whole affair has run me about $550, of which only about $170 was really necessary. The improved chip (and thermostat) I may have done anyway ($220) and the rest was taken up by other part swaps (throttle position sensor, fuel pump relay, rebuilt PCM)

I'll be driving the truck by the mechanic's on Monday -- I'm going to politely request a refund on the defective distributor they installed (and hopefully get the original back so I can get the core refund on the one I just bought) -- and see if it'll be possible to return the PCM that turned out to be completely unnecessary (and possibly defective too).

This is why I like doing my own automotive repairs. Not only do I find it a rewarding exercise, I apparently do a better job than the professionals. Yup, I da man.


Posted by Solomon Peachy | Permanent link & Comments | File under: Life and other BS

August 10, 2013 @ 21:41 EDT

Today...

Today I gave Ron Jeremy $10. For the Children.

No, really!


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Life and other BS

August 09, 2013 @ 19:30 EDT

299/365: What happens when I leave my camera at home

This iguana-like critter let me get pretty close, so the cell phone was adequate.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

August 09, 2013 @ 10:41 EDT

Computer says no...

Bad news/good news. The good news is that the new PROM in the original computer no longer throws any error codes, and that the data stream is sane, with all reported values nominal...

...except for the lack of an RPM value when craking. Yup, the bad news is that the motor's still not coming to life.

I settled my bill with the mechanic (they massively discounted their labor charges seeing as they didn't get it working in the end) and had them tow it to my driveway.

Tonight I'll charge up the battery, and devise a plan of attack. I have a few more things in mind to try, but I intend to start with the proper diagnostics tree and move on to tracing every wire again. In other words, it looks like I'm going to have an evening/weekend project for the forseeable future.

They asked me to let them know what it turns out to be, seeing as this has stumped not only their four techs but also their extended network of contacts.


Posted by Solomon Peachy | Permanent link & Comments | File under: Life and other BS

August 08, 2013 @ 19:16 EDT

298/365: Foliage

Right outside my office window.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

August 08, 2013 @ 15:31 EDT

Second Reality is 20 years old...

For those of you that have no idea what I'm talking about, Second Reality basically knocked the everloving socks off the PC demoscene when it debuted at Assembly '93.

Instead of the customary stringing-unrelated-tech-demos together with no real thought to the overall package, its authors tied together slick visual stunts with a kicking soundtrack, fully sychronized audio/video, processed/generated in realtime across a pretty wide range of hardware.

And speaking of hardware -- Back in 1993, this would have been running bare metal on top of DOS, requiring a high-end 80386 (or better yet, an 80486), utilizing fancy modeX VGA graphics modes, and a Gravis Ultrasound (or a Sound Blaster for those of us unblessed)

We've come a very, very long way since then.

I still have the original Second Reality zip file I downloaded from a BBS during that summer, 20 years ago. And now, the full source code has been released into the public domain. Second Reality on Github

Twenty years ago. Wow. Makes me feel old.


Posted by Solomon Peachy | Permanent link & Comments | File under: Life and other BS

August 08, 2013 @ 10:56 EDT

Hey, what happened to the photos?

In short, since I moved, I've had a lot of other stuff going on that's kept me in a non-photographically-oriented frame of mind. I'm still carrying a camera everywhere with me, but.. I'm just not feeling it, and I'm not going to "force" myself to take a picture for the sake of it.

I could post old stuff instead, I suppose.

Actually, I have been making progress on the photography goal front, but it's all been behind-the-scenes work. I now have the extra room in my new place cleaned up/out, ready for the backdrops to be hung and "stuff to happen" once I have some subjects. My equipment is also neatly organized instead of crammed into a trunk, and I have some new toys to play with (Triggertrap!).

I've also spent time working on workflow/process stuff, with the proper bringup of kalamata and experimentation with other tools.

There's the work on printers and generating larger-format prints, some of which was paid. I'm planning on making a pile of larger-format prints, both for my house and for work, including several poster-sized nature shots -- And I'm waiting on delivery for an 104-inch-wide panorama print of the view from the cliffs of Cabo Rojo in Puerto Rico.

So, it's only a dry spell in the sense that I don't have any new photographs to show, and I can probably blame much of that on the relative dearth of "fun" in my life lately. No socializing means far fewer photos since so much of what I do involves playing off of others.

Since I'm settling in here and running out of "gotta do X" projects, I expect the pendulum to start swinging back soon.

This is a normal cycle for me; the focus of my attention naturally waxes and wanes, but in the grand scheme of things, I'm still doing stuff that keeps me busy. As the relative volume of text posted here over the past couple of months can attest.

And on that note, I see a potential photo outside my window.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos

August 08, 2013 @ 10:23 EDT

Retiring marinara

Two days ago I wiped Linux off my laptop, and restored the original Windows Vista installation it came with. It's not a good way to end this machine's career, but it's being handed to someone who needs it far more than I, and I'm not going to be in a position to provide support.

I don't expect to replace marinara with another laptop anytime soon. I've found I greatly prefer the large screen and good-ol-Model-M keyboard on kalamata (the greatly-upgraded workstation) and my smartphone takes care of my general portable connectivity needs, complete with proper crypto.

About the only thing I really need a laptop for is travel involving photography, and even then it's mainly just a glorified hard drive with a screen. The Chromebook pixel looks like an ideal option (perhaps with an external hard drive) though of course I'd install a proper Linux distro on it.

In the short term, I'll use my employer-provided laptop when I need portability. Aside from the low-res screen, it's actually pretty nice system. However, I'm keeping anything personal off of it, travel excepted.

Kalamata has more than 3x the CPU oomph and 4x the RAM of marinara, plus a three-generation-newer graphics card plugged into a much larger/better (though still not all that great for photography) screen. Oh, and a real keyboard -- Even putting aside the awesomeness that is the IBM Model M, marinara's keyboard was always rather flaky.

Its main weakness is an old hard drive, which I intend to replace with something much faster (eg an SSD) soon. I'm also planning on replacing the old screen with a pair of color-accurate IPS panels, probably vertically stacked, but that will have to wait until after my finances recover from what will surely be a steep bill for the truck.

Anyway. I've migrated my 13-year-old home directories off of marinara to kalamata.. and things JustWorked. Ah, I do so love Linux!


Posted by Solomon Peachy | Permanent link & Comments | File under: Life and other BS

August 07, 2013 @ 20:19 EDT

It keeps getting better

The only place to get a proper replacement PROM is direct from General Motors, as the PROM is specific to the model year and powertrain options of each particular vehicle. Unfortunately it seems that GM hasn't had any to sell for soemthing like six years. This is.. a problem.

So despite GM cranking these trucks out literally by the millions, I can't just find a random 89-95 truck in a junk yard and pull the computer for the PROM. Unless a junkyard has a BDUZ-series PROM for a '94 non-California-emissions pickup (ie not utility/suburban!) with the (non-HD) 350ci motor, the MT8 manual transmission, and a 3.73:1 axle ratio, I'm pretty much SOL.

Fortunately, it turns out there's a bit of a cottage industry there creating customized PROMs for these trucks. In the end, it looks like I had a choice of four, consisting of two "improved stock" PROMs from Jet and Hypertech, plus two higher-performance (and customized to order) PROMs from Harris Performance (aka tbichips.com) and Fastchips (.com). I had the option of getting a stock chip, but given that it really wouldn't save me any money I decided to go with Fastchips' high-performance chip.

"High-performance" is relative given the questionablly conservative choices GM made when putting this motor together, but since I'm spending the money anyway, I might as well get the most oomph possible out of that very-conservatively-built small block V8. I'll need to swap in a cooler thermostat (180 vs the stock 195 deg), but I should have done that anyway when I converted the truck to electric cooling.

Anyway. The replacement chip's supposed to arrive on Thursday. One way or another, the truck's coming home after the chip swap on Friday. Hopefully under its own power.


Posted by Solomon Peachy | Permanent link & Comments | File under: Life and other BS

August 04, 2013 @ 13:50 EDT

More microcontroller woes

My good experiences with STMicro's STM32 family and bad experience with the Freescale development "philosophy" got me curious; Where do the other Cortex-M vendors fall along that spectrum?

  • STMicro -- Provides straightforward zip files of libraries and code examples.
  • Freescale -- Provides an eclipse-oriented environment/code generator as part of a ginormous download, with no meaningful access to libraries or example code. Certian components are windows-only.
  • Atmel -- Provides a ginormous development environment only, apparently built on Visual Studio so it's Windows-Only.
  • Energy Micro -- Provides a windows-based tool (built using MinGW!) that lets you obtain the core libraries and examples. and the "software download" link on their site is broken.
  • NXP -- Provides a straightforward zip file of libraries and code examples.

In other words, Cortex-M vendors are still more tilted towards the tradtional "our-way-or-GTFO" microcontroller vendor approach embodied by Freescale, but they're tending towards the greater openness that ARM is trying to achieve with first CMSIS and now mbed.

In other news, I have my CMSIS microcontroller development framework up and running. It currently supports ARM Cortex-M0, M0+, M3, and M4 cores and the full STM32 (ie F0/F1/L1/W1/F2/F3/F3) family. Adding additional platforms should be pretty easy as long as the vendor supplies a CMSIS port. I'll be adding Energy Micro and NXP ports later today, I hope.

You can find it on my site's git repo

All components, including the (modern GCC/Linaro) toolchain, are suplied in source form and the environment builds and links everything for you. All you need to do is supply a main() function and take it from there.

Why go through this effort? First, there's no meaningful code or documentation out there on how to leverage the (vastly superior IMO) Unix/GNU toolchain and workflows when workring with Microcontrollers. Tools (even compilers) and development environments tend to be highly proprietary and require inferior operating system platforms. They also tend to target rapid prototyping (And thus have a ton of handholding that gets in the way when you know what you're doing) and tightly lock you in to using that particular vendor's platform, encouraging highly non-portable and non-resuable code. They also tend to encourage horrible development practices.

Heh, I think I've just re-articulated ARM's rationale behind their mbed project. My effort isn't entirely overlapping however; ARM's leveraging C++ to target the rapid prototyping folks first, effectively abstracting all the hardware away, but I'm targetting experienced developers, who want a bare-metal C-oriented approach so you know exactly what's going on.

I don't know how far I'll take this thing; it's almost to the point where it's sufficient for my needs, but I'm releasing it to the world in the hope that others find it useful. I know I'd wished for something like this when I first started hacking on microcontrollers!


Posted by Solomon Peachy | Permanent link & Comments | File under: Free Software

August 04, 2013 @ 11:12 EDT

Power outages and UPSes, oi!

About 2:50pm yesterday, the power went out during a particularly violent thunderstorm. Nearly five hours later, at about 7:45pm, FPL restored service.

Everything critical here is on UPSes, but needless to say I don't have five hours' worth of batteries. Fortunately everything shut down in an orderly manner when the battery levels went critical.

Shaftnet is plugged into an old APC Smart-UPS Pro 1400. It (and the network infrastructure) tends to suck down about 21% of its rated capacity. In theory, that UPS, with new 18aH batteries, should be able to sustain that load for ~45 minutes.

I had 35aH batteries plugged in during this outage, which (when new) should be good for ~90 minutes. They lasted twelve. Granted, the batteries have been abused by Florida's oh-so-stable power for nearly three and a half years, so this wasn't entirely unexptected.

This time, instead of relatively expensive AGM SLA batteries, for roughly the same price I picked up a set of more traditional sloshy-sloshy 105aH deep-cycle marine batteries. In theory, this should sustain my sever closet for nearly four and a half hours.

Not that I care to test that theory. :)


Posted by Solomon Peachy | Permanent link & Comments | File under: Life and other BS

August 03, 2013 @ 00:44 EDT

Freescale vs ST-Micro

Tonight I tried downloading the documentation and sample source code for both Freescale's KL25Z "Freedom" board and ST-Micro's STM32F4 "Discovery" board.

STM's site has its navigational quirks, but all documentation and standard peripheral librares were readily available, with no registration, no hoops, no fuss. Everything I need to build a sample project with four different toolchains is now saved on my workstation.

Freescale's site was better organized, and easier to find information, but they take a very different philosophy when it comes to actually obtaining what you were looking for. First, you have to register, supply a ton of information, and agree to a clickthrough license that basically states you may not actually be allowed to do anything with the code you're downloading.

To top that all off, as I type this their site's CDN is basically shot. All downloads are glacially slow, with occasional bursts of 4-8KB of data followed by the connections dropping. Even the documentation download wasn't working.

Then they don't have any simple standalone development tools; instead you're stuck either downloading a quarter-gig customized Eclipse package (aka "Procesor Expert Software, Microcontroller Driver Suite").

Assuming I ever get this stuff downloaded, in order to get what I want (namely the CMSIS and peripheral library definitions their MCUs require) I'm going to have to do some serious spelunking since my goal is to use GNU toolchains to create a codebase that isn't completely tied to a single MCU vendor. Or hack, a single MCU from a single vendor, which is what the Processor Export suite seems to accomplish.

No wonder ARM is trying to push the mbed platform; Despite ARM's earlier efforts to standardize ARM MCU programming with CMSIS, Freescale aptly demonstrates the penchance of MCU vendors to shoot themselves in both left feet. mbed standardizes things at a much higher level, effectively abstracting out (and therefore commoditizing) the entire MCU, even the I/Os, generic peripherals, and more esoteric things like clock setup.

Freescale, you have failed. For all your talk of your "freedom" platform, you're doing a piss-poor job of enabling someone to do, well, anything useful with your hardware. (This is especially true for experienced MCU developers!)

In contrast, STM does a pretty good job here; they provide a full standalone peripheral library, including sample applications to drive each peripheral that tie into several different toolchains. They also provide several full-up applications and link to 3rd-party samples, including ensuring that FreeRTOS has first-class support for their parts.

Anyway. Time for bed. Maybe I'll actually get a hello world project generated for the STM32F4 tomorrow. It's obvious that the KL25Z is going to take a lot more work, and I'm beginning to not care enough to put forth the effort.


Posted by Solomon Peachy | Permanent link & Comments | File under: Free Software

August 02, 2013 @ 11:26 EDT

MALFFLG3

Last night I received an ebay-special GM ODB1/ALDL dongle in the mail. This morning I brought it over to the new mechanic (different shop, different tech, but under the same umbrella/ownership), who filled me in on the wire tracing they'd been performing. Along with a fourth computer.

In short, the wiring appears to be good, and the computer is actually grounding the ignition control reference line. No reference voltage means the distributor pickup coil can't detect the engine rotation. No rotation equals no spark and no fuel. Because.. why bother?

But back to MALFFLG3.

In the earlier days of this problem, I'd mentioned that I'd had a PROM-related problem with the old POS Lumina I'd owned for a while, and that it may be a factor in this truck's woes given that it helps drive the computer. After I finally got the data link working, that theory just gained considerable credence:

MALFFLG3, ie Malfunction Flag 3, is non-zero. According to the charts, this translates to "Error 51 - EPROM Checksum Failure". Well, well, well! The original factory PROM has been moved from computer to computer, with nobody giving it a second thought because "PROMs never go bad!"

The mechanic's going to call up GM and order a new PROM, which is specific to the VIN of the truck. Keep the fingers crossed; this is probably the underlying cause of everything. Even the distributor may not have actually gone bad, though given the rust and whatnot it needed to be swapped anyway.

Anway. In about an hour the mechanics will have had my truck for three weeks. Here's to hoping that doesn't become four.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Life and other BS