I love the history display with the up/down buttons and the sprite test seems very promising!
1 Like
Interesting. I just tried compiling the latest from the github repo (which doesnāt have this change, I checked), and it built and linked without errors. I was building for the default pico_2w target, so maybe this is only a problem for certain targets? Going to try running it now under uf2loader.
EDIT:
Just checked and it seems to run fine too with the default CMakeLists.txt. Thereās one ārowā of the sprite test that looks a little glitchy, unless it was intentional, but otherwise the new functionality seems to work.
I wonder if you were using a different version of the Pico SDK, or were building for a target other thatn pico2_w? Iāve been using version 2.2.0.
Thanks you for your remark, you are absolutely right, sorry, it seems I used pico2 as PICO_BOARD. pico2_w works like charm. Forget my ācorrectionā, please.
Iām using the lastest version of Pico SDk (2.2.0). Iām compiling and testing only for PiOC2W. I havenāt tried it with Pico2 or Pico.
I have created a new branch (ādevā) that Iām using to save my work in progress.I am currently working on using DMA to send data to the display. Iām also moving the management of sprite and tile graphics to core1. I However in this moment the DMA is synchronous; Iām working to making it asynchronous.
2 Likes
I just updated the main branch with the latest changes from the DEV branch. I removed the double buffer management for a single buffer that is never destroyed but updated. Modified the sprite redraw routine. Moved all graphics procedures to core1. Data transfer to the LCD is done via semi-asynchronous DMA. Core0 and Core1 communicate via a FIFO command buffer. The glitch seems to be fixed. I hope.
1 Like
I should draw your attention to this note in the SDK documentation:
The inter-core FIFOs are a very precious resource and are frequently used for SDK functionality (e.g. during core 1 launch or by the lockout functions). Additionally they are often required for the exclusive use of an RTOS (e.g. FreeRTOS SMP). For these reasons it is suggested that you do not use the FIFO for your own purposes unless none of the above concerns apply; the majority of cases for transferring data between cores can be eqaully well handled by using a queue
Thanks a lot. I missed this information. Iāll be change the communication.
1 Like
Modified communication between cores. Replaced inter-core FIFOs with queues to comply with the specifications indicated on PICO SDK (thanks BlairLeduc). Initial tests show that communication is slightly slower than FIFO management. Obviously, the code is not optimized.
Added a new command ātedā. This is a simple a text editor with a four functionalities: Load (F1) Save AS (F2), Save (F3). Press F6 to see a list of files in the current directory. I wanted like to try to create a simple editor.
Very interesting updates, works well and compiled without issue on my setup. I am curious about the DMA thing for the screen updates, does it improve performance significantly ? I am looking at āportingā some graphics heavy thing to the PicoCalc and was wondering if it was worth looking into it ?
And BTW I donāt know if you looked at it but the āofficialā ClockworkPi Shapones port (the NES emulator on the SD) seems to be using some PIO and DMA to good effect, check the picocalc.cpp file, it is lightly commented but looks interesting.
2 Likes
Thanks for the information about Shapones (NES) Iāll look it.
From official Pico SDK documentation:
The DMA data throughput is significantly higher than the RP-series processors. The DMA can perform one read access and one write access, up to 32 bits in size, every clock cycle.
Key DMA Characteristics:
- Maximum theoretical throughput: 1 read + 1 write (up to 32 bits) per clock cycle Raspberry Pi
- Parallelism: 12 independent DMA channels available Raspberry Pi
- Zero CPU overhead: DMA leaves processors free to attend to other tasks or enter low-power sleep states Raspberry PiAPS
Thanks for your feedback.
In a forum an user shared concrete results for a 320x240 RGB565 LCD display:
- Full framebuffer transfer: 18ms at 300 MHz CPU clock with 75 MHz SPI using DMA Raspberry Pi Forums
- Blocking SPI (without DMA) was 19% slower Raspberry Pi Forums
In my example: the Core 0 continue calculations while Core 1 + DMA handle the display. In current version the DMA is yet semi-asynchronous. I have noticed improvements in performance compared to using only the CPU for data transfer. There are some other optimisation to do.
Cool, thanks for the details, that seems really promising !
1 Like
@BlairLeduc Helloā¦ I just released a small project (port of runCPM) made from your framework, it works great !
I found a microscopic bug in clib.c and made a PR for you.
Thank you for the great job !
jF
1 Like
Hi,
Next to come: an onboard C compiler by a freaking good programmer (not me !)
Best wishes
2 Likes