Circle - C++ bare metal environment (with USB)

[MikeDB]

If I read the Known Issues page on Githib correctly any USB device connected to the Pi using Circle has to be there at boot. Whilst adding plug and play would be a major task, I was wondering if it would be possible to just reset the USB initialisation handling, perhaps by use of a pushbutton to a GPIO pin, so as the rest of the processor carried on running.

Any thoughts ? Pointers on where to look in the code to do this ?

[Gavinmc42]

Don't remember if I have compiled and tried this on a Pi4.
https://github.com/raspberrypi/usbboot
Works on PC.

I normally use Ultibo for baremetal and that has only worked on 32bit Pi OS due to the 32bit FPC.
Buildroot on Gentoo64 had no issue compiling for 32 or 64bit Pi's.

Anyone using the 64bit Raspberry Pi OS for 32bit compiling?

[rst]

@MikeDB

Yes, the Circle USB stack does not support hot-plugging. In the main areas of applications based on Circle, time is important. On the Raspberry Pi 1-3 it would be relatively time consuming to poll the USB hubs all the time to be able to detect device plug-ins or removes. On the RPi 4 with its xHCI controller, this would not be a problem any more. Furthermore the whole Circle device handling is not prepared for plug and play. For example if an USB device would be occasionally removed, the current applications cannot react on this.

There is already a solution in Circle for USB mass-storage devices (e.g. flash drives), which can be attached or removed from a running system on application request. This should allow use cases for firmware updates in applications. Have a look at sample/39-umsdplugging for an example.

The USB hot-plugging support is still on my TODO list, but a quick solution is not in sight. When I pick this TODO item, it will probably take longer to implement it.

[MikeDB]

@MikeDB

Yes, the Circle USB stack does not support hot-plugging. .... On the RPi 4 with its xHCI controller, this would not be a problem any more.

There is already a solution in Circle for USB mass-storage devices (e.g. flash drives), which can be attached or removed from a running system on application request. This should allow use cases for firmware updates in applications. Have a look at sample/39-umsdplugging for an example.

The USB hot-plugging support is still on my TODO list, but a quick solution is not in sight. When I pick this TODO item, it will probably take longer to implement it.

My USB inputs are all MIDI but people do plug them in and out constantly whilst live - many keyboardists have a central switch box where they can switch (almost) any keyboard to (almost) any sound generator. This was easy in the DIN MIDI days but USB is somewhat more complicated.

Plan B is to add an external USB host controller such as Microchip USN2504 to deal with this but obviously a shame given the Pi4 does have the xHCI controller.

[LdB]

I must be missing something, I simply don't get the issue in that application Circle has threads doesn't it?
a.) Any new device announces itself to device 0 you just need a low priority thread to look for announcement and trigger rescan.
b.) If you are starting a new baremetal app you do a windows trick and initialize a rescan if you support USB devices.

Rst says he has an example of the rescan code above so you can already do (a) & (b).

That only leaves disconnects (pulled device out) but it was in use, which may crash and burn app which is exactly what happened in Windows95 if you didn't use the "eject safely icon". Okay not ideal but if a user pulls a USB device while in there is a degree of they got what they deserved. If it really worries you then you could look at what happens (I imagine it starts throwing USB comm errors) and then make a handler stub that goes into each app on the same low priority thread as (a).

BTW that is all the MCROCHIP usb stack does in USB_POLLING mode you must make a call to USBDeviceTasks() every 1.8mS maximum and in USB_INTERRUPT mode it handles the timing itself. There is no fancy plug and play or anything like that so there is irony in that it is considered being used.

[MikeDB]

I must be missing something, I simply don't get the issue in that application Circle has threads doesn't it?
a.) Any new device announces itself to device 0 you just need a low priority thread to look for announcement and trigger rescan.
b.) If you are starting a new baremetal app you do a windows trick and initialize a rescan if you support USB devices.

Rst says he has an example of the rescan code above so you can already do (a) & (b).

That only leaves disconnects (pulled device out) but it was in use, which may crash and burn app which is exactly what happened in Windows95 if you didn't use the "eject safely icon". Okay not ideal but if a user pulls a USB device while in there is a degree of they got what they deserved. If it really worries you then you could look at what happens (I imagine it starts throwing USB comm errors) and then make a handler stub that goes into each app on the same low priority thread as (a).

BTW that is all the MCROCHIP usb stack does in USB_POLLING mode you must make a call to USBDeviceTasks() every 1.8mS maximum and in USB_INTERRUPT mode it handles the timing itself. There is no fancy plug and play or anything like that so there is irony in that it is considered being used.

If you have a MIDI USB switch box switching downstream sources to upstream destinations then you are obviously going to have regular disconnects. My system needs to withstand those - crash and burn isn't an option. Remember even if the sound is muted there could be MIDI inputs appearing from other sources such as the central sequencer setting up the next patch so losing data would be disasterous.

