Hello, On Mon, 21 Oct 2013 00:17:20 +0200 Michael Schwingen <[email protected]> wrote:
> On 10/20/2013 11:18 PM, Paul Sokolovsky wrote: > > It is the same with a serial port: no such implementation exists > > now. The detour may be a bit shorter, but not by much. > > Well, I have that covered, I really didn't want to start > > completely theoretical discussion. But I just didn't want to > > overload initial mail with pointing to specific prototype, because > > I first wanted to make sure that overall approach is OK. > > > > So, I have a prototype which works and written in (completely) > > MCU-independent manner: > > https://github.com/pfalcon/simplejtag/blob/master/simplejtag_l0.cpp > > As soon as support for GPIO of new MCU is added, it can just work. > > To achieve that (efficiently), C++ metaprogramming techniques are > > used. Now you see why I started with talking about defining > > protocol first - that's all what's needed on OpenOCD side. But on > > firmware side, I actually strive for the same generality, and > > single source (but multiple configs of course) covers MSP430, AVR, > > STM32, EFM32, LM4 so far - with the price of C++. Of course, that's > > just one possible implementation of protocol, someone can write > > Arduino-specific "sketch" for that, use TI's CCS bloat for MSP430, > > churn STM32 Peripheral Library etc., etc. > > I just don't really see the huge implementation benefit of UART vs. > USB here. > > Any USB stack should provide some means of calling a user function for > read/write of a packet to a defined endpoint - just like UART, only > you read/write packets instead of bytes, and you get them via some > callback instead of interrupt. > > Encapsulation and device-independentness can be handled just like in > the UART case - you just treat the USB stack as a device-specific > external, just like the UART driver in your case. Even with UART, you > need device-specific startup code, UART driver, timer driver and GPIO > driver, so adding in a device-specific USB stack does not make much > difference if the design is done right. Sorry for delay with response - really wanted to get this RFC out before starting travelling. Well, I guess I'm now getting what you mean ;-). I'm coming from "software" world, and never had experience with low-level USB programming, for me it means dealing with descriptors, endpoints, interrupts and DMAs. If you say that typical USB stack offers that higher level abstraction that each pipe is, well, kind of serial pipe, sounds good. Another thing that I mentioned, perhaps too late, is that I didn't want to start theoretical discussion of "cool protocol which everyone else should use", I'm about to offer actual firmwares for the protocol proposed for few LCBs. But as I mentioned, I envisioned "multiple levels" of protocol, and if you'd like to discuss what "level 1" could be, I'd be glad to speculate on that, except that I wouldn't have it in my queue to implement - at least not before "level 0" is "done". But I surely gave thought to that myself. So, level 1 IMHO should support: 1. Pipelining (not require immediate response, so it should be buffered/queued and can be packetized in USB case) 2. Duplex (so, if UART used, it should be hardware) 3. Raw SWD packets seems like natural payload for SWD protocol. 4. And as SWD header byte has 3 fixed bits, we don't really need special framing - we can use raw SWD packets, and will have enough different header values for JTAG and other protocols and commands. 5. For pipelining (at least UART one), I guess it makes sense to make packets fixed-size, so always return ACK + data word for reads, even if ACK has FAULT/WAIT status. 6. Unfortunately, I don't know JTAG well enough to propose what would be good packets for it. OpenOCD seems to miss intermediate level between bitbanging and command_queue either - the level of bitstrings. Questions I'd pose to define needed packets are: a) do we need duplex shift in/out? my guess it's unavoidable for autoprobing, but does openocd requires/uses that for normal operation? b) does it make sense to separate "shift bitstring to TMS" and "shift bitstring to TDI", or that doesn't make sense and those values should always come in pairs (my guess that "shift bitstring to TDI" is definitely makes sense, not sure what dual should be - "shift TMS" or "shift both"). c) ... > > cu > Michael > [] -- Best regards, Paul mailto:[email protected] ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
