Super weird, it’s something with my computer – the page doesn’t load in my browsers, even when using a proxy, but I can access it via Tor. Don’t know what’s happening, but am downloading EmBitz already 
I think EmBitz is Windows only, and I’m guessing you don’t have a Windows computer.
Best report it to @FManga in this thread.
I had similar problems so I made a couple of PRs to solve some of them:
I didn’t solve everything though, so I couldn’t get it to compile.
1 Like
Yeah, I just found out 
I might be able to use it via wine, but web IDE may actually be more comfortable for me. Ideally I’d like to get the Sim/Emu to work and only use the IDE to produce the final build, because I really like my vim workflow. Are there any other potential compilers for the Pokitto microcontroller that could be used in the future?
Also I’d be very glad to get the Sim working without code::blocks – it uses gcc anyway. Would be awesome to have e.g. cmake as an alternative… This is just an idea for the future, code::blocks can be invoked from CLI in the meantime so it’s no blocker to me.
Just download the toolchain and use it directly. I use this with make/emacs, you should be able to get vim working just fine.
What errors do you get compiling the emulator? I still haven’t had a chance to look at the PRs @Pharap sent me.
2 Likes
Code::Blocks (like most IDEs) is basically just a middleman,
eventually it just feeds comands to GCC.
If you can figure out which commands are needed then you can cut out the IDE.
I notice you didn’t mention PlatformIO, Atom or VSCode,
is there a reason you haven’t tried VSCode+PlatformIO or Atom+PlatformIO?
1 Like
Wow, looks great, I’ll try.
Sorry for my ignorance, I tried compiling the code::blocks project but now I noticed there is a Makefile, compiles just fine
Yes but it’s also a build system (or it seems to me) that knows where all the objs and libraries are and links it all together with a thousand of commands. This is exactly what cmake could do pretty easily, but I haven’t tried yet because I have so many new things to set up.
The reason is I don’t know what it is Checking it out right now, it better be all FOSS
The Code::Blocks project is what I had issues with as well.
I’m not sure it would be as many as a thousand.
Probably just one very long command.
I’ve never attempted to compile with GCC on the command line because there’s so many options.
I wouldn’t bother suggesting otherwise.
(Yes, Microsoft is capable of using open source licences.)
Atom is probably open source too, but I’ve never used it.
1 Like
I just keep copy-pasting the options from the old projects You just adjust a few options here and there.
I got close to compiling it all but got stuck somewhere at linking the PokittoLib. I’ll get back to it later.
I know, the problem is a lot of open-source programs are dependent on proprietary platforms – that’s one of my main issues with open-source vs free software. As long as it can all be run using only FOSS, I have no problem with Microsoft being signed below
Okay, I managed to compile with gcc only, and disabled sound in simulator so that it doesn’t crash. Guess I can get to development now
What toolchain + os are you now using, Miloslav? Platformio + Mac?
Edit: or simulator?
Linux Mint, bare command line gcc + simulator (with sound disabled because of pulseaudio library bug). For final build I’ll use mbed.
EDIT:
Still I have to use code::blocks if I want to recompile anything else than my program, e.g. if I change a screen mode or another global #define. To achieve complete independence from code::blocks I’ll have to use CMake, in which case I might as well make a tutorial. Let me see.
As I’m looking at it, CMake can generate code::blocks project files as well as regular Makefiles and many other build systems, so having a CMake might be the ultimate solution.
EDIT2:
There’s a precompiled static library /lib/linux/libPokittoCoreLin.a – how can I recompile this? What source files was it generated from? I think it may also be the source of the pulseaudio library segfaults.
EDIT3:
Seems like too much work now, I think I’ll just go make some small test game 
first experiments 
6 Likes
It’s on the Pokitto now!
4 Likes
There’s no settings file with this.
What screen mode does it use?
Is it lores mode? (110x88 16 colour)
Nevermind, I found the screenmode option buried part way down the code.
I find it odd that this code would compile without a My_settings.h file.
Also, for the record, using small datatypes like uint8_t and uint16_t is probably more expensive on ARM because ARM needs extra instructions to truncate its 32 bit registers after performing arithmetic.
1 Like
The settings file is there somewhere, just not in the repo. I still don’t know how it works exactly, will look at that tomorrow
Interesting, I’m still used to it from Arduboy, I’ll reconsider this. Is there a way to see how much RAM is occupied with global variables, like with Arduino?
EDIT: Just to make it clear, it’s not complete yet. Probably will be tomorrow though.
I guessed as much.
It makes sense to use e.g. uint8_t for arrays when you only need a small range of values because that saves memory, but for things like counters you probably want larger values.
For things like counters, you can use unsigned int as long as you aren’t dependent on underflow/overflow.
If you want your code to be optimal when ported to Arduboy then you might want to opt for uint_fast8_t instead (it’s a bit of a mouthful, so you might want to do using ufast8_t = uint_fast8_t; if you’re lazy).
Some of your types would be best off being replaced with size_t, for the sake of correctness.
size_t's definition is essentially:
size_tcan store the maximum size of a theoretically possible object of any type (including array)
so it’s the type you should always prefer to use for array indexing and sizes.
(Obligatory SO answer.)
(It doesn’t really apply to your code, but while I think of it, there’s a related issue where many people attempt to cast a pointer into an int when the proper type is either uintptr_t or intptr_t.)
When using VSCode+PlatformIO, it’s printed out on the terminal:
Archiving .pioenvs\lpc11u68\lib70d\libArduboy2.a
Linking .pioenvs\lpc11u68\firmware.elf
Checking size .pioenvs\lpc11u68\firmware.elf
Building .pioenvs\lpc11u68\firmware.bin
Memory Usage -> http://bit.ly/pio-memory-usage
DATA: [=== ] 35.0% (used 12900 bytes from 36864 bytes)
PROGRAM: [= ] 14.1% (used 36900 bytes from 262144 bytes)
========================= [SUCCESS] Took 18.27 seconds =========================
I’m pretty sure EmBitz tells you as well, but I have no clue about Code::Blocks.
If I’d realised that I wouldn’t have started making a derived version :P
1 Like
Nice! Thank you @Pharap
I have additional questions, such as
- Does the MCU have an FP unit or is it again only emulated in SW? I suppose it’s only SW as I couldn’t see any FP block in the MCU diagrams when I looked, but I am a complete noob here and may as well be wrong.
- How do I handle program memory vs RAM? On Arduboy there’s the
PROGMEMmodifier (I also found out the hard way that I can’t simply directly assign a value from aPROGMEMmarked variable, I have to use a special function). How does it work here? - Are there any restrictions on C++ language? Is the standard library supported in whole? Or only C lib again?
I am aware the answers are probably to be found around the website here, but I suppose they’re buried in the tutorials for complete beginners. I’d be really really glad if you, or any other of you nice gurus here, could make the
Pokitto programming specifics for those who already know C++
article, in order to have it all in one place. I’d be eternally grateful 
I honestly have no idea.
I’ll leave that one to @jonne to answer.
I believe (don’t quote me on this) that actually the progmem isn’t really progmem, it’s simulated with flash memory (or possibly write protected) and consequently there’s no special instruction for reading from progmem like there is on the AVR, which means you don’t need a special macro for either reading progmem or putting a variable into progmem.
From what I’ve heard the compiler tries to stick anything marked const or constexpr in progmem, and I’m guessing it will possibly try to put other things in progmem following the same rules as a compiler compiling for desktop would for trying to decide what it can put in the ‘constant data’ section of an executable.
So in other words, don’t worry about it too much and just mark anything you don’t change as const (which I try to do anyway - using const on your variables signals to other code readers that you don’t change that variable at any point).
(Not directly related, but you might be interested in single static assignment form, a technique used by compliers such as GCC to determine which variables are truly const and to do reaching definition analysis.)
Full C++11 (and later). Full standard library.
(Unsurprisingly I am immensely happy about this :P)
You can even use dynamic allocation as long as you don’t overdo it.
If you do though, I’d suggest using smart pointers (unless you find them to have a measurable significant negative impact on speed or size).
Not quite the same but I wrote a C++11 for C++03 programmers (which I didn’t get around to finishing because C++11 was a massive update to the language).
If you’re already experienced with C++ then I can’t think of much more that you’d need to know than:
- What’s the chip like? - The chip is a 32 bit ARM chip
- What’s the ISA like? - The instruction set is the 16-bit Thumb instruction set without full 32-bit ARM instructions (and it’s documented here and here)
- Is the stdlib available? - Yes, completely
- Whether there’s an FPU? - Don’t know
- What’s the API like? - Documented here
- What are the other APIs like? - Documented here, very C++, many classes (and even a few templates)
1 Like
No FP in this mcu
2 Likes