Read device info does not work on ATF22V10 (and other 22V10) but read/write/verify does

[rreilink]

The command 'i' (operationReadInfo()) does not send the type info to the Arduino. The Arduino sketch defaults to ATF16V8B. 22V10 GALs have a different number of pesbytes and therefore the readinfo returns the wrong data.

[rreilink]

Fixed by PR https://github.com/ole00/afterburner/pull/17

[ole00]

You probably did not set the gal type by adding parameter '-t [GAL_TYPE]. If you use

./afterburner i -t HELP

then the available GAL types should be printed on the console. Choose one of the type in the list and pass it with the -t parameter. Hopefully that should do.

[rreilink]

I checked, and the problem is there even with -t .

It is caused by the fact that at least on Mac OS X, the Arduino resets when opening the serial port. Most operation<...> functions open the serial port at the start and then close it when finished. Thus the Arduino 'forgets' the GAL type.

My suggestion: let's remove all openSerial() and closeSerial() from all the operation functions and just place them in main(). Would that work? I can make a PR if you want.

% ./afterburner -t ATF22V10C i -d /dev/tty.usbserial-14P52674 -v
Afterburner v.0.3 
opening serial: /dev/tty.usbserial-14P52674
read: 5 ''
opening serial: /dev/tty.usbserial-14P52674
read: 5 ''
opening serial: /dev/tty.usbserial-14P52674
sending 'p' command...
read: 62 'PES info: 3.3V Unknown GAL,  try VPP=10..14 in 1V steps'
PES info: 3.3V Unknown GAL,  try VPP=10..14 in 1V steps
result=0

[ole00]

You are right. Mac OSX resets arduino every time the port is closed. I did not notice that before - thanks for reporting that. I spent few hours trying to set additional parameters to the serial line to prevent that, but without success. So, I've implemented the feature you suggested in another discussion - to not to close the serial port in between operations. The change has been now comitted and afterburner seems to work much better. If you want to compile please add -DNO_CLOSE compilation flag or grab the precompiled binary ver. 0.4 from the releases directory. Thanks.

[artgodwin]

I believe Linux also resets the Arduino on port close (or possibly port open). This is usually shown up by a reset occurring when the Arduino monitor is opened (or, perhaps the monitor itself does it). The Arduino reset is driven, I think, by the CTS line.

[ole00]

Yes, I tried to disable that (flow control) via serial parameters when opening the port to no avail.

[rreilink]

This behavior is indeed what triggers the issue. It is no problem however as long as the serial port is opened only once during the execution of the program (instead of opening and closing several times). This is what PR 19 implements. That fixes the issue.

[ole00]

Thanks for the idea - I implemented it in d518805925b1b6d84b4df7437a5077198a30de1a . NO_CLOSE preprocessor must be used when compiling the PC app for Mac. It still does work for other ports as well and makes the PC program a bit faster, so that was a good suggestion.