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

[rst]

I have uploaded the first step of my C++ bare metal environment for the Raspberry Pi to GitHub:

https://github.com/rsta2/circle (Tag "Step1")

Currently its function is very limited but later it will get an USB stack with support for USB keyboard, mass storage devices and the on-board Ethernet device. The USB stack is already running in a self-made OS kernel. For now the main goal was to setup the C++ build environment.

It should run on all existing models but I can only test it on model B and B+. Later these will be the only supported because of the required on-board USB hub.

Rene

[rst]

Step 2 of Circle is also on GitHub:

https://github.com/rsta2/circle/releases/tag/Step2

It adds frame buffer and MMU support.

The MMU support is not necessary for USB support later but I wanted to have the full performance for it (about 25 times faster in a simple delay loop).

[rst]

Step 3 of Circle is now on GitHub:

https://github.com/rsta2/circle/releases/tag/Step3

It writes text to screen and UART and adds a class to create log messages and some debug features.

[rst]

Step 4 of Circle is now on GitHub:

https://github.com/rsta2/circle/releases/tag/Step4

It adds interrupt support, an abort exception handler and extends the CTimer class by an interrupt driven uptime clock, kernel timers and a calibrated delay loop.

This is the last step without USB and the last which runs on model A for now.

[rst]

Step 5 of Circle is now on GitHub:

https://github.com/rsta2/circle/releases/tag/Step5

It adds an USB host controller interface (HCI) driver and an USB device class as a base class for USB function drivers.

An USB hub driver and function drivers for special devices is not included yet. They will come in the next steps.

[rst]

Step 6 of Circle is now on GitHub:

https://github.com/rsta2/circle/releases/tag/Step6

New features are an USB hub driver which should detect all high-speed devices and a function driver for the on-board USB Ethernet controller.

The sample program dumps all broadcast frames received on the network. The function driver is also able to send frames but this is not used here.

[rst]

Step 7 of Circle is now on GitHub:

https://github.com/rsta2/circle/releases/tag/Step7

The new feature in this step is an USB function driver for USB mass storage devices (e.g. USB flash device).

The sample program dumps the partition table from the master boot record. The function driver is also able to write to the device but this is not used here.

There is also a C port of the Circle USB library on GitHub:

https://github.com/rsta2/uspi

This library can be used in a C bare metal environment. It has currently the same features as in Circle Step7.

[tufty]

Nobody's been replying, but please carry on. This is excellent work.

[rst]

Nobody's been replying, but please carry on. This is excellent work.

Thank you! I will do so.

[macca]

There is also a C port of the Circle USB library on GitHub:

https://github.com/rsta2/uspi

This library can be used in a C bare metal environment. It has currently the same features as in Circle Step7.

Awesome! I have replaced the C++ implementation with that one and looks it is working well. I don't get the same MAC address I was getting with the C++ version but I suppose I'm not using the property tag correctly in that case.

May I ask you what have you used to convert from C++, I guess it is an automated tool ?

One suggestion: try to implement as much as possible to keep the library independent. Maybe use defines to include or exclude parts that others may have already implemented.

Great job!

[rst]

I don't get the same MAC address I was getting with the C++ version but I suppose I'm not using the property tag correctly in that case.

I think so because USPi only takes the MAC address you hand it over in GetMACAddress().

May I ask you what have you used to convert from C++, I guess it is an automated tool ?

I'm sorry there is not a tool. I'm also astonished how quick it can be converted that way by hand.

One suggestion: try to implement as much as possible to keep the library independent. Maybe use defines to include or exclude parts that others may have already implemented.

Can you tell me which parts you would like to exclude? At the moment I only see the functions in util.h (e.g. memcpy) which have a common interface. I have already commited a change to GitHub with which you can use your own implementation of these functions. This has to be enabled in uspios.h (top section).

Thank you!

[macca]

I'm sorry there is not a tool. I'm also astonished how quick it can be converted that way by hand.

Brilliant, I never thought it was that easy.

Can you tell me which parts you would like to exclude? At the moment I only see the functions in util.h (e.g. memcpy) which have a common interface. I have already commited a change to GitHub with which you can use your own implementation of these functions. This has to be enabled in uspios.h (top section).

Actually it is the opposite. I see that it requires a number of external implementations, some of which are common and should not cause any conflict with existing code like Enter/ExitCritical, the delay functions, etc., others seems to require a bit of knowledge of how the library works, specifically ConnectInterrupt and the timer functions. I had a bit of difficult implementing these and ended up converting the C++ classes that already works the way you expect them.

Indeally, I think that the library should be self contained and not require any external implementation, with a note that consumers must setup the interrupt vectors to call the library interrupt handler function. Defines can be used to exclude functions/implementations that others may have already implement in own kernels, or isolate them in a source file that can be easily replaced. Take the csud example, it has make defines to compile as standalone without external dependencies, or lowlevel driver which requires external implementations.

What do you think ?

[rst]

Now I understand your intention. Actually I thought USPi should be a library mainly for existing C environments with interrupt and timer support and should add simply USB support.

Alex Chadwick did a great job to make CSUD easy to be used. USPi needs some more functions. Providing all that other needed functions would mean in fact to port lots of the whole Circle to C.

At the moment I want to finish the USB support first. Then I will re-think my goals. Also Circle does not need to be finished when the USB support is completed. I will need some time to find an answer for this question.

