Your subject is miss-leading. You're searching for a display. You can either use a text only display, ie with I2C or SPI interface.
Or you can still use a HDMI monitor, since you need not disable all HDMI pins. Just keep one or three of them for a black & white frame buffer. BTW: The HDMI pins block PRU-1 GPIO. Only 16 inputs / 15 output are avialable. Instead running on PRU-0 you can have the full set (17 inputs / 16 outputs) and HDMI in parallel. (You've to wire some GPIO to the SD card slot.) <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaTNT.html#SecPruGpio> Am Montag, 6. Januar 2020 19:46:39 UTC+1 schrieb ercola...@gmail.com: > > 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/339b3b88-7b3c-47c7-a8d5-462bf02fbc04%40googlegroups.com.
