Accelerated 2D vector drawing?

[clickworkorange]

I'm completely new to bare-metal development for the Pi but I've spent some time browsing the Circle documentation and it sounds like just the thing I've been looking for. I'd like to build a very basic proof-of-concept mapping appliance that can display a 2D vector map with pan & zoom support. Target platform is the Pi3B+, so OpenVG is an option, but I'm worried that I'd be wasting my time learning what appears to be a deprecated API. Eventually the Pi3 and Videocore IV will be extinct, and OpenVG along with it. So before I even start collecting notes for this project, I'd like to hear which API experienced bare-metal devs would suggest for this application?

Edit: I've built a couple of your examples (fractal, screenanimations and usbmouse) and tested them on a Pi3B+; absolutely 100% amazing. I am very excited by the possibilities this opens up!

[clickworkorange]

Having scratched a tiny bit deeper it seems like the best option, at least to start with, is to go with C2DGraphics from the base library; I don't imagine I'd be able to test an application using OpenVG/VC4 acceleration in QEMU, and rapid iteration is much more important to me.

It's a shame there's no way to write to the SD card from a computer connected via USB - so fiddly to extract the card and insert in a card reader and then back every time you want to test a code change. QEMU will be essential for testing to prevent RSI :)

Perhaps a bootloader could be written in Circle that allows the kernel to be updated via USB? E.g. pulling a GPIO low triggers an interrupt that exits main and enters a bootloader mode, where the Pi becomes a USB widget and exposes the SD card. Crazy idea, I know, but when I do Atmel stuff I set up my Makefile so I can build & flash with one command, which saves a lot of time when you're in the early stages of a project.

[rsta2]

I'm not an expert for accelerated graphics, but perhaps OpenVG 1.1 is still an option. The specification is still on the Khronos website as is a Quick Reference Card. I tried to make access to OpenVG easier in libgraphics, but came not very far. But perhaps C2DGraphics is also an option.

There is serial bootloader support in Circle. Please see the file doc/bootloader.txt for more info. A complete rewrite of the Flashy bootloader tool in C (cFlashy) is on the develop branch, as is support for an USB mass-storage gadget mode, which allows to write to the SD card directly from a connected PC. Unfortunately this does not work with the RPi 3 B+. QEMU is also working. See doc/qemu.txt for this. A network bootloader (via HTTP and TFTP) can be found in sample/38-bootloader.

[clickworkorange]

Thank you, that's very interesting! Shame about the Pi3B/+ not supporting gadget mode - I actually had this information in my brain somewhere, but the index is a little corrupted. And the Pi3A/+ isn't great for this task since occupying the single USB port would preclude the use of any input devices.

Definitely interested in trying to make use of OpenVG - it will take the fastest possible 2D vector drawing capability to handle actual map data. I'm looking at GDAL's OGR library as a likely source for the vector data. But am I right in thinking it won't be possible to test an application written for OpenVG in QEMU? AFICT it has no support for VC4 at all?

[rsta2]

No, QEMU does not have VC4 support. You have to test this on the RPi hardware itself.

[clickworkorange]

I've built the "tiger" VC4 demo and I'm astonished by the performance - 17k vectors with fills & gradients transformed at 75fps with XGA resolution without a hint of glitching. Wow! This is very promising indeed.

[rsta2]

Good to know!

[clickworkorange]

Confused by the directory structure when it comes to "make"; I copied "hello_tiger" to circle/app/ and edited CIRCLEHOME in the Makefile to ../.. but

/myprojectdir/circle/app/hello_tiger$ make
make: *** No rule to make target '../../../../../include/circle/actled.h', needed by 'main.o'.  Stop.

This follows the "hello world" instructions: https://circle-rpi.readthedocs.io/en/47.0/hello-world.html and I've verified that kernel.h has #include <circle/actled.h>. It's frustrating that make doesn't say which Makefile it's falling over on, not even with make -d. There's so many levels of nesting I'm really struggling to figure this out.

