Magnus Lundin wrote: > The only reason I can think of for a specic numbering is that it might > optimize the gate design in a hardware implementation of the tap state > engine. But this is not a problem for us so thats OK. If we want to > follow JTAG documentation standards (ARM ane IEEE) in our code then the > state names should also change like: > > TAP_DREXIT2 --> TAP_EXIT2_DR > etc > (this will have a greater impact ... ) >
Name changes: Luke warm on this *name* change. Value changes: This *should* be safe (as a goal), but I would be only about 90% sure that it is at this moment. I tried to move the code in the direction of switch()es instead of arrays which where were dependent on array index values matching symbol values. But I do not know that all such situations were corrected. So I think we should keep an open eye on this change for awhile, and keep the goal in mind. > and finally > > TAP_INVALID is used in the target code to mean "TAP DONT CARE" so > calling it invalid is a bit misleading. > There are places in the code where we have a don't care, and elsewhere an invalid or initial undefined state. So we would need two symbols to be perfect. With that would come unnecessary complexity. The current symbol might be good enough. I wish to remind the team that next week I will be working on the ft2232 driver. This is with or without the patch from Duane. That is my time slot, and it is not movable due to some manufacturing test schedules that I have to meet for a new ARM board we are making: <http://dl.softplc.com/ds_Smartboard.pdf> http://dl.softplc.com/ds_Smartboard.pdf We want to use ARM-USB-OCD to program the boot flash, perform memory tests, and program the FPGA all under linux hosted OpenOCD as the boards come off the line. The starting point of my work will be whatever is available at that time, patch if available, HEAD if not. Duane? Dick _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
