Excerpts from Peter Stuge's message of Sun Apr 03 13:24:39 +0100 2011:
> > > 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.
Either way, this is a common approach in the drivers, take a look at
src/jtag/drivers/arm-jtag-ew.c which implements global buffers for the
USB pipe.

The code can of course be extended to support this, but ..

> > 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 see nothing in the code to check for anything other than a matching
vid/pid combination, which automatically limits it to just 1 device.

> > I am not aware of any instance structs for this purpose in openocd.
> 
> Maybe someone else on list knows?
No comments as of yet...

Attached are 2 rebased/tidied patches for the 2 features.
First implements LED support within the old code.
Second implements buffering, and updates all of the writes to use the
buffering.
Are these ok now? As you can probably tell, I am not experienced with
cooperating with other people in projects.

-Ali

Attachment: 0001-Add-support-for-LED-to-USB-Blaster-code.patch
Description: Binary data

Attachment: 0002-Buffering-for-up-to-64-bytes-in-USB-Blaster.patch
Description: Binary data

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

Reply via email to