Sorry, wrong guru 
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.
1 Like
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? 
1 Like
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. 
- 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!
1 Like
If you want to trial the VBS approach, the this page has an example:
https://ss64.com/nt/shortcut.html
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"
oLink.Save
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 Like
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.
3 Likes
@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
2 Likes
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.
2 Likes
I have forgiven you. I did manage to flash that Arduboy back into life!
3 Likes
Thank you. 
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.setCursor(0,0);
arduboy.print( (int) data->x );
arduboy.display();
}
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.
2 Likes
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. 
1 Like
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).
1 Like