If you can suggest something better than the Microchip solution please do. I'm still reading up on it and haven't even ordered an evaluation board yet. Obviously one solution would be a dedicated Pi running Linux but was trying to go a bit cheaper than that.

[rst]

@MikeDB I understand, what the problem is. I can have a look at USB host-plugging, but as I said, it will take time and I cannot make promises. Given that Circle is still a (basically one-man) hobby project and for a professional device I would recommend the Linux solution. Maybe I underestimate, what is possible with Circle, but I know it's not perfect and I don't want to overdo it.

@LdB Yes, Circle has threads (I call them tasks here), based on a cooperative scheduler. But this scheduler is not required in the system for all applications. Basic GPIO applications and the USB library can run without it. The scheduler is required, when TCP/IP or VCHIQ comes into play. I already thought about the "eject safely icon" solution earlier, but as I understand it, this wouldn't solve the problem here.

[MikeDB]

@MikeDB I understand, what the problem is. I can have a look at USB host-plugging, but as I said, it will take time and I cannot make promises. Given that Circle is still a (basically one-man) hobby project and for a professional device I would recommend the Linux solution. Maybe I underestimate, what is possible with Circle, but I know it's not perfect and I don't want to overdo it.

That would be great if you could have a look and obviously I'm not expecting a solution but would love to see one. Currently I have the project running well on Pi OS32 and staggering along on Pi OS64. But despite my best efforts with back-up power supplies and write protecting the memory card it's proven to be quite crashable/lockable-up by musicians and roadies who don't expect to shut down a musical instrument, just pull the plugs in and out as they please.

[rst]

@MikeDB OK, I will have a look on it. Powering off the device at any time should not be a problem with a bare metal solution.

[MikeDB]

@MikeDB OK, I will have a look on it. Powering off the device at any time should not be a problem with a bare metal solution.

Yes that's why I want to give up on Linux. Have you had any luck finding a VL805 datasheet ? Or documentation from RPi on how they have used it ?

[rst]

Have you had any luck finding a VL805 datasheet ? Or documentation from RPi on how they have used it ?

The VL805 is a standard xHCI 1.0 controller. The current revision 1.2 of the xHCI specification is here.

[rst]

@MikeDB I had a look on how USB plug-and-play (PnP) can be implemented in Circle. I found a way that both application types (PnP-aware and not PnP-aware) can coexist in Circle, so that existing applications do not need to be modified and new applications can use PnP. The initial attempt of implementing PnP in Circle is on GitHub and described in this issue. Still work has to be done to develop this towards USB PnP support in the next Circle release.

[MikeDB]

@MikeDB I had a look on how USB plug-and-play (PnP) can be implemented in Circle. I found a way that both application types (PnP-aware and not PnP-aware) can coexist in Circle, so that existing applications do not need to be modified and new applications can use PnP. The initial attempt of implementing PnP in Circle is on GitHub and described in this issue. Still work has to be done to develop this towards USB PnP support in the next Circle release.

Great news ! Thanks for everything and hopefully the next release will be what I need, and hopefully others as well.

[cleverca22]

Have you had any luck finding a VL805 datasheet ? Or documentation from RPi on how they have used it ?

The VL805 is a standard xHCI 1.0 controller. The current revision 1.2 of the xHCI specification is here.

i believe it emulates the xHCI standard after it has executed its firmware
but any time you do a pci-e bus reset, the firmware has to be reloaded, and then things start to go heavily non-standard

if the vl805 eeprom is present, it can load its own firmware, but it uses some host ram (via the pci BAR) for its own storage

but newer revisions lack that eeprom, so you need to mailbox the start4.elf to make it load the firmware for you

[timg236]

Have you had any luck finding a VL805 datasheet ? Or documentation from RPi on how they have used it ?

The VL805 is a standard xHCI 1.0 controller. The current revision 1.2 of the xHCI specification is here.

i believe it emulates the xHCI standard after it has executed its firmware
but any time you do a pci-e bus reset, the firmware has to be reloaded, and then things start to go heavily non-standard

if the vl805 eeprom is present, it can load its own firmware, but it uses some host ram (via the pci BAR) for its own storage

but newer revisions lack that eeprom, so you need to mailbox the start4.elf to make it load the firmware for you

Just look at the Linux kernel, on Pi4 1,2,4 GB it's bog-standard PCIe enumeration and XHCI code with no Pi or VIA specific behaviour required. So it's a bit misleading to say it's emulated or not XHCI standard.

There's a trivial mailbox required after PCI fundamental reset before bus mastering is enabled on the 8GB where the SPI EEPROM has been removed and SDRAM is used instead. Search for the patches on Linux, plan9, u-boot which already support that.

You'd have to ask VIA for a datasheet.

[rst]

Circle already has xHCI support, but without plug-and-play so far. That's going to be changed now. The property mailbox call for RPi 4B 8GB models is also included in the latest release.

[MikeDB]

