Programming things

I’ve been trying to exercise my brain a little and test my limits as I get over this horrid flu.

A while back I got an ESP32 microcontroller but didn’t have much of a chance to play with it. It came with Lua installed. I had messed with it for a few minutes then put the Arduino bootloader on it. Fast forward to the last week or so. I got a few of the Arduino demo sketches going on it. It was okay, but it made me realise that Arduino really under utilizes the ESP32, which really is in the grey area between a uC and a SoC already.
The Minecraft mod “Computercraft” popped into my head. It is an interesting concept allowing the player to use computers and robots running Lua to do things in their world. A neat idea but of limited use in the game. I had fun with it programming things like the mining robots to do autonomous work.
My point here is I realised that what I potentially have is a computercraft computer but for real. Could be fun to play with. So all I need to do is re-flash the Lua-RTOS firmware.

Not all things are equal. Reinstalling Lua-RTOS was a nightmare. It shouldn’t be (potentially) so complicated. Everything had to be downloaded and built because the flasher program didn’t work for some reason. On that topic, they want the WhiteCat stuff installed to whatever system application directory is applicable for the OS. There is also an IDE which can be installed which wants to be set up as a daemon almost. This just raises a whole lot of red flags.
In all it took me days of trying in bits and pieces to get everything working just to flash the ESP32. The firmware worked first go, but the process was unnecessarily fiddly.

A couple of simple STM32F030F4P6 (Cortex M0) demo boards also arrived. I was feeling well enough a few days ago to tackle them. I didn’t realise at the time that the ones I had ordered were simple enough not to have the builtin ST-Link programmer. Both boards cost me less than a cup of coffee total so whatever. However it didn’t take me long to work out that all was needed was a USB-Serial adapter. After a couple of false starts due to complete lack of documentation of the board and human error I managed to program one and test it successfully.
This got me thinking about how wildly the difficulty of programming some hardware differs. It also made me wonder if it’s possible to program the M0 uC in RISC OS. The programming utility is way simpler. It just uses serial or I2C. The latter is linux-centric.
This raised a couple of questions.

• Could code actually be at least assembled using RISC OS?
• How would serial interfacing for flashing work in RISC OS?

I2C is pretty well defined in RO, and that aspect could probably be ported easily. Serial however is another matter. It’s fairly ubiquitous in most OSes, but it’s really a bit of a mess in RO. Which layer would a person aim for if they wanted to get a program working with a USB serial port? I saw a recent thread on a functional block driver being made for a specific driver. Would that be the thing to shoot for?
Remember this is all Cortex M related. After seeing the mess involved with ESP32, that goes straight in the “Too hard” basket.

How many others here fiddle with programming arbitrary hardware?

My little oscilloscope is an STM32 device, it programs using Tx, Rx, and Gnd so there’s nothing complicated to hook up.
The thing is, once the hardware is hooked up, do you know the protocol to communicate with the bootloader?

How many others here fiddle with programming arbitrary hardware?

I have used the LPC1114 quite a bit. The nice thing is they have a serial bootloader that is very well documented in the TRM. I have written an app to read, programme and erase them.

STM32 looks fairly simple. Like the baud rate calculation. ;-)

http://www.st.com/resource/en/application_note/cd00264342.pdf

Rick, it does, doesn’t it? Thanks for sharing that. The way the bootloader works looks like what I imagine a bootloader like U-boot would look like if the backend were separated from the CLI. Something like that anyway.

I guess it depends on the path a person would want to go writing a flasher.

https://sourceforge.net/projects/stm32flash/
This is the one I used. Looking at the source it would be less work to adapt it than write a new program for RO, hypothetically. Although I would love to see someone make a drag’n’drop flasher.

Dave, that’s interesting. I guess there’s diversity between manufacturers with ARM based uCs too!

I was trying to tinker with the ESP32 again last night. Such nice hardware. Such terrible software. Remember how I said I had to build everything just to install WhiteCat LuaRTOS? I got around to trying some simple things, including controlling GPIO in immediate mode. I couldn’t. Something was broken. It was giving the nightmare-to-internet-search error “invalid pin”. For whatever reason the GPIO definitions or something were broken. The Lua RTOS on ESP32 has so much potential for testing things, throw together programs etc if it actually worked for me.
There’s a part of me that wants to do a “dumb smart house” setup. Ie have the controller as a microcontroller, or hey why not an RO machine running a scripted program (for the sake of ease of modification) and devices working on a meshnet being controlled / monitored by it. Really the only irritating part I can see about the whole thing is powering the uCs when they are controlling a mains device. They’d need adapters. Might have to check AliExpress for bare 240v→5v adapters.

