Older blog entries for Pizza (starting at number 141)

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

The Kodak 805 works!

I just received the replacement Kodak 805 in the mail. I plugged it in, added its USB ID to the Kodak 1400 backend, and kicked off a test print.

It worked perfectly... and there was a distinct lack of smoke escaping!

In other news, I've fixed the last of the bugs in the Shinko/Sinfonia CHC-S2145 backend, resynced everything with Gutenprint, and now it's time to start unifying the various backends.

This ought to be fun. And by fun, I mean fun. Yeah, I need a life..

Syndicated 2013-07-18 00:14:35 from Solomon Peachy

And the Dyesub printer train continues

The Shinko/Sinfonia CHC-S2145 driver and backend are functionally complete, though bugs remain with the auxilliary commands. I must say it's nice seeing the printer spit out one of my photos in only few seconds, knowing that I wrote much of the driver code. The auxilliary commands work, but there's still something wrong with my handshaking since the printer hangs after the response comes back.

I still have little idea as to the printer error codes, but I found some docs via google that at least enumerate the various errors that are displayed on the printer's LCD screen.

Today I distracted myself a bit and spent some time reverse-engineering the spool format and printer protocol used by the Sony UP-DR150. I committed the initial cut at a backend, and if it turns out to work, I'll go ahead and add that to gutenprint as well.

I find myself wondering if I should just unify all of those disparate backends into a single 'gutenprint-usb' backend that handles everything.
I'm already up to five backends, and that number will only grow.

While all the backends basically do the same thing, there isn't very much directly common code, and trying to genericize the almost-but-not-quite common bits will make things much more complex without really buying us anything. That said, presenting the system with a single executable may be the right way going forward.

The Sony UP-DR200 and DNP DS40 may soon gain improved support as well.

In other news, I had a report of a crash with the CW1200 driver when trying to use Monitor mode. Unfortunately in the process of moving I seem to have lost all of my serial cables -- so I can't get a console on my development board and recreate the crash in a full debug-enabled environment.

I need to do someting about this ASAP.

Syndicated 2013-07-14 21:19:57 from Solomon Peachy

cw1200 driver is officially mainlined

As of about eighteen hours ago, the ST-E CW1100/CW1200 WLAN device driver was merged into the Linus's mainline linux tree, culminating more than a yearlong effort to get the driver into shape.

I'm now trying to get official permission to have the necessary firmware included in the linux-firmware tree. This is stymied by ST-E's recent implosion and the fleeing of all of my former contacts, but I'm told the WLAN group will live on, most likely under the STMicro name.

There's also the open question of support for the CW1x50 and CW1x60 successor chips. I need access to hardware to do any meaningful development, and I have no idea where to obtain that.

Ah, it's a good day.

Syndicated 2013-07-10 13:51:08 from Solomon Peachy

Photo printer developments

Today, I picked up a 20 kilogram package from FedEx. Upon opening the more-than-a-litte-abused box, buried in the sea of foam peanuts was a tightly-bubble-wrapped bundle of high-end kiosk-scale photo printer -- A Sinfonia (nee Shinko) CHC-S2145.

It was express-shipped to me by LiveLink Technology, a photo kiosk solution provider based out of Merry Old England, for the express purpose of getting it to work with Linux (by means of Gutenprint). LiveLink bucks the industry trend by using Linux under the hood wherever possible, so by sponsoring this work they benefit through lower costs and greatly improved flexibility, and the community benefits from the native support of a truly professional printer.

The Sinfonia CHC-S2145 carries enough media to handle seven hundred prints at a time, spits out a 4x6" print in seven seconds, and will do so day in and day out. As a testament to their robustness, this one came heavily broken in to the tune of nearly 78,000 prints.

Anyway. I've already committed the initial support to Gutenprint, which now generates proper raw spool files that match the output of the Windows drivers. Unfortunately (as I've come to expect) this printer requires an intelligent, two-way backend, which will take a bit more time to put together. Fortunately I'll able to reuse large chunks of the backend code I've written for other dye-sublimation printers.

In other news, earlier this holiday weekend I polished most of the rough edges off of the Kodak 1400/805 Gutenprint code, and should have another '805 in a few days -- the seller agreed to send a replacement after the first one aggressively blew the magic smoke out of its power supply.

It's been a productive few days. But now it's time to produce some sleep.

Syndicated 2013-07-06 03:16:41 from Solomon Peachy

More printer goodness

Tonight I finally committed support to Gutenprint for the Mitsubishi CP-9810D/DW high-speed kiosk dye-sublimation photo printers. I have no idea if it actually works, but at least Gutenprint appears to be generating properly-formatted output.

What made the CP-9810D/DW printers interesting is that not only did they require 12 bits of data per pixel, but they also required the lamination pattern to be generated on the host and sent over as another image plane.

Next up, I'll move on to the CP-D70DW/D707DW models. These two models also require a host-supplied lamination plane -- and the image data appears to be a full 16bpp.

It may be worth adding more generic lamination pattern support to Gutenprint, just to see what we can do. But for now I'd just be happy with being able to test out all of this new printer support.

On that note, I've lowballed a bid for a Kodak 805 printer (the successor to the 1400 large-format printer), and I'm in contact with someone who picked up a Mitsubishi CP-9550DW and is willing to be a guinea pig. Hey, it's a start..

Syndicated 2013-06-05 02:52:16 from Solomon Peachy

More on Google and XMPP

I should elaborate a little more about the vitriol of my last post.