Thanks again!

[rst]

Step 8 of Circle is now on GitHub:

https://github.com/rsta2/circle

The USB support is completed now with the USB keyboard driver included.

I will continue to develop Circle as an environment to build bare metal applications but maybe I won't announce any news in this forum because I don't want to flood it. Please look at GitHub if you are further interested in Circle!

[rst]

I have one thing to add. As noted the Circle USB library and USPi are running on Raspberry Pi Model B and B+ only. That means it is not running on the new Model A+ and the Compute Module too.

I have updated the model check in Circle and USPi for Model A+. Please update to the new revision on master branch if have cloned the repository!

The OS interface of USPi has slightly changed: IsModelA() is replaced by GetBoardRevision() in uspios.h.

Perhaps I will order a new Model A+ to overcome this situation.

[tufty]

Is there a reason you haven't separated the "USB" stuff from the "keyboard" stuff?

[rst]

Is there a reason you haven't separated the "USB" stuff from the "keyboard" stuff?

I thought about where to put the keyboard mapping stuff. I think it is tightly bound to the USB keyboard driver because it works with USB physical key codes. I don't wanted to create another library to keep it small. So I had to decide to put it in the base lib or in in the USB lib. But without USB it is currently not useable.

I think in Linux there is another layer of indirection. The physical codes from the USB keyboard will be translated into intermediate codes which are the same for all keyboard interfaces. If we would have another keyboard interface on the Pi perhaps it should be separated. Of course this can be done if such an interface exists. Also there are other functions which could be useful for the keyboard/screen combo (e.g. a line discipline).

Do you think we should have a console library or something like that?

[tufty]

I'm not sure how you want to play it, but...

I'd probably start by thinking about isolating the HID interface from the USB interface, and the Keyboard interface from the HID interface. I'd almost certainly create a "concrete" USB HID class and a generic "input stream", and then do individual device drivers via composition - "this actual keyboard" is an input stream, has a keyboard behaviour, has a usb hid interface. "this mouse" is an input device, has a mouse behaviour, has a usb hid interface.

that way, if you wan to use, for example, a bluetooth keyboard, "all" you have to implement is the bluetooth HID stack. Or, for a PS/2 keyboard, a faked PS/2 HID stack.

[rst]

I thought more in devices but in interfaces and streams. Currently an "USB keyboard" is an "USB device" is a "device" and may be a "character file" and a "file". This is a simple abstraction which makes it easy to be used it in a Linux-like system.

But your approach is interesting. I'm not sure if it can easily integrated into the current Circle where it is especially important that each USB device class derives from CUSBDevice (problem with "stream" and "input device"). The "USB interface" is inherently bound to CUSBDevice.

But perhaps keyboard and mouse behaviour can be a dedicated classes. Perhaps there should be an CUSBHIDDevice which adds the HID interface to CUSBDevice. For a bluetooth keyboard there could be a CBTHIDDevice which has also a "keyboard behaviour".

I have to further think about it and will see what I can do.

[rst]

Circle USB should run on all existing Raspberry Pi models now (tested on A+, B and B+). An USB mouse driver was added.

In the new addon library directory there is a ported library which controls devices via the 1-Wire protocol (e.g. the DS18S20 temperature sensor).

Please use the head revision if you are interested in Circle:

https://github.com/rsta2/circle

[jspeccy]

I'm really astonished by your great work. Circle is a wonderful framework to create bare metal applications.

I'm a spaniard user, so I've created a keymap for spanish keyboards (without dead keys, of course). How can I send my keymap_es.h to you?

Another question is that I have a HP USB keyboard with a SmartCard reader, so the sample 08 don't watch any keypress. What can I do about this?

Thanks by your wonderful work (and excuse me, please, by my [very] bad english)

Best Regards
Jose Luis

[rst]

I'm really astonished by your great work. Circle is a wonderful framework to create bare metal applications.

Thank you!

I'm a spaniard user, so I've created a keymap for spanish keyboards (without dead keys, of course). How can I send my keymap_es.h to you?

That's nice. Please send it to the Email address noted in the header of most source code files of Circle. Thanks!

Another question is that I have a HP USB keyboard with a SmartCard reader, so the sample 08 don't watch any keypress. What can I do about this?

I can have a look at the configuration descriptor of the keyboard. I can give you further info how to get it when you write to me. But unfortunately I cannot make you much hope. I think this is a proprietary device which needs special software and special information to create it.

[mimi123]

Can you make a without interrupts in C without any ASM not using mailboxes?

(for bare-metal VideoCore)

[rst]

Can you make a without interrupts in C without any ASM not using mailboxes?

(for bare-metal VideoCore)

Sorry, I want to focus on the ARM side. But if it is possible and it makes sense: There is a C port of main Circle functions (including a new USPi environment library). See the USPi topic! Perhaps somebody wants to move it on the VideoCore?

[mimi123]

Can you make a without interrupts in C without any ASM not using mailboxes?

(for bare-metal VideoCore)

Sorry, I want to focus on the ARM side. But if it is possible and it makes sense: There is a C port of main Circle functions (including a new USPi environment library). See the USPi topic! Perhaps somebody wants to move it on the VideoCore?

A C compiler works fully on the VideoCore but interrupts are not managed.