I haven’t tried Espressif’s official toolchain yet. It’s on the list too I guess. There’s so much nice hardware on the device to play with. I think it’s such a shame it uses an Xtensa(?)RISC CPU rather than ARM. Although if it did, I’d probably want a port of RO Pico for it lol. Last night I discovered it has I2S so of course I bought a cheap I2S DAC from China moments later.

Back a decade or so I liked using PIC micros. While I still aprreciate them I feel that other current offerings are more versatile. A couple of nights ago when I was reconstructing a PS4 controller… again (shudder) I took the opportunity to set up one of the STM32s “Arduino” style. Ie I gave it female headers on the top, and put some board spacers on the bottom for legs. The USB UART is still free floating via DuPont wires though.
On that subject, has anyone found cheap RS232C to 3v3 adaptors anywhere? USB just can’t do what plain old serial can. Serial ports are role neutral. No masters and devices. It’s the way I used to deal with things and it was really, really useful. These days I keep bumping into the issue of not being able to plug A into B with USB because they are both masters or devices. Frustrating when one needs to shuffle serial links with things.

Are there any “things” which can actually be worked on using RISC OS? I guess Cortex M devices could have code assembled with some care maybe?.Just wondering what else there is. Really for the most part I find RO an easier to use environment for development of small projects than the main contenders.

Sorry about the doublepost. I just got around to trying to build stm32flash on RO. It almost works. A decent chunk of it built before it fell over on some POSIX serial stuff as I expected.

Are there any “things” which can actually be worked on using RISC OS? I guess Cortex M devices could have code assembled with some care maybe?

Having said that I have an app to programme the LPC1114, I use the free IAR suite under Wine to do the compilation – I write in C. I don’t know of any RISC OS ability to compile C to Thumb.

A Lua based RTOS? shudder No wonder the ESP32 needs 600 MIPS & 512KB of RAM.

I can see the appeal of using a “friendly” high-level language on a microcontroller (e.g. MicroPython with the micro:bit). But if you’re using it for serious work there should be some kind of compilation/verification stage to help catch bugs before they crash your systems, and if a microcontroller has an RTOS advertised I’d expect it to make a lot more effort towards being a hard RTOS than LuaRTOS does (AFACT LuaRTOS is no more of an RTOS than RISC OS or Windows or Linux, none of which have the audacity to claim to be an RTOS).

I guess Cortex M devices could have code assembled with some care maybe?

You could probably convince the version of gas that comes with GCCSDK to assemble Thumb code. Not sure about objasm (I doubt ROOL would have bothered supporting it)

As for C, you might get lucky and be able to get GCC to produce fairly sane Thumb output. But it’s not something I’ve tried, and I’m not sure if any of the RISC OS-isms will get in the way (archaic APCS version, etc.)

Worst-case, just use RISC OS to edit the source code and use SSH or VNC or somesuch to trigger compilation on another machine ;-)

AFACT LuaRTOS is no more of an RTOS than RISC OS or Windows or Linux, none of which have the audacity to claim to be an RTOS).

On medical systems the suppliers tend to refer to “Near Real Time” because after passing through an embedded system (windows or linux) it doesn’t really match a true Real Time situation but the subject here is something that really ought to be labelled NNRT = Nowhere Near Real Time.

Gah!

Lua RTOS is a real-time operating system designed to run on embedded systems, with minimal requirements of FLASH and RAM memory.

(my highlight)

RAM memory.

I agree – but RA memory sounds a bit – well, walkin’ like an Egyptian!

But you’re not getting my PIN number!

but RA memory sounds a bit

They’ve already mentioned Flash on a site talking about a supposed RTOS for microcontrollers, so clearly this isn’t an acronym free zone.

Therefore, how about… Oh, I dunno… RAM… perhaps?

And I’ll see your PIN number and raise you an LCD display. ;-)

And I’ll see your PIN number and raise you an LCD display. ;-)

The one on the ATM machine?

