Name of the SERIAL App?

Been tinkering with some microcontroller boards (Like Pi Pico) and wanted to see if RiscOS could be used as the development platform. Poking around in the app store didn’t reveal an obvious answer and searching by name is akin to guessing a vault combination.

Everyone knows windows Putty and Linux screen, can anybody tell me if RiscOS has a similar way of connecting to a REPL in Micropython?

You might want to try Connector (part of the Bonus Binaries package), Nettle or Hearsay.

from a developer’s point of view the perils of
using them outweigh the problem of them not being available at all.

An exerpt from the ReadMe/txt included in the Bonus Binaries download. Looks as though I may have found an unsupported application of RiscOS. It would require a modern USB stack that, I’m told, is still being developed.

Perhaps there is another with the same idea for RiscOS but with a better chance of success! The more RiscOS can do’s, the more RiscOS I’ll use.

Been exploring the USBDrivers trying to get the Pyboard recognized as a drive. The pyboard reports having 1 config and 3 interfaces so I type ‘USBSetInterface 8 x.0 ’’ for x=0 to 2 but still no drive Icon.

The objective is to be able to transfer code using drag-and-drop from RiscOS to the Pyboard. If I can get this one thing working, then RiscOS can be used for development on microcontrollers.

Step two is find a USB ‘serial’ terminal APP to access the REPL directly on the microcontroller. I’ve looked at the options Stuart pointed out, they’re pretty old and don’t currently handle USB. Once I figure out the USB stuff I might be able to edit something.

Been going round and round with the documentation. It’s either too old to include USB or far too terse to teach me anything.

mkdev and mknod would help me out but they are not available in either the bash app or the python3 port. Failed to find any information that would correlate these commands with RiscOS.

I will try reaching out some more but the perceived value of success is waning.

USBDevices shows the pyboard as 8 and a flashdrive as 9
USBDevInfo shows the pyboard as Class EF and flashdrive as 00.
the subclass is 02 and 00 respectfully.
the protocol is 01 and 00 respectfully.

USBConfInfo lists the interfaces as:
0.0 class 8.6:80 ‘’
Endpoint 1 Bulk IN, 64 bytes 0 frames
Endpoint 1 Bulk OUT 64 bytes 0 frames
1.0 class 2.2:1 ’’
Endpoint 2, Interrupt IN, 8 bytes 32 frames
2.0 class 10.0:0 ’’
Endpoint 3 (info same as 0.0 above)

“USBSetConfig .” I don’t know what to give as a config.
“USBSetInterface .” What is setting?

The difference inprotocol, class and subclass must be the key. Back to the PRMs.
Just notes. If you can help me to clear up how to use the USBDriver commands, it would be appreciated.

More notes: Hooked up a Microbit SBC and it works. I was able to drag a hex file to it using the filer. The Microbit has the same Class, Subclass and uses the same protocol as the Pyboard so I’m stumped as to why one works and the other doesn’t. Could still be my lack of understanding the use of USBSetInterface. No idea of the default interface on power up and still unable to set it up differently.

Given time, I’m sure to learn something.

USBSetConfig and USBSetInterface are no use.

The 8.6:80 interface is the normal mass storage interface understood by riscos.

For Serial try Hearsay2_24_05.zip

If it is USBSerial try USBSerial.zip with hearsay.

Thanks David, Colin. Hearsay was one of the first Apps I tried but it will not start. Looked over the USBSerial information and it did give me another piece of the puzzle but its too early in the project to delve that deeply into the works. Frankly, most of it is still over my head.

When I first pondered the idea of learning BBC Basic and the WIMP, I wanted to create an IDE for Assembly on RiscOS similar to ones I have written for other platforms. I realized that the niche audience for the IDE have all moved on to Python and Micropython.

Being just a follower, I began a mini plausability study of RiscOS to determine if it can be used in the huge and fast growing micro-controller market. Pyboard, Microbit and Pi Pico are all UK produced micro-controller boards and many more will follow.

While there are several existing programs to support this burgeoning technology, there are none that can be run on RiscOS. I believe the that survival of our favorite OS hinges on finding new uses for it. RiscOS is too good to be relegated as only for the nostalgic user. No offense intended, I too am a fan of retro technology.

The difficulties I’ve encountered, in this study, are telling of the magnitude of the overall project with my capabilities. I get more lazy and dumber with each passing year.

If StrongED were to be written to include development of micropython on microcontrollers, then this battle has been won. As yet, this too is beyond my current level of coding on RiscOS.

Should this be posted in the WISH LIST forum?

there are none that can be run on RiscOS.

The problem in most, if not all, cases is a lack of developer time/resources. It would be nice to do this in RISC OS. It would also be nice to run a compiler/uploader for ESP32 natively (because it takes FOREVER on my 2.4GHz PC).
But, we’re still lacking native support for stuff like WiFi and Bluetooth ¹ and so on because of this. It’s a bit of a catch 22 really. We need to attract more development, but we need the resources to attract the developers.

