Pokitto::Code::Blocks

Pokitto Software
28

That’s a REALLY bad new.

29

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.)

30

@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!

1 Like
31

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
32

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
33

@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
34

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
35

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

3 Likes
36

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.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
37

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

38

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

1 Like
39

Do you? With debug support?

40

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
41

I use VSCode and PlatformIO for Pokitto.

There were some teething problems early on, but after relocating one or two files I have absolutely no issues and setting up a project is just a matter of copy-pasting and renaming a folder.

It’s much easier to use than EmBitz because you don’t have to go fiddling with target settings.

1 Like
42

I’ve recently updated and it rise again the problem with c++11

That’s a major selling point for me, together with easy lib update

But I’d like to debug the code with break point, step execution, watch windows etc etc.
Is there a guide for that?

43

Give me a moment to remember how to fix that.
I’m reasonably confident I had to edit a file somewhere in \.platformio\packages\framework-mbed\.

Edit:
Could you post the contents of your \.platformio\packages\framework-mbed\platformio\variants\LPC11U68\LPC11U68.json file?
I’ve got a feeling that might be the one.

I haven’t been able to get that working yet.

Every time I try to use the Cortext plugin it says “Couldn’t find a compatible version of Cortex-Debug with this version of Code.”, so I need to get round to updating my VSCode install.

44

I remember using these things with the Cortex plugin and that it was relatively easy to setup. Two caveats: everything in VSCode is configured by editing JSON files (less intuitive than a nice UI, but easier than emacs’ lisp), and you’ll get much better results if you’re compiling with -O0 and -g (or was it -ggdb).

I stopped using graphical debuggers since most of the time I use -O3 and need to see the disassembly. Command-line GDB was the only thing that didn’t fall apart with my weird code. :stuck_out_tongue:

45

I’ve already fixed as the last time thanks anyway.

So this should work also with your emulator? Enabling gdb?
Could I deploy/upload directly to the emulator from vscode?

Should I open a new Thread to query the current state of the development tools? I feel actually there are different approach to code for Pokitto right now.

46

Didn’t notice that.
That would have saved me a few minutes of searching. :P

There’s:

  • PokittoLib +
    • EmBitz (Windows only, C++11)
    • Mbed online (C++98, no inline assembly)
    • Code::Blocks (C++11)
      • (Last time I tried I couldn’t compile it)
    • Emacs + make
    • VIM + make
  • PokittoIO + PlatformIO (C++11) +
    • VSCode
    • Atom
    • Possibly others

I don’t know if there’s an ‘official’ IDE, but I tihnk we ought to be heading down the PlatformIO route.
It has a lot of positives and very few negatives.

47

I can confirm it works with C++11

I’d like it would be only one :grin:

I like Visual Studio, vscode is close enough on capabilities, I’m only missing the debugger right now.