Laserline for LilyGo T-Display S3 #427
Replies: 5 comments 17 replies
-
|
Welcome, @SeanMcKeen. All the pieces SHOULD be there. I think I just laid out the plans at #428 I don't know much about laserline (if you do, please submit a PR adding it to the comment block at the top of platform.ini and maybe README.md - maybe we need another section there for UMBRELLA, LANTERN and other things that are effects combinations layered atop DEMO. but I think you'll need a few changes. platformio.ini probably needs a new block that's something like: ; LILYGO T-Display-S3 Laserline Now if this (or something like this) works, please submit a PR to enable it for the next person. If it doesn't work, we'll figure it out. The power of determined people willing to hit-and-miss something should never be underestimated! I don't have that exact board, but I have ones that are pretty similar. Using the map I (tried to) lay out in #428, I see in src/effects.cpp that the -DLASERLINE builds an effects table of exactly one effect, that it's a strip effect (so I assume I can replicate it with some set of the bazillion 2811/2812's i have) and that the arguments passed to the constructor are 500 and 20. So looking in include/effects/strip/laserline.h we see it "Sound reactive laser "shot" that travels down a strip" (ah, yes, I think I have seen some videos on this; it also served as a lesson on voltage sag...) so it'll be built with speed of 500 and a size of 20. Sounds reasonable. This information is totally contradictory to the #elif LASERLINE case in include/globals.h, so also as part of your initial It catches my eye that this effect is setting the LED pin Now if your board has GPIO pin 32 available, there's no real shame in just attaching your strip of 700 (MATRIX_WIDTH) LEDs there and rolling with it. HOwever, looking at https://www.lilygo.cc/products/t-display-s3 - it seems highly unlikely that it's on 32. So is this a valid, tested, working combination that someone submitted or is it copy-pasted from other config that's never actually worked? I can't see it on https://github.com/Xinyuan-LilyGO/T-Display-S3-AMOLED/blob/main/schematic/T-DISPLAY-S3-AMOLED.pdf. So finding an appropriate GPIO pin is up to you. Not knowing the board, I'd start researching in the pink block of 16-43 in the upper right. The .ini file says that the buttons (onboard buttons? Buttons you wire up?) should be on GPIO pins 37 and 39, but there's nothing in laserline.h that sets event handlers for buttons. Unless you know that laserline has/needs/uses buttons, please just delete those lines in that hunk. The following two lines for NUM_INFO_PAGES and ONSCREEN_SPECTRUM_PAGE seem like they should depend on what you're building ON (LILYGOTDISPLAYS3) and not what effect you're building. Since we're turning off USE_SCREEN above (at least for now) that has no chance of working in this configuration. I'm unconvinced so far they work on any hardware for this effect, but they're probably harmless for now. Wait, the schematic shows you DO have two buttons: one on GPIO0 (after boot) and one on GPIO21. But LAsERLINE doesn't seem to use buttons, so let's keep ignoring them for now. You said you're not experienced, so I'll over-explain this since it's a bit more than copy-paste. This means "if it's not set elsewhere, use PIN0 (the default pin we put blinkies on) to 32. That'll let it keep working for whomever wrote this. Now tweak your newly created entry in platform.io to include This moves the hardware defines into the places that are choosing hardware-specific things and keeps it out of the pattern-specific stuff. It'll keep working the same for everyone not using your new board. Now, however, we've now declared "For T-Display S3, the first blinky pin shall be 321". If there's anything ELSE that builds for T-display-s3, and it strongly insists on #define LED_PIN0 something-else, the choice is to add a similar #ifndef bracket around the code that's about to start whining OR just accept their choice of LED_PIN0 and move your wire from 321 to whatever THEY chose. It's all a bit of a dance in this project, I'm afraid. Having an active developer in this project with this board will help defend others from breaking it, so welcome to your new role as T-D S3 maintainer, unless it's already filled. :-) Now for the bonus round: the question you didn't ask! Obviously, a major effect of that board is the display. Nothing in this configuration tries to turn it on. There are a couple of different boards from LilyGo with that approximate name. (AMOLED? "old and new" LCD, etc.) Depending on the exact board you have, this might get a bit involved. The good news is that there are other projects (Adafruit Feather, Panlee) that run similar displays (7796, 7789) all through the excellent Bodmer TFT library. The TTGO board links with https://github.com/Xinyuan-LilyGO/TTGO-T-Display, but I can't tell if that works with your board or not. Those boards all seem to use SPI to talk to the board, but the schematics looks like it's using parallel, so we'd have to define all the pins individually and then tell Bodmer TFT how to hook to it. You can look in platformio.ini for ledstrip_feather and see the USE_SCREEN through SPI_FREQUENCY or so to see the approximate type of configuration we may have to set up. For env:panlee see USE_SCREEN through SMOOTH_FONT for inspiration. If the setup really is parallel instead of SPI, we'll have to define all the data bits, select, clock, and such. It's just drudgery to work through it all. I'm sure it's possible. Depending upon your experience level and determination, it could range between easy and frustrating. Just this weekend, I discovered I have a similar ESP32-S3 board that has an integrated 7789 and LCD, so it's possible that in upcoming weeks, I'll refine my own expertise in this general area. It's likely to be as annoyingly different to your boards as the existing boards are to yours. I'm not really sure how much is to be gained by setting it all up. I haven't seen screenshots of those devices while running NightDriverLED or given src/screen.cpp much more than a skim. Mirroring the Mesmerizer display would be cool, but I can't ttell that the code is even trying to do that offhand. Let's get your strip blinking first. Give that a try and see if we can get there and THEN decide if the LCD thing isimportant to you. |
Beta Was this translation helpful? Give feedback.
-
|
Wow! Lots of information, I honestly did not expect such a detailed response especially in such a short amount of time. I appreciate this a lot! I managed to get the program to build, but upon upload I am given a BUNCH of errors, and unfortunately I have no CLUE how to fix any of them. When I said I'm inexperienced I really mean it lol. The big error I understand is that in clockless_rmt_esp32.h it throws the error "static assertion failed: invalid pin specified [Ln 358, Col 46]" It seems simple to understand, but when trying to find when that "DATA_PIN" would be defined to something wrong, I am unable to. I think you mentioned finding out what my GPIO is, it's 21, or that's what I have my LED strip attached to. The other errors it throws are as follows: *** [.pio\build\lilygo-tdisplay-s3-laserline\src\colordata.cpp.o] Error 1 I assume this is because the build failed earlier on and just couldn't continue through these files Everything else are just warnings so I wont bother you with that. Thank you for all of your help so far. |
Beta Was this translation helpful? Give feedback.
-
|
@SeanMcKeen What do you mean when you say that you got "the program to build"? I'm asking because these are clearly compile-time errors - the actual upload follows after that. I'll spare you a discussion of the whole chain that leads to the static assertion failure, but bottom-line it indicates that To short-circuit this a little bit, would it be possible for me to look at the exact platformio.ini and globals.h you are now working with? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, my mistake, I had gotten it to build before just using "laserline" because I hadn't changed it yet, and then forgot to try to build it again and just tried uploading. That probably doesn't make sense but the errors were from the lilygo-laserline, so I'll just continue with that. Not sure if you wanted code snippet or the file, but since it wont let me upload the files themselves I'll include a text file of it because I just learned the code snippet does not work very well |
Beta Was this translation helpful? Give feedback.
-
|
This works for me. :) It looks to me like you implemented half of the suggestion @robertlipe made, that being the change to globals.h. However, the change to platformio.ini to actually pass on the correct value for Personally, to get started I would just change what is now line 451 in your globals.h to However, if you prefer to follow Robert's advice then the way to go about that would be to add one line to the [env:lilygo-tdisplay-s3-laserline]
extends = dev_lilygo-tdisplay-s3
build_flags = -DLASERLINE=1
-DENABLE_WIFI=0
-DUSE_SCREEN=0
${dev_lilygo-tdisplay-s3.build_flags}to [env:lilygo-tdisplay-s3-laserline]
extends = dev_lilygo-tdisplay-s3
build_flags = -DLASERLINE=1
-DENABLE_WIFI=0
-DUSE_SCREEN=0
-DLED_PIN0=21
${dev_lilygo-tdisplay-s3.build_flags}The line that's added thus being the |
Beta Was this translation helpful? Give feedback.
-
|
I think I can contribute, what is hopefully, clarifications on some of @robertlipe comments above. LASERLINE should work with a WS2812 strip as long as 1000, the caveat is having enough 5v power injected at the beginning and end of the strip to drive a strip that long. A strip of 700 long is more power conserving and is how my copy of NightDriverStrip code is setup for. But, as @davepl mentions in his YT Laser Cannon video, you can use any strip length you want because shorter length strips the serial data sent down the strip that doesn't have a "receiving" RGB LED just falls off into the void of time. The LASERLINE code runs fine with my unique WS2812B strip configuration that has only 84 LEDs with no code adjustment. The only thing that I noticed is that the serial data stream time needed for 700 LEDs in the strip results in an audio delay "dead spot" that occurs until a new serial data stream can be transmitted in reaction to a new audio trigger. My first "tweak" of the LASERLINE code is to shorten the NUM_LEDS to 84 which is my modest project LED length. I'll stay away from any comments on LCD matrix display challenges as I'm a newbie to this but have a general understanding of writing to pixels. I'll be happy to help @SeanMcKeen with his lilygo board (is it the T-display S3?) getting LASERLINE working. As @robertlipe said, getting the GPIO pin variable set right as well as your ESP32 board type. |
Beta Was this translation helpful? Give feedback.
-
|
Nice. That video helps explain some of the strip project names. I'd never run that effect and never really chased it, but I've always assumed "laser line" was associated with laser line levels. We really should make a section in README.md that explains all these various effect types, perhaps with links to time sections in that video. (Might be worth some extra clicks for someone. :-) ) Some day, we should have a discussion and subsequent batch of changes (both of which I'm willing to lead...) about name consistency. Maybe we should have DEVICE_ELECTOW and DEVICE_M5STICK running EFFECT_LASERLINE (or EFFECT_LASERCANNON) and a divorce ot TTGO between DEVICE_TTO and EFFECT_TTGO and maybe push RING and FAN into EFFECT_LASERCANNON_RING and so on. We should probably have some base effects that are common enough that we try to make them work out of the box for new people and mark that some effect blocks (UMBRELLA, BELT, FANSET, probably others) that are going to depend very much upon the hardware of a custom build. But let's just think about this paragraph for now, even if it's to think about how much you hate long names. :-) If you have a working board in hand for M5StickC (family), what do you think about moving LED_PIN0 to [dev_m5stick-c] to platform.ini and getting rid of the #if M5STICK/#define LED_PIN0 stuff in config.h? It's just confusing to users (this weekend, we've had two different potential devs run ashore with this) to have the #defines in multiple places and it's even worse as things grow. (I have two totally new board configurations on the loading dock...) I think it's quite reasonble to expect someone physically attaching a wire to a BOARD to look at the BOARD configuration place (and only one place, please) instead of in the effect configuration place. This is a change I think is sane (important, even) to make now. MAYBE, we have to Between my remarks above and the third para here, can you code that up and submit a PR? I can help with this, but I don't have those boards. I don't think any of us has them all - even those of us that can probably fill a 5 gallon bucket with our various dev boards of approximately similar types, but for different processors. Lipe Pro Tip: use the "search symbol" in the right of the GitHub code browser to find every place in the source tree that a symbol is used. e.g. M5STICKCPLUS It's worth a disclaimer that the actual project owners may totally hate all of this and reject it, but they're usually receptive to changes that should improve the unboxing experience for more users that's a result of carefully reasoned design. I'm pushing it a bit asking you to do the work (it's like, a dozen lines....) when I can't actually accept it. But I think it's reasonable to have ONE consistent place where decisions like this are made in the code. |
Beta Was this translation helpful? Give feedback.
-
|
RE: Lipe Pro Tip - great idea, very useful. Now, why isn't this type of search available in PlatformIO projects??? |
Beta Was this translation helpful? Give feedback.
-
|
No idea. I don't use the IDE part. My decades have taken me to sublime, language server, and ack https://beyondgrep.com/ ... but my personal toolbox is admittedly not for everyone. - and if you use ack here, constrain the search to src and include or else it wanders into dozens of copies of libraries that it squirreled away inside .pio/ . |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate this a lot, thank you for the summarization, both of you made me understand what's going on a lot more. |
Beta Was this translation helpful? Give feedback.
-
|
@SeanMcKeen thanks for letting us know, Glad it was helpful. |
Beta Was this translation helpful? Give feedback.
-
|
Tonight I got "demo" to work with my M5StickC Plus, 84 LED strip. (yea!) |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. The default brightness is face-melting bright from some bulbs. I've considered adding a ramp-up to fade them in on startup so it's not like flashgun in the eyeball when booting in a lab or portable environment. I do some of my testing with the BTF 2812b "fairy" strands because they're 5V, they aren't bright/hot and because 50 of them will stay coiled in a roll about palm sized. Nice for testing. $9 https://www.btf-lighting.com/collections/ws2812b-string-5v (I gambled on other fairy lights that look very similar, but are not 2812s. They'll get gifted...) I'll confess when I'm working on a 2812 change, I'm never certain which knob actually sets the brightness and as slow as the build is, I just blindly stab at them all and turn them all down by half or more. One of the few button pairs that's on most remote is brightness and it's the one most strongly labeled inside the code as controlling... something besides brightness. (They change the effect.. ,🤷♂️) if you can find authoritatively which setting controls brightness, I'll help get it landed in the doc and maybe make it more. Consistent in gloanss.h. The inconsistent naming is a problem. I've floated a few proposals trying to get some feedback or buy-in, but it looks like the preference is to just go build it and maybe it'll be accepted and maybe not. I may do that anyway, so feedback is welcome. |
Beta Was this translation helpful? Give feedback.
-
|
I've only used Adafruit's NeoPixels or BTF's WS2812Bs which are basically the same 5V coiled strips. All of my reorders have been from BTF. I only have one IR remote that came with the SP106e LED Music Controller and is laughable but works as intended with the SP105e. I'll let you know where I find brightness settings. In laserline.h its on line 63 in the CHSV construct's 'is' parameter |
Beta Was this translation helpful? Give feedback.
-
|
I like BTF. Current view. https://photos.app.goo.gl/u7iZL7UbVFYq3nQC8 (more over---> there) 🤪 I'd bet you could use that remote once you add the receiver. Find that chap that wired one up this weekend or so to confirm if it needs a pull-up (or just web search that) then enable it in the code and wire it up. Note the "unknown key code" errors when you stab buttons then add those codes to the switch in remote*cpp. |
Beta Was this translation helpful? Give feedback.
-
|
Well, the IR receiver is already "added" and active in the M5StickCPlus. The rest of your suggestion is beyond my pay grade right now. |
Beta Was this translation helpful? Give feedback.
-
|
I found my 1838 IR receiver which works from 2.7 to 5.5v, so 3.3v is the sweet spot. Connecting it will be easy for 3.3v operation on the M5StickC Plus. I'll probably go with GPIO 26 on the 8-pin header. I looked at an Uno IR.h library and see better how their outputs button values are defined, read and interpreted. Now I'm looking at the remotecontrol.cpp file. Thanks again for the pointers. |
Beta Was this translation helpful? Give feedback.
-
|
You're overcomplicating things. Attach it, set the #define for
IR_REMOTE_PIN to 28, rebuild, reflash, and go.
When the RX pin sees a valid key press, it should hit the debug print at
the top
debugV("Received IR Remote Code: 0x%08X, Decode: %08X\n", result,
results.decode_type);
You'll get 8 digit numbers. When they match the codes in
include/remotecontrol.h, it'll do the things.
In my tree, it's more selective about letting globals.h pick up the include
for rc.h so I don't have to rebuild the entire project when I change rc.h.
But that falls into the "if you see code that works, but isn't the way you
like it, leave it alone" rule, so I've not submitted fixes for that...
…On Mon, Sep 18, 2023 at 10:25 PM aldengaw ***@***.***> wrote:
I found my 1838 IR receiver which works from 2.7 to 5.5v, so 3.3v is the
sweet spot. Connecting it will be easy for 3.3v operation on the M5StickC
Plus. I'll probably go with GPIO 26 on the 8-pin header.
I looked at an Uno IR.h library and see better how their outputs button
values are defined, read and interpreted. Now I'm looking at the
remotecontrol.cpp file.
Thanks again for the pointers.
—
Reply to this email directly, view it on GitHub
<#427 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD32KKTNL7LXTWEYHLPTX3EGBLANCNFSM6AAAAAA4WR2EAE>
.
You are receiving this because you were mentioned.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/427/comments/7041228
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I simply do not know where to add #define IR_REMOTE_PIN 26 or #define ENABLE_REMOTE 1. So now it compiled with "demo" no errors but no remote either. But my TVs turn on with this Elegoo 21 button remote. I don't even know how to identify this remote other than it has Elegoo stamped on it. I will persevere though...eventually. |
Beta Was this translation helpful? Give feedback.
-
|
LOL that a 25 y/o arduino remote works on your TV. I TOLD you these were
pretty universal things.
Big Hammer. Let's get you something that works and forget about
integration. Just go to the end (where the per-project fan out that I
described a couple of times starts to fan in again).
https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/17f4d45774be6334f2a95ece5351566e65c08e09/include/globals.h#L1419
#undef IR_REMOTE_PIN (in case it was defined somewhere in that huge mess
above it)
#undef ENABLE_REMOTE
#define IR_REMOTE_PIN whatever
#define ENABLE_REMOTE 1
I think DEMO and LASER each have only one
<https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/17f4d45774be6334f2a95ece5351566e65c08e09/src/effects.cpp#L333>
effect, so it's going to be hard to see much benefit from the remote there.
You're going to have to decide what you want it to do from the options in
effects.cpp and remotecontrol.cpp - this will be a bit of a "choose your
own adventure" exercise. Find the pin your SOC can receive signals from
your diode receiver. Find codes your remote sends. Find (or make)
something that the NightDriverLED does that responds to those codes and
connect them in remote*cpp. You'll see the debug prints on every key press.
Skimming it,
https://www.circuitbasics.com/arduino-ir-remote-receiver-tutorial/ or
https://myenterprised.com/mods/model-remodel/arduino/remote-control/ won't
QUITE work, but seem to hit the needed education points. They show the kind
of codes you'll be looking for - maybe the exact matching codes.
I can't help you with Windows amnesia. Sorry. Like the antivirus thing
earlier today, that's just the price you pay.
…On Tue, Sep 19, 2023 at 12:54 AM aldengaw ***@***.***> wrote:
Sorry, I simply do not know where to add #define IR_REMOTE_PIN 26 or
#define ENABLE_REMOTE 1.
So my attempt to add it under #if DEMO in globals.h didn't compile at
first. frustrating
I alternately get upload errors 'couldn't open COM8, it doesn't exist',
when just earlier it compiled and uploaded just fine.
If I leave leave upload_port undefined in the .ini file when compliling
'laserline" it usually finds COM8 and uploads to it.
However, half the time when I try to compile "demo" it couldn't open COM8
unless I manually specify it, and even then it sometimes says it couldn't
open COM8 which of course in my M5StickC Plus.
So now it compiled with "demo" no errors but no remote either. But my TVs
turn on with this Elegoo 21 button remote. I don't even know how to
identify this remote other than it has Elegoo stamped on it.
I will persevere though...eventually.
—
Reply to this email directly, view it on GitHub
<#427 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD37F2L3AEPZO2OSGQT3X3EXPVANCNFSM6AAAAAA4WR2EAE>
.
You are receiving this because you were mentioned.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/427/comments/7041932
@github.com>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Been trying this for a while, the laserline env doesn't seem to be compatible with the lilygo, obviously, since its made for m5. I'm wondering if anyone has made a working version of laserline for the lilygo? I'm not very experienced with this sort of thing and its hard to find instructions on how to do this. Help would be appreciated.
Beta Was this translation helpful? Give feedback.
All reactions