Øyvind Harboe wrote: > The problem with microcontrollers is not cost, but that they are > ephemeral. > > OpenOCD is going on 6 years now? What MCU and PCB layout would be > relevant more than a year or two?
With a relevant protocol abstraction nothing significant would have changed. The only change during these years is the addition of SWD. Other than that, the high level use of JTAG hasn't really changed. Or is that a misconception of mine? Assuming that it is indeed accurate, maybe the transport could have changed over the 6 years, or the hardware implementation, but actually no, I don't believe that to be true either.. USB microcontrollers programmable in C with open source tools were available 6 years ago too. They are *way* faster larger simpler nicer now, but it could certainly have been done then as well. Maybe only low-speed USB with something like PIC 16C765 at 12 MIPS and very little RAM, but there were also more performant choices. If a protocol was made back then we would still be using it for all JTAG, and we would be looking at how to extend it to fit SWD. Maybe ARM would have done it for us. Who knows? The code in the hardware would also still be usable, it would just be running 6x faster now, and be able to buffer a whole lot more transactions. I've been looking at STAPL lately, that's a pretty good example of what I mean by a high level protocol, although it may be a little *too* generic. I'd really like a port of Altera's 8051 Jam bytecode player to an ARM. I think it's obvious that it's the right way to deal with STAPL. > I'd like OpenOCD to be maintained against something that spans > 5-10's of years and here the PC programming model does nicely. I don't think this is reasonable in 2010. The world changes much too fast, and instead we must find a way to deal with the changes. The key is of course to have interfaces that are designed well enough so that a layer which probably will not last for the full lifetime of the project (such as LPT, or COM) can be replaced easily with something else (USB) but still be used for the exact same high-level interface. > Also the PC programming model is common to *all* developers and > users, and this gives the OpenOCD code the most amount of testing. Why insist on the least common denominator? Relevant abstraction is the only way to get decent performance *and* have a chance at being forward compatible. //Peter _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