Circle already has xHCI support, but without plug-and-play so far. That's going to be changed now. The property mailbox call for RPi 4B 8GB models is also included in the latest release.

8GByte in an embedded processor application ! I remember squeezing code into a 6805 with 8kbits (1kbyte) !

[rst]

Circle already has xHCI support, but without plug-and-play so far. That's going to be changed now. The property mailbox call for RPi 4B 8GB models is also included in the latest release.

8GByte in an embedded processor application ! I remember squeezing code into a 6805 with 8kbits (1kbyte) !

Honestly one can currently effectively use "only" 3GB of that memory with Circle. That was caused by some early RPi 4 DMA requirements, which I had discovered in the Linux code and which were handled there using temporary buffers. I don't know, if this technique is still used in Linux.

In any way this has not been implemented in Circle, because I wasn't able to test it on my own 2GB RPi 4. 3GB is the amount of memory, which can be used safely with Circle and should be sufficient for most embedded applications.

The property mailbox call for the 8GB RPi 4 is needed, so that USB can be used at all with Circle on this model.

[MikeDB]

Honestly one can currently effectively use "only" 3GB of that memory with Circle.

I'll struggle through

At 96kHz even 3Gbyte makes an 86 minute long stereo reverb

[rst]

Honestly one can currently effectively use "only" 3GB of that memory with Circle.

I'll struggle through

At 96kHz even 3Gbyte makes an 86 minute long stereo reverb

86 minutes should be enough.

[MikeDB]

Hello rst

I've started porting some of my code across to Circle and USB and audio are working well even if I can't hotplug the keyboards yet.
However I would like to not have a HDMI monitor present. I found this post from years ago :

Been trying to make some simple programs work but seem to be hitting a problem when initialising my CTimer object - execution just stops when I get the the command "m_Timer.Initialize()". been over and over the examples but can't find the problem.

The problem was sorted out using Email. The lesson from it is: Even if you do not have a display attached to a system using Circle do not remove the CLogger member and the logging device (CScreenDevice or CSerialDevice) from CKernel because there may be logging messages generated which may crash the system otherwise.

However it now seems to crash the system just by unplugging the monitor, as it does by trying to remove CLogger

I saw the comment about using a null CDevice but the PCIE and USB modules do produce comments which are useful to have sometimes, just not on a screen. I was therefore wondering if it is possible to override a single or possibly a few functions somewhere in the the CLogger and/or screen functions so that all such debugging is output to a file on the memory card ? I had a go at this based on the "15-files" sample but I just seem to still crash the system.

Any chance you could guide me as to where best to do this override ?

Many thanks

[rst]

Hello MikeDB,

the common logger target for Circle development without an attached monitor is the serial output over GPIO14 (SoC numbering) using the class CSerialDevice and an USB serial adapter on your development host. This is implemented in most sample programs. You only need to include the following option in the file cmdline.txt to enable the serial output:

Code: Select all

logdev=ttyS1

Another possibility to read the log messages without using a monitor is by using a syslog client over network. Please see sample/33-syslog for an example.

If you want to direct the log messages to a log file, I can create a special example, but you cannot switch off the Raspberry Pi at any time with this, because the log file must be closed and the file system unmounted. This must be triggered in some way by the user before switching off the power.

BTW. On the Raspberry Pi 4 the initialization of the class CBcmFrameBuffer and so of CScreenDevice will fail, if there isn't a monitor attached. You should not use CScreenDevice, if you're working without monitor. The system option SCREEN_HEADLESS is a workaround to use the samples without modification in this case and can be enabled in include/circle/sysconfig.h.

[MikeDB]

I'd just like to publicly thank Rene for all the work he has done helping me out by email and improving Circle for my application. The USB MIDI plugging/unplugging and multicore processing both appear bulletproof when compared to Linux/ALSA so if you've a high performance audio application that needs this Circle is most definitely the way to go !

[blippy]

I'd just like to publicly thank Rene for all the work he has done

Circle is really neat. There's a few guys on here who have done amazing work (thanks also go to Sean Lawless. I'm really planning on getting his book).

My only lamentation is that there's a lot of code that is necessary to get the hardware going. I had hoped to build something on my own from scratch, but I'm ever-approaching the conclusion that such an undertaking is not feasible.

[sean.lawless]

My only lamentation is that there's a lot of code that is necessary to get the hardware going. I had hoped to build something on my own from scratch, but I'm ever-approaching the conclusion that such an undertaking is not feasible.

Circle is based on Linux so the USB host driver has a lot of Linux system dependencies, as you mentioned (hence Circle OS). Personally I was excited about Circle but over time found it to be brittle and unremovable from the Linux system dependencies. I really tried to use Circle instead of writing a new USB host driver, but I just couldn't get Circle to work in the simplified, flexible, and modular way I wanted. But that does not mean it won't work for you.

Don't be afraid to leverage the work of others when building something of your own.