Rk3588 evb7 v11 - #127
Open
C-Ackerman wants to merge 2 commits into
Open
Rk3588 evb7 v11#127C-Ackerman wants to merge 2 commits into
C-Ackerman wants to merge 2 commits into
Conversation
Reads frames from /dev/amcam0 on the RK3588 EVB7 AMP configuration, draws them centred on the framebuffer, outlines whatever the detector found and reports what the transport is doing. Statistics matter as much as the picture here, so -s reports without touching the display at all. A camera preview that looks wrong says very little - a black screen is a dead sensor, a dead pipeline, a dead notification path, a bad descriptor or a blit into the wrong buffer, and they are indistinguishable by eye. The counters separate them, and they are printed once before the first read as well, because read() blocks and the counters that explain why would otherwise be unreachable. Boxes are drawn between the blit and FBIO_UPDATE rather than after it, so a frame never appears without its detections and then with them a moment later, which reads as flicker on every box. They are fetched every frame rather than only when a notification arrived: the producer publishes about ten sets a second while this draws thirty frames, so drawing only on the frames with a new set would leave two in three blank and turn an acceptable lag into flicker. Confidence is a bar rather than a number because there is no font here - and a bar is read at a glance, which is how a preview gets looked at, with none of the glyph handling that would be thrown away when this moves to LVGL. Verified on hardware: 30.0 fps, camera preview with boxes on the panel.
A home screen with a camera icon and a button, and a camera screen showing the frames the Linux side publishes in the shared carveout with the detections drawn over them, plus a back button. Started at boot from the board's rcS. Replaces ampcam rather than complementing it. ampcam mmaps /dev/fb0 and writes the first of its two buffers, publishing with FBIO_UPDATE only; LVGL's fbdev backend mmaps the same region, renders into whichever buffer is free and follows with FBIOPAN_DISPLAY. There is no ownership protocol between them - no lock, no shared state, neither knows the other exists - so running both means two writers on the same pixels and neither picture survives. ampcam is still built for the transport counters it prints; only one of the two can run. Nothing is lost by moving the viewer inside LVGL. The frame still arrives as one copy out of the carveout and the boxes are still direct stores. What is gained is a back button hit-tested by the toolkit instead of a hand-drawn rectangle and hand-written coordinate comparisons. The canvas is sized to the frame, not to the screen. read() returns whole rows packed at stride = width * 4, and with LV_DRAW_BUF_STRIDE_ALIGN at 1 lv_canvas_set_buffer() computes exactly that, so the frame is read straight into the canvas buffer - same copy count as ampcam. It also deletes the centring arithmetic: a 540x960 frame fills the screen and a 512x288 one is centred, and the difference is lv_obj_center() rather than an x0/y0 offset threaded through the blit and every box. Boxes are then in the canvas's own coordinates, which is the space the producer already publishes them in. Frames are pumped from a timer, not read in a loop. /dev/amcam0 has no poll method, so there is no way to wait on it alongside anything else, and a blocking read holds still for up to two seconds when the producer is idle - which would freeze the button that gets you out of the screen. O_NONBLOCK turns "no new frame" into -EAGAIN, i.e. a tick with nothing to do, and keeps the whole application single-threaded. The heartbeat is not decoration. Esmart3 stays in vp3's plane mask, so a Linux modeset switches the window off, and it comes back only because every register is rewritten on each flip. The home screen is static: with nothing invalidated there is no flush, no pan, no flip, and the panel would stay dark from the moment Linux starts its side. A once-a-second invalidate of one small object is enough - 58 rows, ~0.3ms of cache clean. Drawn as a visible dot so that a stalled UI looks stalled rather than looking like a display fault. Labels are English because the only fonts built in are Montserrat 20 and 24. CJK text would render as empty boxes and a CJK font is several hundred kilobytes of glyph data in an image under a megabyte. The camera icon is drawn from six styled objects for the same reason - there is no camera glyph in the symbol set. Measured on RK3588 EVB7 V11: the camera screen runs at 20-25 fps against the producer's 30. Per frame, 39.7-50.6us total, of which lvgl 32-42ms, wait 7.7-10.6ms and clean 251-422us. The cost is the toolkit's composition, not the cache maintenance. Not optimised, because the 13ms it sits above ampcam has three plausible causes and no attribution yet. Verified: autostarts at boot, home screen renders, button opens the camera screen with detections following the subject, back button returns, no assertions.
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note: Please adhere to Contributing Guidelines.
Summary
Update this section with information on why change is necessary,
what it exactly does and how, if new feature shows up, provide
references (dependencies, similar problems and solutions), etc.
Impact
Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.
Testing
Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.