Archives

I’ve begun looking into options for a USB-to-ADB adapter, to enable use of modern USB keyboards and mice on vintage Macintosh and Apple IIgs hardware. There’s no real “meat” to this yet, as I’m just looking at parts availability and searching for relevant example code, but every project has to begin somewhere.

I did a search to find the cheapest microcontroller with USB Host support (actually USB OTG), and the winner was the Microchip PIC32MX. I know zero about developing with PICs, but how hard can it be? Actually I’ve heard that older PICs were quite awkward to work with, but the PIC32 is a modern RISC-type design.

Microchip sells a PIC32 USB Starter Kit III for $59. I’m not quite sure what this is yet, but it’s probably a better starting point than a bare PIC32 chip.

The kit has an 8 MHz crystal. Will that be enough? Is it replaceable? The PIC32MX is rated to 40-50 MHz depending on the version, but I’m not sure I’ll actually need that speed.

Do I need a USB OTG cable for the finished product? Can the hardware support two attached USB devices (mouse and keyboard), or a USB hub?

24 Comments so far

Mark March 18th, 2016
6:24 pm

I don’t have a data sheet handy but I suspect the 8MHz xtal will run the MCU at 32MHz. Microelektronica also makes some useful PIC dev boards and they are available from Digikey. I do use a lot of PICs (though not much USB) and am happy to help with any questions.

Charles Hawkins March 18th, 2016
8:25 pm

Neat! I made an Arduino (an Uno running at 16 MHz) speak ADB for fun. Or at least speak it well enough for the iMate I tested it with (the Mac was all the way upstairs you see…); granting that the iMate seems to use a rather abbreviated version of the protocol, skipping all that bus enumeration and address conflict resolution nonsense that a real Mac does (surely it’s not important!). I never really did anything with it beyond have it relay characters it saw on the serial line as keystrokes.
Even if the PIC is running at 8 MHz that should be more than fine for generating ADB signals. ADB uses a duty cycle modulation scheme (similar, incidentally, to the later Nintendo 64 controller’s protocol) where each bit is 100 µsec; a “1” is pulling the data line low for 35 µsec and a “0” is pulling it low for 65 µsec. At 8 MHz that’s 280 and 520 cycles, respectively, and there isn’t anything smaller than that you need to measure out. And the host leaves an interval between polling of something like 10 ms, leaving plenty of time to do other things.

That’s an odd signaling mechanism… I’ll have to think about that. If I need to resort to bit-banging or high-frequency timers to produce the necessary bit-by-bit duty cycle modulation for ADB, it may use up all the available time, so there’s nothing left to service the USB side or do anything else. Maybe there’s some SPI or serial module that can be abused to accomplish this.

Coming from the AVR world where the IDE and compiler are free, $500 for the official PIC C compiler is a little hard to swallow. I guess there are alternatives, but how well do they integrate with the IDE and official USB library/example code?

Looks like the PIC32 has just one USB interface. If I hardwire that for USB host usage (a USB A connector), then I can’t ever use a USB bootloader for end users to flash new firmware to the device. But if I use a USB OTG connector, then the device will require one of those weird USB OTG cables. Possibly I can have both a USB A and a USB B (or mini-B) connector on the device, connected in parallel, with a configuration switch to select between them? Sounds complicated. Maybe end user firmware upgrades aren’t really necessary anyway (though my experience with Floppy Emu says otherwise).

For initial program after assembly, if I don’t have a USB bootloader, then I’ll need an in-circuit programmer. The PicKit 3 is $48, but Microchip seems to go out of their way to discourage its use. I’m not sure what’s different between the PicKit and more expensive ISP “production” programmers, or something like the mikroProg.

I think I don’t understand what USB OTG actually is, in terms of the connector and the detection of host/device mode, nor what those USB OTG cables actually do. Time to do more reading!

Hmm… if the PIC32 only has a single USB interface (a single pair of USB D+ and D- pins), then how can I connect a mouse and a keyboard at the same time? There’s a lot I don’t know about USB. Will I need to integrate a separate USB hub chip? I assume I can’t just run the same D+/D- pair to two separate USB A ports and expect them both to work somehow. The “B” in USB means bus, but I don’t think it’s a true bus in the sense that multiple devices can be connected directly to the same signal lines.

Andrew H March 19th, 2016
3:09 am

Why not stick to AVRs and the like that you already know, or an LPC1768 or something similar on the ARM side? PICs make me angry. There’s so little that makes sense. You will need a USB hub chip, yeah, or a chip with two USB host ports.

Do you know of a good candidate AVR with USB Host (or OTG) capability? I couldn’t find an obvious one, and the Atmel product finder tool doesn’t seem to be working. From my limited knowledge, any AVR parts beyond the basic 8-bit series (like the XMEGA or MEGA32) aren’t very popular and don’t have many good examples available. There are software USB solutions for AVR, but that seems like a poor choice if other microcontrollers have hardware USB and are cheaper too.

The PIC32 is attractive because it’s so cheap – about $2 each vs closer to $10 for some other options. I’m thinking ahead to the final device, offering it as a product to other computer collectors, and how to keep the cost as low as I reasonably can.

Dual USB Host is going to be a problem, I see that now. The cheapest micro I found that actually has two USB interfaces is the STM32F407, which is about $10. At that price it would be cheaper to simply use two PIC32’s instead, but the software complexity would increase with two intercommunicating mcus.

