-
Notifications
You must be signed in to change notification settings - Fork 123
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
Make programmer usbasp libavrdude ready #1763
Conversation
@stefanrueger do you have an idea what happened to the make build system? I'm not able to build anymore:
|
I can confirm that 4761a70 is the issue on my computer... |
I don't have the foggiest. I use the following Makefile
and type |
No issues here under my Mac Mini M1 2020 (macOS 14.4.1). The following is the build log for git main.
|
Please install pkg-config to see if the issue goes away.
|
The step of I do not install PRs to the system -- I only install git main to the system from time to time. For PRs, I either test in the @MCUdude
I do not recommend you to use the installation step even though it may work for you (x64 Homebrew). It will conflict with homebrew's installation. |
At the moment, pkg-config is a build requirement only for detecting and using libgpiod on Linux. So we can also move the pkg-config detection logic into the conditional block, so that is not required on other Unix-like platforms. Signed-off-by: Michael Heimpold <mhei@heimpold.de>
@MCUdude : could you give mhei@3d18fe5 a try on your system? This moves the pkg-config build requirement into a conditional block which is then only required when linuxgpio is enabled. I guess this is not the case on MacOS. |
I have updated the wiki to reocmmend the installation of pkg-config (Linux and macOS) or pkgconf (FreeBSD and Cygwin/MSYS2). I see that as one of the essential package for anyone building avrdude and its dependancies from source codes. For example, libusb-compat-0.1 will require pkg-config. Still I think your fix is still good to have for now. |
I cannot test Issue #1755 but at least a sanity check is okay using ATmega128A. Tested under macOS (Mac Mini M1 2020).
|
This PR is also good for ATmega168P.
|
The data sheet wants a single word write, not a write block
Brilliant tests, @mcuee. Many thanks for checking this PR and the other as well as far as your hardware is accessible. This needs a final test for TPI programming, in particular the fuse. I have now studied the data sheet and rewritten the usbasp_tpi_write_byte() routine accordingly. Although the previously used write block of 16 bytes probably worked, the data sheet only requires writing one word. @MCUdude or @mcuee could you check usbasp with a TPI part (say, ATtiny10)?
|
Unfortunately I do not have the ATtiny10 or other TPI parts for testing. |
@mhei ssorry, but that didn't work:
But thanks for the tip @mcuee! |
But I can confirm that this PR resolves #1755. Now I'm able to write to the fuse memory, something I couldn't do before. However, I was stupid enough to write |
Oh no! What about |
The on-board LED is constantly flashing, so I'm not sure what's happening. |
Maybe we need to re-think how to test a
Maybe the |
Sorry for being so unavailable lately. I've been busy with other things in life, but I'll try to catch up as soon as I have some spare time. I concluded that my T10 was absolutely fubar. While trying to recover it by applying 12V to the reset pin, I acidentally applied 12V to the VCC pin instead. I didn't have a spare T10, but I did have a T9 I could use as well. And with the latest commit, this PR seems to be good to go!
|
@MCUdude Thanks for testing, and sorry for the collateral damage to the t10! Great to know. I'll merge a ton of PRs soon, including this one. |
It's a draft that is supposed to also fix #1755.