This is a bundle with the (as of 07/25/2018) latest PokittoLib + latest ARM GCC + MinGW GCC + latest Code::Blocks IDE.
While you’re waiting for the release to download, read the step-by-step guide ahead.
Steps 1 to 5 only need to be done once.
1- Extract somewhere. Say, C:\PCB.
2- Run codeblocks.exe.
3- Select GNU GCC Compiler for ARM NONE (first in the list), click Set as default, click OK.
4- Click on Settings -> Compiler... -> Toolchain executables
5- change arm-none-eabi-gcc into an absolute path. If you extracted to C:\PCB, that would be C:\PCB\arm-none-eabi-gcc. Click OK.
6- Click on File -> New -> Project... -> Pokitto Project (NOT ARM Project) -> Go
7- Appease the project creation wizard.
8- Build. Done!
The ARM GCC compiler is autodetected with a relative path that needs to be changed into an absolute one for it to work. (Code::blocks limitation)
PokittoLib Simulator files were removed for now (mea culpa).
From experience with the offline builds of ProjectABE, MacOS does everything its own way and has its own set of problems to overcome (I’ve been wary of making releases I can’t test by daily use since bricking @filmote’s Arduboy) . >_<
I can make an installer for the stable windows build. I don’t know how to do it Linux or MacOS.
For now, simply unzipping is more convenient.
for mac you really want to have everything inside a folder to drop into Applications directory and be done with it packing code::blocks with the compiler already arranged cuz dealing with the hidden folders is a real pain
im not sure why you need-absolute paths, is the relative one based on the code::blocks location or the project location?
The IDE can’t call the compiler with a relative path. Since I bundled the compiler with the IDE, I have no idea where its going to be extracted. This works with MinGW because support for bundling that is hardcoded.
To fix this bug we’ll have to modify the XMLCompiler plugin. It’s a really simple fix, but the environment for building plugins needs to be set up first.
at least for the mac applications are supposed to go in the application directory thats sort of the standard so you do know the path
not sure for linux, but thats usualy some comandline in /bin /dev somthing right?
and for windows its in “Program Files (x86)” i think
On Windows I can make an installer that sets up the correct absolute path.
On Linux I’d need to check what the options for making installers are. I think it’s supposed to extract into /usr/share/[appname], but that’s how Ubuntu does it.
On MacOS, if the application directory is standard, I guess I could hardcode that.
Still, some people prefer simply extracting a zip instead of using an installer, and for people on locked-down computers (a library’s PC) this is their only option, so the proper fix (changing a line of code in the plugin) would be best.
Since this is an “Initial test release”, it’s expected to have some rough edges and having to fix the path is probably the smallest of the issues. I haven’t even looked into debugger support yet and I’d like to make a C+±based Pokitto emulator to add to the bundle.
Overall its a lot of work so I uploaded it as-is so others can chip in if its deemed worth doing at all.
On MacOS the Arduboy shows up as 4 different devices at once. ProjectABE tried to flash all 4 at the same time. Somehow this resulted in his bootloader getting erased. He had to open the arduboy and flash it with a USBasp to fix it, IIRC.
D’oh! I’ll fix that as soon as I get home. Use the internal one.
I haven’t gotten around to it yet… I think I’ll stick @jonne’s avatar there on the next build.