GTA04 Block V4

Yair Mahalalel yair at
Mon Aug 18 03:39:23 CEST 2008

On Sun, Aug 17, 2008 at 06:09:15PM +0100, Andy Green wrote:
> Hash: SHA1
> Somebody in the thread at some point said:
> |>  > There is good support for the PIC16 series.
> |>
> |> Completely different toolchain, though.
> | yes, on the other hand sdcc has worked well for me.
> I also used sdcc on some nice cheap turbo 8051-based Silicon Labs USB
> devices, I don't think it's some killer issue if it is sdcc.  That is
> GPL'd just fine and was stable for me.

sdcc supports PIC18, and there are a couple of Free USB implementations
that work with it. See here for example -

(Xiaofan, BTW, is a linux enthusiast and involved in several projects on
the PIC/USB/FOSS crossroad. He'll be able to advise you about what's
available in that area)

> |>  > And those are well able enough to do the consierge job.
> |>
> |> Good luck with USB ;-)
> | OK, I've only done non USB stuff with PICnns
> On SiLabs device they had canned code for operating the endpoints and
> doing the logical part of the USB protocol, it wasn't a problem.
> Ultimately the game of things having firmware and the choice of
> write-once or unbrickable has to end with something with no firmware
> that is simply inherently unbrickable,

Which is where the very simple, updated externally only solution might
fit. As a back door to the "unthinkable", who'll bootload the
bootloader's bootloader problem, you can have a few vias on the board
exposing the PIC's serial programming interface, which is pure

> that's the FTDI chip in this
> story.  If they did a really small package it would be a no-brainer.

Did you have a look at TI's TUSB3410? It does the UART<->USB conversion in
~34mm^2. It isn't as simple to use as the FTDIs, mostly because it isn't
ashamed of being a uC (which is almost a requirement at USB's complexity
level). And you do want a uC in there for debug/control purposes beyond
debricking, no?

> Other MPU functions are simpler to specify for when we remove USB from
> the mix, a cheap ultra low power MSP430 is fine then.

And then? Back to the debug board for flushing a bootloader? Or having
two separate cores on board, one for USB and another for control?


PS. mistyping FTDI2232 into google (instead of FT2232), the first hit
was emulation code for the PIC18. You can load it and read/write protect
the entire chip for a smaller/cheaper/customized FTDI replacement - .

> - -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> P0IAnAxrBV8Beuj2umta5X+tgMza9FoY
> =wgf3
> _______________________________________________
> hardware mailing list
> hardware at

More information about the hardware mailing list