Maybe we could… oh, I dunno… try something like crowdfunding to raise some cash for development? ;-)

If StrongED were to be written to include development of micropython on microcontrollers

StrongEd is an editor, like Notepad (only not crap). It could be extended to have some sort of syntax colouring mode for Python (if it doesn’t already?), but that’s all it would be. If we’re talking microcontrollers, does it need to be compiled or can they run it directly? How does the code get onto the device? Some extra programs may be needed.

¹ I believe these are being worked on, to some degree.

Oh, okay…

Just done a little bit of Googling. It looks like getting code onto the device is the easy part. Plug it in, it should appear as a filesystem device, like an 8MB drive.

Getting the code, that’s the harder part. It looks like you are supposed to use an editor in a browser (!) with your code being compiled elsewhere to generate a hex file that you can download. So, clearly, there’s a need for some sort of compiler to translate the Python into the hex file.
Looks like Yotta (uses GCC or ARMCC) can be set up to do offline compiling → https://lancaster-university.github.io/microbit-docs/offline-toolchains/

I’ve been using ‘MU’ to compile locally, it came about early in this craze and there are others that have gained notoriety. PyCharm is the choice of serious programmers for the time being. The Online compilers are, I think, mostly for the kiddies but offer a good selection of different compilers.

StrongED has great potential if it had a module, or something, that would extend its compiling capabilities to include these modern chips. It doesn’t have to be the best on the market to be the best on RiscOS.

The real stumbling block at this point seems to be the USB support, however, the success with testing the MicroBit board has minimized the original perceived workload of the project.

I’m wondering if the new Pi Pico is recognized by the filer.
Pi Pico users?
You there?

we’re still lacking native support for stuff like WiFi and Bluetooth

Interestingly, the newest ESP32-S2 has just about everything built in. Even a version of the RISC-V programmable IO something like the PIO state machines in the Pi Pico. One of these MC boards plugged into a USB port can service most calls for WiFi or BT as a dongle with very little coding on the host machine. That brings us back to the USB stack on RiscOS.

StrongED has great potential if it had a module, or something, that would extend its compiling capabilities to include these modern chips.

I’m not sure what you mean by this seeing that StrongED has no compiling capabilities. You can create a keybinding and/or set up a toolbar icon to call an external program that starts a build process. The compiler/assembler within that build process is what needs to understand modern chips.

If there’s anything that you’d like StrongED to do that currently isn’t possible, let me know and I’ll see what can be done.

Fred, that’s great news. The compiler is in the micropython OS on the microcontroller (MC). When connected, the MC is currently recognized as a flash storage device. The toolchain couldn’t be simpler:

1. The 1st and most important tool is a Text editor. I’m thinking StrongED is a great match for this requirement. While it isn’t an advanced IDE, it appears to have everything the beginner or novice would need without a steep learning curve.

2. Second is a Serial terminal to access the REPL (Read, Eval, Print Loop) on the microcontroller. The REPL to the MC is the same as a Task Window in RiscOS. Instead of *Commands you use micropython commands to control the hardware. Very similar construct as BBC Basic right down to the Inline_Assembler.

The Current Challenge: Need a stable USBSerial comm to transfer the python scripts from the filer to the microcontroller. I have had success in transferring a pre-compiled hex file from the filer to a Microbit board but, it is hit and miss on the CRC for some reason. Transferring a script file (filename.py) is corrupted without fail. This is the stumbling block in my testing right now.

I’m mostly an X86 platform developer with a strong linux background. The challenge is compounded by my inexperience with BBC Basic,

Currently, Python is the number ONE programming language in the World and Micropython is the number ONE language supporting the Internet Of Things craze. I’m thinking if RiscOS supported this group of developers, some of those developers will support RiscOS and we all live happily ever after.

I have had success in transferring a pre-compiled hex file from the filer to a Microbit board but, it is hit and miss on the CRC for some reason. Transferring a script file (filename.py) is corrupted without fail.

From past experience with serial comms, the first place I’d look for this problem would be flow control. Do the source and destination use the same flow control – software or hardware? If hardware, are the correct pins connected?

the first place I’d look for this problem would be flow control.

I’m guessing flow control is set to none. I have more to research on the different interfaces and what is already supported. Then I need to solve the HOW of adding the additional interface needed for the serial comm.

Currently the serial interface is not recognized as a comm port, only a storage device. This is good for transferring files but, without a serial terminal the project is half baked.

I’m digging into the code Colin wrote (in 2016?) to address the lack of a USBSerialTerminal. Could take me awhile for these critical short term goals.

You reminded me that I had a Microbit somewhere here – the SerialUSB driver doesn’t work with it. This version of SerialUSB does.

With the microbit I have here – which is version 1 – it appears as a usb drive so I can program it by dropping a hex file into the directory and with the new SerialUSB module above I can communicate with the microbit over usb serial.

I have the latest firmware on the microbit.

Does it work for you?

If you double click on !SerialTerminal you should see

SerialUSB#noblock;nohandshake;baud=115200;data=8;stop=1;noparity:

and elsewhere mine says

CDC Device, ARM, BBC micro-bit CMSIS-DAP

Which shows it is recognised as a serial device.

If the program on the microbit is outputting at 115200 baud you should see it.

If you double click on !SerialTerminal you should see

SerialUSB#noblock;nohandshake;baud=115200;data=8;stop=1;noparity:

Using either version of !SerialTerminal, I get “Serial1” The root hub.

USBDevInfo reports:

Interface 0.0 class 8.6:80 ‘USB_MSC’
Endpoint 2, Bulk IN, 64 bytes 0 frames
Endpoint 2, Bulk OUT, 64 bytes 0 frames

Somewhere I was told that this is the only spec currently supported. May not be entirely true though as I have a Pyboard that then should be but, is not recognized.

Interface 3.0 class 3.0:0 ‘CMSIS-DAP’
Human interface device, HID1.00, country 0
Descriptor 1, HID descriptor type 22, length 33
Endpoint 1, Interrupt IN, 64 bytes 1 frames
Endpoint 1, Interrupt OUT, 64 bytes 1 frames

Is the interface that is absent from the Pyboard. Only with this have I been able to see the “SCSI” instead of expected “FAT32FS” storage in the Filer. This would also be critical in supporting the “Device Firmware Update (dfu)” utiility. I’ve delved into the HID spec and found that the Pi is virtualizing the port much in the same way it does Ethernet. Another layer of software and mystery.

Interface 2.0 class 10.0:0 ‘mbed Serial Port’
Endpoint 4, Bulk OUT, 64 bytes 0 frames
Endpoint 4, Bulk IN, 64 bytes 0 frames

This has to be the interface that is NOT being seen by !SerialTerminal despite my efforts in the CLI to specify the device. ie: SerialTerminal -echo -dev USB12 reports a failure to open USB12. Usbdevinfo 12 reports the name as ’’ so its not being registered. USBSerial reports NO serial usb devices connected.

I tryed USBSetInterface but I think it expects the device to have been assigned a memory block before changes can be made.

Did some reading from the USB_IF and found that the Standards pertain only to those systems having a BIOS. Pretty much leaves RiscOS to invent another USB standard.

You know that feeling you get when you finally reach the peak of the mountain and, what you see is more and bigger mountains?

Messing with SerialTerminal won’t help if the SerialUSB module detects the device it will work.

What version of the firmware are you using on the microbit?

Is the microbit version 1 – if you don’t know how old is it?

I may be able to help if I see the descriptors. Can you get USBDescriptors.zip and double click on it.

Then in a taskwindow type:

 usbdesc. usbnn

where nn is the usb number for the device as indicated in the window that appeared when you double clicked.

Do that for the microbit and the Pyboard. Can you then send me the output to the address on the ftpc page

Messing with SerialTerminal won’t help if the SerialUSB module detects the device it will work.

I did wonder why Philip continued without the notified updated SerialuSB_test and then checked the link – looked OK, but it’s a 404 at the host end.

Odd it works ok for me.

It occurs to me that if you have already loaded the original SerialUSB the new !SerialTerminal in SerialUSB_test/zip will not load the new SerialUSB module. So can you double click on the new SerialUSB module before running either !SerialTerminal – the !SerialTerminal program is unchanged.

What version of the firmware are you using on the microbit?

The interface version is 0241. Old enough to be version 1 I think. Current update is 0255 according to the support web site. I’ll have to dust off the one book I have for Microbit to see how to query the flash for more information.

I used the Microbit for a Franklin Clock project and then tucked it away. Seem to recollect deciding it was too limited for Micropython development when compared to the likes of the Pyboard, ESP32 variants etc.

Do that for the microbit and the Pyboard. Can you then send me the output to the address on the ftpc page

I have the Descriptors file on its way. Yahoo on Websurf is a challenge.

So can you double click on the new SerialUSB module before running either !SerialTerminal – the !SerialTerminal program is unchanged.

Thought I had done this before, may have been with the Microbit. Here’s what I get:

Escape codes removed
SerialUSB#noblock;nohandshake;baud=115200;data=8;stop=1;noparity:
Transmit and Receive
Key echo off
Line ending LF
CDC Device, MicroPython, Pyboard Virtual Comm Port in FS Mode

Don’t seem to have the ability to send commands to the board though. Not entering the REPL yet.

Odd it works ok for me.

Hmmm, just checked something.
Turned off the “HTTPS_Only” in Firefox, and it worked here. Another quirky HTTPS.

Looks like the iconbar HTTPS is a bit broken – the https://ftpc.iconbar.com/SerialUSB_test.zip ends at a 404 message that is a working iconbar page on HTTPS and the base https://ftpc.iconbar.com works without any error.

It looks like you may have a potential reason Philip might not be using the updated “test” version