Older blog entries for Pizza (starting at number 148)

Mitsubishi CP-K60DW-S

Recently Mitsubishi announced their CP-K60DW-S photo printer. Outwardly it is identical to their existing CP-D70DW, except for the use of red labels instead of grey. Beyond that, it appears to be functionally equivalent (even uses the same media) to the CP-D70 series, although not as fast.

This morning I dug into the spool file format the CP-K60DW uses. It's almost identical, though different enough to be annoying. Most of the changes had to do with print sizes; they're all slightly different, and there's support for 6x6 prints (but not the 6x9 the CP-D70x supports)

Some judicious decoding later, and Gutenprint now theoretically supports the CP-K60DW-S. Of course, lacking access to one of these printers I have no way of testing this, and can only hope its command stream is identical.

In the process I discovered and fixed a couple of bugs relating to command padding on the the CP-D70 series. Anyone out there with access to any of these printers (Mitsubishi CP-D70DW, CP-D707DW, CP-K60DW-S) that's willing to help me out?

Syndicated 2013-11-24 16:08:06 from Solomon Peachy

Kodak 605 works!

The Kodak 605 Photo Printer is their replacement for their earlier 68x0 series. And, true to form, it's incompatible with everything that came before.

Last night, I commited a backend for the Kodak 605 photo printer. Tonight, the last of the known bugs were fixed, and it appears to work!

Yay, that just leaves most of the Mitsubishi models (CP3020D/DA, CP-D70/707, CP-D9550/9600) that need testing/validating, plus whatever else comes along in the mean time.

Syndicated 2013-11-24 03:17:18 from Solomon Peachy

12 Sep 2013 (updated 24 Nov 2013 at 04:11 UTC) »

Okay, Freescale, I give up.

The Freescale "Freedom" FRDM-KL25Z boards have a lot going for them. They're cheap ($13), and sport an ARM Cortex M0+ core in an Arduino-ish form factor, with a fancy "OpenSDA" USB-based flash/debug thingey bolted onto the side for user-friendlieness.

Unfortunately.. they botched the execution in many ways; some subtle, some less so.

Let's start with the first impression. In order to get anything more useful than marketing materials from Freescale's web site, you have to register. They then hand this info off to a distributor who proceeds to email and call you before you have a chance to meaningfully evaluate anything.

The actual datasheets and programmer manuals were okay; not the worst I've seen by any means, but not all that great either.

But the software side of things is another story. The only thing they offer is a ginormous plugin for an obsolete version of Eclipse that supports all of their microcontrollers... via a code generator. Theoretically, once you generate that skeleton codebase it's usable outside of Eclipse.

At least you can extract the not-quite-CMSIS-compliant processor headers from that morass. But those files say "all rights reserved" which makes them technically unredistributable. Sigh.

But the best part, the part I spent the last day and a half fighting, was their "OpenSDA" programming/debugging mechanism.

In theory, it's a smart design -- It presents as a composite USB device consisting of a serial port and a virtual mass storage device. The serial port gives you the console, and to program the controller's flash, you just copy a new firmware image over to the filesystem.

It turns out there's nothing open about it.

OpenSDA is about as proprietary as it gets. To actually use it as a debugger under Linux you'll need a proprietary 32-bit-only binary drivers+libraries. That's right, they don't even supply an application to use it -- even a GDB server will cost you extra.

So it's useless as a debugger. What about as a flasher/programmer? It fails even more spectacularly there, thanks to it simply not working under Linux (or even OSX), due to gross violations of the USB mass storage spec.

In all fairness, they did eventually fix these problems (both in their bootloader and their flasher "application").. but you'll still need a native Windows system (not a VM, because their USB enumeration is just that badly broken) to do the update. Once you have the new application running, it works well enough, though it doesn't complain if you try to write something too large.

The one saving grace is that Keil released a firmware file that replaces the anything-but-OpenSDA "flasher+debugger" with ARM CMSIS-DAP compliant interface that JustWorks(tm). Unfortunately, it's only usable as a debugger with the tools I have, so to actually flash an image, you have switch back to the OpenSDA "applications" -- which, since they pulled their fixed-for-Linux bootloader, requires a Windows box.

All I want to do is write a "Hello World" program on this thing, and I've wasted the better part of two days on things that should JustWork(tm).

So much to "Open" or "Freedom" -- Grand ideals ruined by horrible execution. Unfortunately, this is the sort of thing I've come to expect out of Freescale. Every encounter leaves me wanting to bash my head againt the wall.

A month or so ago I compared Freescale to someone shooting themselves in both left feet. Maybe I should add "while running backwards" to that analogy.

In comparison, STMicro's STM32F4DISCOVERY board ($15 with a Cortex-M4!) isn't without its flaws, but it took less than half an hour to assemble everything I needed to flash and debug the board, and their documentation and software samples are comprehensive and excellent.

...It's not much of a race.

Syndicated 2013-09-12 02:56:27 (Updated 2013-11-24 04:11:59) from Solomon Peachy

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 Sizebur) 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. :)

Syndicated 2013-08-28 02:27:21 from Solomon Peachy

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

This week's (Linux Weekly News)[lwn.net) (kernel)[http://lwn.net/Articles/563977] 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.

Syndicated 2013-08-22 14:20:42 from Solomon Peachy

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] (http://wbo2.com.au/~techedge.com.au//vehicle/aldl160/160serial.htm)

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.

Syndicated 2013-08-22 04:11:16 from Solomon Peachy

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/

Syndicated 2013-08-21 04:08:59 from Solomon Peachy

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!

Syndicated 2013-08-04 17:50:20 from Solomon Peachy

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.

Syndicated 2013-08-03 04:44:17 from Solomon Peachy

Gutenprint/CUPS unified dyesub backend committed; what's next?

I just committed the unified 'gutenprint+usb' CUPS backend into the upstream gutenprint tree. It ends a two-week-long flurry of slicing and dicing the old standalone backends into a cohesive whole, including fixing the inevitable pile of regressions.

There were also a small pile of (non-regression) bugfixes that made it in, plus the ability to deal with printers that report no serial number (I'm looking at you, Shinko S2145)

Additionally, support for the Kodak 6800 was beefed up, and full support for the Kodak 6850 was added.

This commit pretty much wraps up my task list relating to printers, barring bug reports and/or another printer showing up on my doorstep.

Meanwhile. My next meaty software project is likely to be microcontroller-oriented (ARM Cortex-M series). It's still in the planning stages (a glorified science project) but coming out of it will be skeleton project that others can re-use.

My motivation for this is that if you're entering into the microcontroller world after being used to a typical F/OSS workflow (ie gcc+make+gdb) it's a bit of a shock to discover that IDEs and proprietary tools/libraries are usually crammed down your throat, and there's a dearth of information out there on how to set up a modern hello world project that is written in pure C, is well-documented, and doesn't rely on proprietary bits or third-party "magic handwaving happens here" binaries.

It'll include a modern GCC C/C++ toolchain (via crosstool-ng), debugging support (via OpenOCD and GDB), and a basic FreeRTOS example/port. All of this will be supplied in source code form, even the toolchain.

I haven't decided on how to license this framework, but it'll probably be something ultra-permissive (eg MIT/X) rather than the copyleft (GPLv3) I normally use for software I write.

Syndicated 2013-07-27 12:41:31 from Solomon Peachy

139 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!