Back to tinkering with the (now repaired) FRDM-KL25Z board and, at the moment, mbed.
Since I've got a few things on the horizon that could plausibly use KL20-series chips and want some sort of basic comm channel over USB, I fiddle with the USBSerial_HelloWorld demo app.
Obvious test is to install the app, connect the board's target-USB port, and cat /dev/ttyACM0, but that doesn't seem to work: sometimes gets the first character of the intended output, but more often not even that.
I try gtkterm, and it (a) doesn't think ttyACM0 is a thing, so I have to type in the name manually, and (b) doesn't work.
After some 'net wandering, I try PuTTY, and it works. So does screen.
C'mon, now, guys. POSIX used to make serial ports nice and transparent. If Linux is going to stick with POSIX's sucky, PDP-11-era fixed list of predefined Baud rates, it should at least make CDC-ACM devices act like the various kinds of USB serial UARTS, and actual serial ports.
Guess I'll have to see what PuTTY and screen are doing differently, and make sure whatever libraries I write for talking to my gadgets do the same thing.
(I don't have any other CDC-ACM devices handy, apart from maybe an old cellphone. I thought treating /dev/ttyACM0 like /dev/ttyUSB0 or /dev/ttyS0 used to work. Has Linux changed, or is there something different about the mbed USB stack? Maybe it's emulating flow control?)
Oh, well: I probably want to check out Freescale's RTOS offering, too, and I'll see if its USB-serial thingy behaves differently. The final applications will tend to need some combination of PWM, ADC, I2C, and SPI, and various amounts of multitasking. Significant consideration: KDS has the nice (?) GUI for configuring pin assignments, device configurations, and so on, though I still haven't gotten far enough to determine just how useful that really is.
Update: A USB CDC demo program built & installed using KDS does indeed seem to behave as expected (once I figured out that the demo program was missing a call from main to the actual innards; I'd assumed there was a task configured somewhere, and there wasn't)... so there's something wonky about the mbed implementation. Given that the intended application is more MQXish than mbedish, maybe I need to get up to speed on the whole KDS/MQX thing. After I find time to get some actual work done, that is.
Update 2: I guess the demo in question isn't even using MQX; looks like it's on the bare metal, plus device drivers and maybe CMSIS or something. Gotta get up to speed on the Cortex M culture (which has been on the to-do list for a couple of years now, but it's (still) not revenue-track).