[rsta2]

Maybe there was a stale main.d file in the directory? This is produced by the conditional build system. Just do a make clean in the project's directory. This is always a good idea after moving something around.

[clickworkorange]

Thank you, I was just going to say it's now building - and yes, that was after a make clean. Another facepalm moment, and I'm only just getting started!

[clickworkorange]

Hello. It's me again... I've managed to get a serial connection set up, Flashy installed, modified the "tiger" code to respond to the magic word by rebooting, rebuilt the circle/boot files (in fact, I rebuilt the whole stack after a ./makeall clean, just to be sure), copied everything to the card, and

$ make flash
/myprojectdir/circle/app/hello_tiger Makefile
  COPY  kernel8-32.hex
node  ../../tools/flashy/flashy.js \
	/dev/ttyUSB0 \
	--flashBaud:115200 \
	--userBaud:115200	 \
	--reboot:toober \
	 \
	kernel8-32.hex
Opening /dev/ttyUSB0 at 115200...ok
Sending reboot magic 'toober'...ok
Sending reset command...ok
Waiting for device...

Nothing. The Pi just reboots and starts the "tiger" demo back up again. Do I need to call something other than reboot (from sysinit.cpp, or do something else, to get the Pi to go into bootloader mode? The instructions do not say, nor does the Internet.

Edit: I noticed that the serial monitor output was slightly garbled, so I lowered the baud rate to 19200, but it's still garbled, like some bytes are dropped and/or altered:

lr: Cirle 47 started on Raspberry Pi  B+ 1GB
logger: Revision code is a020mpiler has been GCC 13.3.1
000.66 timer: SpedFactor is 1.51
00:.66 printk: vchiq: vchiq_init_stte: _zero = 0x0048000, is_master = 0
00:66 kernel: Iitialized
00:00:00.66 kel: Compile time: Sep  9 2024 :57:56

lr: Circle 47 started on Raspberry Pidel B+ 1GB
logger: Revision code is 3, compiler has been GCC 13.3.1
000.66 timer: SpeedFactor is 1.51
0:06 printk: vchiq: vchiq_init_state: slzero = 0x0048000, is_master = 0
00:0.66 kenel: Initialized
00:00:0066 nel: Compile time: Sep  9 2024 21:57:5

lr: Circle 47 started on Raspberry PiModel B+ 1GB
logger: Revision code isd3, compiler has been GCC 13.3.1
00:00.6 timer: SpeedFactor is 1.51
00:00.6printk: vchiq: vchiq_init_state:ot_ero = 0x00480000, is_master = 0
000.66 kernel: Initialized
00:00:00.66nel: Compile time: Sep  9 2024 21:57

If you look at those three reboots (triggered by typing the magic word directly in Putty) you can see some characters are missing, and some are incorrect, even at 19200 baud. Could it be that my USB <> TTL adapter (PL2303) is bugging out on me? I do have a bonafide FTDI TTL interface here as well, but that's connected to something else at the moment - might give that one a try tomorrow.

[clickworkorange]

I think I know why the serial connection is flakey:

1 V P-P 225 kHz noise on the Tx line coming out of my PL2303 USB <> TTL adapter! That'll ruin any data transfer at any bitrate... Will have to extract the FTDI interface and see how that performs (note: the Pi was not powered on when I took this measurement).

[clickworkorange]

Ok, it was actually easy to get rid of that noise, by simply putting a 10 uF cap across the GND & 3v3 pins on the PL2303 adapter. The signal is now very tidy:

And as suspected this also got rid of the transfer errors on the serial console:

logger: Circle 47 started on Raspberry Pi 3 Model B+ 1GB
logger: Revision code is a020d3, compiler has been GCC 13.3.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.66 printk: vchiq: vchiq_init_state: slot_zero = 0x00480000, is_master = 0
00:00:00.66 kernel: Initialized
00:00:00.66 kernel: Compile time: Sep 10 2024 09:42:19

logger: Circle 47 started on Raspberry Pi 3 Model B+ 1GB
logger: Revision code is a020d3, compiler has been GCC 13.3.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.66 printk: vchiq: vchiq_init_state: slot_zero = 0x00480000, is_master = 0
00:00:00.66 kernel: Initialized
00:00:00.66 kernel: Compile time: Sep 10 2024 09:42:19

logger: Circle 47 started on Raspberry Pi 3 Model B+ 1GB
logger: Revision code is a020d3, compiler has been GCC 13.3.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.66 printk: vchiq: vchiq_init_state: slot_zero = 0x00480000, is_master = 0
00:00:00.66 kernel: Initialized
00:00:00.66 kernel: Compile time: Sep 10 2024 09:42:19

But unfortunately the make flash behaviour remains the same; the Pi reboots and I get Waiting for device..., but the application just starts as normal and no transfer occurs. Any ideas?

[clickworkorange]

No difference I'm afraid. I see that the IHEX-F message is sent in response to make flash and not just a boot message. Interesting pattern on the Tx line; seems it's wiggled 260 times to make the bootloader kick in?

No relevance to the issue I'm having, just curious.

Edit: Found this comment in flashy.js which explains things:

    // Reset signal consists of 256 x 0x80 chars, followed
    // by a reset 'R' command.  The idea here is the 0x80s will
    // flush a previously canceled flash out of a binary
    // record state.  0x80 is used in case the bootloader is
    // cancelled at the start of a binary record and we don't 
    // want to write a lo-memory address that will trash the
    // bootloader itself.

[clickworkorange]

Passing --noack to Flashy makes the transfer go.

node tools/flashy/flashy.js /dev/ttyUSB0 /myprojectdir/circle/app/hello_tiger/kernel8-32.hex --noack
Opening /dev/ttyUSB0 at 115200...ok
Sending.............................................................................................................................................................................................................................................................................................ok
Finished in 103.0 seconds.
Sending go command...ok
Closing serial port...ok
Done!

Serial console shows:

IHEX-F
#EOF:ok
--

But the SD card appears unchanged afterwards.

[clickworkorange]

This is really too embarrassing to share... But I owe it to you. And anyone else who gets stuck with the same problem. I never would have thought it was a permission issue, not least since I could read and write to the port without getting any permission errors. But it was. After trying to get Flashy v3 working I wondered about the missing ACK, and just thought I'd double check that I was in the dialout group (despite being 100% sure I would get "is already a member"):

$ sudo adduser pebkac dialout
Adding user `pebkac' to group `dialout' ...
Done.

What!? Surely I was already a member!? Apparently not. And of course, now the bootloader works without a hitch. Yes, it's another facepalm moment!

$ flashy /dev/ttyUSB0 kernel8-32.img
Found device: 
    - Raspberry Pi 3 Model B+
    - Serial: 00000000-7f6d04bc
    - CPU Clock: 600MHz (range: 600-1400MHz)
    - Bootloader: rpi2-aarch32 v3.0.0.4, max packet size: 4096
Sending 'kernel8-32.img':
.....................................................................................................
Transfered 413100 bytes in 4.6 seconds.

It's ok to laugh.

[rsta2]

The kernel image is not written to the SD card. It it simply loaded into memory and started there.

It's really strange, that it does not work without --noack. Flashy has not been developed by myself and the developer has made his own project from it. Because of some issues with the original version in Circle (e.g. deprecated messages from used submodules) there is a complete rewrite in C on the develop branch. It can be activated with USEFLASHY = 0 in Config.mk.

Another option is the Python flash tool. It is used, when the USEFLASHY = option is completely left out, but needs the Python serial module.

[rsta2]

A OK, it's working. I did not read your recent post, before sending my post.