Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Testing with real hardware #5
My budget can't always support having every single Arduino on hand to test this with. I would love if anyone has matching hardware supported by avrgirl-arduino to verify that everything works well. I just recently busted my Arduino Mega's FTDI connection somehow, so this sort of thing becomes a problem for me to keep up with.
I mostly test with OSX (which is my dev machine). I have both Windows and Linux VM's that I use to test those platforms with, however these sometimes don't replicate a "real" machine experience. An example of this is due to using a modern.ie image for Windows, I can't get a realistic take on the automatic device driver installation workflow that Windows normally does. So! I would love if those with any platform could just give this library a go with any Arduino they have sitting around that is supported
Successfully uploading a Blink.cpp.hex file is a great test to try. Included in this repo is a copy of a compiled and ready-to-flash Blink file for each supported device.
If you encounter any issues, please open a new issue on this repo describing what happened (errors, screenshots etc), or comment on an existing issue with a
Thank you so much in advance
referenced this issue
Oct 3, 2015
I have a few other devices I wanted to try adding support for, but they seem to be finicky ones: Due (ARM), RFDuino (uses a custom loader - see http://rfduino.com/package_rfduino_index.json), Red Bear MK20 and WiFi Mini (CC3200) and the Spark/Particle (which I think you have too). Any thoughts on them?
Specifically if you think any are desirable, or if others are a particularly long rabbit hole to go down. I'm still investigating,
Hey! A few thoughts:
Desirable: short answer is no but yes but is complicated.
The purpose of avrgirl-arduino is to support the flashing of a specific subset of devices that would be classed as an 'Arduino'. This essentially means:
So - avrgirl-arduino may not be the right repo/package to support these boards (other than perhaps the Due). There is a lot of extra complexity underneath which would be required to support them (such as adding a whole new usb package, writing several new protocols from scratch), which leans towards them being better developed in separate packages/libraries entirely for ease of maintenance and testing.
As an added note, the purpose of AVRGirl as an umbrella project, is solely focused on the ATmega and ATtiny families for the first big AVRGirl release. This is the supported list as per avrdude, which was the inspiration for AVRGirl. There are a large number of parts and programmers that need to be deemed stable before any different architectures (such as ARM) can be considered being added. This means that ARM would be nice, but it's on a distant roadmap only for now, and there is a much heavier focus on testing the ATmega and ATtiny families only at this stage. There is a lot of tuning that needs doing before moving on, and that's where I need the help most via testing
This issue was meant to be more about testing the already supported devices on different OS platforms. I did mention briefly about introducing new Arduino support too, so that is my bad I apologise.
To address your board suggestions:
The ARM chips require a DFU style way of programming them, and are a little bit more complex than the ATmega and ATtiny family of RISC processors. Fair warning - plenty of rabbit holes would be ahead. The Tessel and Particle folks have done great work on this kind of stuff that you can see in their repos, although they are tuned very heavily to their specific ARM chip on board and their own development ecosystems.
Sorry for the long winded reply, but I realise that I have all of this stuff in my head only. I need to get it out so I can start communicating the mission and roadmap better (in writing) in some obvious places (such as the AVRGirl repo README or wiki). I didn't expect anyone to be interested in AVRGirl, to be honest, so this has caught me off guard!
Thanks for the detailed reply, Suz! I was wondering about some of this. The Arduino IDE has done a pretty good job of hiding a lot of the complexity to the end user and looking like an all purpose tool when it is really doing a lot of different things and using a lot of vendor provided software to fill the gaps. Thus I think it's sometimes hard to see where the boundaries lie, so I appreciate the clarification.
I'll see if I think there's anything I can contribute to other areas instead. :)
The Arduino IDE is indeed impressive! It takes an easy to use library and pairs it with several cross-compilers and many uploading tools (including avrdude). The easy flashing experience has been a point of inspiration for me to try to emulate.
I'm going to amend this issue with much better wording around testing hardware and how to do it. I'm very new to this 'having contributors' thing, so I am learning along the way!
Let me know if you have any questions about what we're doing!
@JonLim really cool, thanks for getting in touch here to let me know things have been working out so far.
The only thing I've quickly tested in Electron is setting up a boilerplate app in OSX, and then flashing a Blink hex to an Arduino Uno. It seemed to go fine after a tiny patch I had to release to do with binding some globals, but let me know if you run into any dramas!
I'm excited to see what you're up to with it
@noopkat For sure!
The only drama llama situations that have come up were during
It's crude, but it seems to be working.
What I'm currently building is an extension of functions that uses the conventions you've built to send and receive messages from the auto-detected and validated port. The goal for this is to eventually have it check the version of existing firmware flashed on the Arduino board, and download and flash the more up to date version if possible.
PS. We've flashed our full firmware onto a board and tested that it still works, so I'm pretty excited!
@JonLim oh super cool!!! Thanks for providing more detail.
Ah, I ran into the same compilation issues, which spun off this blog post: http://meow.noopkat.com/using-node-serialport-in-an-electron-app/ but forgot all about that. Glad you figured it all out.