Sorry, wrong guru :flushed:


What’s in your code? I only had time to test with a small snippet.

Mind if I bundle that with the release? I wonder if it’s possible to do that with a shortcut file instead of a bat.


Why? .bats run when you double click on them.

Or is it an admin priveledge issue?


For those who prefer an installer that creates a desktop/start menu shortcut.


I can confirm this works on Windows 8.1, I would presume it works on Windows 7.

The problem is that it deals in absolute paths, so a shortcut for one computer probably wouldn’t work on another.
It might be possible to generate it programmatically somehow.


False alarm. It works fine.

Test.bin (75.3 KB)

I just take it from code blocks forum, so not problem at all.

Yes, just set Compatibility/DPI settings in the shortcut but

Testing in Win10 and I like this.

Do you believe it can evolve to have a Cross Build (arm and simulator) in the same IDE? Maybe with Debug, deploy to Pokitto and export to ProjectAbe?

And coffe machine? :coffee:


Good news and bad news.

The good news is there is a way to make shortucts in batch.
The bad news is that it doesn’t work in Windows 8 or Windows 10 because Microsoft deprecated it for some absurd reason.

The other good news is that I found another way to do it.
The bad news is that other way is to use a VBSScript.


That’s a REALLY bad new.


Aparently you can also just right click an .exe and tick “Disable display scaling on high DPI settings”.

It may also be possible to use a .reg file to edit a registry key, but that will need admin access.
(And it’s hopefully not as convoluted as this webpage makes it seem.)


@Pharap: Thanks, this gives me some ideas to test when I get home. :bulb:

  • Build for arm and simulator in the same IDE: I’m not sure. I don’t use Code::Blocks, so I don’t know how to make it ignore the simulator files when building for hardware and vice versa. I also don’t know how to make a project that can be built by two different compilers. I assume it can be done, which is why I bundled MinGW along with it.
  • Hardware Debug: This shouldn’t be an issue, but I’ll have to wait till the mail delivers my debugger before I can do something about it.
  • Emulator: I can put ProjectABE but I’ve been having a hard time getting javascript to emulate GPIO quickly enough. I’m looking into making a C++/SDL based emulator so that we can both run and debug. This might solve the need to build for the simulator, with the added bonus that it would run at the correct speed.
  • Coffee: An IDE is not of much use without coffee so it sure would be convenient to ship the two together!

I’m thinking of removing some of the other project templates (Fortran, Matlab, Java, PowerPC, OpenCV). Anybody have any objections/suggestions?

I just updated the zip in the release to fix the duplication issue and I changed the icon. Thanks @HomineLudens & @adekto!


If you want to trial the VBS approach, the this page has an example:

I’ve just finished writing and testing something that should work:

Set oWS = WScript.CreateObject("WScript.Shell")
sLinkFile = "PokittoBlocks.lnk"
Set oLink = oWS.CreateShortcut(sLinkFile)

currentDir = CreateObject("Scripting.FileSystemObject").GetParentFolderName(WScript.ScriptFullName)

oLink.TargetPath = "cmd"
oLink.Arguments = "/c """ & currentDir & "\DPIFix.bat"""
oLink.Description = "MyProgram"
oLink.WorkingDirectory = currentDir
' I really want to make this the PokittoIcon somehow :P
' oLink.IconLocation = "C:\Program Files\MyApp\MyProgram.EXE, 2"

Where DPIFix.bat is the batch file that contains

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

Also, it would be good if you could post an explanation of how your Code::Blocks fix works at some point so we can understand it and think of ways to develop it or improve it and understand what’s different about it to plain old Code::Blocks.


1- Started with plain old Code::Blocks
2- added arm-none-eabi-gcc
3- created share/CodeBlocks/compilers/compiler_arm-none-gcc.xml *
4- created share/CodeBlocks/compilers/options_arm-none-gcc.xml *
5- created the pokitto project template/wizard *
6- added PokittoLib and removed the parts that wouldn’t compile (Simulator code)

*These were made by copying an existing file from other architectures and making the minimum necessary changes. The wizard is based on the makefile I use in Linux.


@FManga @Pharap : wiping the bootloader is not bricking. It’s more like an initiation rite to embedded programming. You’re not trying hard enough until you’ve busted the bootloader.

Wiping the bootloader and setting flash write protect fuse bits so that the device can never be written again is bricking


Hehe, true. The thing with Arduboys is that the average user is not supposed to ever have to open the device. Most lack the equipment/knowledge to fix the problem, so it’s as good as bricked.


I have forgiven you. I did manage to flash that Arduboy back into life!


Thank you. :slight_smile: Still, the situation could’ve gotten much worse if more people had tested that build on MacOS so I’ve learned a lesson about being extra careful with others’ microcontrollers.
It’s surprisingly easy to mess up something. A theoretical example:

struct Data {
  char stuff[0x23];
  char x;
} *data;

void loop() {
    arduboy.print( (int) data->x );

By “forgetting” to set the data pointer, x becomes a reference to PORTB and you see the button state printed on the screen. You could just as easily have a reference to DDRB and writing to it could set that pin into an output. A common null pointer mistake becomes a short (and possibly a burnt pin) when a button is pressed.


Any further development here?
Is it possibile to integrate latest debug function on CBP?


Sorry, no updates on this. I thought everyone had switched to Platformio. :stuck_out_tongue:


Do you? With debug support?


I use emacs and make. For debugging I’ve been using gdb directly, most of the time.
If you use VSCode you can get the Cortex plugin for debugging (both hardware and the emulator).