I had downloaded that, but I was looking for how you managed to write the vc.pqf in the examples, because it was clear that the “if ison goto” or “if clsh goto” events were built into it. But then I realized it was script based (found the “generate.py” file) and understood that that is how you compiled it altogether. You not only accounted for events, but used the red blue and green images to generate secondary colors for purple, cyan, and yellow. Thank you. I’m still generating font splash screen PQFs and programming the config. But I should have something to show in the next couple days.
So, I’ve wired it up, had some success, but some weird things too. Font.SCR only seems to work when something gets interrupted. It’s as if idle takes over everything. I thought maybe because all my presets use the same file names (although I’ve changed each virtual crystal PQF to correspond to the preset blade color). So, I tried using a few cases where I edited the SCR files to call unique pqf names. I’ve also simplified so that it’s never using multiple layers. Each event (SCR) only calls for one PQF. I did find that if I time out idle.SCR that causes enough interruption that the next time i select a new preset it calls the font.pqf accordingly.
However, I only used one preset with that idle timeout to test, and I had and all new set of files for another preset. And the when I switched to the previous preset from that altered timedout idle, that one would sometimes timeout too. Despite the PQFs and their code within the SCRs not pointing to files with any similar names.
I filmed a four minute explanation, and uploaded to YouTube here. But I wondered if there was some explanation as to why the font event seems to get ignored when switching between presets while a looping pqf file plays.
Battery level preset’s idle.scr:
file=m160x80.pqf
Battery level preset’s pli.scr:
file=m160x80.pqf
layer
file=battery.pqf
A=battery
time=6000
First font preset (survivor) boot.scr:
file=boot.pqf
time=5000
First font preset (survivor) font.scr:
file=font.pqf
time=6000
First font preset (survivor) idle.scr:
file=vc.pqf
time=4000
Every other font has the exact same code for boot.scr, and font.scr, but the other idle.scr reads:
file=vc.pqf
In other words no time declaration. And so no other preset will show the font.pqf, it just keeps playing the idle and animation, even though it will switch colors. Meaning it’s reading the SD card correctly.
The color display code is still relatively untested, so the likely cause for the weird things is:
drum roll
BUGS
It seems pretty clear that the timeout isn’t cleared up properly in some cases, so I’m going to look into that first.
As for the font not showing up, that’s a little more strange, although I suppose it could be related. Have you tried checking the serial monitor to see what it says when it’s supposed to show the font but doesn’t?
I’ve copied the long string of events into this pastebin. It does show that it should be reading font.scr, but doesn’t necessarily play it. I’m also seeing (and perhaps just because it’s connected via USB) that SD unmounts. That causes the screen to blank out, which is what helps to allow the next preset change to actually work.
Everytime it doesn’t work I’m seeing three rows of “file not found.” just after calling the font.scr. I’m guessing that’s related.
I mentioned it in the demo video, but I’m going to re-create the virtual crystal, but break it out into just an on, idle, lock, etc. set of SCR and PQF files. To see if that changes. Each will again be one line calling one file. But I’ll update after I’ve made those adjustments.
So, looking at the pastebin, I see this:
00:12:20.343 -> Playing Sol/160x80/font.scr
00:12:20.343 -> File not found.
00:12:20.343 -> File not found.
00:12:20.343 -> File not found.
00:12:20.343 -> Playing Sol/160x80/idle.scr
I think the the three file not found comes from a call to stop(), which calls Play("") on each of the layers. Obviously, we’re not supposed to call stop() right after playing the font file.
What prop are you using?
I have uploaded a potential fix for this to github.
I wasn’t using multiple layers in my SCR (with the exception of my PLI) as I hoped by overriding the base layer when an event is called, that might solve my issue. So, the fact that it doesn’t find 3 files when I’ve only used one seems odd.
I’m using the fett263 prop file. (Because my clients want the new bladestyle functions he’s making, like party mode, cortosis clash, other multi-phase stuff).
I did run a test last night where I used the virtual crystal image sequences (normal, bright-normal, and bright) to create separate idle, on, lock, etc. PQFs. And I still ran into the issue. However, even when not plugged in and using serial monitor I noticed the screen blank out–implying the “Unmounting SD card” issue that was occuring during monitoring persisted.
I will download the MasterOS and report back. But as a question of optimization, was it your intention when creating the example with your boot.scr and font.scr all having the three layers (vc.pqf, batt.pqf, and logo.pqf) intended to call the files up once, so that they’re not read at the moment the event occurs on the saber? I was attempting the opposite, by separating and using single layers in the hopes that would solve the font screen not showing, but also in hopes that it didn’t cause as much strain on the board. All my presets, no matter how simple the bladestyle, all seem to have a huge delay between ignition and hum when the display is on. And most of the presets really lag, making smoothswing nearly non-existent.
I’m going to run another test after loading the MasterOS whereby the pqf for all states is just a static image and see if that changes the behavior. I know you warned these screens are like having several multi-string blades on at once, so I may have to limit my use of the screen during normal saber operations.
it’s possible I didn’t get the correct MasterOS, but I couldn’t compile. Here are the Arduino errors (using Arduino 1.8.19 with the Proffie 4.6 manager): pastebin link
edit: downloaded master moments ago from: GitHub - profezzorn/ProffieOS: Lightsaber Controller Software
It’s not odd. The stop() function doesn’t really have anything to do with you SCR files. It’s just meant to stop anything that is showing/playing, and it’s meant to be called when you transition from one preset to another. stop() calls Play with an empty filename on all layers, and by default there are three layers available, whether you use them or not. Calling Play with an empty filename prints out a warning that the file cannot be found, which is why you see that three times.
The stop() call occurs when the display gets a EFFECT_CHDIR event, and playing the font.scr file happens when we get the EFFECT_NEWFONT event. I was thinking that maybe these events were occurring in the wrong order, which is why I wanted to know what the prop file was.
However, now that I look at it again, I don’t think that’s actually what’s happening.
When Play() is called, it doesn’t start playing immedately. Instead it starts playing a little bit later, and that’s when the error message is printed out, which might explain why they are showing up out of order.
Don’t let me forget about checking on this. I’m looking into other problems first…
I’m not sure I understand the question. If you have three files in your scr file, then they do get read the at the moment the event occurs on the saber…
It wasn’t done as an optimization for anything. I just needed three layers to achive the effect I wanted.
Please don’t work too hard to work around problems. From a testing perspective I would rather see you “strain” the board to see what works and what doesn’t.
I don’t think is because of “strain”, but rather a bug or misconfiguration somewhere.
Is the delay on the blade? Or in the sound? (or the display?)
Does it show up in the video you posted?
That’s not good, and obviously not intended.
How does this lag show up though? In the sound? On the blade? both?
Are you compiling with “fastest code”? It is highly recommended when using color displays.
It did compile, but didn’t fit on the board.
I’m not using three files in my SCRs. I’m currently trying only one file per scr (except the PLI, since I borrowed the transparent battery level images from the example, but made them fit the whole screen and only show up when ondemand battery is pressed (hold aux tap power from fett’s buttons)
I suppose I’m both attempting to work around the issues and at the same time change the setup for my preferences. In other words, I broke out the image sequences so that I could also show a bright crystal upon clsh, and blst (without having to learn to alter your python script and generate a single PQF with conditional logic). I just used independent scr files.
I will film another short demo demonstrating presets with the newest attempts at separating vc.pqf into individual events, and presets where i just use your example pqf, but with my scr. Stay tuned.
sound only. the blade is a tad slow, but not by much. the color display jumps flawlessly in and out of the different pqfs. but depending on the bladestyle (and a few are complex due to fett’s multi-phase options for Jedi Survivor Party Mode, Osha Crystal Bleed, and Acolyte Cortosis Clash), the lag between the ignition sound and when the hum sound kicks in has been anywhere between one to five seconds. and the smooth swing artifacts will be better explained in the video.
I was using smallest code when pushing OS8.4, but I switched to fastest code for the MasterOS. My config only took up 78% of the memory when loading OS8.4, so I’m not sure what I did in between. That first line about memory shows up when pushing OS8.4, but ultimately works regardless. When I switch to smallest code it doesn’t do that. Using the master, and just verifying my config, I get the following in Arduino:
C:/Users/skinn/AppData/Local/Arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/14-2-rel1-xpack/bin/../lib/gcc/arm-none-eabi/14.2.1/../../../../arm-none-eabi/bin/ld.exe:C:\Users\skinn\AppData\Local\Arduino15\packages\proffieboard\hardware\stm32l4\4.6\variants\STM32L452RE-ProffieboardV3/linker_scripts/STM32L452RE_FLASH.ld:224: warning: memory region `SRAM2' not declared
lto-wrapper.exe: warning: using serial compilation of 13 LTRANS jobs
lto-wrapper.exe: note: see the '-flto' option documentation for more information
Sketch uses 396880 bytes (78%) of program storage space. Maximum is 507904 bytes.
EDIT: MasterOS demo video (using smallest code, since it won’t compile with any other setting)
Please consider removing a few presets to make it work with “fastest code”. The display code becomes much much faster when using “fastest code”.
That shouldn’t really be possible, so it has to be a bug somewhere.
Please post your full configuration so I can try it out.
I removed all but 8 of the simplest presets and it still gives me those errors using “fastest code”.
Here is the pared down config: SpaceJunk Mining Colony with color display config - Pastebin.com
Should I have not used GND as your table says, but used Data4? I have accents on Data4, but I thought the DFrobot was not this type of display, their wiki said it was an ST7735.
The DFrobot display is indeed ST7735 and using GND is fine.
That’s unfortunately.
I’ll try your config.
2 Likes
What version of the arduino-proffieboard plugin do you have?
When I compile your config file, it comes out at 62% with smallest code, and “fastest” comes out to 101%, but fits if I comment out a single preset.
I used Arduino 1.8.19 with the 4.6 proffieboard plugin. I’ve always used smallest code. I guess I’ve never understood the difference in what each option (smallest, fast, faster, fastest) does.
I still can’t understand what all the various notations are during compiling about “flto” and “malloc” in nearly every style h file. I cleaned up some using styles, and removed a preset to get to 96%, but just during verification. I haven’t tried uploading this to test the board again, but here is the pastebin for those Arduino messages.
Both flto and malloc are warnings that can be ignored.
I should have another go at fixing those things at some point.
As for smallest/fast/faster/fastest, they really correspond to options given to the compiler:
O1, O2 and O3 have simple definitions that can be found in the gcc manuals. I brief description of each level:
- O1 - prioritize compilation speed and simple generated code for easy debugging
- O2 - highest optimization that does not break any C/C++ rules.
- O3 - break any rule that the user probably won’t notice anyway if it makes the code faster
- Os - similar to O2, but optimize for code size rather than speed.
Unfortunately Os is special. O1/O2/O3 maps directly to flags for the compiler, but Os changes internal settings directly . I’ve tried to come up with options that are somewhere between Os and O3, but it’s never really worked. 