#Initial test release

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!

Known Issues:

  • 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).
  • Windows only (blame Canada)
  • Still have to copy the bin manually

what exactly makes this windows only apart from the directory paths?

The paths are relative (so should work on anything). The builds (ARM GCC, CodeBlocks) are for Windows. I’ll make other builds when its confirmed to work for others. What OS are you using?

i got macOS (10.13.6), some version of ubuntu and windows 10
but i mostly develop on the mac

That makes you the official beta tester, then. :laughing:
I’ll make a Linux build next, as that’s what I use the most. Making a MacOS build is going to be harder for me.

its usualy not much diferent from linux since the file system is mostly the same unix base atleast for compilers/makefiles what have you, but i know devil is in the details with the mac usualy

making some sort of wizard program to install all this would be nice idk if thats a possibility

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.

It’s possible to brick an Arduboy? How?

@Pharap I believe the zip on git hub contains some duplication.

The first executable have no wizard for Pokitto:

The second have it:

But Icon is wrong!!! :wink:

should I point to

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.

1 Like

@FManga it’s dangerous to go alone take this


Now is working as it shoud.

Also the output bin seems to do something. But seems to exit the main loop after the first render. Is it possible?

For your convenience:


There’s some visual defects in version 17.12 of CB vs 16.01
At least on my machine the windows is all blurry (and I’m not the only one)

I’ve created a codeblocks.bat in the folder that run:

@set "__COMPAT_LAYER=~ HIGHDPIAWARE" & start "" /max "codeblocks.exe"

Result is much bette, hope is useful for some one else.

Not to permenantly brick it, but it’s possible to overwrite the bootloader on some models because the bootloader protection pins weren’t set properly at the factory.

All it takes to fix it is to re-burn the bootloader using an ISP programmer.
But then not everybody has suitable ISP programmers lying around.

Why are you telling me this? :P

Haven’t got around to testing yet, but I will do.

1 Like