Feature request: add linuxgpio programmer to programmer options in arduino IDE

[louigi600]

Hi Hans and contributors,
first of all tanks for your efforts.
Would you consider adding a linuxglio programmer option in the project programmers ?
This would also require rebuilding avrdude to support linuxgpio.

I did 1/2 the work and added the programmer and config ... but then when I try to use it the IDE reports that avrdude was not complied with linuxgpio support.

ATB,
David

[louigi600]

Ok I got round to rebuilding avrdude too: by default if you build from https://github.com/avrdudes/avrdude
linuxgpio is enabled.
I just need to hook up a atmega32 that I have not permanently damaged to check if it works.
avrdude.conf needs to be setup accordingly to which gpio ports you intend to use .... I guess this is kind of a bummer for distributing ... but you could put a note in README that by default it uses and that if you want to change you need to go into ~/.arduino15/....../avrdude.conf

[louigi600]

Should you want to know: it works ... no further hacks were necessary to get the recompiled avrdude pulled freshly from github to work with linuxgpo.
The blink example was compiled and uploaded on the atmega32.
This makes a very easy wiring for RPi:
programmer
id = "linuxgpio";
desc = "Use the Linux sysfs interface to bitbang GPIO lines";
type = "linuxgpio";
reset = 17;
sck = 18;
sdo = 27;
sdi = 22;
;

And a RPi Zero makes a very small and cheap programmer that unlike the "ARDUINO as ISP" wont try to screw you if you don't have a genuine arduino.

[kizniche]

@louigi600 Could you please elaborate on your wiring and setup so I can better understand how you got this to work? I am also trying to program with my Raspberry Pi 4 (CM$ actually, on the Development IO board), the ATMega1284. I've compiled the latest avrdude with linuxgpio and linuxspi enabled.

I've and inserted your programmer lines into /etc/avrdude.conf:

programmer
    id = "linuxgpio";
    desc = "Use the Linux sysfs interface to bitbang GPIO lines";
    type = "linuxgpio";
    reset = 17;
    sck = 18;
    sdo = 27;
    sdi = 22;
;

I've connected the wires from the Pi to the development board (https://www.tindie.com/products/MCUdude/dip-40-arduino-compatible-development-board/),

Pi <-> Dev Board
GPIO 17 - Reset (RST)
GPIO 18 - SCK (D7)
GPIO 27 - SDO/MOSI (D6)
GPIO 22 - SDI/MISO (D5)
GND <-> GND

Dev board VCC SEL set to 3.3v

I'm able to generate the hex file with:

/home/pi/arduino//bin/arduino-cli compile -b MightyCore:avr:1284 /home/pi/arduino/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6.ino --output-dir /home/pi/arduino/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6

And this is what the arduino-cli normally uses to upload when connected via a USB cable:

/home/pi/.arduino15/packages/MightyCore/tools/avrdude/7.1-arduino.1/bin/avrdude -C /home/pi/.arduino15/packages/MightyCore/hardware/avr/2.2.2/avrdude.conf -v -V -p atmega1284 -c arduino -P /dev/ttyUSB0 -b 115200 -D "-Uflash:w:/tmp/arduino/sketches/4EAE4362F2D9679C02C12BFA9624E4F9/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6.ino.hex:i"

I've looked at this command and adapted it to this for use with the linuxgpio method with just jumper wires connected:

avrdude -v -V -C /etc/avrdude.conf -p atmega1284 -c linuxgpio -D "-Uflash:w:/home/pi/arduino/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6.ino.hex:i"

The output is:

avrdude: Version 7.1
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

System wide configuration file is /etc/avrdude.conf
User configuration file is /root/.avrduderc
User configuration file does not exist or is not a regular file, skipping

Using Port                    : /dev/parport0
Using Programmer              : linuxgpio
AVR Part                      : ATmega1284
Chip Erase delay              : 55000 us
PAGEL                         : PD7
BS2                           : PA0
RESET disposition             : possible i/o
RETRY pulse                   : SCK
Serial program mode           : yes
Parallel program mode         : yes
Timeout                       : 200
StabDelay                     : 100
CmdexeDelay                   : 25
SyncLoops                     : 32
PollIndex                     : 3
PollValue                     : 0x53
Memory Detail                 :

Block Poll               Page                       Polled
Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom                 65    10   128    0 no       4096    8      0  9000  9000 0xff 0xff
flash                  65    10   256    0 yes    131072  256    512  4500  4500 0xff 0xff
lfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
hfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
efuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
lock                    0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
calibration             0     0     0    0 no          1    1      0     0     0 0x00 0x00

Programmer Type : linuxgpio
Description     : Use the Linux sysfs interface to bitbang GPIO lines
Pin assignment  : /sys/class/gpio/gpio{n}
RESET   =  17
SCK     =  18
SDO     =  27
SDI     =  22

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9706 (probably m1284)
avrdude: reading input file /home/pi/arduino/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6.ino.hex for flash
with 21382 bytes in 1 section within [0, 0x5385]
using 84 pages and 122 pad bytes
avrdude: writing 21382 bytes flash ...
Writing | ################################################## | 100% 4.72s
avrdude: 21382 bytes of flash written
avrdude done.  Thank you.'

The -V flag during upload is used to skip verification, which is what I saw the arduino-cli use when it uploaded the code (BTW, which worked when I have a USB cable connecting the Pi to the dev board). Note that verification fails when I don't include the -V flag, so I'm not sure if this is expected and that's why arduino-cli skips verification when it issues the upload command.

Here is the output for the mismatch:

avrdude: verifying flash memory against /home/pi/arduino/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6.ino.hex

Reading | ################################################## | 100% 4.25 s

avrdude avr_verify() warning: verification mismatch
        device 0x32 != input 0x33 at addr 0x52df (error)
avrdude do_op() error: verification mismatch

My issue is that although it says it's written, it doesn't actually run the code it says it's written once it's done. It continues running the previous code, so it doesn't seem like it's actually written. My way of verifying this is to define a string in the new code that it prints back to me over serial (Pi <-> Dev board: Gnd <-> Gnd, Tx <-> Rx, Rx <-> Tx), and it returns the string from the previously-uploaded code, not the latest uploaded code after the upload command.

Any help would be appreciated.
Thank you,
Kyle

[louigi600]

This looks like the crunch of your issue :
avrdude avr_verify() warning: verification mismatch
device 0x32 != input 0x33 at addr 0x52df (error)
avrdude do_op() error: verification mismatch

I really did not do anything complicated, it was more difficult some 5 years ago when you needed to patch avrdude.
I made the simplest wiring where
RPI GPIO17 is conected to ATMEGA reset
RPI GPIO18 is connected to ATMEGA sck
RPI GPIO27 is connected to ATMEGA mosi
RPI GPIO22 is connected to ATMEGA misoi
RPI pin 2 is connected to ATMEGA VCC trough rectifier diode
RPI GND is connected to ATMEGA GND

For my setup I don't use the spi ... even if it might be faster this is not an issue for prottyping or hobby projects.

I remember I had some issues with the non low voltage capable atmega32 when I was powering it off 3.3v so instead I started powering it from 5v (pins 2 and 4) trough a 1N4007 that wouls provide about a 0.7v drop so the atmega32 was running at about 4.3v.

Make sure the fuses are set correctly, and that you can read them. Once that is working you can attempt to upload a compiled hex file to the MCU.

avrdude -v
-patmega32
-clinuxgpio -Pgpio
-e -Ulock:w:0x3f:m
-Uhfuse:w:0b11010110:m
-Ulfuse:w:0b10100100:m
-Uflash:w:/root/optiboot_flash_atmega32_UART0_38400_8000000L_B0.hex

This was to flash bootloader on a amega32

But since I got the arduino ide to use the linuxgpio I don't play manually with avrdude anymore.

[kizniche]

Interestingly, if I change that single defined string back to the previous value that I successfully uploaded using the USB cable, compile, then upload the hex file using the linuxgpio method, I get a successful verification:

avrdude: verifying flash memory against /home/pi/arduino/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6.ino.hex

Reading | ################################################## | 100% 4.36 s

avrdude: 21382 bytes of flash verified

This indicates that it can read the MCU, but it's not able to actually successfully write the hex to it (despite it stating it was successful).

I've already flashed the bootloader (using this: https://www.tindie.com/products/mfkamprath/programmer-shield-for-avr-dip40/) using the Arduino IDE and can successfully upload hex files using the arduino-cli via a USB cable.

I have the MCU using 3.3v, since this is the voltage of the Pi GPIOs and using the MCU at 5v would require a logic level shifter between the Pi and MCU, since the Pi is not 5v-tollerant.

For my setup I don't use the spi

I didn't either. I have in the edit history of my original post an attempt that I eventually removed. I think I may have got it to communicate once, but I abandoned that method for linuxgpio.

I'll keep investigating, but this is rather frustrating, because it seems it is near working but something is preventing it from actually uploading properly.

[kizniche]

I found by removing "-D" (Disable auto erase for flash) it now works 100%. It's a bit embarrassing I didn't test without that option, but in hindsight I shouldn't have just blindly used that option because the arduino-cli used it. Anyway, thanks for responding and helping me figure this out!

[louigi600]

With the diode the mcu is not running on 5v but somewhere between 4.3 and 4.4v. The RPI seems to be fine with that .... I have not burned any of the RPI4 gpio ports yet. 3.3v is fine as long as your mcu is capable. My atmega32 will run code just fine at 3.3v but some io features have issues down there ... after all it is certified to only go as low as 4.5v.

…

On Wed, Jun 28, 2023, 00:01 Kyle Gabriel ***@***.***> wrote: Interestingly, if I change that single defined string back to the previous value that I successfully uploaded using the USB cable, compile, then upload the hex file using the linuxgpio method, I get a successful verification: avrdude: verifying flash memory against /home/pi/arduino/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6/input_code_13eded39-1d5e-4285-9a2c-a6a574fff3c6.ino.hex Reading | ################################################## | 100% 4.36 s avrdude: 21382 bytes of flash verified This indicates that it can read the MCU, but it's not able to actually successfully write the hex to it (despite it stating it was successful). I've already flashed the bootloader (using this: https://www.tindie.com/products/mfkamprath/programmer-shield-for-avr-dip40/) using the Arduino IDE and can successfully upload hex files using the arduino-cli via a USB cable. I have the MCU using 3.3v, since this is the voltage of the Pi GPIOs and using the MCU at 5v would require a logic level shifter between the Pi and MCU, since the Pi is not 5v-tollerant. For my setup I don't use the spi I didn't either. I have in the edit history of my original post an attempt that I eventually removed. I think I may have got it to communicate once, but I abandoned that method for linuxgpio. I'll keep investigating, but this is rather frustrating, because it seems it is near working but something is preventing it from actually uploading properly. — Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCS6PK2X2EWDXSCBS3WZRDXNNJ4RANCNFSM6AAAAAAY2VRSRE> . You are receiving this because you were mentioned.Message ID: ***@***.***>