Circle is a C++ bare metal programming environment for the Raspberry Pi.



If you read this file in an editor you should switch line wrapping on.


Circle is a C++ bare metal programming environment for the Raspberry Pi. It should be usable on all existing models (tested on model A+, B, B+, on Raspberry Pi 2, 3, 4, 400 and on Raspberry Pi Zero), except on the Raspberry Pi Pico, which is not supported. The new Raspberry Pi Zero 2 W is not supported yet. Circle provides several ready-tested C++ classes and add-on libraries, which can be used to control different hardware features of the Raspberry Pi. Together with Circle there are delivered several sample programs, which demonstrate the use of its classes. Circle can be used to create 32-bit or 64-bit bare metal applications.

Circle includes bigger (optional) third-party C-libraries for specific purposes in addon/ now. This is the reason why GitHub rates the project as a C-language-project. The main Circle libraries are written in C++ using classes instead. That's why it is named a C++ programming environment.

Release 44.2

This intermediate release supports USB HID-class touchscreens in digitizer mode now, which has been tested with the Waveshare 5 inch LCD B and 7 inch LCD C displays. Such USB touchscreens will be detected automatically, when the USB support is included in an application, and an instance of the class CTouchScreenDevice will be created, which provides the generic API for touchscreens. Please note that the class CTouchScreenDevice was the driver for the official 7 inch Raspberry Pi touchscreen before, which has been renamed to CRPiTouchScreen now. Existing applications, which support the official 7 inch Raspberry Pi touchscreen, have to be modified this way. sample/28-touchscreen and the LVGL and uGUI wrappers have been updated to support both the official 7 inch Raspberry Pi touchscreen and USB HID-class touchscreens in digitizer mode. There is a new calibration tool in tools/touchscreen-calibrator, which allows to gather the calibration info for USB touchscreens, which require calibration.

The I2S sound device driver supports I2S sound input now. This is demonstrated in sample/42-i2sinput. See the file README in this directory for more info on using this sample program. The recognized I2S format is the same as the format, which is generated by the driver for output (2 channels with 32-bit width and 24-bit signed data).

There has been an inconsistency with SoundFormatSigned24 in the sound drivers, because there are two different variants of it: one 24-bit format, which occupies 3 bytes per sample and one, which occupies 4 bytes per sample (value of one byte ignored). Previously the 4-bytes-format was used for CI2SSoundBaseDevice::Write(), if SoundFormatSigned24 was selected as write format with 2 channels. For all other sound devices the 3-bytes-format was used. To fix this, a new SoundFormatSigned24_32 is introduced, which is the 4-bytes-format. SoundFormatSigned24 is now the 3-byte format in any case. In existing applications, which use CI2SSoundBaseDevice::Write(), it may be necessary to change the parameter of SetWriteFormat() to SoundFormatSigned24_32.

Further improvements:

  • Class CScreenDevice supports ANSI colors (see doc/screen.txt).
  • Class CSerialDevice supports setting specific line parameters now and registers different device names, when used with nDevice > 0 on the Raspberry Pi 4.
  • Add class CBcmWatchdog, which controls the watchdog device of the Raspberry Pi.
  • Add MCP3004/3008 DAC driver and sample to addon/sensor.
  • Update LVGL graphics support to v7.11.0. The screen resolution is variable now up to 1920x1080.
  • The USB CDC-class serial driver (class CUSBSerialCDCDevice) should be compatible with Arduino devices now.

Don't forget to update the used firmware to the one downloadable in boot/! The recommended toolchain is GCC 10.3.1 based now.

The 44th Step

This release comes with new features, improvements and bug fixes. There is a new HDMI sound driver class CHDMISoundBaseDevice, which allows to generate HDMI sound without VCHIQ driver, which can be easier to integrate in an application. This is shown by the sample/29-miniorgan and sample/34-sounddevices. On the Raspberry Pi 4 only the connector HDMI0 is supported. The class CI2SSoundBaseDevice now supports the PCM5122 DAC.

A new class C2DGraphics has been added to the base library, which provides 2D drawing routines, which work without flickering or screen tearing. This is demonstrated in the sample/41-screenanimations.

The scheduler library has been improved and provides the new classes CMutex and CSemaphore. Multiple tasks can wait for a CSynchronzationEvent to be set now.

There is a new serial bootloader and flash tool (Flashy), which improves the download speed and reliability. Please see the second part of the file doc/bootloader.txt for more information! You can interrupt the download process with Ctrl-C now and start again, without resetting your Raspberry Pi. You should update your bootloader kernel image(s) on the SD card in any case. The old flash tool is still available.

Circle comes with a configure script now, which can be used to create the configuration file easier. Please enter configure -h for a description of its options.

The C++ support has been improved. Now placement new operators and static objects inside of a function can be used. Furthermore the C++17 standard is optionally supported and can be enabled with the option --c++17 of configure, if you have a toolchain version, which supports it.

Further improvements:

  • There is a new system option NO_BUSY_WAIT. With this option enabled, the EMMC, SDHOST and USB drivers will not busy wait for the completion of synchronous transfers any more. This should improve system throughput and network latency, but requires the scheduler in the system.
  • The embedded MMC memory of the Compute Module 4 can be accessed, when the system option USE_EMBEDDED_MMC_CM4 has been defined.
  • The class CTFTPFatFsFileServer was added to addon/tftpfileserver to support TFTP access with the FatFs filesystem module.
  • The class CDS18x20 in addon/OneWire has been improved and is now part of the library, not of the sample as before. It determines the used power mode of the sensor automatically.
  • Functions for atomic memory access have been added to .

