Should I make a Pokitto Uploader?

Hi,

Time ago I made a little tool for uploading compiled games to the Arduboy:

That tools goes together with a website: http://arduboy.ried.cl that contains arduboy:links (to launch the tool directly). Now I have 3 questions for Pokitto users:

  1. Do we need a Pokitto Uploader?
    Functionality explained:
    a. You double click a .bin or .pkto or .pokitto, whatever file… OR you click in a pokitto:link in the browser… OR it is listening for new files in a folder (i.e.: if you are using the online dev environment, so any new compiled file will trigger the upload)
    b. Uploader pops and ask you to press Reset + Load in the device, it waits for a new device
    c. Deletes the old firmware.bin and puts the new one for you

  2. Do we need pokitto:links protocol?
    That launches the uploader tool as explained in 1

  3. Do we need a SD loader?
    That fetches the last sd package from the web, and preloads the contents in an SD that the user provides and calls the uploader from 1 with one of these files. The sd_loader.exe can live inside the same SD card to make the process seamless.

8 Likes

I just checked out your pages and the tool and you’ve done an excellent job with both the tool and the web end.

I believe we could greatly benefit from a pokitto uploader tool - especially if we can make versions for win/mac/linux to harmonize the process for different platforms

Hi @eried

that and your website is a fantastic asset for the Arduboy and it’d be wonderful if you would do something similar for pokitto!

1 Like

For Windows dragging and dropping a bin isn’t an issue, but it has been for Mac, so Mac could benefit from that.

I think having an online repo and a program that handles pokitto: links would be a good idea, but I think the system’s communication protocols should be partially standardised so that other people can set up their own uploader/downloader clients or their own repos/repo mirrors.

Having multiple repos/repo mirrors can help keep the system robust in case a more popular one falls over and allowing different client vendors allows users to add features the base client doesn’t have or remove features they don’t like.

We don’t necessarily need to sit down and all agree on one standard because the beauty of standards is that if one doesn’t work out you can just invent another one. All it basically means is having the communication system documented and not introducing vendor-lock.

That’s an ideal situation though, it’s probably better to just get a basic system running first.

Good thinking.

2 Likes

i have looked at doing a uploader for the mac and its just not possible with current restrictions from the os not allowing access to drives without going true the filesystem (using the filesystem causes hidden files to be made)

I disagree with that. I do not particulary enjoy deleting the current firmware.bin but I am very lazy with repetitive stuff, so it might be just a personal thing.

[quote=“Pharap, post:4, topic:644”]
I think having an online repo and a program that handles pokitto: links would be a good idea, but I think the system’s communication protocols should be partially standardised so that other people can set up their own uploader/downloader clients or their own repos/repo mirrors.[/quote]

Agree. But I was thinking on using the current one :slight_smile: not making a new one. The protocol “pokitto:link” in this case should always provide the direct download link (much like PirateBay’s “magnet:link”)

Yeah… about that… I do not use/enjoy mac nor linux. But I have used the mono compiler succesfully in the past so I can try to get it working at least in linux.

Have you tested whether programmatically (i.e. with C, C++ or similar) creating files causes these hidden files to appear?
I understood that it’s actually finder and some of the other UI tools that actually create the hidden files and not the file system itself.

Either way, you’ve shown a simple script can account for that, so doing it programatically shouldn’t be too much of a deal, it’s just a matter of sleeping the thread for a second and then deleting any hidden files.


Fair enough. Laziness is a virtue.

As long as it all makes sense in the new context (i.e. hex files are now bin files) and you document it ~somewhere~.

1 Like

i had trouble using the system calls in c itself
if i recall the volume is protected in some way

and the command file is pretty much functional just not as clean looking as a app

I just watched your youtube video about ArduboyUploader. The web page looks good and the process is beautifully integrated. I definately would like to see this working in Pokitto! Especially for the people without the SD-card.

The “SD loader” would be convenient too.

1 Like

There’s a chmod function which should work fine.

(Not that chmod will be needed for this anyway. Regular C/C++ stuff will work fine, though I’m 90% sure @eried is planning to do this in C#.)

Anything that’s programmatically ‘protected’ has a way of being unprotected. Often it’s as simple as running in admin mode or having some sort of security token that proves the program has permission.

Functional yes, but not friendly for non-programmers.
(Frankly I’ll probably stick to manually loading bin files, but the Pokitto has many different audiences.)

i know but theres a reason im not just giving people the command file since due to protection iseus
it has to chmod +x wich id dint need that before in older version of osx

im looking into a cross platform solution using electron, if you want some sort of a download manager aswell

Like I said, eried won’t have to worry about chmod anyway since it’ll be an executable file, which should either run when clicked on or prompt the user to confirm they want to run it.

you still have to use chmod on linux for exacutibles, depending on the distro

If someone’s using Linux I would hope they know what chmod is and how to use it. Linux isn’t the sort of thing I’d expect a beginner/non-programmer to be using.

This is also one of the reasons I suggested to make the communication protocol standardised. Once @eried’s made the original repo+uploader and published the details about how to communicate with the repo, anyone else can write their own uploader for any OS with any language.
I’m 90% @eried’s planning to use C# so having other versions will save people having to set up wine if they haven’t already got it set up. (Though I think there’s a version of Visual Studio that can compile C# for Mac now.)

why use c# its realy bad on linux and mac
code would be much simpler in c/c++
and shouldent jonne be doing the repo for the game directory?

lol omg im an idiot i just solved my problem in c
dam \ XD
"diskutil unmount /Volumes/CRP\\ DISABLD"

It is because it feels like joy :smiley: not a task. And I am not planing on using Wine, I want to compile the code with mono so it is “native” in Linux. It even run nice in the RPi 1 model B: https://github.com/eried/PowerSpeck

1 Like

A) It’s a nice language
B) @eried likes C#
C) That’s what the Arduboy uploader was written in so it’ll be easier to port

As much as I like C++ I’m not so sure about that.
I’ve never had to use a http library for C++, but I can’t imagine it being very fun.

I found this. Some of those examples are scarier than others.
Happy Http and Casablanca look the least scary.

A) Jonne’s busy enough already getting Pokittos shipped, arranging the page for selling Pokittos, doing some fritzing component stuff, maintaining the library (lots of other stuff)
B) Once eried’s made the first system there’s nothing to stop Jonne making another more official repo later (using the same protocol so integration is seamless)


Even better.

1 Like

A i dont like it
B i still dont like it
C the avr usb serial is totally different from what we do on the pokitto

update i now have a mac app where you can drag and drop the files onto, still have to work on detecting if the pokitto is mounted
its in c++ and uses glfw as windowing so its going to be easy to port.