Arduboy Source Compatibility Library | Flipper Devices | Page 1

stoic dawn Dec 29, 2023, 11:04 PM

#

This is something I've been tinkering with thanks to Wr3nch and np0. Finally have something functional and want to gauge interest overall as well as use this as a place to dump updates until its ready for release.

WHAT THIS ISN'T:
This is not a general Arduino compatibility library, that is not the goal. That is too broad to try and cover the whole Arduino space.

WHAT THIS IS:
A modification of Arduboy2 libraries and tools to allow building Arduboy games from source to run on the Flipper Zero.

HARD LIMITATIONS:
While the screen is the same size between the Arduboy and Flipper Zero, and they have the same button count; the Flipper Zero screen is slower to update, and the buttons are one-handed. This means that high-action games probably arn't worth running. Same with games where you need to use D-pad and A/B simultaneously. I have ideas on how to try and address this down the road.

RIGHT NOW:
I've got basic startup, printing to screen (using the Flipper font, not Arduboy font, so it looks silly), framerate timing, and input handling. Currently, thanks to the Arduboy and general Arduino paradigms, there is no way to exit back to Flipper. Hard reboot with Left+Back only. I'm also using the direct_draw modes

TODO:
A lot. A whole lot. I'm not publishing this work yet as it is a bloody mess. But once I get closer to a clean and well-featured interface, I will happily release this as well as maybe push some games to the Flipper Application Catalog. I also would love to have a loader interface, so multiple games can be bundled in a single .fap, even better would be a way to load from SD assets. Really just to keep this as self-contained as possible.

HOW YOU CAN HELP:
Right now, tell me what are your favorite Arduboy games. Preferably games that are more simple, with low refresh rate needs. As I get compatibility folded in, I'll drop .faps here for people to test out.

#

Heres a simple hello world. The code below compiles cleanly in Arduino (as well as for Flipper).

/*
Hello, World! example
June 11, 2015
Copyright (C) 2015 David Martinez
All rights reserved.
This code is the most basic barebones code for writing a program for Arduboy.

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
*/

#include <Arduboy2.h>

// make an instance of arduboy used for many functions
Arduboy2 arduboy;


// This function runs once in your game.
// use it for anything that needs to be set only once in your game.
void setup() {
  // initiate arduboy instance
  arduboy.begin();

  // here we set the framerate to 15, we do not need to run at
  // default 60 and it saves us battery life
  arduboy.setFrameRate(15);
}


// our main game loop, this runs once every cycle/frame.
// this is where our game logic goes.
void loop() {
  // pause render until it's time for the next frame
  if (!(arduboy.nextFrame()))
    return;

  // first we clear our screen to black
  arduboy.clear();

  // we set our cursor 5 pixels to the right and 10 down from the top
  // (positions start at 0, 0)
  arduboy.setCursor(4, 9);

  // then we print to screen what is in the Quotation marks ""
  arduboy.print(F("Hello, world!"));
  arduboy.setCursor(4, 19);
  if ((arduboy.pressed(UP_BUTTON))) arduboy.print(F("Up"));
  if ((arduboy.pressed(DOWN_BUTTON))) arduboy.print(F("Down"));
  if ((arduboy.pressed(LEFT_BUTTON))) arduboy.print(F("Left"));
  if ((arduboy.pressed(RIGHT_BUTTON))) arduboy.print(F("Right"));
  if ((arduboy.pressed(A_BUTTON))) arduboy.print(F("A"));
  if ((arduboy.pressed(B_BUTTON))) arduboy.print(F("B"));

  // then we finaly we tell the arduboy to display what we just wrote to the display
  arduboy.display();
}

The .fap is for Flipper API 50.0

📎 test.fap

viscid void Dec 30, 2023, 12:27 AM

#

omg I was so excited seeing this show up in the project threads, I still am. This would be incredible, I don't think the general community realizes how many awesome games we'd get from this.

#

Basically would turn the FZ from a novelty game device into an actual one with a large collection if the library ends up working. Following this closely, I'll help as much as I can at the end of March if the source is made available by then.

stoic dawn Dec 30, 2023, 12:34 AM

#