Honestly the English for anything associated with Whitecat is pretty atrocious so I’m going to guess ESL.

I got the LUA RTOS working properly last night. The secret seems to be to choose the compilation options for their Whitecat board, which I don’t have. So the other options are for the same SOC, but with the GPIO missing somehow, and with some absolute weirdness for the USB port name, which no matter what I had to change to “/dev/ttyUSB0” anyway.

The Lua RTOS seems to be an RTOS with a simple userland that has a Lua interpreter plonked on top with some native libraries for hardware access.
Can I say the nice thing about modern microcontrollers is the sheer number of times they can be reflashed! I’m having fun playing with it like it’s some bizarre ‘80s computer that needs to be accessed via serial cable. I want to find a use for the Lua RTOS, but I think I’ll invest in another esp32 to put it on eventually. I’m using my good one with an 18650 Li-ion battery.

Getting a little meta, last night I succeeded in programming the AVR uC on an AVR programmer I bought ages ago that had weird firmware that required a terrible Chinese flashing GUI utility which I just couldn’t use. I’ve tried to reprogram it and failed in the past. Last night I succeeded. It’s a good feeling. Funny thing was I had to flash an Arduino as an AVR programmer to do it. Which is almost the polar opposite of the reason I bought the AVR programmer. I have some special “Arduinos” that I need an ISP for. Really they are more or less an AVR with Arduino pin notation, and set up to run at 3v3.

A Lua based RTOS? shudder No wonder the ESP32 needs 600 MIPS & 512KB of RAM.

Yeah… I don’t think that’s the endorsed method of programming them. However I think using the IDF and optionally the RTOS (not the Lua one) is the way things are intended to be done. I haven’t really looked into it but I believe a common configuration is to have one core handling hardware and the other for the user program. The esp32 is a very versatile uC. A little too versatile. It actually makes me feel bad about not utilising more of it.

You could probably convince the version of gas that comes with GCCSDK to assemble Thumb code. Not sure about objasm (I doubt ROOL would have bothered supporting it)

That was my thinking. I haven’t looked yet. I feel pretty sure the GCCSDK C would be very difficult to make work, if it could at all with something like an STM32. AFAIK it doesn’t have the full Thumb instruction set.

https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M0

Yep. missing a few.
Ooh. There’s a radiation hardened version. Just what I need for …absolutely nothing. Neat though. I guess it could be used in a cubesat for something. Beyond that I can’t even imagine.

e: I’ll have to take another stab at it later. I just tried doing some assembly with the GNU assembler on RO. It almost worked. It made an object file but didn’t recognise the -Ttext flag and fell over before it could reach the elf step.
On the bright side it means it didn’t reject the -mthumb flag. Don’t know if it worked or silently failed TBQH.

I think I did successfully assemble some thumb code. No idea what to stick the binary in to have a look at it though.

http://www.martinhubacek.cz/arm/arm-cortex-bare-metal-assembly/stm32f0-cortex-m0-bare-metal-assembly

What I did is based roughly around the listing on the tutorial page. I didn’t download the files.

To get it to work the following should suffice:

*Remove the platform triplets from the makefile.

*change the linking line (uses -Ttext) from as to ld because as doesn’t pass -Ttext correctly for some reason.

• change / remove the contents of clean probably.

I also get a 12 byte long file. The first word is that throwaway stack vector(?) in the example. The other two look like garbage in Zap and StrongEd, so I guess it’s thumb code maybe?

e: caveat. I didnt use -T text 0xwhatever. I used -T ldscript

Honestly the English for anything associated with Whitecat is pretty atrocious so I’m going to guess ESL.

With the current state of education, I’ve seen worse from EFL people!

But in this case, a simple lookup shows: IBEROXARXA SERVICIOS INTEGRALES, S.L.

I also get a 12 byte long file. The first word is that throwaway stack vector(?) in the example. The other two look like garbage in Zap and StrongEd, so I guess it’s thumb code maybe?

Second word should be the start address, third word should be the code.

The Debugger module has support for disassembling the original “Thumb 1” instruction set. So you should be able to verify things by entering the following in a task window:

*load my_code 8000
*memoryi t 8008 + 4

