https://github.com/probonopd/MiniDexed/

Dexed is a multi platform, multi format synth that is closely modeled on the famous DX7 synthesizer by a well-known Japanese manufacturer. While https://github.com/rsta2/minisynth/ 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:

• Teensy Microcontroller using the Arduino environment: MicroDexed
• lvtk (LV2): dexed.lv2

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 https://github.com/rsta2/minisynth/, 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.

Hello,

A user asked for debugging Circle with our GDB stubs (https://github.com/farjump/raspberry-pi). 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 \
          -DARM_IO_BASE=0x20000000
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.

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.

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!

Hello,

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 : main.zip 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 : Goden_Axe_-_Stage_1.zip

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.

Hello,

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.

Notes:

• 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

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.

Hi,

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.

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: https://iosoft.blog/2020/09/29/raspberry-pi-multi-channel-ws2812/

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

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

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?

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

This issue was reported by a user with a CP2104 device (following on from https://github.com/dwhinham/mt32-pi/issues/305).

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!

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?

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: https://github.com/RPi-Distro/firmware-nonfree/issues/23

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 https://github.com/RPi-Distro/firmware-nonfree/tree/bullseye/debian/config/brcm80211/brcm 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: https://github.com/RPi-Distro/firmware-nonfree/commit/b3eec612566ca08913f0830d299f4df70297428f

Hello,

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 :)

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?

https://github.com/matemaciek/circle/blob/14a120ad68ca668b01bc24cff15afff4e841fc07/lib/i2ssoundbasedevice.cpp#L473-L515

This is a dump from a pristine (no config changes made) Raspberry Pi OS installation with the WM8960 driver from https://github.com/waveshare/WM8960-Audio-HAT:

$ 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

https://github.com/waveshare/WM8960-Audio-HAT/blob/master/wm8960_asound.state 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

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 https://github.com/probonopd/MiniDexed/issues/160 , also what was already checked. Filesystem is definitely FAT32, card was freshly formatted.