I see the AVR tools in HaikuDepot. Who all uses Haiku for AVR and Arduino stuff? I just got an AVR Dragon and a handful of ATMega and ATTiny chips.
I’m more interested in the AVR side of things, but Arduino seems nifty.
I use some AVR, but not Arduino, I roll my own libraries. If you hit problems with avrdude or avr-gcc, let me know, I can try to fix/update them.
2 Likes
I use arduinos at work (ranging from Nano to Yun), but i would be a bit afraid of compiling + uploading a sketch in “unstable” state with company hardware 
Hearing that avr-gcc works is still good news for me.
Right now, I’m not sure what my issue is. Avrdude detects my AVR Dragon fine, but I’m having issue connecting to the target via dragon_isp. I’m not sure yet if I’m having hardware issues, a problem with my connection between dragon and target, or an issue with using in Haiku. I have yet to try in another OS.
I’ve tried with targets of ATMega328p and ATTiny85. I get the same errors indicating failure to connect to target. I’ll post the errors later when I’m back to my AVR box. I’ll also try in Linux.
I’m looking forward to doing an AVR documentation series on Haiku. I’m mainly interested in AVR, but would include some Arduino stuff if I get around to it. I’m also kicking around the idea of making a simple AVR IDE for Haiku based on the standard avrdude and avr-gcc tools.
@PulkoMandy, what AVR interface(s) do you use? Do you have any experience with the dragon? Any tips for AVR in Haiku or in general? I’m thinking perhaps my USB cable might be too long. This seems to be a common issue with the dragon.
I’m using an USBASP compatible device IIRC, and I also have an STK500 devboard. I also use various bootloaders on the devices I work with.
Indeed I often ran into problems with faulty USB cables, especially as the USB stack in Haiku isn’t that great at error recovery.
I’ll start with a new cable then. And try in linux
Having used the same STK500 board with Olimex devices, I must say that i never had usb cable problems (in windows), so i agree on the usb refinement required in Haiku. Or i must have been lucky with the cables back then.
BTW, how’s the usb<->serial (as in FTDI) support in Haiku?
@bullfrog, in general Atmel/AVR Studio (aka ladybug software) was what I used back in the day, and worked fine for all the chips we flashed. But that binds you to Windows, iirc.
Read you can use the Dragon with Arduino IDE too, so if it worked on Haiku, the provided toolchain may be used to flash devices and/or use the Dragon.
We have drivers for FTDI, Prolific, Silicon Image, and standard USB-ACM serial ports. As far as I know, they all work, the FTDI driver may need some tweaks for particular chips but let me know if you run into problems with that.
1 Like
Yeah it doesn’t work with my quad port FTDI cable last I checked.
I’d like to see programmers for PIC32 chips on Haiku… they are my go to chip these days, simple IO, and much faster than AVR some of the Chipkit boards you can program with Avrdude after there is a bootloader on them.
There are several prorgrammers in addition to avrdude that would be nice to have.
https://github.com/eerimoq/pictools (can program pic32mm in 4.5sec).
Supports most pic32 chips except some recent ones like pic32mm
https://github.com/sergev/pic32prog
PIC32 would be a perfect MCU to base a modern blinkenlights and geekport on… especially the faster 250Mhz ones could do some quite impressive IO from a PC and most of them have USB built in via CDC-ACM. Some Pic32 chips have more ram and performance than a hobbit BeBOx… maybe even a ppc bebox considering you can put 128MB ram on some of the PIC32MZ DA chips.
Getting Icestorm/arachne-pnr/nextpnr etc… working would be really cool also.
1 Like
Bugreport with listusb -v please 
I used the PIC (PIC8?) at uni as a microchip example for digital electronic course. May work greatly when programmed, but the simplicity of the arduino c++ instructions is hard to beat. DigitalWrite is just an example
However, If i had to do something at a small scale (no OS, just a logical program), i would use a NodeMCU32 (or previous NodeMCU), which gives a lot of bang for the buck. Can have c++/lua/micropython code, plus giving you wifi/BT usage.
I even have some weird plans to do with Haiku and NodeMCU’s boards that i have next to me right now 
btw ,NodeMCU32S listusb:
10c4:ea60 /dev/bus/usb/0/1/0 "Cygnal Integrated Products, Inc." "CP2102/CP2109 UART Bridge Controller [CP210x family]" ver. 0100
Works nicely in Haiku, and I’m able to communicate serialwise to the board at /dev/ports/usb0, and this is being passthrough through virtual USB in a VM, so can’t find a more complex example.
So that’s another board to take in account at Haiku, if Expressiff toolchain to compile & flash can be ported to the OS.
1 Like
I wasn’t talking about the older PICs , I was talking about PIC32 which is MIPS based and Chipkit supports the Arduino stuff on it quite well… There is even a 28pin DIP version with USB if you need that. You can even run RetroBSD on some of the PIC32 chips… they are about an order of magnitude or more faster than AVR (though less deterministic).
Unless you need chips that cost under $1 or have old programs for the 8 bit PICs then there is very little reason to use the slower MCUs anymore.
I’ve gotten avrdude to communicate with the target through the AVR Dragon. I had been skipping a step in producing the hex files. Now I’ve getting a failure at the burn verification stage.
avrdude: verification error, first mismatch at byte 0x0000
I think I may need to run the dragon off an externally powered USB hub. Or maybe my reset circuit needs tuning.
Or it could be a USB stack bug… you might try using USB 3.0 vs 2.0 vs 1.0 if you have a PC with 1.0
Do see anything interesting in syslog while programming?
I’ll check on my next round of tries.
Syslog:
KERN: usb hub 7: port 1: device removed
KERN: usb hub 7: KERN: port 1 disabled
KERN: usb hub 27: port 1: new device connected
lsusb:
[Device /dev/bus/usb/1/1]
Class .................. 0xff (Vendor specific)
Subclass ............... 0x00
Protocol ............... 0x00
Max Endpoint 0 Packet .. 16
USB Version ............ 1.16
Vendor ID .............. 0x03eb (Atmel Corp.)
Product ID ............. 0x2107 (AVR Dragon)
Product Version ........ 0x0100
Manufacturer String .... "ATMEL"
Product String ......... "AVRDRAGON"
Serial Number .......... "00A200022097"
[Configuration 0]
Configuration String . ""
[Interface 0]
[Alternate 0 active]
Class .............. 0xff (Vendor specific)
Subclass ........... 0x00
Protocol ........... 0x00
Interface String ... ""
[Endpoint 0]
MaxPacketSize .... 64
Interval ......... 10
Type ............. Bulk
Direction ........ Input
[Endpoint 1]
MaxPacketSize .... 64
Interval ......... 10
Type ............. Bulk
Direction ........ Output
usb chip on board:
PDIUSBD12
avrdude:
avrdude -p attiny85 -c dragon_isp -U flash:w:nothing.hex:i -F -P usb -u
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.15s
avrdude: Device signature = 0x000000 (retrying)
Reading | ################################################## | 100% 0.15s
avrdude: Device signature = 0x000000 (retrying)
Reading | ################################################## | 100% 0.15s
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATtiny85 is 1E 93 0B
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "nothing.hex"
avrdude: writing flash (58 bytes):
Writing | ################################################## | 100% 0.11s
avrdude: 58 bytes of flash written
avrdude: verifying flash memory against nothing.hex:
avrdude: load data flash data from input file nothing.hex:
avrdude: input file nothing.hex contains 58 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.11s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x00 != 0x0e
avrdude: verification error; content mismatch
avrdude done. Thank you.
Well, it may not be a good idea to continue then. I bricked some AVRs due to bugs in libusb/Haiku USB stack (but I built a fusebit doctor to recover them).
So yes, some more USB work needed then…
I’m not really afraid of bricking these things. The AVR Dragon can do high voltage programming, and set/reset fuses. It’s a rather complete programmer. I just need to learn to use it.
Next step is Linux. If it doesn’t work there, I think it’s safe to say the problem is in USB hardware somewhere. My only cable is ungodly long. It’s also reported in many places that this programmer requires a powered USB line to operate properly.
Should I open a Trac ticket?
1 Like
Well. A year has passed. I managed to use Haiku, avrdude and the dragon to train an ATTiny85 to blink an LED. Albeit with a long list of errors, and very off timing of the blink compared to what I programmed. The same program works fine programming from Debian.
1 Like