On Tuesday, January 7, 2020 at 10:32:34 AM UTC-8, Dennis Bieber wrote:
>
> On Mon, 6 Jan 2020 16:46:04 -0800 (PST), Greg Ercolano wrote:
>
> >Oh wow, I guess this is close to what I was looking for:
> >https://elinux.org/BeagleBone_VGA
> > I can't tell if it's a dead project ("Discontinued") or a work in
> progress ("Manufacturer's link available soon")
> >Also, it sounds like it still uses a lot of pins.. probably because it's
> supporting full VGA including VGA graphics modes.
>
> If it acted as a real VGA board (with VGA rendering circuits and
> memory) it would probably take a LOT more pins. Real VGA boards were
> memory-mapped into the processor space (for that era, that means it likely
> had 16 address lines) along with 8 data lines.
>
> Since the Beagle does not expose the processor address lines
> (except
> possibly for RAM, if the RAM is not inherent to the SoC itself) that means
> using GPIO to emulate a parallel address bus, along with GPIO for the
> 8-bit
> data bus... OR one uses a serial transfer to send address and data
> information -- in which case one is talking I2C or SPI (or pure UART), and
> one is giving up the speed advantage of parallel I/O ports&addressing.
>
OK -- yeah, that makes sense.
I was trying to envision a text mode only VGA cape that could maybe use
6 bits GPIO; 4 for a data nibble, and one to strobe the nibble, and
just have
a write only interface to the 4k of onboard text memory, sending an X,
Y position
to write to, and an 8 byte character, and optional attribute char.
Which is maybe fine for making a dumb terminal, but operations like
scrolling
become a headache, since partial window "region scrolling" is needed
for applications
like VI which allows horizontal split screen, one can't really use a
tty like interface
unless one supports full ANSI/XTERM on the cape. Then we're basically
back to
a VT100. :-/
OK, so I get it -- that's kinda a dead end.
The only way I could see out of that situation is maybe to use PRU0 to
offer
4k of shared memory to the processor as 'screen memory', and the PRU
constantly
snapshots that memory to the cape's text memory as fast as it can, and
the cape
handles converting the text chars to glyphs and a pixel stream to a
VGA out connector.
I'm not familiar at all with what the Arm provides, but Stuart sent me
a few emails
giving me some idea about that; I take it internally everything's very
pixel oriented,
which probably slows things down a bit when it comes to text; fast
enough for most
purposes, maybe even my purposes, I should do some tests.
I did do a quick test writing my counters to /dev/vcs while on the
BBB's text console
(HDMI enabled) and it worked perfectly from a screen layout point of
view. Should probably
do a speed test to see how fast I can update the counters.
But I take it writing to "text screen memory" via /dev/vcs might be
handled by the linux
drivers as a software operation, converting the text chars into pixels
/in software/, is that correct?
And by "in software", I take that to mean, by the linux host processor
itself, which means the pixel
conversion process eats into the processor's cpu time? Which might be
bad for me, since I'll
also be trying to update motors. AFAIK the Arm is single core, so some
of that cpu load couldn't
be offloaded to another core.
Mmm, I see, I see..
--
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/f457a4eb-0eb7-4a36-adc9-ddf1c98dc467%40googlegroups.com.