Uh… Zap has a mode where it’ll disassemble Thumb. It just reads half words and tosses them at Debugger_DisassembleThumb so it is no better or worse than the above method posted by Jeffrey, only this way is nice, GUI friendly, and colourised. ;-)

Just thought I’d mention it…

If Debugger_DisassembleThumb ever gets post-Thumb-1 capable, Zap will need to get cleverer than just bunging halfwords at it 8~( – not insurmountable, I don’t imagine though. The IfThen (IT) instruction would probably be the most difficult part – otherwise you just have to send two halfwords instead of one, and be prepared to be told, “I only used one of those, and the second one wants your next halfword to finish it.” You could do that for IT as well, but then the disassembled listing couldn’t be UAL; you’d have to have some non-standard way of writing the IT instruction.

Edit: well, the “clever” for IT would all be down to the Debugger, not Zap, when I think about it! Even the normal two-halfword instructions would only need the debugger to say to Zap, “Okay, nothing yet, send us another halfword and I’ll tell you.”

Even the normal two-halfword instructions would only need the debugger to say to Zap, “Okay, nothing yet, send us another halfword and I’ll tell you.”

The protocol is nowhere near that clever. What happens is that each (half)word of memory (ARM/Thumb as applicable) is handed to Debugger and a string is returned which is parsed and printed to screen.
There isn’t even a call to set/return the current disassembly flags, which is a PITA… although Zap’s source seems to think SWI Debugger_63 would do the job, so maybe that worked once upon a time?

Getting Thumb+1 working may involve some work on behalf of the Zap extension. The simplest approach I can think of is for the Debugger to reject the incomplete instruction with a message such as “Insufficient data”. In this case, a dumb halfword loop will display “Insufficient data” followed by a bogus instruction (as the second halfword is disassembled); while a smarter loop will spot this and retry the instruction with a full word of data, fixing up the offsets as applicable.

Uh… Zap has a mode where it’ll disassemble Thumb.

Oh! So it does. It wasn’t where I thought it would be.

Good news is the disassembly looks perfect :) So RO GCC gas can do Thumb 1.

edited for clarity.

edit again. Thumb is unimplemented for gcc in arm-unknown-riscos. Not surprising.

I followed up on an odd option I saw in the LuaRTOS build config. Apparently the esp32 has a version of TinyBASIC burned into it. It was used for testing the boards and left in there as an Easter Egg, with precautions taken that it’s not a security risk. Such a weird microcontroller.

The protocol is nowhere near that clever. What happens is that each (half)word of memory (ARM/Thumb as applicable) is handed to Debugger and a string is returned which is parsed and printed to screen.

Yep. For certain things (long Thumb instructions, warnings about dangerous code sequences, etc.) the Debugger remembers what the last instruction was that it was supplied. Which is obviously not going to work very well if you’ve got more than one program trying to use the debugger at the same time.

although Zap’s source seems to think SWI Debugger_63 would do the job, so maybe that worked once upon a time?

No obvious sign of that in ROOL’s sources. Maybe a feature of an extension module?

Maybe a feature of an extension module?

Probably the Debugger Plus module apparently distributed with Zap. It does produce a few extra SWI’s

For certain things (long Thumb instructions, warnings about dangerous code sequences, etc.) the Debugger remembers what the last instruction was that it was supplied.

It also won’t work very well with the later Thumb’s variable size instructions. It would be better to know how this is handled to disassemble word-width instructions as a word, and not as two bytes of gibberish followed by the real instruction (akin to how DebuggerPlus dealt with ADRL).

No obvious sign of that in ROOL’s sources. Maybe a feature of an extension module?

and:

Probably the Debugger Plus module apparently distributed with Zap. It does produce a few extra SWI’s

No, DebuggerPlus has a SWI for reading the settings flags. In the Zap sources, we have code like this:

 [ NEW_DISASM = 0
        SWI     XDebugger_63
 |
        SWI     XDebugger_Flags
 ]

Where NEW_DISASM is zero for Acorn Debugger, and non-zero for DebuggerPlus. It seems as if Debugger_63 is used for both reading and writing flags…?

I don’t know where/what though. I’ve looked at the RISC OS 3.70 Debugger in RedSquirrel, and I downloaded Arculator and picked the RISC OS 3.11 Debugger apart using the Debugger itself ☺ and in no case is there anything that looks capable of recognising SWI #63.

<shrugs>