Testing with real hardware #5

Closed
noopkat opened this Issue Sep 11, 2015 · 9 comments

Comments

Projects
None yet
3 participants
@noopkat
Owner

noopkat commented Sep 11, 2015

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 👍 if you spot a duplicate.

Thank you so much in advance 🙌

@makenai

This comment has been minimized.

Show comment
Hide comment
@makenai

makenai Oct 6, 2015

Contributor

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,

Contributor

makenai commented Oct 6, 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,

@noopkat

This comment has been minimized.

Show comment
Hide comment
@noopkat

noopkat Oct 7, 2015

Owner

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:

  • a device that is produced by Arduino/Genuino
  • a direct Arduino clone
  • an 'Arduino at Heart' device that represents a prototyping board similar in looks, functionality, and especially architecture, to an actual Arduino (a perfect example of this is the Red Bear Blend Micro).

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:

  1. RFDuino and Arduino Due - both ARM.
  2. The Red Bear products that you listed are not 'Arduino at Heart', but at most would be closer to an 'Arduino Certified' status. Right now I'd prefer to only support 'Arduino at Heart' products. They are also ARM.
  3. Spark/Particle boards - also ARM.

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!

Owner

noopkat commented Oct 7, 2015

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:

  • a device that is produced by Arduino/Genuino
  • a direct Arduino clone
  • an 'Arduino at Heart' device that represents a prototyping board similar in looks, functionality, and especially architecture, to an actual Arduino (a perfect example of this is the Red Bear Blend Micro).

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:

  1. RFDuino and Arduino Due - both ARM.
  2. The Red Bear products that you listed are not 'Arduino at Heart', but at most would be closer to an 'Arduino Certified' status. Right now I'd prefer to only support 'Arduino at Heart' products. They are also ARM.
  3. Spark/Particle boards - also ARM.

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!

@makenai

This comment has been minimized.

Show comment
Hide comment
@makenai

makenai Oct 7, 2015

Contributor

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. :)

Contributor

makenai commented Oct 7, 2015

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. :)

@noopkat

This comment has been minimized.

Show comment
Hide comment
@noopkat

noopkat Oct 7, 2015

Owner

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!

Owner

noopkat commented Oct 7, 2015

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!

@JonLim

This comment has been minimized.

Show comment
Hide comment
@JonLim

JonLim Dec 8, 2015

Hiyo @noopkat!

Recently found avrgirl-arduino and successfully used it (I think) to upload our firmware onto our boards last night. Currently working it into our Electron-based app, so you'll have some cross-platform testing coming your way. We're working with the Mega boards, and will report back on any issues we might encounter.

Let me know if you have any questions about what we're doing!

JonLim commented Dec 8, 2015

Hiyo @noopkat!

Recently found avrgirl-arduino and successfully used it (I think) to upload our firmware onto our boards last night. Currently working it into our Electron-based app, so you'll have some cross-platform testing coming your way. We're working with the Mega boards, and will report back on any issues we might encounter.

Let me know if you have any questions about what we're doing!

@noopkat

This comment has been minimized.

Show comment
Hide comment
@noopkat

noopkat Dec 9, 2015

Owner

@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 😁

Owner

noopkat commented Dec 9, 2015

@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 😁

@JonLim

This comment has been minimized.

Show comment
Hide comment
@JonLim

JonLim Dec 9, 2015

@noopkat For sure!

The only drama llama situations that have come up were during npm install avrgirl-arduino, serialport was not enjoying itself because it wasn't being compiled properly. Updated node, updated npm, installed electron-rebuild, re-installed everything, rebuilt the Electron dependencies, and the moved serialport.node to the folder it was asking for.

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 commented Dec 9, 2015

@noopkat For sure!

The only drama llama situations that have come up were during npm install avrgirl-arduino, serialport was not enjoying itself because it wasn't being compiled properly. Updated node, updated npm, installed electron-rebuild, re-installed everything, rebuilt the Electron dependencies, and the moved serialport.node to the folder it was asking for.

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!

@noopkat

This comment has been minimized.

Show comment
Hide comment
@noopkat

noopkat Dec 9, 2015

Owner

@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.

Owner

noopkat commented Dec 9, 2015

@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.

@JonLim

This comment has been minimized.

Show comment
Hide comment
@JonLim

JonLim Dec 9, 2015

@noopkat Ah, dang, wish I saw that earlier!

All good, had to make sure I had the right build while using electron-build as well.

JonLim commented Dec 9, 2015

@noopkat Ah, dang, wish I saw that earlier!

All good, had to make sure I had the right build while using electron-build as well.

@noopkat noopkat closed this Jan 18, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment