- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
Neo6502 / Re: Prophet server for the Neo...
Last post by Ralf - October 29, 2026, 05:38:37 PMHi Béné,
thanks for your reply.
I'm using Trinity v0.16.69 and NeoDOS v0.32.1
That was the Olimex UART MOD-WIFI-ESP8266 I used.
On first boot with Trinity, I got a flood of endless error messages. These messages were somehow turned into files, so I got a lot of filenames like ER and ROR and so on. They were mostly 0 bytes, so I didn't bother to open and read any of them, and the system is working nicely and stable with the Pi Pico, so I don't feel compelled to replicate that event. ;-)
However, as the MOD-WIFI-ESP8266 is the only peripheral I haven't plugged into the Neo6502 again, I strongly suspect it was the culprit.
As for the keymaps, yes, NeoBasic does support German, however, I don't want to boot Trinity, run NeoBasic for the German Keymap, and then run NeoDOS again because of its advantages.
Sure, I guess a few lines in AUTOEXEC.BAT and autostart.bas will do the trick, but it's still not a neat solution.
Anyways. In NeoBasic with German keymap, the ö ä ü ß give the English (US?) mapping, i.e. ; ' [ -
Lastly, did you do something to speed up the whole Neo6502? There is this clockspeed.bas demo and it gives me a clockspeed of around 6.8MHz, and the test.bas demo which generates a Mandelbrot set also runs faster than it used to.
Which is cool though. :-)
So long
Cheers
thanks for your reply.
I'm using Trinity v0.16.69 and NeoDOS v0.32.1
That was the Olimex UART MOD-WIFI-ESP8266 I used.
On first boot with Trinity, I got a flood of endless error messages. These messages were somehow turned into files, so I got a lot of filenames like ER and ROR and so on. They were mostly 0 bytes, so I didn't bother to open and read any of them, and the system is working nicely and stable with the Pi Pico, so I don't feel compelled to replicate that event. ;-)
However, as the MOD-WIFI-ESP8266 is the only peripheral I haven't plugged into the Neo6502 again, I strongly suspect it was the culprit.
As for the keymaps, yes, NeoBasic does support German, however, I don't want to boot Trinity, run NeoBasic for the German Keymap, and then run NeoDOS again because of its advantages.
Sure, I guess a few lines in AUTOEXEC.BAT and autostart.bas will do the trick, but it's still not a neat solution.
Anyways. In NeoBasic with German keymap, the ö ä ü ß give the English (US?) mapping, i.e. ; ' [ -
Lastly, did you do something to speed up the whole Neo6502? There is this clockspeed.bas demo and it gives me a clockspeed of around 6.8MHz, and the test.bas demo which generates a Mandelbrot set also runs faster than it used to.
Which is cool though. :-)
So long
Cheers
#2
A20 / Re: Wich board to correctly mo...
Last post by LubOlimex - October 29, 2026, 01:53:29 PMThe output shows that the system is already running from SATA (/dev/sda1 is /). olinuxino-sd-to-sata excludes the current root device, so "Failed to detect SATA device" is expected in this state. Reflash the complete Olimage image to the whole SD card, first boot it with SATA disconnected, and verify findmnt -no SOURCE / reports /dev/mmcblk0p1. Then reconnect SATA, verify SD is still root, and rerun the migration script. If it again boots SATA, please provide the UART boot log, especially the "U-boot loaded from" and "Boot script loaded from" lines - these are at beginning of boot and require USB-serial cable.
#3
Neo6502 / Re: Prophet server for the Neo...
Last post by béné - October 29, 2026, 02:00:24 AMThanks a lot for the kind words, and for testing Trinity so thoroughly!
- Olimex UART WiFi card: you are right, it is not supported. Only the USB CDC modem (Pico W, "picowifiusb", on the USB-A port) is handled. I honestly don't know what wrote those stray files to your USB drive, and nothing about this card is documented yet. To dig into it, could you tell me: your Trinity version, the exact names of the stray files, the text of the error messages, and how the card is connected (UART or USB)? I can't promise a fix or a warning yet, but I'll note it in the docs.
- Keymaps: the firmware already embeds several locales (fm, gb, sw, us, fr, de, fi, it, ch), so a German one is there, inherited from upstream (Olav Schettler's code). You can already select it from NeoBASIC with LOCALE "de" (or through the API, group 1, function 6). There is no NeoDOS command, no persistent setting and no selection at boot yet, so it has to be set again at each launch. I'll look into adding a NeoDOS command and a remembered setting, with no date for now. I have only validated the French keymap (AZERTY) on real hardware; the German one is untested on my side, so please tell me what you get with LOCALE "de" (ä ö ü ß in particular).
Thanks again for the feedback,
Béné
- Olimex UART WiFi card: you are right, it is not supported. Only the USB CDC modem (Pico W, "picowifiusb", on the USB-A port) is handled. I honestly don't know what wrote those stray files to your USB drive, and nothing about this card is documented yet. To dig into it, could you tell me: your Trinity version, the exact names of the stray files, the text of the error messages, and how the card is connected (UART or USB)? I can't promise a fix or a warning yet, but I'll note it in the docs.
- Keymaps: the firmware already embeds several locales (fm, gb, sw, us, fr, de, fi, it, ch), so a German one is there, inherited from upstream (Olav Schettler's code). You can already select it from NeoBASIC with LOCALE "de" (or through the API, group 1, function 6). There is no NeoDOS command, no persistent setting and no selection at boot yet, so it has to be set again at each launch. I'll look into adding a NeoDOS command and a remembered setting, with no date for now. I have only validated the French keymap (AZERTY) on real hardware; the German one is untested on my side, so please tell me what you get with LOCALE "de" (ä ö ü ß in particular).
Thanks again for the feedback,
Béné
#4
A20 / Re: Wich board to correctly mo...
Last post by oly - October 28, 2026, 01:45:19 PMHello,
Sorry, for the delay.
Sorry, for the delay.
Code Select
root@TOTO:~# olinuxino-sd-to-sata
Detecting board...
Detecting the root device...
Root partition: /dev/sda1
Root device: /dev/sda
Detecting SATA device...
Failed to detect SATA device!
Code Select
root@TOTO:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 111,8G 0 disk
└─sda1 8:1 0 111,8G 0 part /
mmcblk0 179:0 0 14,8G 0 disk
└─mmcblk0p1 179:1 0 1,1G 0 part
Code Select
root@TOTO:~# df .
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
/dev/sda1 114784676 1262712 107645052 2% /
#5
ESP32 / Re: ESP32-POE (ISO) LiPo Batte...
Last post by LubOlimex - October 28, 2026, 08:13:43 AMRemoving FET2 won't work in your case. You need to carefully unsolder and remove U3 TP4054 (the battery charger IC). Refer to the schematic. It is SOT23-5 package, chip with 5 pins.
#6
ESP32 / Re: ESP32-POE (ISO) LiPo Batte...
Last post by oguzhan306 - October 27, 2026, 08:16:33 PMHi LubOlimex,
I have a similar question, but my use case is slightly different.
I'm using an ESP32-POE-ISO Rev. M in a device that will operate in cold environments, potentially below 0°C.
The device is normally powered via PoE, and I want to use a Li-ion battery strictly as a backup power source in case PoE fails.
I do not want the battery to be charged by the board under any circumstances, particularly because charging Li-ion batteries at sub-zero temperatures can be unsafe.
My requirements are:
When PoE is available, the device should operate from PoE.
When PoE is lost, the battery should automatically take over.
When PoE returns, the device should switch back to PoE.
The battery must never be charged by the board.
A brief power interruption or ESP32 reset during switching is acceptable.
In your earlier reply, you mentioned removing FET2 to disable the charging circuit.
Would removing FET2 on the ESP32-POE-ISO Rev. M completely disable battery charging while preserving the automatic battery backup functionality?
If not, is there another component that could be removed or a simple hardware modification you would recommend?
Thank you for your help!
I have a similar question, but my use case is slightly different.
I'm using an ESP32-POE-ISO Rev. M in a device that will operate in cold environments, potentially below 0°C.
The device is normally powered via PoE, and I want to use a Li-ion battery strictly as a backup power source in case PoE fails.
I do not want the battery to be charged by the board under any circumstances, particularly because charging Li-ion batteries at sub-zero temperatures can be unsafe.
My requirements are:
When PoE is available, the device should operate from PoE.
When PoE is lost, the battery should automatically take over.
When PoE returns, the device should switch back to PoE.
The battery must never be charged by the board.
A brief power interruption or ESP32 reset during switching is acceptable.
In your earlier reply, you mentioned removing FET2 to disable the charging circuit.
Would removing FET2 on the ESP32-POE-ISO Rev. M completely disable battery charging while preserving the automatic battery backup functionality?
If not, is there another component that could be removed or a simple hardware modification you would recommend?
Thank you for your help!
#7
New Products release / Build smart home Matter Light ...
Last post by olimex - October 26, 2026, 03:07:37 PMTurn the OLIMEX OSHW ESP32-C6-DevKit-Lipo into a Matter-over-Wi-Fi light 💡 It's commissioned over BLE and controlled locally from an Android phone.
You get On/Off and brightness control of the onboard LED, and the physical button reports its state back to the app.
https://olimex.wordpress.com/2026/10/26/esp32-c6-devkit-lipo-becomes-a-matter-light-a-step-by-step-guide/
#Matter #ESP32C6 #IoT #OpenSourceHardware #SmartHome #OSHW #Olimex
You get On/Off and brightness control of the onboard LED, and the physical button reports its state back to the app.
https://olimex.wordpress.com/2026/10/26/esp32-c6-devkit-lipo-becomes-a-matter-light-a-step-by-step-guide/
#Matter #ESP32C6 #IoT #OpenSourceHardware #SmartHome #OSHW #Olimex
#8
A64 / Re: Realtime scheduling for au...
Last post by LubOlimex - October 26, 2026, 01:13:47 PMNo idea but let me know if something breaks.
#9
A64 / Realtime scheduling for audio ...
Last post by winfried - October 24, 2026, 01:11:36 PMTrying to setup a streaming station, I found, getting crackled audio with puredata:
"priority 8 scheduling failed" for dsp process and "priority 6 scheduling failed." for GUI...
Test:
Fix the security limits `ulimit -r`-> 0:
- add a group audio, I set the limits in security:
so
But still
With AI help, I found:
Solution: build and installed new kernel from last branch with new config like described in Olimage-guide.pdf:
So the issue is now fixed and working without crackling.
The questions:
Was there a reason for "CONFIG_RT_GROUP_SCHED=y", maybe the stability of the system might be affected or something other does not work ?
Is it this fix save ?
Any hint or discussion about this is welcomed.
Mfg winfried
"priority 8 scheduling failed" for dsp process and "priority 6 scheduling failed." for GUI...
Test:
Code Select
$ ulimit -r
0
$ /usr/bin/chrt -f 8 true
chrt: failed to set pid 0's policy: Operation not permitted
Fix the security limits `ulimit -r`-> 0:
- add a group audio, I set the limits in security:
Code Select
sudo -s
cat > /etc/security/limits.d/99-audio.conf << EOF
@audio - rtprio 20
@audio - memlock unlimited
#@audio - nice -19
EOF
so
Code Select
ulimit -r is now 20, which is correct.But still
Code Select
chrt -f 8 true fails, so I looked in kernel config:Code Select
grep -E 'CONFIG_(CGROUPS|CGROUP_SCHED|RT_GROUP_SCHED|PREEMPT_RT)=|# CONFIG_(CGROUPS|CGROUP_SCHED|RT_GROUP_SCHED|PREEMPT_RT) is not set' "/boot/config-$(uname -r)"
CONFIG_CGROUPS=y
CONFIG_CGROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
With AI help, I found:
QuoteCONFIG_RT_GROUP_SCHED=y. With that option, a task in any cgroup other than the root cgroup can only use realtime scheduling if that cgroup has cpu.rt_runtime_us > 0. systemd puts your login session in user.slice/user-1000.slice/session-N.scope, and those cgroups default to 0. The kernel then returns EPERM even though rtprio is 20 in limits.conf
Solution: build and installed new kernel from last branch with new config like described in Olimage-guide.pdf:
Code Select
scripts/config --disable RT_GROUP_SCHED
make olddefconfig
grep RT_GROUP_SCHED .config # should show "is not set"
So the issue is now fixed and working without crackling.
The questions:
Was there a reason for "CONFIG_RT_GROUP_SCHED=y", maybe the stability of the system might be affected or something other does not work ?
Is it this fix save ?
Any hint or discussion about this is welcomed.
Mfg winfried
#10