Sounds good. Most of what’s next is just mechanical code translation to use flipper routines right now. If you’ve got ideas long term for how to make this more self contained, e.g. have a fap as a loader and load blobs from sd or some other useful process, I’m all ears. I don’t have a timeline, but I’d like to say I should have a public release by march.

gilded ravine Dec 30, 2023, 12:45 AM

#

This is awesome

viscid void Dec 30, 2023, 12:49 AM

#

That's what I was thinking originally, a loader. It seems like the files are .hex (compiled Arduboy games), and .arduboy files are .hex files plus some metadata/screenshots. Hex files are the bytes that literally get loaded into flash memory along with the address to load them at, plus the checksums. I think if the blobs are looking for Arduboy shared library functions in the loader, those could be linked in at runtime allowing you to run the unmodified hex files with a Flipper Zero API.

#

The compiled blobs are for the RISC architecture so we'd likely load the entire hex blob into memory (32 KB) and translate instructions using a tiny Arduboy VM.

#

Otherwise, recompilation is necessary with the library (which also works). Since they are both reduced instruction sets, translating between them is definitely doable but I'll say from experience that ARM LE is an absolute nightmare to translate.

#

Your approach makes more sense I think.

#

(anyone who thinks otherwise is welcome to try my ARM LE challenge: <#voice message>)

stoic dawn Dec 30, 2023, 3:01 AM

#

Yeaaahhh, I did some thinking on it and came to the conclusion that a VM would likely work, but that is going to be highly dependent on the application itself, how it looped, how many instructions it needed to run between frames, etc. Since the Arduboy API has a missed frame indicator, I figured its probably more common than I considered. If it were bare metal yeah it could probably do it, but dealing with freertos and a VM I figured would introduce too much lag.

At that point, a from source path made the most sense. Especially now that I found the direct_draw mode of flipper; makes it much easier to handle graphics like the Arduboy library does.

But, when I say "fap as a loader..." I more meant to have it behave like the Arduboy FX with a menu system to select a game and launch it from EEPROM rather than only being able to hold a single app. So, still compile from source, but somehow linking the main application to the arduboy-flipper library implementation at runtime. So part of the fap could browse loose files on the SD card, objects built for flipper, load those in, and run there. The issue of distribution still remains though, as I think right now the application catalog can only distribute a single .fap per application, and no other files alongside it (unless I'm mistaken).

stoic dawn Dec 30, 2023, 7:38 AM

#

Arduboy Souce Compatibility Library

stoic dawn Dec 30, 2023, 8:05 AM

#

Arduboy Source Compatibility Library

stoic dawn Jan 2, 2024, 5:11 AM

#

Set up a custom u8g2 font to mostly match the Arduboy font. At some point if I'm feeling pedantic then I'll create a pixel exact match of the fonts. If anyone is interested in doing that, go right ahead 😉

This also matches some of the drawing primitives, lines, boxes, circles, etc. The test.fap attached only implements a couple of these. I'm hoping to grab a basic game and test that in the near future and start getting live implementations going.

📎 test.fap

stoic dawn Jan 3, 2024, 6:44 PM

#

I hit a brick wall when starting to work on the Sprites library.

Arduino uses a format optimized for its LCD, which appears (read: just based on the Arduboy code, havn't pulled up the LCD datasheet) to be addressed top to bottom, left to right, LSB first. So the sprite table format is set up to match that. The first byte, LSB is the top-left pixel, MSB is the bottom-left pixel. The next byte is top-left+one to the right and down. So on.

The flipper expects XBM format, which is, left to right, top to bottom, LSB first. The first byte, LSB is top-left pixel, MSB is top-right pixel. Next byte is top-left+8 to the right, continuing left. So on.

I don't know of any good bit swizzling algorithms to handle that on an x-by-y dimensional array. And everything I've come up with so far is really not viable at runtime. I'm open to ideas if anyone has any.

I could try and add some API routines to flipper firmware to handle this a little more gracefully; but I think it would have the same issue as needing to swizzle bits from one orientation to another.

It could be tackled at compile time, but most of the ideas I have there would require pre-processing (which flipper-application-catalog tools have no ability to do AFAIK), or direct modification to the Arduboy code (which is not really in the spirit of this projecct, but not out of the question). The latter would want to have the original sprite images available (not all projects do) to re-process those to XBM format.

If anyone has any other ideas, I'm all ears. I'll keep plodding away at it and seeing what I can make work with minimal runtime impact.

viscid void Jan 3, 2024, 7:13 PM

#

Interesting problem. What if you cache the sprites? We have plenty of RAM right?

#

Whenever a call is made to draw one, it does the bit swizzling and stores the updated sprite in memory for later drawing.

#

since the sprites have deterministic memory addresses (the pointer to the bitmap), we can look up the cached sprite based on the pointer given to us and build out the cache at runtime

#

it'll only be slow the first time it renders it which should be imperceptible, especially because the FZ's STM32 is 4x faster than the Arduboy's ATmega32U4

#

lmk @stoic dawn

stoic dawn Jan 3, 2024, 7:24 PM

#

That... is clever. I like that

#

There is plenty of RAM compared to Arduboy, however, a lot of sprites are stored in EEPROM. Which, again, I think has a pretty hard limit less than F0's RAM. I'll dig in to those numbers when I get a chance and see how well that could work out

stoic dawn Jan 5, 2024, 11:53 PM

#

Got base sprites working. Its still a mess, I'm not doing any caching so there is indeed noticeable lag. More to come once I have time to write a caching mechanism and do more testing.

stoic dawn Jan 11, 2024, 3:31 AM

#

Found a fairly simple game to start testing with, https://community.arduboy.com/t/catmines-a-minesweeper-clone-for-the-arduboy/10028/6

Main menu loads and navigates. Title sprite and selector icon load and work. Despite there being lag thanks to the still shoddy sprite drawing, menu is still pretty snappy.

Unfortunately, the game crashes when you try to start it right now lol.

I'm running in to an issue debugging because the .elf generated by ufbt doesn't seem to want to debug quite right. ... ... Though I just now realized I can pretty easily change the compile options, so I'll try that in a bit... However, when I try to build with fbt in the firmware repo, I get an error I'm not familiar with:

scons: *** [build/f7-firmware-D/.extapps/test.impsyms] build/f7-firmware-D/.extapps/test.fap: app may not be runnable. Symbols not resolved using firmware's API: {'__cxa_pure_virtual'}

I don't speak much C++ but it seems to be related to that specifically. That error doesn't pop up with ufbt, either.

If anyone has any ideas on resolving it, or, can at least tell me what stupid thing I did that might be causing it, I'd love to hear it.

Attached .fap is same one used in video, built with API 50.0 for ofw

📎 test.fap

stoic dawn Jan 11, 2024, 6:50 AM

#

innnteresting. I went to change -Osin ufbt sdk_opts file to -O0 and compile again (already specifies -g) and now ufbt fails to build with the same cxa error

viscid void Jan 11, 2024, 7:32 AM

#

Silly question, do you have a WiFi dev board?

#

I cannot imagine how difficult it would be to write this without one lol

#

Also is the WIP source up anywhere I can pull it down and debug later, so I can tell you what might be going on?

#

(I can tell you where it crashes, the dev board does that easily)

#

@stoic dawn do you need a dev board?

stoic dawn Jan 11, 2024, 7:39 AM

#

I 100% have a devboard, but thank you 😄

#

The problem is, with ufbt, gdb is not correctly showing the source, and the reason is because -Os. But, I'm running in to C++ virtual function nonsense that I'm trying to learn about as I go

#

once I get past that, I can definitely get debuggin'

stoic dawn Jan 11, 2024, 7:41 AM

#

viscid void Also is the WIP source up anywhere I can pull it down and debug later, so I can ...

Not yet, its a fragile mess still, but, I may take you up on that if I stay stuck

viscid void Jan 11, 2024, 7:41 AM

#

I haven't needed to use -Os to debug the crash location in the source, when I get it set up with vscode it takes me immediately to the crash without needing -Os to debug

#

(in the source)

stoic dawn Jan 11, 2024, 7:43 AM

#

No no no, sorry for confusion. Little intoxicated at the moment. ufbt is compiling by default with -Os, which confuses gdb. When I remove it and force -O0 -g that __cxa_pure_virtual error crops up

#

which, building with fbt in the firmware tree itself, also causes that cxa error, presumably because its compiling with similar options

viscid void Jan 11, 2024, 7:44 AM

#

Yeah I meant to say you don't need -O0 -g, I was a bit confused too

#

it builds it by default with symbols

#

there's plenty of debug info without modifying the compilation flags

stoic dawn Jan 11, 2024, 7:45 AM

#

hm... it was definitely doing very wrong things when stepping through. Maybe I missed something stupid. I'll give it another go tomorrow, should have time then

viscid void Jan 11, 2024, 7:46 AM

#

Let me know if you want me to tell you where the crash is, I have vscode set up but I can't get to it until later today

#

(need to do a local build with source though, I understand if you're not ready to release that yet)

stoic dawn Jan 11, 2024, 11:19 PM

#

(Sorry if you got a ghost ping, I accidentally hit enter too soon on a message)

Okay it looks like I'm fighting C++ nonsense. I know where the crash is, but, can't debug it correctly because it doesn't show line numbers, e.g.

(gdb) bt
#0  ...
...
#7  0x08067cba in canvas_draw_str (canvas=<optimized out>, x=<optimized out>, y=<optimized out>, str=str@entry=0x2000ff14 "N") at applications/services/gui/canvas.c:153
#8  0x2000cdf8 in Arduboy2::write (this=<optimized out>, c=<optimized out>) at /home/.../arduboy-flipper/arduboy-flipper/lib/arduboy2-flipper/Arduboy2.cpp:1330
#9  0x2000d10c in Print::write (this=0x2000e32c <arduboy>, buffer=0x2000dce1 "ormal", size=<optimized out>) at /home/.../arduboy-flipper/arduboy-flipper/lib/arduboy2-flipper/Print.cpp:38
#10 0x2000d11e in Print::print (this=<optimized out>, str=<optimized out>) at /home/.../arduboy-flipper/arduboy-flipper/lib/arduboy2-flipper/Print.cpp:64
#11 0x2000da84 in Game::gameLoop() ()
#12 0x2000cc78 in loop () at /home/.../arduboy-flipper/arduboy-flipper/HelloWorld.cpp:435
...

Note Game::gameLoop() doesn't have a line number nor does it show source when you break on it (and the bp is actually at a completely different place somehow). But its in HelloWorld.cpp and is called by loop()

The crash I've been seeing ends up looking like this:

(gdb) bt
#0  0x080104ea in __furi_crash_implementation () at furi/core/check.c:164
#1  0x08006796 in MemManage_Handler () at targets/f7/furi_hal/furi_hal_interrupt.c:271
#2  <signal handler called>
#3  0x2000d598 in Field::updateField() ()
#4  0x2000d96c in Game::gameLoop() ()
#5  0x2000c618 in loop () at /home/.../arduboy-flipper/arduboy-flipper/HelloWorld.cpp:433

Which I managed to figure out what was crashing, but I can't understand why yet. It looks like an invalid pointer/array index, but its all within the code that works on real Arduboy.

I've wrapped the whole HelloWorld.cpp in extern "C" { ... } and that didn't seem to help. Any ideas?

viscid void Jan 11, 2024, 11:23 PM

#

I can look at it if you send the source, I'm surprised you are using CLI GDB here

#

Their vscode integration is excellent. You can hover over variables for their value, you can easily set breakpoints, visually explore memory, and you can see exactly where the crashes are (in firmware or in the FAPs). Also it breaks at the beginning of the FAP so you can set breakpoints.

#

It would be no trouble for me to tell you exactly what's happening

stoic dawn Jan 11, 2024, 11:26 PM

#

I mean, I can normally do all of that from gdb, but not in some of those functions, they just, break. I'll tar up the code and let you give it a whirl.

viscid void Jan 11, 2024, 11:27 PM

#

Don't get me wrong, I often use CLI GDB too (I reverse engineer NFC/BT functions). Working in VSCode for this is night and day

stoic dawn Jan 11, 2024, 11:27 PM

#

I mean, if that ends up working for you, I'll switch to vscode in an instant lol. I've just never had a reason and am faster in a CLI environment.

#

@viscid void Let me know if you find anything interesting

📎 arduboy-flipper.tar

viscid void Jan 11, 2024, 11:32 PM

#

Got it, checking now

#

Wow, Sprites::drawBitmap is hardcore

#

same with Arduboy2Base::drawPixel

stoic dawn Jan 11, 2024, 11:37 PM

#

viscid void same with Arduboy2Base::drawPixel

all of that asm is leftover, thats Arduboy's doing lol

viscid void Jan 11, 2024, 11:47 PM

#

Alright I now have everything set up. The Flipper, the editor, the dev board, and I hit the crash

#

So something called __furi_crash(), walking back

#

#0  0x080104ea in __furi_crash_implementation () at furi/core/check.c:164
#1  0x08006796 in MemManage_Handler () at targets/f7/furi_hal/furi_hal_interrupt.c:271
#2  <signal handler called>
#3  0x2000bf58 in Field::updateField() ()
#4  0x2000fdbc in Game::gameLoop() ()
#5  0x2000ecc0 in loop () at /home/kubuntu/Downloads/arduboy-flipper-test-source/HelloWorld.cpp:433
#6  0x2000f3d2 in test_app (p=<optimized out>) at /home/kubuntu/Downloads/arduboy-flipper-test-source/lib/arduboy2-flipper/main.cpp:47
#7  0x0804ae30 in flipper_application_thread (context=0x2000ecb9 <loop()>) at lib/flipper_application/flipper_application.c:224
#8  0x08012a5c in furi_thread_body (context=0x20009e28) at furi/core/thread.c:92
#9  0x08012a1a in furi_thread_catch () at furi/core/thread.c:63

stoic dawn Jan 11, 2024, 11:48 PM

#

yup, thats the same issue I had

viscid void Jan 11, 2024, 11:48 PM

#

updateField was the last function to be called but I'll break in gameLoop too

stoic dawn Jan 11, 2024, 11:48 PM

#

#3 and #4 have no associate source info, and you can't step through them

#

I commented out chunks of code until I found the crash, its specifically checkMarks() that is triggering some memory issue. But, without being able to really view details of the code as it runs through that function, its hard to see exactly why. And I don't know if its some C++ screwyness or what.

stoic dawn Jan 12, 2024, 12:12 AM

#

Yeah, in googling a bit, I think there is symbol mangling going on. I'm not familiar enough with that so I'll have to research more. But, I think I'm moving slowly in the right direction lol

viscid void Jan 12, 2024, 12:31 AM

#

Okay this program does not like to be debugged. The -O0 issue is specific to the Arduboy2.h header, I can use pragma to make the rest of HelloWorld.cpp -O0 just fine.

stoic dawn Jan 12, 2024, 12:32 AM

#

yeah, the -O0 issue is related to virtual functions I think. A bunch of things rely on Arduino write() that doesn't exist. So I gotta figure out how to rip that out

#

but with what I've been reading, I'm not sure that will help with this specific situation

#

basically, everything here in .text._ZN... is not correctly associating with a source location. Thats the reason for using extern "C" but, I don't yet have the correct incantation to prevent mangling

add symbol table from file "/home/karl/.ufbt/build/test_d.elf" at
    .text_addr = 0x2000b834
    .text._ZN4Game8gameLoopEv_addr = 0x2000c27c
    .text._ZN5Field9showFieldEv_addr = 0x2000b19c
    .text._ZN5Field13generateFieldEv_addr = 0x2000b514
    .text._ZN5Field11placeCountsEv_addr = 0x2000b424
    .init_array_addr = 0x2000cb74
    .text._ZN5Print5writeEPKc_addr = 0x2000c4f4
    .text._ZN5Field12getNeighborsEhhPP4CellPh_addr = 0x2000b2b4
    .text._ZN5Print5flushEv_addr = 0x2000a51c
    .text._ZN9CellQueue7enqueueEP4Cell_addr = 0x2000a63c
    .text._ZN5Field9initFieldEh_addr = 0x2000b0a4
    .text._ZN5Field11updateFieldEv_addr = 0x2000bfec
    .text._ZN5Field18floodFillNeighborsEhh_addr = 0x2000b5ec
    .bss_addr = 0x2000cbc4
    .text._ZN4Game13showResultBoxEb_addr = 0x2000c10c
    .data_addr = 0x2000cb0c
    .rodata_addr = 0x2000c554
    .text._ZN5Print17availableForWriteEv_addr = 0x2000a494

viscid void Jan 12, 2024, 12:43 AM

#

well the issue is clearly that the state property is unintialized in the Cell class object when it gets referenced in getState(). The question is, why

#

like modifying getState to

    CELL_STATE getState() {
        return HIDDEN;
    }

results in no issue

#

so it happens when the state property is accessed, I'm guessing it is NULL

#

which is why the FZ crashes with NULL pointer dereference

stoic dawn Jan 12, 2024, 12:46 AM

#

is it? I only have issues when updateField() calls checkMarks(), if I comment out that call, I see no crash anymore

viscid void Jan 12, 2024, 12:46 AM

#

return MARKED runs fine too btw

stoic dawn Jan 12, 2024, 12:47 AM

#

nothing shows on screen, thats definitely another issue to deal with, but, its still running

viscid void Jan 12, 2024, 12:48 AM

#

actually a game shows up when you have it return MARKED

#

but yea the issue is the access to the property of the state, so why isn't it being initialized when the object is created

#

oh I think I know why

stoic dawn Jan 12, 2024, 12:51 AM

#

I don't get anything else on screen when I modify getState to just return MARKED O_o

#

oh, I had to put checkMarks back in. Though, I get the "game over" screen, the box with the little clock icon

viscid void Jan 12, 2024, 12:57 AM

#

yep, that's what I get too

stoic dawn Jan 12, 2024, 12:57 AM

#

interesting

viscid void Jan 12, 2024, 12:58 AM

#

viscid void oh I think I know why

NVM for this, I tested if it was a dumb issue I've experienced in the past with memory management on the FZ and it wasn't (it really seems to care if you memzero)

#

or rather some programs assume memory is zeroed

stoic dawn Jan 12, 2024, 1:01 AM

#

FWIW I don't think ATMega guarantees RAM in any specific state, so I don't think the applications would assume that

#

So, question. Are you able to single step through, e.g. gameLoop or updateField, at source and not disassembly level? Or are you seeing the same thing where it shows no associated source?

If not, you don't seem to be as surprised about it as I am?

#

I'll come back to this later, wandering off for a bit

viscid void Jan 12, 2024, 1:19 AM

#

stoic dawn So, question. Are you able to single step through, e.g. gameLoop or updateField,...

Yeah I'm not single stepping a line by line basis for whatever reason

#

I'll see if I can get that fixed

#

I'm not surprised because I'm used to the BS that goes along with FZ apps lol. This absolutely should have worked, I never have to compile with -g to step through the code line by line or get variable info.

#

Something isn't playing well with that

stoic dawn Jan 12, 2024, 1:22 AM

#

I’ve never had this issue either. Which is why I think it’s something specifically thanks to c++ and not necessarily flipper related

#

I can step through disassembly, but I don’t want to lol

viscid void Jan 12, 2024, 1:25 AM

#

I think I know what the issue is with the debugging of this app

#

I don't have any issue single stepping or dumping variables in the Arduboy2 library, that works fine

#

its an issue with the compilation of HelloWorld.cpp

stoic dawn Jan 12, 2024, 1:28 AM

#

yup, its only some of the functions in there

#

and like I noted above, it seems to be only the mangled symbols that don't have source associated with them

#

also, I wandered off for a whole 20 minutes lol

#

just as an FYI, that code can be built in arduino and run on an arduboy (at least the emulator) without issues. So whatever fault happening is related specifically to F0 or the Arduboy2 libraries WIP

stoic dawn Jan 12, 2024, 5:48 AM

#

I'm getting nowhere with this. After going back and forth with some others, I'm going to try wiring up my jlink and see if its the same issue or different issue in terms of not being able to step through code

viscid void Jan 12, 2024, 3:38 PM

#

this might be a bug

#

in the build tools/fbt

viscid void Jan 12, 2024, 4:03 PM

#

worst case scenario, fap_extbuild in application.fam maybe?

#

this is a good question for hedger imo, its a bug as far as i can tell. even just inserting breakpoints at certain locations causes it to crash

viscid void Jan 12, 2024, 4:12 PM

#

stoic dawn <@548357534994399237> Let me know if you find anything interesting

@frail tapir is there a bug in how debug info is embedded in this executable by ufbt? HelloWorld.cpp can't be debugged properly

stoic dawn Jan 12, 2024, 10:33 PM

#

At this point, I think I agree. I've tried the wifi devboard, jlink, and an openocd ftdi debugger all to the same result. So its not an issue with blackmagic's gdb server. I still feel like I'm missing something silly in the code itself, but I have no idea what at this point.

stoic dawn Jan 12, 2024, 11:39 PM

#

A friend noticed that, all of the functions that have this issue, are weak symbols:

.\dist\debug\test_d.elf:00000435 T Arduboy2Core::flipper_input_cb(void const*, void*)   C:\...\.ufbt\current\scripts\ufbt/C:\...\Downloads\arduboy-flipper\arduboy-flipper-test-source\lib\arduboy2-flipper/Arduboy2Core.cpp:483
.\dist\debug\test_d.elf:00000001 W Game::showResultBox(bool)
.\dist\debug\test_d.elf:00000001 W Game::gameLoop()
.\dist\debug\test_d.elf:00000001 W Field::placeCounts()
.\dist\debug\test_d.elf:00000001 W Field::updateField()
.\dist\debug\test_d.elf:00000001 W Field::getNeighbors(unsigned char, unsigned char, Cell**, unsigned char*)
.\dist\debug\test_d.elf:00000001 W Field::generateField()
.\dist\debug\test_d.elf:00000001 W Field::floodFillNeighbors(unsigned char, unsigned char)
.\dist\debug\test_d.elf:00000001 W Field::initField(unsigned char)
.\dist\debug\test_d.elf:00000001 W Field::showField()
.\dist\debug\test_d.elf:00000541 T Print::printNumber(unsigned long, unsigned char)     C:\...\.ufbt\current\scripts\ufbt/C:\...\arduboy-flipper\arduboy-flipper-test-source\lib\arduboy2-flipper/Print.cpp:203

No clue how or why, they shouldn't be, nothing is defining them as weak. Not sure if that is relevant here or not either, but, its strange.

viscid void Jan 13, 2024, 2:05 AM

#

Interesting!

viscid void Jan 14, 2024, 9:16 PM

#

idea: add -g to CXXFLAGS that fbt/ufbt uses in scons

stoic dawn Jan 14, 2024, 9:22 PM

#

I got it compiling with ‘-g -O0’ and still the same gdb issues. I put it down for a bit after spending most of a day trying different debuggers and such. Started messing with a different arduboy game in the meantime. One that has a bunch of physics stuff. It so far runs, but not quite right.

#

Using -O0 caused an unknown symbol of __cxa_pure_virtual. I added that func in to code and just made it so a while(1) for testing. It ran, but, still same gdb nonsense

frail tapir Jan 19, 2024, 8:34 PM

#

can you give precise repro steps?

#

I'll see if that can be fixed. C++ code is tricky, it creates a crapton of sections when using the way we link executables. And they have to be loaded separately

viscid void Jan 19, 2024, 8:39 PM

#

#1190430159627620502 message using this project, set debug mode on the Flipper, compile the project with ufbt and launch it, then try setting a breakpoint in most any line of HelloWorld.cpp (such as line 452, the justPressed down button)

#

you'll not only not be able to hit that breakpoint, but you can't read the content of the variables in most of the function (including the rest of the functions in the file, which it executes and no breakpoints are executed)

#

sometimes I set breakpoints and the Flipper crashes while it is paused

#

only for that file, HelloWorld.cpp

#

@frail tapir let me know if this is detailed enough, neither bunni nor I can debug the file so I believe we've eliminated environment issues from the probable causes

#

(also - single stepping over lines is broken as well)

#

single stepping through instructions works

frail tapir Jan 19, 2024, 8:49 PM

#

regarding __cxa_pure_virtual - we'll add a stub for it with upcoming toolchain upgrade

#

https://github.com/flipperdevices/flipperzero-firmware/pull/3254/files#diff-1e56f3c9ad3c279942b264469af64d5aa01283662cef0062c973e28f06c89d0bR1

#

well, I crashed on
// furi_assert(context);
in void Arduboy2Core::flipper_input_cb(const void* value, void* context), because it's set up with NULL context

viscid void Jan 19, 2024, 9:00 PM

#

were you able to set breakpoints and line step?

frail tapir Jan 19, 2024, 9:01 PM

#

kinda, but crashed on new game

#

I'm also using dev firmware SDK. Because - it's not that obvious - apps inherit optimisation flags from the SDK

#

release & RC are built with debugging support off and extra optimisations, and dev firmware is not

viscid void Jan 19, 2024, 9:03 PM

#

I didn't know that! I'll try using the dev SDK a bit later

frail tapir Jan 19, 2024, 9:04 PM

#

inspect works, but stack navigation is borked. Looking into it

viscid void Jan 19, 2024, 9:06 PM

#

@stoic dawn looks like hedger found out why we couldn't debug HelloWorld.cpp clap

#

wrong ufbt release channel

stoic dawn Jan 19, 2024, 9:13 PM

#

oh snap!

viscid void Jan 19, 2024, 9:14 PM

#

I have my FZ set up here, just trying to change the channel to test it

stoic dawn Jan 19, 2024, 9:14 PM

#

I don't think I tested dev with fbt, but I definitely tested release ufbt and fbt to end up wit the same issue

viscid void Jan 19, 2024, 9:15 PM

#

ufbt update --channel dev

stoic dawn Jan 19, 2024, 9:15 PM

#

cool. I'll probably spin back up on this shortly then party

viscid void Jan 19, 2024, 9:17 PM

#

should know in a sec if breakpoints work. running the app now

#

scons: *** [/home/kubuntu/.ufbt/build/test.impsyms] /home/kubuntu/.ufbt/build/test.fap: app may not be runnable. Symbols not resolved using firmware's API: {'__cxa_pure_virtual'}

Looks like we need that new toolchain

frail tapir Jan 19, 2024, 9:18 PM

#

validating section addresses atm

#

void __cxa_pure_virtual() {
    furi_crash("C++ pure virtual call");
}

just add that at the top of the file

stoic dawn Jan 19, 2024, 9:20 PM

#

So wait, still sounds like there are stack issues?

frail tapir Jan 19, 2024, 9:24 PM

#

some sections are not recognised by gdb. investigating

viscid void Jan 19, 2024, 9:47 PM

#

Debugging is still broken

stoic dawn Jan 19, 2024, 9:47 PM

#

Yeah, sounds like that is still being looked in to

viscid void Jan 19, 2024, 9:50 PM

#

I can't break on this line:

        if(arduboy.justPressed(DOWN_BUTTON) && selector < 2) {

line stepping takes me all over, and sometimes the breakpoints crash the FZ

#

the good news is, the stub did resolve the imports issue

frail tapir Jan 19, 2024, 9:56 PM

#

yep, something's not adding up. Now I more or less consistenly crash on app load, when calling .init section

#

before, I could get to the menu

stoic dawn Jan 19, 2024, 10:03 PM

#

I love bugs that make no sense 😄

stoic dawn Jan 23, 2024, 7:56 PM

#

hedger, I'm curious if you have any more datapoints on this or have made any headway on getting something like this working? As much of a mess as it is, I'm happy to open up the repo I'm working with if it would help. I've not changed much since the tarball above though. Toolchain issues are not in my wheelhouse, unfortunately.

stoic dawn Jan 29, 2024, 7:50 AM

#

I've started playing with a different game that I've got as a WIP, https://github.com/jonthysell/ArduLO Same issue with as with sprites, but the bitmaps also need some bit swizzling it looks like. But also, it looks like its actually debuggable. So, something with how that previous "HelloWorld.cpp" was being compiled just wasn't giving the debugger any happiness.

Should have a demo of this in the next few days. I'm also going to start cleaning things up to get ready to at least make it public. But need to separate out some of the library stuff first.

pure siren Jan 29, 2024, 11:21 AM

#

gcc doesn't have a novtable equivalent, right? That'd save some code space because if you have interfaces they're getting method tables with pure vcall stubs that are unreachable

#

msvc compiler can skip emitting those useless vtables, would be nice if gcc can too

#

Nope it doesn't seem to be a thing, there is only -fdevirtualize

#

-Os implies devirtualize so the generated output probably already benefits from that, alongside disabled rtti

stoic dawn Jan 30, 2024, 7:27 AM

#

Okay! Back on track with more graphical work. ArduLO is a bit easier to work with so far. There is some sprite cutoff but its actually playable. This uses a handful of Arduboy library functions so it will be a good exercise in getting more support together.

FAP is built for current dev, API 52.0

📎 test.fap

#Arduboy Source Compatibility Library