Another unexpected issue is the handling of USB hubs. Even if this device doesn’t require a hub, some people may want to use one, and some keyboards have the equivalent of a hub built-in. But it looks like (as of 2013 at least) the PIC USB framework does not support hubs.

One warning about ADB compatibility. Test everything on a ROM 01 Apple IIgs. Why? Because it was the first ADB machine ever shipped by Apple and it has incompatibilities with later ADB peripherals. The most notable examples being the Apple Ergonomic Keyboard and later revisions of the Kensington TurboMouse trackball (I think up to version 3.0 works on the ROM 01). The ROM 3(1989) has a newer ADB controller that doesn’t have the same issues.

Also related, the IIgs seems to support 2 button ADB mice where the 2nd button is a “click lock” function.

Vincent March 19th, 2016
3:49 pm

I’m not sure if you are doing this to sell or just for fun.

If just for fun, I would start with a Pi Zero for all the USB stuff and use a PIC as a serial to ADB converter as per app note AN591 for the tight timing stuff.

John March 21st, 2016
3:21 am

There’s also TI’s MSP series. They have some small(ish) cheap ones with USB, like the MSP430F5500, which Digikey tells me can be yours for under $2.

I don’t have any experience with them, and don’t know what the compiler situation is (although it looks like there’s a gcc for it).

I think the PIC32 is probably the better choice for this purpose. At least for the specific MSP version you mentioned, it only has USB device capability, not USB host. And the price is about $3.20/each for the quantities I’d be buying. From a brief look at the other MSP variants, none of them appear to have USB Host capability. That’s too bad.

Andrew H March 21st, 2016
9:41 pm

The XMEGA chips are as supported as anything else – hell, the Arduino Zero and the Adafruit Feather M0+ uses one of the new SAMD atmel ARM chips which has USB host support. And there’s these Freescale chips too; https://developer.mbed.org/platforms/FRDM-KL46Z/

Kevin Harris March 22nd, 2016
1:20 pm

I know you are at the very early stages of this project but would you think it would also be possible to use this the other way around so for example you could use an Apple ADB keyboard on a PC etc, just a thought as I would luv to use my IIGS original keyboard on my PC 🙂

The Standard and PRO editions seem to just offer better code optimization when compiling for memory efficiency.

When I took a microcontrollers course at college last year, our instructor had us use PIC24 based chips on breadboards. I believe we used the PicKit 3 and it worked just fine for getting the bootloader on them. After that we used USB to TTL adapters to load different programs.

The official IDE is also free: http://www.microchip.com/mplab/mplab-x-ide (In fact it’s a heavily modified version of the open source NetBeans IDE.) Last time I used it though the menus were glitchy, hopefully they’ve resolved that since then.

I’m a little confused by the various compiler versions. According to http://www.microchip.com/mplab/compilers#what-are-the-different-modes, the free edition of the compiler has minimal optimization. The standard edition ($500) has “execution speed much faster than the Free Edition” and 20-25% smaller code, while the pro edition ($1000) has execution “a little faster than the Standard Edition” and 50-60% smaller code. I haven’t actually tried compiling anything yet, but it sounds like the free edition is basically debug/unoptimized, and you’ll need standard or pro for any real work. It would be helpful to quantify “much faster” execution speed, or describe the specific optimizations that are/aren’t present. Can the free edition be used for real work, or is it just a toy?

Owen March 24th, 2016
4:00 pm

The “free” compiler is literally an ancient version of MIPS GCC crippled to only operate at -O0, with an EULA on their peripheral libraries stating that you can only use their compiler version with them (so you can’t just use a normal MIPS GCC build and avoid their crippling).

Yup, that’s right – they want you to pay $1000 for a license for a compiler they got for free under the GPL. How kind.

Atmel’s SAMD21 parts seem to come in at a similar price. The compiler is free (an ARM maintained Cortex-M focused build can be found at https://launchpad.net/gcc-arm-embedded, for Atmel parts conveniently packaged up in Atmel Studio also), one debugger will work for all parts (and normally one comes on the dev board – ST sell some $15 devboards which include a completely generic ARM SWD programmer/debugger!), and Atmel’s peripheral library is under an eminently reasonable license (BSD like, with the added restriction that you can only use it with Atmel parts)

And, well, you’re not stuck in Microchip’s ecosystem with their user-hostile compiler pricing, flaky debuggers (I’ve heard lots of bad things about both the PICKit3 and ICD3, which is a shame because back in the day I quite liked my PICKit2) and which is generally just the road less travelled in the greater community.

toru173 March 25th, 2016
4:59 am

With respect to multiple USB host functionality, why not tie multiple MCUs together on the ADB side? ADB is a multi-drop bus, and you could have each MCU self configure as a keyboard or mouse and announce itself accordingly. Doesn’t solve the issue of keyboards with built in hubs, but is an easy way to get multiple peripherals.

Firmware updates might be possible by the MCU acting as a USB host for a thumbdrive, and the firmware BIN copied to the drive root. That way, no USB client or OTG needed, only host

I would suggest trying the Free edition with the -O1 flag enabled. Or use the -O2 flag while you’re still in the 60 day evaluation for PRO. I know, I just spewed a bunch of scattered links and info… Just throwing out options.

From what I can tell on the microchip forums, O1 optimization works fine for most hobbyists. I haven’t been able to find any information/benchmarks comparing O1 and O2 on PIC32 chips.

Seamus McMillan April 26th, 2017
7:57 am

If anyone ever comes up with a device that would enable me to use a USB mouse/keyboard on my ADB-input PowerMac 8600 I’d be very happy to pay for it (within reason of course).