The Great PokittoLib Cleanup of 2020

@FManga , began testing the overhaul PR

Femto

  • Hello CPP fails
    fix:
    replace -std=c++14 with -std=c++17 in project.json
  • Hello Java builds OK
  • Hello MicroPython fails
    no fix yet

EmBitz

… in progress

  • requires deselecting GNU C++ 14 from options and passing -std=c++17 in Build options / C++ flags / others
  • requires copying newer version of GCC from Femto to EmBitz
    – from: \IDE-windows-v0.1.5\windows\arm
    – to: \EmBitz\1.11\share\em_armgcc

But still fails to create hex file (problem with objcopy, investigating)

arm-none-eabi-objcopy.exe: .\build\hello.hex 64-bit address 0x4b4fa300000000 out of range for Intel Hex file
arm-none-eabi-objcopy.exe:.\build\hello.hex: bad value

this is a reported bug in GCC :slight_smile:

https://bugs.launchpad.net/gcc-arm-embedded/+bug/1810274

FIX for the OBJCPY problem (hex file build on EmBitz)

save arm-none-eabi-objcopy.exe from old \EmBitz\1.11\share\em_armgcc and put it in place of \EmBitz\1.11\share\em_armgcc\arm-none-eabi-objcopy.exe

EmBitz builds OK!

2 Likes

I’ll make the next FemtoIDE release automatically change the -std=c++14 flag into -std=c++17.

3 Likes

Very happy with results so far, got EmBitz to build with not big hurdles

1 Like

After trying FManga PR
I did have the same problems as @jonne.

Screen Modes

  • 1 OK
  • 2 OK
  • 13 OK
  • 15 OK
  • 4 (gamebuino) broken
  • 64 broken (never used by any games)

MicroPython broken

EmBitz

works after some hacks (i did’t replace any files just modify the settings)

  • Add the assembly files (Pokitto/POKITTO_HW/asm) under Project | Add files.
  • Change the compiler to femto compiler under Settings | Tools | Toolchain exutables.
  • Add -std=c++17 to c++ flags under Project | Build options| Compiler settings.
  • Uncheck Generate hex file under Project | Properties | Build targets.
  • Change the Post-build steps to
arm-none-eabi-objcopy.exe .\build\$(TARGET_OUTPUT_BASENAME).elf -O binary .\build\$(TARGET_OUTPUT_BASENAME).bin
.\build\lpcrc .\build\$(TARGET_OUTPUT_BASENAME).bin

under Project | Build Options | Pre/post build steps.

2 Likes

Mode 4? What mode 4?
giphy

Edit: Added a to-do list to the first post, so I don’t forget anything.

2 Likes

Found it in the wiki

Updated the Wiki, I’ll add TAS Mode to it when it’s merged.

1 Like

@jonne, @FManga
We are officially Moving to this PR?

Yes we are as soon as I am happy with testing it

Edit: there’s an old saying in Finland:

“Merge first, ask questions later”

We need a bigger TO-DO list:

  • Make femtoIDE examples/tutorials.
  • Remove all the old tutorials (PokittoSim, online IDE, EmBitz), alternatively we could move them to a new category in the forum PokittoLib Legacy.
  • Fix MicroPython.
  • Clean PokittoLIb.
    • Remove PokittoSim (does not support C++ 17).
    • Remove gamebuino/arduboy support.
    • Remove the none working examples.
    • Move all the functions From POKITTO_HW to POKITTO_CORE.
1 Like

I think examples could be a separate repo in the future

3 Likes

@bl_ackrain

http://candcplusplus.com/enable-c17-in-code-blocks-mingw-gcc-for-all-version-with-pictures

  • What would FemtoIDE examples demonstrate? Java?
  • I agree about moving the examples to their own repo
  • Fixing MicroPython is already in the list of things I’m going to do, in the first post of this thread.
  • PokittoSim will need fixing, not removing.
  • Gamebuino/Arduboy support is partially gone already.
  • The HW and CORE separation is useful.
2 Likes
  • Change the c++ examples from EmBitz to femtoIDE projects, make getting started tutorials for femtoIDE (for new commers)
  • How you are going to fix PokittoSim?
  • You only remove the screen update function still lot to remove (Audio, GUI, Battery, Backlight, other support files).
  • If we remove the simulator, why we need the separation?

I agree with deprecating the online IDE, but some people still use EmBitz so I don’t think we should deprecate it just yet.

I was halfway through suggesting this before I spotted your comment.

Though I already suggested this in the ‘to do’ list:

Hopefully we’ll eventually bring these back as separate libraries.

The problem with PokittoSim is that it means the work of maintenance is doubled for certain functions.

I think most people use the emulator anyway, so removing it might be an option.
(I’d definitely want to do a public vote on removing that though.)

1 Like

I was saying we should depricate the getting started tutorials that use EmBitz not EmBitz it self.
Right now our best option for new commers is femto, FManga did a great job making it

1 Like

In that case, I think we should still keep the tutorials,
but ‘lock’ them and move them to a designated ‘archive’ section to make it clear that they are only kept for reference purposes.

Which reminds me…

Rather than completely removing the information about the deprecated screen modes,
I think it would be better to move them to a ‘deprecated’ section (in a ‘details’ block) so that the information is still available for historical purposes,
but it is clear that that functionality is no longer available.


If nothing else, these things are an important part of the Pokitto’s story (or history),
so it would be nice to keep a remnant of them rather than allowing them to degrade to word-of-mouth stories.

1 Like

Being a bit of a newcomer to the community and pokitto development I went through all the various tutorials using the various IDE options (back before my windows machine started having issues) and when @FManga suggested trying FemtoIDE due to my issues with the SD card access it was the only one I hadn’t tried and ended up being by far the simplest and easier setup. Download the appropriate zip file and run it. The best part is (coming from mostly Arduino development) it seems perfectly content to let you use an external editor and jump back to it for building. The only real improvement needed is the compile output history getting cropped with all the lengthy warning messages, any warnings/errors in your project’s code could easily get buried, so -1 for that.

I give it a +10 for built in debugging support using the emulator and gdb, with the option of also using j-link for hardware debugging. I’ll give it another +20 for the detailed breakdown of Flash and RAM usage when clicking on the elf file (that alone is what convinced me to not look back on the CLI build method).

That doesn’t mean it should be the only option (much like people are also free to not use the Arduino IDE at all), but it does greatly simplify the development process from creation to full release. The simplicity, features, and benefits of FemtoIDE seems like it would be the best bet for centering all future tutorials around, especially since there’s very little involved with the setup and use of the IDE which allows the tutorials to focus more on the actual coding. This in turn makes it easier for people to use the environment of their choosing, and there’ll always be help from the community to get any particular setup working.

All in all it’s definitely another amazing product from @FManga. Now if we can just convince him to make a game.

5 Likes

While the emulator environment should be the final goal for developing programs for Pokitto,
PokittoSim is currently the most productive way to make programs. That is mostly due the excellent debugging features in CodeBlocks. It is also the only environment where audio works correctly outside HW.

1 Like

I think that’s probably subject to opinion,
which is why I’d ideally like to do a public vote to gather people’s opinions.

Does the simulator not work in FemtoIDE?

If so, that’s another good reason for being rid of it.
Requiring people to use more than one IDE if they want to compile their game for both hardware and simulation is a bit much.