17:00 | se6astian | MEETING TIME, who is here?
| 17:00 | BAndiT1983 | is here
|
17:01 | se6astian | great, how are things going on the ili front BAndiT1983?
| 17:01 | Bertl | is here as well
|
17:02 | BAndiT1983 | a bit slowly, sparse time as usual, still trying to get proper setup for the axiom remote display, generally it works, but lvgl isn't providing the performance i would expect, not becuase the MCU is slow, but something leads to stutters
| |
17:03 | BAndiT1983 | still investigating, will also start to implement other screens too, but first i should clean up everything and upload the code
| |
17:03 | BAndiT1983 | that would be it
| |
17:03 | se6astian | thanks!
| |
17:03 | se6astian | any news Bertl from your side?
| |
17:04 | Bertl | yes, there has been some progress in different areas
| |
17:04 | Bertl | first, I've implemented SWD in PIO to test (re)programming an RP20240 over SWD
| |
17:04 | Bertl | *RP2040
| |
17:04 | BAndiT1983 | from scratch? or pre-recorded commands?+
| |
17:05 | Bertl | bascially from scratch as I could not make heads or tails from the captured data
| |
17:06 | Bertl | I first tried to analyze pico probe data but all the analyzsers I used for that didn't produce meaningful SWD data
| |
17:06 | Bertl | I later figured out why, but it wasn't a promising start
| |
17:07 | Bertl | so I decided to look into Pico SWD in more detail and figured out that it has some oddities compared to 'normal' SWD
| |
17:08 | Bertl | first, it requires a quite complicated sequence to enable the SWD port (hundreds of bits ;)
| |
17:08 | Bertl | before that, the port doesn't react to SWD commands
| |
17:08 | Bertl | then, the RP2* implements a shared bus version of SWD
| |
17:09 | Bertl | i.e. both (all) cores share the SWD interface with an additional recovery chain
| |
17:09 | Bertl | so you need to first select with what unit you want to talk
| |
17:10 | Bertl | this is a separate procedure but already part of newer SWD protocol
| |
17:10 | Bertl | after that, you can actually do something over SWD
| |
17:11 | Bertl | and that was the main reason all analyzers I tried before didn't understand the communication because of the initialization sequence
| |
17:12 | Bertl | the current proof of concept implementation can upload and download memory content (RAM/ROM) and in theory it should be able to start a program from RAM
| |
17:12 | Bertl | but so far I haven't managed to get a simple blink running from RAM
| |
17:13 | Bertl | note that I didn't succeed to get that working without my SWD code either, so it might not be a problem in the SWD code, more a problem with missing initialization or so
| |
17:13 | Bertl | performance is quite good, I can fill up the entire RAM in less than a second within the spec
| |
17:14 | Bertl | and there is still room for improvement when optimizing the sequences
| |
17:15 | Bertl | on a different note, I've been digging into our v4 Beta code and updated everything to recent tools
| |
17:15 | BAndiT1983 | what's the v4? is it a version of the firmware 2.0?
| |
17:15 | Bertl | this is mainly done for a customer who wants improved capture and buffering
| |
17:16 | Bertl | cmv_hdmi4
| |
17:16 | Bertl | this is the gateware where we separate capture and hdmi output to allow for an external sequencer
| |
17:17 | Bertl | I've written a bunch of Rust code (well, I had AI write it :) to capture to specific buffer addresses
| |
17:17 | se6astian | very nice
| |
17:18 | Bertl | and also retrieve subregions of full or partial captures
| |
17:18 | Bertl | this is quite performant (faster than the gigabit ethernet) so transfers over ssh or similar are at wire speed
| |
17:19 | Bertl | this can also be optimized in the future but it seems to work reasonably well
| |
17:19 | Bertl | in this context, I also tried different CMV clock rates and LVDS transfer speeds
| |
17:20 | se6astian | cool!
| |
17:20 | Bertl | and it seems that we can currently go up to 366MHz without issues but we can't reach anything above 400MHz at the moment
| |
17:20 | Bertl | (we were using 250-280MHz before)
| |
17:21 | se6astian | sensor is rated at 600mhz though right?
| |
17:21 | Bertl | yup
| |
17:21 | se6astian | still very good!
| |
17:21 | Bertl | it was originally rated at 300MHz max
| |
17:22 | Bertl | they then certified it for 600MHz after a while
| |
17:22 | Bertl | not sure all versions support 600MHz, maybe it was a change in production as well (but I doubt it)
| |
17:22 | Bertl | there are still some issues on the HDMI output path
| |
17:23 | Bertl | i.e. sometimes the image starts shifting, which I can't explain yet, as the fabric based sequencer works without any issues
| |
17:23 | Bertl | this will need some further debugging in the future but is not really relevant at the moment
| |
17:24 | Bertl | that's it from my side for today
| |
17:24 | se6astian | many thanks!
| |
17:24 | se6astian | anyone else around? vup/anuejn?
| |
17:26 | se6astian | alright then, MEETING CONCLUDED, thanks BAndiT1983 & Bertl!
| |
17:29 | Bertl | thanks for the moderation!
| |
00:15 | intrac | left the channel | |
00:17 | intrac | joined the channel |