ProjectABE (ArduBoy Emulator) released!

(Felipe Manga) #221

The mac build has a different file structure and I had to guess where things went. Looks like I guessed wrong. :persevere:

I’ll make a new mac build tomorrow at work, I’ll be able to test before uploading there.

(Felipe Manga) #222

@filmote: I got that Mac build up. I actually got to confirm that it runs, this time! :stuck_out_tongue:

I wish I could be sure about the flasher, though… I broke my cloneboy (dropped it, dead screen). I can flash the board, but I can’t tell if the thing actually runs. >_<

EDIT: As a Mac user, do you have any preference over zip or tar.xz?

(Scott R) #223

You could always upload blink (RX TX) to test

Having no screen does suck I ran my clone for quite some time with just a piezo.

(Simon) #224

I will give the new code a test tonight (10 hrs time) when I get home.

I prefer ZIP personally as it is handled natively. I had to download a different tool to get the tar.xz to work.

(Felipe Manga) #225

@Keyboard_Camper Yeah, blink and piezo will have to do, for now.

@filmote Ah, I was under the impression that Macs handled tar.xz, being sorta unixy. Will upload zips from now on, then.

(Pharap) #226

Sorry to but in, but truth be told I’ve never heard of an .xz, is it a variant of .gz?

(Simon) #227

They might from the command line but I couldn’t open your last one natively. Maybe it was the way you compressed it?

(Simon) #228

I had to google it too!

(Felipe Manga) #229

I think its unrelated to gzip, I haven’t looked into the algorithm, yet. All I know is it compresses better than zip/gz and Linux seems to be switching everything over to it by default.

(Pharap) #230

Aparently it’s LZMA2 based with some modifications:

Windows can handle it with 7zip or winrar, Mac seems to be the one that’s behind the times with this one.

(Simon) #231

The zip works fine now.

When I try to upload, it comes up with a message ‘Could not connect to device. Did you push the Up button?’.

I tried with the Up button pressed for parts of the upload and the entire upload - neither worked.

(Erwin) #232

@FManga related with the multi-upload, I think that there are very hard physical problems to achieve that. First the way the leonardo exposes the port after the reset with 1200 bauds is not reliable in timing and I did not saw any way to identify a device as unique only by its usb descriptors…

I remember that the FTDI chips used in the past had an internal serial code you could use for individual identification, but that is not the case now.

How do you flash the Arduboys right now?

(Felipe Manga) #233

I noticed the unreliable timing when I tried to use avrgirl and wrote the new flasher with that in mind. This is how it works:

  • it continuously polls for a list of devices
  • if it finds a vid/pid of a 32u4 that’s not in the bootloader, it tries to reset it.
  • if it finds a bootloader vid/pid, it connects to it and tries to upload

Either of the two steps above might fail, so it will auto-retry a few times. And polling is stateless, so it’ll still look for devices that need resetting even after it has started uploading to another.

Since the same thing is being flashed, it’s not necessary to tell which device is which. Just knowing what it is (by means of the vid/pid) should be enough. So, in theory, it’s supposed to work and, according to your videos, it almost does. I just need to write a few test sketches (blink/piezo), finish implementing the logging, and then get back to bug hunting.

I’m betting the current issue is something silly, like the alert boxes halting the uploads in your videos.

(Erwin) #234

How do you detect at the end if the user just was not quick enough to disconnect a flashed Arduboy and try again?

It all depends on how @bateske flashes the Arduboys right now. I can imagine:

  1. Having 1 to N laptops with a script that run constantly (so what you do is plug the Arduboy and unplug it a package it, no need to press any key)
  1. Having 1 to N usb cables in 1 laptop, plug all the Arduboys at once, press something, wait and unplug them all, store them and repeat.

I am guessing due the delay in programing each Arduboy the option 1) is going to work faster because you can do stuff while the programming happens (I am pretty sure that this could be mathematically supported, but meh too much effort for 1 time thing).

The fastest solution is 1+2 where the program “remembers” each Arduboy, so you do not need to connect them all at the same time and press a button.

(Felipe Manga) #235

Right now it stops polling as soon as the first upload is complete. Otherwise it would keep reflashing the same arduboy again and again. :stuck_out_tongue:

(Erwin) #236

That is my point.

Having the following fake times:

  • Unpackaging 5s
  • Plug 10s
  • Programming 30s
  • Unplug 5s
  • Package 10s (to retail package)

For 1,2,3,4,5 Arduboys, we get a fake estimation of:

  • 36s per Arduboy in the multiple upload/parallel case
  • 30s per Arduboy in the serialized one with 3 laptops

Of course @bateske can optimize the system, imagine in the Parallel case he start to unpackage and plug a new Arduboy before packaging the already programmed one, but that will become a mess (and he will start making mistakes and needing to re-test some units)

(Scott R) #237

I would assume someone will be around to help him.

I also doubt he gets them in retail packaging most likely just a box of units with the protective plastic so all one person has to do is plug in a number of units to the right and the pass them once flashed to the to the left person doing the packaging.

(Felipe Manga) #238

I see. I could do this, then:

  • When you start the upload, a window will show up with the log.
  • polling happens while the window is open
  • if it finds a reset vid/pid, it resets
  • if it finds a bootloader, it uploads

Uploads are done in 128 byte chunks. I’ll make it verify a chunk first, if it fails, upload the chunk. If you try to upload a hex that is already in the flash, it’ll just verify the whole thing and write nothing. Continuous polling will then be harmless. A flashed arduboy can then be removed and a blank one plugged in its place.

The procedure now looks like this:

  • Unpack, plug, start upload to first arduboy
  • While uploading to the first, unpack, plug second, third, fourth…
  • somebody else unplugs, packs first when its done

Methods for multi-upload
(Kevin) #239

To avoid getting any further off track discussing ProjectABE directly, I’ve made a thread for discussing multi-uploads where we can talk more about process engineering and how ProjectABE or any other tools could be used to upload to multiple devices.

Let this thread continue with the further development onto multiple platforms.

P.S. I also have a Mac I can test with at home.

(Scott R) #241

Btw is there an option to upload your own hex?
Or a simple way to add your own local directory?