Ali Lown wrote:
> > Buffering can be a great performance improvement. But do you know if
> > the hardware and software (openocd) can handle buffering? Ie. there
> > may be some operations that must be committed immediately, besides
> > read operations?
> 
> Not that I have found. By ensuring on the next read and when the
> program closes that any leftover commands has let it work as expected.
> 
> Also, by forcing a buffer submit when the LED changes state (whch the
> jtag main loop in OpenOCD does at the start and end of each set of
> jtag commands) ensures all necessecary data is sent.

Sounds good. I like that approach a lot.


> > Your implementation seems extremely dangerous to me. You add a global
> > buffer, which will get corrupted if more than one device is being
> > used. Is there a "contract" from openocd core that there will never
> > be more than one instance of a hardware driver? If so this method
> > would be safe, but is still pretty ugly. Is there an instance struct
> > that could be used instead?
> 
> I simply extended what already existed, using 1 uint8_t as an output
> buffer.

Big difference. The output data was previously being passed as
parameter to the output function, ie. it was not global.


> Do people have more than 1 of the same adapter to be connected via
> the same instance of openocd?

Even if they do not, why should the code be limiting this? Unless the
assumption is made throughout openocd I don't think it's OK in the
driver.


> Surely the fact they would have the same vid/pid combination would
> ensure only the first adapter would ever be used?

Every device should have a serial number, allowing two to be
distinguished easily. Clones probably do not, but even then they can
be distinguished by which USB port they are connected to.


> I am not aware of any instance structs for this purpose in openocd.

Maybe someone else on list knows?


//Peter
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to