On Wed, Nov 18, 2009 at 16:17, Øyvind Harboe <[email protected]> wrote: >>> Actually, the minidrivers don't clone today, so that's already taken care >>> of. >> >> Doesn't that apply only to zy1000.c ? > > The USB case needs to delay execution to build a long > scan, so there copy is required.
I think you misunderstood what I am proposing. I did not suggest to execute the sequence immediately. I am not only aware of the USB latency, in fact the arm11 code relies on it for the burst mode. >>> The USB drivers have a 1ms roundtrip problem to contend with, the >>> rest is in the noise, essentially. There is plenty of evidence to this >>> effect. >> >> *You* brought up performance as concern... My goal was primarily >> streamlining code. > > I did. We need both streamlined and fast code. Until we have both sorted, > we leave things the way they are. My proposal does not imply any decrease in speed, it can lead to an increase. It still builds up a jtag sequence before executing it, it just modifies the interface for value types. >> Your example seemed to be too much of a workaround rather than >> addressing the problem directly, which IMO is that the uint32_t case >> is so common that there should be a short unambiguous way to deal with >> it. >> >> Of course even a set of standard wrappers to package the set-up of the >> most common field configurations would help a lot, without also >> serving as a shortcut into the minidriver-layer to avoid the copying. > > I've got some thoughts on how to do this, but nothing written up yet. > >>> Also we have to *carefully* consider how we can make *small* steps that >>> can be tested on all the hardware combinations. Otherwise any change >>> is unlikely to pay off. We're getting there but it will and should take >>> time. >> >> It was a suggestion on long-term goals. Small steps are usually most >> effective when they go towards a specific target. > > I'm doing small steps in a branch for now. We'll see how it pans out. > > That branch might end up being a big leap before it is pushed to > the master branch. Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
