Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rreilink opened this issue Mar 27, 2022 · 8 comments

Comments

@rreilink
Copy link
Contributor

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
Copy link
Contributor Author

Fixed by PR #17

@ole00
Copy link
Owner

ole00 commented Mar 28, 2022

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
Copy link
Contributor Author

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
Copy link
Owner

ole00 commented Apr 22, 2022

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
Copy link

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
Copy link
Owner

ole00 commented Jan 22, 2023

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

@rreilink
Copy link
Contributor Author

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
Copy link
Owner

ole00 commented Jan 22, 2023

Thanks for the idea - I implemented it in d518805 . 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants