Closed vortigont closed 1 year ago
I've updated the PR, added dependent c functions, adjusted legacy code. Now it builds fine.
BTW, I was unable to locate ArduinoOnPc-FastLED-GFX-LEDMatrix/examples/NeoMatrix-FastLED-IR
dir to do test build, is it missing in this repo?
Many of the other examples are failing to build with error:
libraries/FastLED_RPIRGBPanel_GFX/FastLED_RPIRGBPanel_GFX.h:29:10: fatal error: led-matrix.h: No such file or directory
I was able to build some of the tft examples though :) like examples_orig_tft/Flappy
Let me review this in a little bit, but to answer your questions 1)
sauron:~/arduino/emulation/ArduinoOnPc-FastLED-GFX-LEDMatrix/examples/NeoMatrix-FastLED-IR$ git remote -v
origin git@github.com:marcmerlin/NeoMatrix-FastLED-IR (fetch)
origin git@github.com:marcmerlin/NeoMatrix-FastLED-IR (push)
It is a sub tree, not part of the tree you have. It's pretty big piece of code that relies on more stuff, and the main reason why I have ArduinoOnPc-FastLED-GFX-LEDMatrix. See https://marc.merlins.org/perso/arduino/post_2023-05-17_Party-LED-Outfit-Version-5_5_-Flexible-P15-LED-Strings_-LED-Fanny-Pack_-Rez-Inspired-LED-Goggles_-LED-Laces-and-LED-Shoes.html
2) FastLED_RPIRGBPanel_GFX/FastLED_RPIRGBPanel_GFX.h relies on sauron:~/arduino/emulation/ArduinoOnPc-FastLED-GFX-LEDMatrix/rpi-rgb-led-matrix$ git remote -v origin https://github.com/hzeller/rpi-rgb-led-matrix/ (fetch) origin https://github.com/hzeller/rpi-rgb-led-matrix/ (push) This allows changing the emulated linux framebuffer with an RGBPanel framebuffer run on rPi, which again was the end goal of the project mentioned above
3) But you seem to be hitting some problem, the rPi code should not be happening if you build on linux/PC/Mac/anything but Rpi. Are you using linux on rPi by any chance? Have a look at sauron:~/arduino/emulation/ArduinoOnPc-FastLED-GFX-LEDMatrix/examples$ less neomatrix_config.h
#if defined(ARDUINOONPC)
// Those defines (including RPIRGBPANEL) come from makeNativeArduino.mk
#if defined(RPI4)
#pragma message "Detected ARDUINOONPC on rPi4, RPIRGBPANEL defined and will use FastLED_RPIRGBPanel_GFX"
#elif defined(RPI3)
#pragma message "Detected ARDUINOONPC on rPi3, RPIRGBPANEL defined and will use FastLED_RPIRGBPanel_GFX"
#elif defined(RPILT3)
#pragma message "Detected ARDUINOONPC on pre-rPi3, RPIRGBPANEL defined and will use FastLED_RPIRGBPanel_GFX"
#else
#ifndef LINUX_RENDERER_SDL
#pragma message "Detected ARDUINOONPC. Using LINUX_RENDERER_X11 FastLED_TFTWrapper_GFX Rendering"
#define LINUX_RENDERER_X11
#else
#pragma message "Detected ARDUINOONPC. Using LINUX_RENDERER_SDL FastLED_NeoMatrix Rendering."
#pragma message "Comment out LINUX_RENDERER_SDL for X11 rendering instead of SDL. Use + for brighter."
#endif
#endif
#endif
On linux you want LINUX_RENDERER_SDL which should auto select unless you are on rPi. If that's the case, you can force LINUX_RENDERER_SDL anyway and make sure you have the SDL linux libs installed.
Does that help? The tree is a lot more useful if you are using SDL output, unless your code isn't 2D display related.
I tested your new branch with my own build on linux and it worked fine. Merging. Please do review my previous comments/answers, I hope they explain how I use this code, and what all the directories do, hopefully you can get some 2D example to display without the TFT backend but with the SDL backend.
If you are on linux/amd64, try this ./NeoMatrix-FastLED-IR binary, you can play with 'n', and 'p', or 3 digit numbers + enter, or a bunch of other keys defined in the code NeoMatrix-FastLED-IR.gz
that makes more sense now, thank for the examples. Actually I was trying to build examples from this repo "as-is", i.e. git clone && cd examples/blah && make
I run in on PC linux, not rPi. Without going into NeoMatrix-FastLED-IR
subtree.
With a bit of hacking and with a bit of Makefile and .h hacking SDL works fine for some of my demos.
Mmmh, I'm glad you got it working, but it should "just work" if you build on linux/PC. Do you mind checking neomatrix_config.h and #ifdefs to see why they aren't doing the right thing for you? The top magic is supposed to just make things work with SDL by default on linux
@vortigont also if you have your own 2D demos you'd like to contribute, you can submit them to https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos
which is a submodule of this project and you or I can add a symlink tree for those new demos to this tree since it's mostly just a shell to build existing code from other arduino modules, on linux.
Relatedly, if you haven't tried it, debugging arduino code on linux with gdb or even just the memory leak checker, is sooo much faster
Hey, Marc! I'm not making funny demos actually. I mostly concentrate on lib development and core app. Have a project "FireLamp" that runs various demos on LED matrixes and work my way coding around that area. It has many demo "effects" mostly contributed or collected from other open projects around. I've wrapped it all in a nice c++ classes and developing an engine to control and work with it. Still not tried debugging on PC, mostly use it for templates validation and compute testing
Just in case you might be interested I'm developing a lib LedFB, a kind of same ideas as yours Framebuffer_GFX
but having more abstracted interface based on inheritable classes and templates.
It's still in the early development, so no docs or examples yet. But as of now I was able to implement the following features
graphic interfaces like adafruit are to come, along with other things like text blocks and layers, etc... Have no rpi's available at the moment, but thinking about getting one for a more easy and faster development. BTW how good is ws2812 support on rpi? Never tried it actually. Have tried to run HUB75 matrixes long ago on rpi, though.
P.S. I've opened a Discussions for LedFB. Anytime welcome!
Thanks for the details @vortigont before I respond to the rest, did you find out why my examples don't just build and work with SDL on linux for you, when they do for me? What patches/changes did you have to make?
@vortigont for rPi questions
1) last I checked WS2812 support on rPi is ok-ish, but given that it's not a realtime OS, I'm not sure how reliable it is. Also since those pixels cost a lot, having so many that it wouldn't fit on an ESP32, isn't really an issue I've ever had :)
I know there are add-on boards that do realtime driving of those pixels, but I think effectively they use a small ESP like MCU to drive them :)
2) I switched to rPi for RGBPanels because ESP32 tops out at 64x128 with SmartMatrix. With the newer I2S libs, how many pixels can you drive on ESP32? With rPi and 3 channels, I can do about 384x256 with 3 parallel channels, that's the only reason I went to rPi and wrote this lib you are now using (to keep my same arduino code but run it on rPi) https://marc.merlins.org/perso/arduino/post_2020-03-13_RGB-Panels_-from-192x80_-to-384x192_-to-384x256-and-maybe-not-much-beyond.html
As for your comment on 0 copy, I believe both my WS2812 is 0 copy, is it not?
https://github.com/marcmerlin/FastLED_RPIRGBPanel_GFX/blob/ec1ac0b8c436da7c087f6bc218de7403334ae6c2/FastLED_RPIRGBPanel_GFX.cpp#L25 isn't but running on a CPU so fast that I just didn't bother spending the time.
RGBPanel with SmartMatrix is 0 copy also https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/blob/e97beb41a2b129ec0205a2bf689b4e63c30cec36/neomatrix_config.h#L459
@vortigont hi. I just found out this broke me slightly by having 2 conflicting pgmspace.h files. I added this patch to solve the problem on my side https://github.com/marcmerlin/ArduinoOnPc-FastLED-GFX-LEDMatrix/commit/52af8fdbf974fadfa5914391f5bc30dfa19f8815
mmmh, now another problem in compiling my code after I pull in your update:
In file included from /root/ArduinoOnPc-FastLED-GFX-LEDMatrix/src/main.cpp:13:0:
/root/ArduinoOnPc-FastLED-GFX-LEDMatrix/examples/NeoMatrix-FastLED-IR/NeoMatrix-FastLED-IR.ino:1567:36: error: reference to ‘map’ is ambiguous
matrix->setPassThruColor(Wheel(map(x, 0, len*fontwidth, 512, 0)));
^~~
In file included from /root/ArduinoOnPc-FastLED-GFX-LEDMatrix/src/main.cpp:12:0:
/root/ArduinoOnPc-FastLED-GFX-LEDMatrix/src/cores/arduino/Arduino.h:71:6: note: candidates are: long int map(long int, long int, long int, long int, long int)
long map(long, long, long, long, long);
^~~
In file included from /usr/include/c++/6/map:61:0,
from /root/ArduinoOnPc-FastLED-GFX-LEDMatrix/rpi-rgb-led-matrix/include/graphics.h:15,
from /root/ArduinoOnPc-FastLED-GFX-LEDMatrix/rpi-rgb-led-matrix/include/led-matrix.h:32,
from /root/ArduinoOnPc-FastLED-GFX-LEDMatrix/libraries/FastLED_RPIRGBPanel_GFX/FastLED_RPIRGBPanel_GFX.h:29,
from /root/ArduinoOnPc-FastLED-GFX-LEDMatrix/examples/NeoMatrix-FastLED-IR/neomatrix_config.h:968,
from /root/ArduinoOnPc-FastLED-GFX-LEDMatrix/examples/NeoMatrix-FastLED-IR/nfldefines.h:32,
from /root/ArduinoOnPc-FastLED-GFX-LEDMatrix/examples/NeoMatrix-FastLED-IR/NeoMatrix-FastLED-IR.ino:36,
from /root/ArduinoOnPc-FastLED-GFX-LEDMatrix/src/main.cpp:13:
/usr/include/c++/6/bits/stl_map.h:96:11: note: template<class _Key, class _Tp, class _Compare, class _Alloc> class std::map
class map
^~~
../../makeNativeArduino.mk:131: recipe for target 'build//root/ArduinoOnPc-FastLED-GFX-LEDMatrix/src/main.o' failed
make: *** [build//root/ArduinoOnPc-FastLED-GFX-LEDMatrix/src/main.o] Error 1
make: *** Waiting for unfinished jobs....
This didn't happen on linux/intel when I tested before merging your code, it's only happening on linux/avr...
I'll see if I can figure out what's happening, but pasting here for reference
mmmh, so doing more research it seems to be that g++ on my Rpi3 is too old and incompatible with the newer files you submitted. Given that, I'm going to leave this commit alone even though it broke me (and hopefully no one else) and look at upgrading all of raspbian (just updating g++ is not a reasonable option in that install)
Hi @marcmerlin!
I saw this before. This is due to ugly Arduino's map()
prototype, it so unwise to declare such a common function name in main Arduino's header. But this is what we get for decades already.
I traced it down to this string https://github.com/marcmerlin/NeoMatrix-FastLED-IR/blob/da6fcead6c110d1a48c1fe5a1e0618da658d03f1/Aiko/AikoEvents.h#L9
It' better to never import namespaces in .h
headers but only in .cpp files to avoid such naming clashing.
Need to remove it and fix following code to prefix required objects with std::
where it is required.
thanks @vortigont , yeah, I've been bisecting things more to see what on earth broke and didn't know about what you just found, especially since aiko was written by a friend of mine and I just imported it. I'll have a look at your suggestion, thanks
welcome! You never know where some 3rd party lib could affect your code through another gap in some else one's code :)
A more recent implementation of String() class. Existing one is really old, it misses some methods, like a simple
isEmpty()
. I took source files as-is from esp32 package since it has stubs forFlashStringHelper
and PGM types functions, which does not makes sense on x86 anyway.