07:40 | GuestZero | joined the channel | |
11:38 | intrac | left the channel | |
12:03 | intrac | joined the channel | |
12:08 | intrac | left the channel | |
12:50 | intrac | joined the channel | |
13:39 | Guest88 | joined the channel | |
13:39 | Guest88 | left the channel | |
16:01 | se6astian | MEETING TIME!
| |
16:01 | se6astian | who is here?
| 16:01 | Bertl | is here ...
| 16:01 | BAndiT1983 | is here
|
16:01 | se6astian | wonderful! who has news to share?
| 16:02 | Bertl | raises hand ...
|
16:02 | se6astian | hurray! I am very curious!
| |
16:03 | Bertl | well, I finally got around doing a test setup with the RP2040 and our ILI based display
| |
16:03 | se6astian | superb!
| |
16:03 | Bertl | to check out what performance we can expect with a 4-wire SPI connection versus a parallel connection to the display
| |
16:04 | Bertl | the results are quite interesting ...
| |
16:04 | Bertl | I also used the opportunity to get a feel for the PIO state machines in the RP2
| |
16:05 | Bertl | so, the main points are basically:
| |
16:06 | Bertl | with the 4-wire SPI, according to the datasheet, we should be limited to 10MHz clock, which allows for roughly 8-9 full frame updates per second
| |
16:06 | Bertl | that's not much to work with, especially not for smooth transitions or similar without hardware scroll support or so
| |
16:07 | Bertl | but I also tested with higher SPI clock rates, as similar controller as the ILI9341, specifically the ST7789 support clock rates up to 60MHz
| |
16:08 | Bertl | and to my surprise, that worked quite well, even at 62.5 MHz which is what the RP2 can achieve with stock clock rates
| |
16:09 | Bertl | this would allow a whooping 50 FPS for full updates
| |
16:10 | Bertl | but as we probably want to stay within or at least near the spec, I also tested the parallel mode
| |
16:10 | Bertl | there we are also limited to 10MHz clock according to the datasheet, but we can transfer roughly eight times as much data as before (for 8-bit parallel)
| |
16:11 | Bertl | and so we can get 65 FPS for full updates within the spec
| |
16:11 | se6astian | very cool
| |
16:12 | Bertl | I also tested higher clock rates, and even at 62.5MHz (again, the best we can do without overclocking on the RP2) everything seems fine
| |
16:12 | se6astian | which would mean close to 400fps
| |
16:12 | BAndiT1983 | isn't rp2 running at 150mhz?
| |
16:12 | Bertl | we do not need the high frame updates we can achieve there though, so it makes sense to stay within or near the suggested limits
| |
16:13 | Bertl | 125MHz is the default clock, but it can do up to 200MHz certified
| |
16:13 | Bertl | i.e. there has been an update in the certification from the Raspberry Pi Foundation for that
| |
16:14 | Bertl | and I've seen folks clocking the RP2 with up to 280MHz
| |
16:14 | BAndiT1983 | ok, iirc then rp2040 was at 125mhz by default and rp2350 at 150mhz
| |
16:14 | BAndiT1983 | datasheet rp2350: "Dual Cortex-M33 or Hazard3 processors at 150 MHz"
| |
16:14 | Bertl | yeah, was testing with the RP2040
| |
16:14 | BAndiT1983 | ah, ok, was confused by rp2040
| |
16:14 | BAndiT1983 | *rp2
| |
16:15 | se6astian | splendid!
| |
16:15 | Bertl | so yes, the conclusion here is, we probably want to go with 8-bit parallel and we probably can keep within specs
| |
16:16 | Bertl | what I didn't test yet, but maybe BAndiT1983 has or will, is the display sync using TE or scan line readback
| |
16:16 | Bertl | to avoid tearing by synchronizing the upload with the display scan
| |
16:17 | BAndiT1983 | yep, can do, after my setup is also capable of 8bit parallel communication
| |
16:17 | se6astian | there is no double buffering so the communication just writes the displays internal framebuffer right?
| |
16:17 | se6astian | no matter when it updates
| |
16:17 | se6astian | thats why tearing appears
| |
16:17 | Bertl | yep, the display memory is exactly the size the controller can drive
| |
16:17 | se6astian | makes sense
| |
16:18 | Bertl | we can do some buffering on the RP2, but we need to sync the update
| |
16:18 | Bertl | next thing I'll look into is the SWD interface for direct reprogramming and/or RAM loading
| |
16:18 | Bertl | that's it from my side for today, I'm sure BAndiT1983 has a ton of interesting stuff to report as well ...
| |
16:18 | BAndiT1983 | we can do the double buffering with LVGL and also reduce the memory usage, but with rp2350 we should have enough ram for 2 full buffers
| |
16:19 | se6astian | thanks Bertl!
| |
16:19 | se6astian | sounds good, any news on your side as well BAndiT1983?
| |
16:19 | BAndiT1983 | not really, when there was some spare time was trying to debug my 8bit parallel PIO code and get more insight, but am stumbling into different problems, so looking forward to our Q&A session, as my knowledge is not that deep in the MCU area
| |
16:20 | Bertl | don't be shy, you did some work on LVGL and emulator IIRC, no?
| |
16:20 | BAndiT1983 | basic LVGL setup was working with SPI and also the first UI screen was replicated from old firmware, additional one was added for sliding animation test, which worked fine, but would like to test the display with proper connection
| |
16:21 | BAndiT1983 | and also the visualizer was adjusted to allow development without hardware, still have to upload the code and document it, but have to polish it a bit, as it's rough prototype
| |
16:21 | BAndiT1983 | that would be it for now
| |
16:22 | se6astian | great!
| |
16:22 | se6astian | anyone else around? vup/anuejn I saw some github pushes for NAPS?
| |
16:24 | se6astian | ok then MEETING CONCLUDED! thanks Bertl & BAndiT1983 you can start your debug VC
| |
16:25 | BAndiT1983 | many thanks for moderation!
| |
16:36 | anuejn | here is my somewhat late report:
| |
16:37 | anuejn | vup and me have been working on naps quite a bit and brought it into a shape where it works with amaranth 0.5.4
| |
16:37 | anuejn | also we fixed all the tests (some stuff bitrotted)Â and we now have pachages to pypi again
| |
16:38 | anuejn | I also wrote some getting started docs that might be interesting for people interested in the project
| |
16:38 | anuejn | but that is not yet merged and awaiting a review from vup
| |
16:38 | anuejn | moreover I am currently kneedep in reverse engineering the 5d2 sensor as this is my machelor thesis
| |
16:39 | anuejn | (which I have to hand in in ~1,5 mo)
| |
16:40 | anuejn | after the picture that I showed last week, I am now trying to build a setup without a scope that can stream a live image over ethernet
| |
16:40 | anuejn | to experiment a bit more with timing of different signals and register settings
| |
16:41 | anuejn | also I am working on writing stuff up but thats probably not too interesting yet
| |
16:41 | anuejn | thats it from my side :)
| |
16:43 | Bertl | thanks! didn't know there was a machelor thesis :)
| |
16:48 | se6astian | very nice!
| |
16:48 | se6astian | mr makelor!
| |
16:57 | anuejn | *batchelor :D
| 16:57 | anuejn | fat fingered their keyboard
|
19:25 | GuestZero_ | joined the channel | |
19:27 | GuestZero_ | left the channel | |
19:29 | GuestZero | left the channel |