Google's largest advocates were the more technically inclined. The early adopters and the folks who either made technical decisions or heavily influenced those that did.

This was especially true of Google Talk, which brought the first meaningful interoperable Instant Messaging to the masses, unlike MSN, Yahoo, ICQ, AIM, and several other proprietary networks. This was the driving force to get our organizations to set up XMPP servers, because, hey, it'll interoperate with Google, and we all know Google does the right thing.

Now we're eating our words.

The masses that use Google Talk the same way as they used AIM or Skype or Facebook chat don't care; they were already using the network they started with. Instead, it's the technical folks, and those who listened to us, that are screwed over. Like, oh, our employers.

It was never about "using a single client" -- it was about using a single, universal identifier (not unlike your email address) that let anyone get in touch with you, without having to juggle half a dozen separate logins. With that, clients competed on features, rather than network-effected lockin.

We consequently built our Instant Messaging systems under the assumption that it would be federated, and now we find ourselves suddenly unable to communicate with an increasing part of our contact lists simply becase they clicked "okay" when Google prompted them to "upgrade" to Hangouts. Bang, they're now forced inside Google's walled garden, and all non-google contacts are gone.

If you're going to exist in a walled garden, why not just continue using Facebook? Google is now trying to beat Facebook at its own game, and in doing so, is becoming the very enemy it once decried.

Syndicated 2013-05-30 02:50:20 from Solomon Peachy

Wither Google?

I remember Google's original motto of "Don't be Evil." I believed them, because they backed up those words with actions. Their products were open and interoperable. Where standards didn't exist, they wrote and published them. They were principled, and consistently so.

Not any more.

It's been a slow slide from grace, but the final straw was them half-assedly killing their formerly interoperable IM service, Google Talk. Ironically, this happened the very same day their CEO decried their competitors for not interoperating with open standards.

Why is this a big deal? Simple -- Network effects. Why are telephones (and SMS), snail mail, and email so useful? Because anyone can communicate with anyone else. XMPP was that for Instant Messaging, and Google was its biggest champion. Unlike its competitors, the service was federated, just like email. You could operate your own server and still communicate with anyone else using the standard. Everyone had a walled garden, but Google through their clout started kicking those walls down. Until they changed their minds, using a set of bullshit excuses ("oh, the standard wasn't keeping up with our needs" -- nevermind they had no problem extending said standard before, and indeed, conveniently ignored many already-defined features they claimed they needed)

Now it's effectively dead, because not only has Google actively chosen to wall their garden off, they did it in such a way that renders communication with the outsiders useless -- you're told they're available, but nothing gets through. No errors, just silently dropping everything.

Why am I so pissed about this? My last two employers used federated XMPP to talk to vendors and customers. One had independent servers, one used Google Apps directly. And guess what? Now everyone who uses google can still communicate, as can everyone who doesn't. but those inside the wall can no longer talk to anyone outside.

What the fuck, Google? You just destroyed your primary value proposition over your competitors. We don't want to socailize or "hang out", we want to communicate with people we need to communicate with.
We need the tools to facilitate business. Heck, even Microsoft's communication suites are fully federated (with XMPP!) these days.

I've had it. Google, which I had such high hopes for initially, is just another Facebook now. Only they've done the Embrace, Extend, Extinguish trifecta far more effectively than anyone else.


Today was my first day at the new job. They're using a combination of Hosted MS Exchange and Skype for commnications. It's an utter mess, slow, and won't scale much longer. I'm supposed to give some recommendations on how to grow this cleanly, but what am I going to recommend? Host everything ourselves (naturally) but should I fight for open systems (standard SMTP/IMAP, CalDAV, XMPP, built on LDAP) or just take the easy way out and recommend an all-encompassing Microsoft solution?

After all, I have the only Linux desktop in the office. So what makes the most business sense? Where's the value proposition fighting this uphill battle? Not only to the business, but to me, personally? Heck, would I honestly be better off just doing my Linux work in a Virtual Machine?

On that same note, I don't need Google to communicate. I run the server that hosts my DNS, photos, web pages (ie this blog!), email, and IM presence. RSS feeds adorn everything. It even does calendaring and address books. I'm working on adding federated VOIP services next.
Everything built on open, federated, interoperable standards.

I started this before there was any real choice, but I've kept at it because I believe in the principle that I should control my own data, and not rely on the good graces of an increasingly-arbitrary third party for my digital presence.

The big feature that Hangouts added over Talk was (far) better Google+ integration. But that presumes you actaully care about Google+. What did Google+ offer me that I didn't already have? Or maybe I should rephrase that. What did Google+ have to offer that they didn't just arbitratily take away? (Aside from the ability to be a collosal waste of time, that is...)

So, I've purged my Google+ profile, and told Google why when they asked. It's a token gesture -- about as effective as farting into a hurricane.

Since my employer doesn't use Google services, I've also purged all but the essentials from my Android phone; the stuff I personally find useful. Which boils down to Voice (far better than my carrier's voicemail system) and Maps (OSMand is catching up quickly though!)

It's a shame there aren't any meaningful alternatives to Android; while I may be more than a little disgusted with Google these days, at least I still have the ability to recompile the entire Android system from scratch, and that's nothing to sneeze at. And as increasingly bad as Google's garden walling is, it has quite a ways to go before it catches up with its competition. If you can't beat them, join them. Or beat them, then join them anyway.

Anyway. Time for bed. Maybe I'll wake up with a better idea about what battles to fight.

Syndicated 2013-05-29 03:37:31 from Solomon Peachy

132 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!