Bug fixes:

  • System timer IRQ handling may have stopped working after a while on the Raspberry Pi 1 and Zero before.
  • xHCI USB controller did not work on some Raspberry Pi 4 models.
  • Starting secondary cores 1-3 was not reliable.
  • Access to USB mass-storage devices was not reliable on Raspberry Pi Model A+, 3A+ and Zero before.
  • Add workaround for non-compliant low-speed USB devices with bulk endpoints.
  • Suppress concurrent split IN/OUT requests on Raspberry Pi 1-3 and Zero in USB serial drivers.
  • Enable serial FIFO in polling mode too.
  • The screen size select-able in cmdline.txt was limited to 1920x1080 before.
  • Semaphore implementation in addon/linux was not IRQ safe, but used from IRQ handler in VCHIQ driver.
  • Allow received text segment in TCP state SYN-RECEIVED.

Don't forget to update the used firmware to the one downloadable in boot/!


Circle supports the following features:

Group Features
C++ build environment AArch32 and AArch64 support
Basic library functions (e.g. new and delete)
Enables all CPU caches using the MMU
Interrupt support (IRQ and FIQ)
Multi-core support (Raspberry Pi 2, 3 and 4)
Cooperative non-preemtive scheduler
CPU clock rate management
Debug support Kernel logging to screen, UART and/or syslog server
C-assertions with stack trace
Hardware exception handler with stack trace
GDB support using rpi_stub (Raspberry Pi 2 and 3)
Serial bootloader (by David Welch) included
Software profiling support (single-core)
QEMU support
SoC devices GPIO pins (with interrupt, Act LED) and clocks
Frame buffer (screen driver with escape sequences)
UART(s) (Polling and interrupt driver)
System timer (with kernel timers)
Platform DMA controller
EMMC SD card interface driver
SDHOST SD card interface driver (Raspberry Pi 1-3)
PWM output (2 channels)
PWM sound output (on headphone jack)
I2C master(s) and slave
SPI0 master (Polling and DMA driver)
SPI1 auxiliary master (Polling)
SPI3-6 masters of Raspberry Pi 4 (Polling)
I2S sound output and input
HDMI sound output (without VCHIQ)
Hardware random number generator
Watchdog device
Official Raspberry Pi touch screen
VCHIQ interface and audio service drivers
BCM54213PE Gigabit Ethernet NIC of Raspberry Pi 4
Wireless LAN access (experimental)
USB Host controller interface (HCI) drivers
Standard hub driver (USB 2.0 only)
HID class device drivers (keyboard, mouse, gamepad)
Driver for on-board Ethernet device (SMSC951x)
Driver for on-board Ethernet device (LAN7800)
Driver for USB mass storage devices (bulk only)
Drivers for different USB serial devices
Audio class MIDI input support
Touchscreen driver (digitizer mode)
Printer driver
File systems Internal FAT driver (limited function)
FatFs driver (full function, by ChaN)
TCP/IP networking Protocols: ARP, IP, ICMP, UDP, TCP
Clients: DHCP, DNS, NTP, HTTP, Syslog, MQTT
Servers: HTTP, TFTP
BSD-like C++ socket API
Graphics OpenGL ES 1.1 and 2.0, OpenVG 1.1, EGL 1.4
(not on Raspberry Pi 4)
uGUI (by Achim Doebler)
2D graphics class in base library
Not supported Bluetooth
USB device (gadget) mode
USB isochronous transfers and audio


For building 64-bit applications (AArch64) see the next section.

This describes building on PC Linux. See the file doc/windows-build.txt for information about building on Windows. If building for the Raspberry Pi 1 you need a toolchain for the ARM1176JZF core (with EABI support). For Raspberry Pi 2/3/4 you need a toolchain with Cortex-A7/-A53/-A72 support. A toolchain, which works for all of these, can be downloaded here. Circle has been tested with the version 10.3-2021.07 (gcc-arm-10.3-2021.07-x86_64-arm-none-eabi.tar.xz) from this website.

First edit the file and set the Raspberry Pi version (RASPPI, 1, 2, 3 or 4) and the PREFIX of your toolchain commands. Alternatively you can create a file (which is ignored by git) and set the Raspberry Pi version and the PREFIX variable to the prefix of your compiler like this (don't forget the dash at the end):

PREFIX = arm-none-eabi-

The following table gives support for selecting the right RASPPI value:

RASPPI Target Models Optimized for
1 kernel.img A, B, A+, B+, Zero, (CM) ARM1176JZF-S
2 kernel7.img 2, 3, (CM3) Cortex-A7
3 kernel8-32.img 3, (CM3) Cortex-A53
4 kernel7l.img 4B, 400, CM4 Cortex-A72

For a binary distribution you should do one build with RASPPI = 1, one with RASPPI = 2 and one build with RASPPI = 4 and include the created files kernel.img, kernel7.img and kernel7l.img. Optionally you can do a build with RASPPI = 3 and add the created file kernel8-32.img to provide an optimized version for the Raspberry Pi 3.

The configuration file can be created using the configure tool too. Please enter ./configure -h for help on using it!

There are a number of configurable system options in the file include/circle/sysconfig.h. Please have a look into this file to learn, how you can configure Circle for your purposes. Some hardware configurations may require modifications to these options (e.g. using USB on the CM4).

Then go to the build root of Circle and do:

./makeall clean

By default only the latest sample (with the highest number) is build. The ready build kernel.img file should be in its subdirectory of sample/. If you want to build another sample after makeall go to its subdirectory and do make.

You can also build Circle on the Raspberry Pi itself (set PREFIX = (empty)) on Raspbian but you need some method to put the kernel.img file onto the SD(HC) card. With an external USB card reader on model B+ or Raspberry Pi 2/3/4 model B (4 USB ports) this should be no problem.


Circle supports building 64-bit applications, which can be run on the Raspberry Pi 3 or 4. There are also Raspberry Pi 2 versions, which are based on the BCM2837 SoC. These Raspberry Pi versions can be used too.

The recommended toolchain to build 64-bit applications with Circle can be downloaded here. Circle has been tested with the version 10.3-2021.07 (gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf.tar.xz) from this website.

There are distro-provided toolchains on certain Linux platforms (e.g. g++-aarch64-linux-gnu on Ubuntu or gcc-c++-aarch64-linux-gnu on Fedora), which may work with Circle and can be a quick way to use it, but you have to test this by yourself. If you encounter problems (e.g. no reaction at all, link failure with external library) using a distro-provided toolchain, please try the recommended toolchain (see above) first, before reporting an issue.

First edit the file and set the Raspberry Pi architecture (AARCH, 32 or 64) and the PREFIX64 of your toolchain commands. The RASPPI variable has to be set to 3 or 4 for AARCH = 64. Alternatively you can create a file (which is ignored by git) and set the Raspberry Pi architecture and the PREFIX64 variable to the prefix of your compiler like this (don't forget the dash at the end):

AARCH = 64
PREFIX64 = aarch64-none-elf-

The configuration file can be created using the configure tool too. Please enter ./configure -h for help on using it!

Then go to the build root of Circle and do:

./makeall clean

By default only the latest sample (with the highest number) is build. The ready build kernel8.img or kernel8-rpi4.img file should be in its subdirectory of sample/. If you want to build another sample after makeall go to its subdirectory and do make.


Copy the Raspberry Pi firmware (from boot/ directory, do make there to get them) files along with the kernel.img (from sample/ subdirectory) to a SD(HC) card with FAT file system. Put the SD(HC) card into the Raspberry Pi.

The config32.txt file, provided in the boot/ directory, is needed to enable FIQ use in 32-bit mode on the Raspberry Pi 4 and has to be copied to the SD card in this case (rename it to config.txt). Furthermore the additional file armstub7-rpi4.bin is required on the SD card then. Please see boot/README for information on how to build this file.

The config64.txt file, provided in the boot/ directory, is needed to enable 64-bit mode and has to be copied to the SD card in this case (rename it to config.txt). FIQ support for AArch64 on the Raspberry Pi 4 requires an additional file armstub8-rpi4.bin on the SD card. Please see boot/README for information on how to build this file.


  • include: The common header files, most class headers are in the include/circle/ subdirectory.
  • lib: The Circle class implementation and support files (other libraries are in subdirectories of lib/).
  • sample: Several sample applications using Circle in different subdirectories. The main function is implemented in the CKernel class.
  • addon: Contains contributed libraries and samples (has to be build manually).
  • app: Place your own applications here. If you have own libraries put them into app/lib/.
  • boot: Do make in this directory to get the Raspberry Pi firmware files required to boot.
  • doc: Additional documentation files.
  • test: Several test programs, which test different features of Circle.
  • tools: Tools for building Circle and for using Circle more comfortable (e.g. a serial bootloader).


The following C++ classes were added to Circle:

Base library

  • C2DGraphics: Software graphics library with VSync and hardware-accelerated double buffering
  • CBcmWatchdog: Driver for the BCM2835 watchdog device
  • CDMASoundBuffers: Concatenated DMA buffers to be used by sound device drivers
  • CGenericLock: Locks a resource with or without scheduler
  • CHDMISoundBaseDevice: Low level access to the HDMI sound device (without VCHIQ)

USB library

  • CUSBTouchScreenDevice: Driver for USB HID-class touchscreens

Input library

  • CRPiTouchScreen: Driver for the official Raspberry Pi touch screen
  • CTouchScreenDevice: Generic touch screen interface device

Scheduler library

  • CMutex: Provides a method to provide mutual exclusion (critical sections) across tasks
  • CSemaphore: Implements a semaphore synchronization class

The available Circle classes are listed in the file doc/classes.txt. If you have Doxygen installed on your computer you can build a class documentation in doc/html/ using:


At the moment there are only a few classes described in detail for Doxygen.

Additional Topics


Raspberry Pi is a trademark of the Raspberry Pi Foundation.

Linux is a trademark of Linus Torvalds.

PS3 and PS4 are registered trademarks of Sony Computer Entertainment Inc.

Windows, Xbox 360 and Xbox One are trademarks of the Microsoft group of companies.

Nintendo Switch is a trademark of Nintendo.

Khronos and OpenVG are trademarks of The Khronos Group Inc.

OpenGL ES is a trademark of Silicon Graphics Inc.

The micro:bit brand belongs to the Micro:bit Educational Foundation.

HDMI is a registered trademark of HDMI Licensing Administrator, Inc.

  • Idea: MiniDexed, a FM synthesizer on Circle

    Idea: MiniDexed, a FM synthesizer on Circle

    Dexed is a multi platform, multi format synth that is closely modeled on the famous DX7 synthesizer by a well-known Japanese manufacturer. While implements subtractive "analog" synthesis, Dexed implements additive "digital" FM synthesis. So it would be a great complement.

    I am wondering whether Dexed could be ported to Circle, in order to recreate basically an open source equivalent of the TX802 (8 DX7 instances without the keyboard in one box).

    Dexed has a sound engine written in C++ and has already been ported to:

    The author of MicroDexed says he'd be happy to see a it on Raspi-bare-metal and while he doesn't have the time to do the port on his own, he is happy to help by answering questions. I hope a lot could be reused from, but the sound engine would have be to swapped out.

    Performance wise, a Raspberry Pi 4 1GB running REAPER on Linux could handle 8 (and probably more) instances of Dexed simultaneously in my tests. And it looks like a lot of code, e.g., for handling USB MIDI keyboards, etc. is already there in minisynth.

    opened by probonopd 68
  • Alpha GDB Stubs

    Alpha GDB Stubs


    A user asked for debugging Circle with our GDB stubs ( There was almost nothing else to do other than using your existing USE_RPI_STUB_AT macro, but I couldn't properly provide the cache-coherent memory region to Circle.

    So by changing current assumptions on cache-coherency and by making them explicit everywhere in Circle, I could make it work with a memory mapping other than the default one (we chose a MMU configuration working for every RPi model). It also has the benefit of clearly stating what memory access properties Circle requires: one with cache-coherency, one uncached, etc.

    To do so, I basically modified GetCoherentPage() to no longer assume 0x0... is cache-coherent, and introduced GetUncachedAlias() to get the uncached alias of a memory pointer. I then replaced every GPU_MEM_BASE + ... with a call to it. Note that they should be reviewed as I wasn't every time sure of whether or not getting the uncached alias was really intended.

    So changing the MMU configuration is a matter of setting the different macros. For example, to debug Circle with our gdb stubs:

    CFLAGS += -DUSE_RPI_STUB_AT=0x7F00000 -DGPU_IO_BASE=0x80000000 \
              -DGPU_UNCACHED_BASE=0x40000000 -DGPU_CACHE_COHERENT_BASE=0x40000000 \
    OPTIMIZE := -O0 -g3 -ggdb

    This PR is mostly to start discussing. We could definitely go much further and make debugging a first-class feature of Circle. Among our best features: GDB multi-core debugging, GDB semihosting (for example to print Circle logs in GDB's console), and GDB's stop signal.

    opened by Julio-Guerra 30
  • Add support for WM8960 to CI2SSoundBaseDevice

    Add support for WM8960 to CI2SSoundBaseDevice

    I've added i2c init commands for WM8960, based on raspiaudio Ultra++ hat.

    Another change is trying to detect DAC type automatically, basing on found i2c devices.

    opened by matemaciek 27
  • support for USB mouse HID report protocol

    support for USB mouse HID report protocol

    This can be considered an initial PR attempt as the code can be further improved and debugged, but I'm throwing it out there for others to tests and comment. Also the coding style might not match the rest of the code base. Some code, specifically TMouseReport storage and its use in the CUSBMouseDevice::ReportHandler(), and the bit to integer extraction code CUSBMouseDevice::ExtractUnsigned() should be looked into. Major parts and ideas were adopted from this driver and that brings the possibility of creating a more generic HID report parsing, that could be used by all USB HID devices in the future. One thing to note is that the HID report descriptors are quite versatile and flexible as I found out in the last couple of days, and parsing them out in a safe and generic way might be a quite a challenge. So far, I tested this with three different USB mice, all with differing HID report descriptor content and layout.

    A a direct consequence of the this change, support for mouse wheel is demonstrated in the updated 10-usbmouse sample.

    Here are the HID report descriptors I tested this with parsed.log.

    Here is the example serial dump of the detected USB mouse with the HID report descriptor and parsed report items:

    logger: Circle 43.1 started on Raspberry Pi Zero W                                     
    00:00:01.00 timer: SpeedFactor is 1.00                                                 
    00:00:01.36 usbdev0-1: Device ven248a-8367 found
    00:00:01.37 usbdev0-1: Interface int3-1-2 found
    00:00:01.37 usbdev0-1: Using device/interface int3-1-2
    00:00:01.38 usbdev0-1: Interface int3-1-1 found
    00:00:01.38 usbdev0-1: Using device/interface int3-1-1
    00:00:01.44 umouse: Report descriptor
    00:00:01.45 umouse: Dumping 0x8E bytes starting at 0x50B120
    00:00:01.45 umouse: B120: 05 01 09 02 A1 01 85 01-09 01 A1 00 05 09 19 01
    00:00:01.46 umouse: B130: 29 05 15 00 25 01 95 05-75 01 81 02 95 01 75 03
    00:00:01.46 umouse: B140: 81 01 05 01 09 30 09 31-15 81 25 7F 75 08 95 02
    00:00:01.47 umouse: B150: 81 06 09 38 15 81 25 7F-75 08 95 01 81 06 C0 C0
    00:00:01.48 umouse: B160: 05 0C 09 01 A1 01 85 03-75 10 95 02 15 01 26 8C
    00:00:01.48 umouse: B170: 02 19 01 2A 8C 02 81 00-C0 05 01 09 80 A1 01 85
    00:00:01.49 umouse: B180: 04 75 02 95 01 15 01 25-03 09 82 09 81 09 83 81
    00:00:01.50 umouse: B190: 60 75 06 81 03 C0 05 01-09 00 A1 01 85 05 06 00
    00:00:01.50 umouse: B1A0: FF 09 01 15 81 25 7F 75-08 95 07 B1 02 C0 A2 D2
    00:00:01.51 umouse: Report ID 1, size 5 bytes, item count 4
    00:00:01.52 umouse: [0] item ID 1 offset 8, count 5
    00:00:01.52 umouse: [1] item ID 2 offset 16, count 8
    00:00:01.52 umouse: [2] item ID 3 offset 24, count 8
    00:00:01.53 umouse: [3] item ID 4 offset 32, count 8
    00:00:01.54 dwroot: Device configured
    00:00:01.54 kernel: Compile time: Oct 18 2020 15:36:14
    00:00:01.55 kernel: Mouse attached

    Looking forward to your comments and ideas!


    opened by hinxx 19
  • Serial.Read() randomly crashing

    Serial.Read() randomly crashing


    I've noticed after a lot of investigations that calling Serial.Read() may crash the Raspberry PI 3B+ (happens anywhere between 1min / 2 hours in my program). It's random, but a way of making it crash very fast is to send serial data to the raspberry and call Read() in a loop without the program doing other things, like in this minimal example : I test it using MIDI data (sent by my computer through an USB/MIDI adapter, then fed into an optocoupler and some resistors then to the RPI's GPIO). I use this file because it has a lot of events so it also helps crashing it faster :

    If no serial data is sent, Read() is fine and will never crash. The problems shows only when there is a least one byte to read.

    If you uncomment line 45 to make Read() calls less frequent, it will take more time for it to crash.

    It's not dependant of the total bytes received, in my real program it crashed anywhere between 300KB/3MB of data received.

    When it crashes, either the Raspeberry freezes, or the error is catch by your ExceptionHandler and it's always a Prefetch Abort error, FSR = 0xD (permission error according to the ARM docs)

    I've tried your example #29 (miniorgan) and managed to crash it (I just rewrote the GetChunk with a loop that write zero's so it's not much busy and can crash in less than one minute). I don't get much Prefetch Abort errors here but freezes and sometimes this message just before :

    interrupt.cpp(122): assertion failed: FIQData.pHandler == 0

    Do you know what may happen ? I can do more tests if you want, since it may not be that easy for you to setup.

    opened by ghost 19
  • Output jitter/latency after interrupt (caused by the network components ?)

    Output jitter/latency after interrupt (caused by the network components ?)


    My program needs to receive some bit patterns through TCP/IP and then write them to an output after a synchronization signal. To make it easier to understand it would be used to print a layer in a micro-scale printer, so the bit patterns being send are the lines of the layer.

    My program is working as expected, the TCP/IP communication is working perfectly and an (fast) interrupt is being used to start the writing, listening to the sync signal.

    The problem that I found was that there is a a random latency between the synchronization signal and the time it is starting to write the bitpatern(varying from 20 to 50 ns). As you can imagine this will cause misalignment between the lines, since the lines are not being written with a fixed latency after the sync signal. A jitter of 5 ns would be acceptable. Note that the latency itself is not a problem if it has a fix value.

    Another aspect that I noticed is that if I hard code the bit pattern in the Pi code and remove all the network, removing CDWHCIDevice, CScheduler and CNetSubSystem, there is no jitter in the output, it works smoothly and precisely. However I really need to have the TCP/IP communication.

    Therefore, my questions are:

    1. why adding the network (TCP/IP communication) is causing random latency reacting to the interrupt and how can I have all the core processing power to execute the writing of the bit pattern, in order to remove the jitter/random latency ?
    2. is there any way to halt all the communication layers when I want to start the writing process? This might be enough to correct the problem.


    • I'm using a Raspberry Pi 3+.
    • Before starting to listen to the fast interrupt I'm entering in critical mode (using EnterCritical(IRQ_LEVEL); ).
    • I'm using "#define REALTIME" in sysconfig.h, because it is a time critical program
    • I suspect that the CDWHCIDevice instantiation is causing some delays in the program execution.

    Looking forward to hear from you

    opened by fmcoelho8 18
  • assertion failed: m_pURB == pURB

    assertion failed: m_pURB == pURB

    I'm attaching two cases of failures seen running sample/10-usbmouse sample. This was provoked by removing / attaching some mice I have.

    00:03:12.01 dwhci: Transaction failed (status 0x202)
    00:03:12.51 dwhci: Transaction failed (status 0x202)
    00:03:13.01 dwhci: Transaction failed (status 0x202)
    00:03:13.51 dwhci: Transaction failed (status 0x202)
    00:03:13.86 kernel: Mouse removed
    00:03:13.86 kernel: Please attach an USB mouse!
    00:03:13.87 usbdev0-1: Device ven46d-c539 removed
    00:03:36.25 usbhiddevice.cpp(221): stack[11] is 0x140B0
    00:03:36.25 usbhiddevice.cpp(221): stack[13] is 0xB3FC
    00:03:36.25 usbhiddevice.cpp(221): stack[17] is 0xB654
    00:03:36.25 usbhiddevice.cpp(221): stack[20] is 0xBBF4
    00:03:36.25 usbhiddevice.cpp(221): stack[23] is 0xB314
    00:03:36.25 usbhiddevice.cpp(221): stack[35] is 0xBAD0
    00:03:36.25 usbhiddevice.cpp(221): stack[47] is 0xBBF4
    00:03:36.25 usbhiddevice.cpp(221): stack[51] is 0x24688
    00:03:36.25 usbhiddevice.cpp(221): stack[53] is 0x24748
    00:03:36.25 usbhiddevice.cpp(221): stack[54] is 0x1BF44
    00:03:36.25 usbhiddevice.cpp(221): stack[63] is 0x2478C
    00:03:36.25 usbhiddevice.cpp(221): assertion failed: m_pURB == pURB
    00:00:42.64 dwhci: Transaction failed (status 0x202)
    00:00:42.64 dwhci: Transaction failed (status 0x202)
    00:00:42.64 dwhci: Transaction failed (status 0x202)
    00:00:42.64 kernel: Mouse removed
    00:00:42.64 kernel: Please attach an USB mouse!
    00:00:42.64 usbdev0-1: Device ven46d-c539 removed
    00:00:42.64 usbhiddevice.cpp(228): stack[11] is 0x14144
    00:00:42.64 usbhiddevice.cpp(228): stack[13] is 0xB3FC
    00:00:42.64 usbhiddevice.cpp(228): stack[17] is 0xB654
    00:00:42.64 usbhiddevice.cpp(228): stack[20] is 0xBBF4
    00:00:42.64 usbhiddevice.cpp(228): stack[23] is 0xB314
    00:00:42.64 usbhiddevice.cpp(228): stack[35] is 0xBAD0
    00:00:42.64 usbhiddevice.cpp(228): stack[47] is 0xBBF4
    00:00:42.64 usbhiddevice.cpp(228): stack[51] is 0x24730
    00:00:42.64 usbhiddevice.cpp(228): stack[53] is 0x247F0
    00:00:42.64 usbhiddevice.cpp(228): stack[54] is 0x1BF44
    00:00:42.64 usbhiddevice.cpp(228): stack[63] is 0x24834
    00:00:42.64 usbhiddevice.cpp(228): assertion failed: m_pURB == pURB

    Seems both cases were provoked by removing device ven46d-c539. The same device is very prone to make dwhci: Transaction failed (status 0x202) appear.

    opened by hinxx 17
  • Bluetooth not Initializing at Rpi Zero W

    Bluetooth not Initializing at Rpi Zero W


    First, sry for my english... I will be more clear possible.

    I am using u library in my projetct, where i am using Rpi Zero W with a TFT with Touch. All is working fine, but the bluetooth not. He is in a infinit looping at "boolean CBTSubSystem::Initialize (void)", the line(s) below:

    while (!m_HCILayer.GetDeviceManager ()->DeviceIsRunning ()) { CScheduler::Get ()->Yield (); }

    I am verify and is here... the process stops and stay here. I am analised u code, but i think u can helpme better.

    Ty a lot. Moacir Jr.

    opened by moahrs 16
  • Second Memory Interface

    Second Memory Interface

    I have to drive a strip of Neopixel LEDs but my SPI/PWM pins are taken for other functions, so I thought of using the SMI interface as described here:

    I've therefore tried to write an SMI driver for circle. As always, I am not sure of the semantics, so any comments welcome :)

    It's untested, give me a few days :)

    opened by sebastienNEC 15
  • Suggestion ST7789 LCD Driver

    Suggestion ST7789 LCD Driver

    There's a couple open source drivers for screens like the ST7789, which are popular amongst some portable projects. Is there any chance that something like this could be supported in an example?

    opened by froggestspirit 15
  • Circle 42 Networking Example with LAN + WLAN + mbedtls

    Circle 42 Networking Example with LAN + WLAN + mbedtls

    Hi Rene,

    This is not a bug report. I just wanted to let you know that I spent some time on implementing network features into a temporary fork the code of the Sidekick64 project for Pi 3A+/3B+. Since a few days I moved on to circle-stdlib and started using mbedtls. All of this is only possible because of your good work and the excellent examples that come with circle. Also, Stephan Mühlstrasser has in the same way added nice examples to circle-stdlib so that the transition to HTTPS was quite easy. Everything is still experimental in my code. Cable based ethernet works perfectly, WLAN works pretty good (although I have to do some keep-alive requests in the Sidekick64 setting to prevent a disconnect/zombie state where a reconnect takes a couple of seconds).

    Because I have to build circle-stdlib twice, once with REALTIME (needed for the other features of Sidekick64, allows cable based LAN networking) and once with SDHOST for WLAN, I started hacking together some Docker images that automate the build and contain pre-built versions of circle-stdlib so that the build process is shorter if I just want to compile the application.

    I had a lot of fun in doing this up to now and more fun lies ahead. Thank you for your framework!

    What surprises me is that there are quite a few projects out there using Circle but there seems to be no Wiki page that summarizes the projects. Is there anything like that and I haven't found it yet?

    Cheers, Henning

    opened by hpingel 15
  • Expanded support for CP210x family USB serial devices

    Expanded support for CP210x family USB serial devices

    This issue was reported by a user with a CP2104 device (following on from

    Removing a part number check in the CP2102 driver (relevant code) apparently gets it working for CP2104, and possibly other members of the CP210x family as they appear to be very similar.

    This PDF (page 2) suggests that the differences are very minor (e.g. number of stop bits supported).

    Searching for partnum within the Linux driver also reveals where behaviour varies depending on the part number.

    It would probably make sense to:

    • Rename the driver to CP210x.
    • EITHER: Remove the part number check and deal with any further issues as reported by users of the hardware (easiest solution).
    • OR: Expand the part number check to other known part numbers and adapt the behaviour of the driver to enforce the correct maximum baud rates, stop bits etc in a similar way to the Linux driver to account for the minor differences in the CP210x family (requires more effort/testing with the hardware).

    I would offer to help, but sadly I don't possess any of the devices concerned, hence I'm only able to ensure the issue is tracked.

    Many thanks as always!

    opened by dwhinham 4
  • SQLite3 example?

    SQLite3 example?

    I was attempting to compile sqlite3 for use with circle, though has no luck. I'm not sure if this might be something useful for others if it were to be supported?

    opened by froggestspirit 16
  • Pi Zero 2 W: Different revisions, different WLAN firmwares

    Pi Zero 2 W: Different revisions, different WLAN firmwares

    Hi Rene, Yesterday I noticed that two different PI Zero 2 W PCBs can have different WLAN hardware: These logger lines exist on different Pis:

    wlan: ether4330: chip 43430 rev2 type 1 (my Pi) wlan: ether4330: chip 43430 rev1 type 1 (the Pi of a colleague) In the next line my colleague gets this: wlan: ether 4330: can't enable HT clock: csr 50 wlan: I/O error

    Now, I was wondering if this error could be related to the WLAN firmware files. But it could also be something else like a power supply or a hardware fault. (EDIT: The colleague told me he didn't copy all the firmware files in the meantime. So his problem seems to be fixed.)

    Today I came accross this ticket:

    I tried to understand if this is of any relevance to the issue above and am not convinced. But anyway, I wanted to let you know that there are some firmware files for the Zero 2 W in that are not yet grabbed by wget from Circle's side.

    The missing files are: brcmfmac43436s-sdio.bin brcmfmac43436s-sdio.txt

    And there were some changes to some files after October 2021.

    Cheers, Henning

    P.S.: Also see:

    opened by hpingel 2
  • Device recommendation for I2S input

    Device recommendation for I2S input


    First, congratulations on providing such fine piece of software for all of us !

    I would like to test I2S input (and ouput) on my Pi3 using Circle. I was wondering if there was any DAC/ADC chip and/or modules recommended for this purpose (o avoid ordering parts which would be incompatible with Circle). Preferably a cheap one (44100Hz would be largely enough), and also if possible, one with Line-IN AND Line-OUT ?

    Thanks in advance :)

    opened by Buanderie 3
  • Improve WM8960 sound quality

    Improve WM8960 sound quality

    I noticed that when using Circle, the WM8960 sounds a lot noisier than when using Linux. Possibly we can improve things by tweaking the default configuration of the i2c registers?

    This is a dump from a pristine (no config changes made) Raspberry Pi OS installation with the WM8960 driver from

    $ sudo su
    $ cat /sys/kernel/debug/regmap/1-001a/registers
    00: 0127
    01: 0127
    02: 016d
    03: 016d
    04: 0049
    05: 0008
    06: 0000
    07: 0002
    08: 01c9
    09: 0000
    0a: 01ff
    0b: 01ff
    10: 0000
    11: 007b
    12: 0100
    13: 0032
    14: 0000
    15: 01c3
    16: 01c3
    17: 01c0
    18: 0000
    19: 0140
    1a: 0001
    1b: 0000
    1c: 0008
    1d: 0000
    20: 0138
    21: 0138
    22: 0170
    25: 0150
    26: 0000
    27: 0000
    28: 016d
    29: 016d
    2a: 0040
    2b: 0000
    2c: 0000
    2d: 0070
    2e: 0020
    2f: 0000
    30: 0002
    31: 0037
    33: 00a4
    34: 0036
    35: 0024
    36: 00dd
    37: 002f

    When one unmutes Noise Gate Switch (by default it is muted) in alsamixer and sets Noise Gate Threshold to ~80%, then the following changes:

    14: 00c9
 defines no less than 58 controls that could theoretically be tweaked for this codec. But possibly using the default Linux driver configuration could already improve sound quality over what we currently have?

    cc @matemaciek

    opened by probonopd 4
  • Small  SD cards do not work correctly

    Small SD cards do not work correctly

    This issue originally was raised for the MiniDexed. After booting the appropriate kernel image, access to the FAT32 file system does not work correctly for a small Micro SD card, i.e. in my case 128MB. More details can be found here , also what was already checked. Filesystem is definitely FAT32, card was freshly formatted.

    opened by fp64lib 6
Rene Stange
Rene Stange
A C++ bare metal environment for Raspberry Pi with USB (32 and 64 bit)

A C++ bare metal environment for Raspberry Pi with USB (32 and 64 bit)

Rene Stange 1.5k Jan 2, 2023
Metal-cpp is a low-overhead C++ interface for Metal that helps developers add Metal functionality to graphics apps, games, and game engines that are written in C++.

About metal-cpp is a low overhead and header only C++ interface for Metal that helps developers add Metal functionality to graphics applications that

Бранимир Караџић 164 Dec 31, 2022
Tutorial: Writing a "bare metal" operating system for Raspberry Pi 4

Tutorial: Writing a "bare metal" operating system for Raspberry Pi 4

Adam Greenwood-Byrne 2.5k Dec 31, 2022
Dexed FM synthesizer similar to DX7 running on a bare metal Raspberry Pi

Dexed is a FM synthesizer closely modeled on the famous DX7 by a well-known Japanese manufacturer. MiniDexed is a port to run it on a bare metal Raspberry Pi (without a Linux kernel or operating system).

null 680 Dec 27, 2022
✔️The smallest header-only GUI library(4 KLOC) for all platforms

Welcome to GUI-lite The smallest header-only GUI library (4 KLOC) for all platforms. 中文 Lightweight ✂️ Small: 4,000+ lines of C++ code, zero dependenc

null 6.6k Jan 8, 2023
the checkra1n set of tools targeting bare metal, Linux and Windows

Universal toolchain Low-effort cross-compiling for the masses. What's Universal toolchain? It's a collection of sysroots and shell scripts in such a w

null 67 Jan 5, 2023
Because why not? Pi Zero bare metal project that ends in an RTOS implementation

PiZeroRTOS Because why not? This repo starts out as a Pi Zero bare metal project and it could very well end up as a viable RTOS implementation with a

null 7 Feb 13, 2022
A bare metal SDK for the ESP32 & ESP32C3

MDK (Minimal Development Kit) - a baremetal ESP32/ESP32C3 SDK An bare metal, make-based SDK for the ESP32, ESP32C3 chips. It is written from scratch u

Sergey Lyubka 100 Jan 2, 2023
The near bare metal multi-container supervisor and OS management system.

Pantavisor What is Pantavisor? Pantavisor is the easiest way to build and manage embedded Linux projects with lightweight containers. Put your Linux d

Pantavisor 30 Dec 20, 2022
Microshell - a lightweight pure C implementation of shell emulator dedicated for embedded bare-metal systems.

MicroShell Lightweight pure C implementation of virtual shell, compatible with VT100 terminal. Support root tree, run-time mounting paths, global comm

Marcin Borowicz 110 Jan 5, 2023
It's like Porth, but in C++. Yep, we're going full circle.

Corth It's like Porth, which is like Forth but written in Python, but written in C++. But I don't actually know for sure since I never programmed in P

null 17 Oct 25, 2022
YoloX for a bare Raspberry Pi 4 using ncnn.

YoloX Raspberry Pi 4 YoloX with the ncnn framework. Paper: Special made for a bare Raspberry Pi 4, see Q-engineer

Q-engineering 7 Nov 3, 2022
A programming environment for Lua for the Raspberry Pi Pico microcontroller

picolua A programming environment for Lua for the Raspberry Pi Pico microcontroller. Version 0.3, April 2021 What is this? picolua is a proof-of-conce

Kevin Boone 65 Jan 8, 2023
A bare-bone SQL implementation

MiniSQL A bare-bone SQL implementation. Project Structure include folder contains header files of all modules. These header files are meant to be shar

null 16 Apr 23, 2022
Prueba del Raspberry PI PICO con un display Raspberry PI TFT 3.5"

Raspberry-PI-PICO-display-RPI35 Prueba del Raspberry PI PICO con un display Raspberry PI TFT 3.5" Con ayuda de la libreria

null 1 Nov 10, 2021
Teliva - an environment for end-user programming

Teliva - an environment for end-user programming “Enable all people to modify the software they use in the course of using it.” — https://futureofcodi

Kartik Agaram 151 Dec 3, 2022
PLP Project Programming Language | Programming for projects and computer science and research on computer and programming.

PLPv2b PLP Project Programming Language Programming Language for projects and computer science and research on computer and programming. What is PLP L

PLP Language 5 Aug 20, 2022
Minimalistic C++/Python GUI library for OpenGL, GLES2/3, Metal, and WebAssembly/WebGL

NanoGUI NanoGUI is a minimalistic cross-platform widget library for OpenGL 3+, GLES 2/3, and Metal. It supports automatic layout generation, stateful

Mitsuba Physically Based Renderer 1.2k Dec 28, 2022
Low Level Graphics Library (LLGL) is a thin abstraction layer for the modern graphics APIs OpenGL, Direct3D, Vulkan, and Metal

Low Level Graphics Library (LLGL) Documentation NOTE: This repository receives bug fixes only, but no major updates. Pull requests may still be accept

Lukas Hermanns 1.5k Jan 8, 2023
🎮 C Bindings/Wrappers for Apple's METAL framework

Apple's Metal for C C Wrapper for Apple's METAL framework. This library is C bindings of Metal API (MetalGL). Since OpenGL is deprecated, this library

Recep Aslantas 116 Dec 30, 2022