On Monday, January 6, 2020 at 7:56:44 AM UTC-8, TJF wrote:
>
> I don't understand your target.
> When you need high speed GPIO and a controller running on a PRU, your
> controller will operate at a frequency beyond 10 kHz.
>
> Even if you manage to write messages that fast directly to the text
> screen, nobody can read that fast (the human eye takes ~ 7 picture a
> second). Even messages at the standard (serial) console are often faster
> than anybody can read.
>
> What kind of messages should your project provide in a speed that nobody
> can follow?
>
I didn't want to get into the specifics of the project to avoid
derailing the focus of the question,
(does a text mode only cape exist?) but if it helps, here are some
details:
The text screen will be displaying large frame counters for motion
picture film that will run in
realtime while the motors are spinning.
The counters have to be able to update quickly without "wiping" during
drawing, so that one can
actually read them easily as they roll by. Even if they can't read the
fast moving digit, they can read
the slow moving ones (depending on the motor speed), to tell where they
are in the shot. The operator
needs this information for various reasons (E-stop, knowing when the
end of the shot they'd setup approaches..)
The PRU won't be driving the screen, the PRU will be handling flipping
bits on multiple stepper motors.
The main program (running in linux) will be (a) feeding stepper motor
velocities to the PRU code through
a ring buffer and will also handle updating the large frame/position
counters based on the stepper motor's
current positions, all while the motors are running. The main program
should be able to keep well ahead of
the PRU in generating velocities to the ring buffer, and has plenty of
time to update the counter screen.
The counters are "large"; each digit being a 4x3 matrix of ASCII
characters (or if available, IBM PC graphics
characters, e.g. codepage 437, if available) to make each digit.
Writing directly to screen memory avoids the main program wasting any
time waiting for e.g. a serial controller
buffer or a linux printf()/puts()/write() tty buffer flush to push out
a combo of ANSI cursor positioning to redraw
the counters, and avoids the user seeing the text "wipe" as the
counters are redrawn, seeing partially drawn
characters, and a text cursor flying all around the updating counters
(looks terribly ugly).
But I really don't want to derail into more details on that subject;
suffice it to say the goal is to free up the high speed
GPIOs normally used by HDMI, yet still provide a text screen of some
kind that can be updated very quickly
(screen memory would be great, or perhaps some other high speed way to
update without using up the high speed
PRU gpio pins). VGA would be best, because then the end user can choose
a large screen (instead of a small LCD).
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/17c2d677-a5aa-4496-91dd-3984e31ddcd9%40googlegroups.com.
