 | PineTime Development | 262 Members |
| Welcome to PineTime Development, this is a channel for PineTime development related questions. General discussion goes to #pinetime:matrix.org. InfiniTime, WaspOS and all other coding discussion welcome! | 48 Servers |
| PineTime Development | 262 Members |
| Welcome to PineTime Development, this is a channel for PineTime development related questions. General discussion goes to #pinetime:matrix.org. InfiniTime, WaspOS and all other coding discussion welcome! | 48 Servers |
| Sender | Message | Time |
|---|---|---|
| 11 Dec 2024 | ||
 Pine64 Protocol Droid | [D] <cidwel> Folks, some ideas. I'm drawing some sprites for the tamagotchi. There are many of them. These are 16x16 pixels. But I want to display them in x4 resolution. Right now I'm increasing the size which is not optimal. But I'm not sure if it would eat the ram by keeping them in memory instead of just reading them. So, right now I have (I think) some issue because I preload all the bins for all subimages as lvgl img objects. Let's iamgine tha the tamagotchi displays 4 frames when IDLE, then when you hit on "food" it starts eating, and that's another 4 frames of animation. There might be many other sprites
Would make sense to "load" them from SD when I need to paint those states then unload them right after | 10:46:24 |
| Pine64 Protocol Droid | [D] <cidwel> Folks, some ideas. I'm drawing some sprites for the tamagotchi. There are many of them. These are 16x16 pixels. But I want to display them in x4 resolution. Right now I'm increasing the size which is not optimal. But I'm not sure if it would eat the ram by keeping them in memory instead of just reading them. So, right now I have (I think) some issue because I preload all the bins for all subimages as lvgl img objects. Let's iamgine tha the tamagotchi displays 4 frames when IDLE, then when you hit on "food" it starts eating, and that's another 4 frames of animation. There might be many other sprites
Would make sense to "load" them from SD when I need to paint those states then unload them right after, and just have a very limited amount of LVGL objects in screen? I guess this is more a generic thing than a pine issue. Weird thing is that I don't have issues in the simulator, so I need to be very cautious of the pine capabilities | 10:47:07 |
| Pine64 Protocol Droid | [D] <cidwel> Folks, some ideas. I'm drawing some sprites for the tamagotchi. There are many of them. These are 16x16 pixels. But I want to display them in x4 resolution. Right now I'm increasing the size which is not optimal. But I'm not sure if it would eat the ram by keeping them in memory instead of just reading them. So, right now I have (I think) some issue because I preload all the *.bins for all subimages as LVGL image objects. Let's imagine the tamagotchi displays 4 frames when IDLE, then when you hit on "food" it starts eating, and that's another 4 frames of animation. There might be many other sprites
Would make sense to "load" them from SD when I need to paint those states then unload them right after, and just have a very limited amount of LVGL objects in screen? I guess this is more a generic thing than a pine issue. Weird thing is that I don't have issues in the simulator, so I need to be very cautious of the pine capabilities, but I'm sure if loading resources from the flash is efficient or if this is a task that I shouldn't be calling that often | 10:48:23 |
| Pine64 Protocol Droid | [D] <cidwel> Folks, some ideas. I'm drawing some sprites for the tamagotchi. There are many of them. These are 16x16 pixels. But I want to display them in x4 resolution. Right now I'm increasing the size which is not optimal. But I'm not sure if it would eat the ram by keeping them in memory instead of just reading them. So, right now I have (I think) some issue because I preload all the *.bins for all subimages as LVGL image objects. Let's imagine the tamagotchi displays 4 frames when IDLE, then when you hit on "food" it starts eating, and that's another 4 frames of animation. There might be many other sprites
Would make sense to "load" them from SD when I need to paint those states then unload them right after, and just have a very limited amount of LVGL objects in screen? I guess this is more a generic thing, or a LVGL question, than a pine issue. Weird thing is that I don't have issues in the simulator, which is expected since it's a simulator, and not an emulator, so I need to be very cautious of the pine capabilities, but I'm sure if loading resources from the flash is efficient or if this is a task that I shouldn't be calling that often | 10:49:08 |
 neroburner | Loading from flash is slow 🐢 but I'm thinking of 240x240 background image for a watchface. I never dabbled with loading from spi memory myself | 11:40:58 |
 Scott | Should be able to figure out how long it would take to load from the datasheet but the links on the page are dead https://pine64.org/documentation/PineTime/Further_information/Datasheets_schematics_and_certifications/ | 11:53:55 |
 mark9064 | IIRC it's pretty much all SPI bus bound, the NOR itself is fast | 12:03:34 |
| mark9064 | there might well be some optimisation opportunities in the firmware itself too | 12:03:48 |
| Pine64 Protocol Droid | [D] <cidwel> I need to do speed tests there, but having to flash the watch all the time consumes so much time with bluetooth. I wonder if there's some better way to flash a devkit quickly without bluetooth. Haven't tried a programmer, but I don't even know how to flash this thing | 13:51:14 |
| Pine64 Protocol Droid | [D] <cidwel> the images that I need to load are "kinda" small, around 64x64 per frame, so 4 frames. Still I need to figure out how to load a indexed image. The builtin converter doesn't seem to recognize the 4bit indexed image (or even better, 2 bit). That might speed up things a lot | 13:53:56 |
 Username joined the room. | 18:47:07 | |
| neroburner | In reply to @p64protocolbot4:matrix.orgYeah. I implemented just the minimum required subset to get rid of the npm script. To test you could install the npm script and change the CMake script to use it instead. And if it works implement the needed stuff in our minimal Python Script | 19:24:00 |
| neroburner | In reply to @p64protocolbot4:matrix.org As far as I've heard the programmer is extremely fast compared to Bluetooth Maybe infiniemu could help as well | 19:25:46 |
| Pine64 Protocol Droid | [D] <pipe01> There's no slowdown due to SPI because I haven't added any delays there, but otherwise it should work | 19:46:56 |
| mark9064 | flashing the watch takes about 15s for me with Gadgetbridge. how long does it take you? | 20:11:13 |
 scorpion2185 | if it's a devkit you can use the cable it takes 2 secs | 20:13:58 |
| scorpion2185 | pinephone took 12 minutes | 20:14:08 |
| Pine64 Protocol Droid | [T] <KieranC> ble seems to be super variable, some people get 15kB/s, others 1.5 | 20:18:51 |
| Pine64 Protocol Droid | [D] <cidwel> Oh. I found some project that implements all types. It is fully python. I reconverted cmake and adapted the generate-img script. Maybe I should push a PR with this change. It works in my tests.
I've also adapted the pinetime file explorer to be able to clear the flash in one click which took so much time with their implementation. And I saw that Siglo seems to be the best firmware uploader. It seems to be the most consistent one, but it does not let you upload resources :(, but there's some folk which included this via PR | 20:32:26 |
| Pine64 Protocol Droid | [D] <FintasticMan> on an old phone of mine, i consistently got 30 kb/s, with peaks of 40 | 22:15:04 |
| mark9064 | i wrote a flash DFU flasher in python. there are severe performance problems with the linux kernel in its default configuration with the realtek drivers in my laptop. it wont go any faster than "superbly slow" | 22:26:38 |
| mark9064 | if i ever have the time to boot up kgdb or whatever and rip apart the kernel BT stack i might try fix it, but it's something i dont know anything about and just cant justify weeks on | 22:27:21 |
| mark9064 | * i wrote a fast DFU flasher in python. there are severe performance problems with the linux kernel in its default configuration with the realtek drivers in my laptop. it wont go any faster than "superbly slow" | 22:30:52 |
| mark9064 | for reference, i know the BLE channel is fast enough as i get good performance using notify, around 31KB/sec reading from the flash. so for a normal image DFU should theoretically transfer in about 15s | 22:39:38 |
| mark9064 | * for reference, i know the BLE channel is fast enough as i get good performance using notify, around 31KB/sec reading from the flash. so for a normal image DFU should theoretically transfer in about 15s. queued writes runs at about 4KB/s | 22:43:08 |
| mark9064 | * for reference, i know the BLE channel is fast enough as i get good performance using notify, around 31KB/sec reading from the flash. so for a normal image DFU should theoretically transfer in about 15s. queued writes runs at about 4KB/s, so 95s | 22:43:33 |
| mark9064 | still much faster than some people quote here, i can post the dfu script somewhere if people want | 22:43:53 |
| 12 Dec 2024 | ||
| Pine64 Protocol Droid | [D] <cyberneel> For my SleepTk port, I want to add a way to send the last sleep duration to gadget bridge. Is there a way to do this already setup since gadget bridge is already supported or is this something I have to do work on the android side? | 04:01:14 |
| Username changed their profile picture. | 20:24:52 | |
| Username changed their display name from Pro Soccer Legend to Username. | 20:26:19 | |