This is my 3,000th post!

Just saying…

(^_^)

Spammer! (says the guy with 17000 posts on a different forum…)

This is my 50th! :—)

I know…been absent for quite a while…too busy working.

At least work is now interesting in that I’m programming ARM devices – our own custom OS though…they’re so low power not even sure RISC OS would run!

Great to see the forum alive and kicking on my return though…

And congratulations Rick! Do you get a gold star or something like on eBay?

At least work is now interesting in that I’m programming ARM devices – our own custom OS though…they’re so low power not even sure RISC OS would run!

One of the M series?
I think RISC OS ought to be portable to anything with an MMU, given suitable datasheets. After all, the specs of the original Archimedes are unbelievably low compared to today.

Great to see the forum alive and kicking on my return though…

And RISC OS on the Pi2, as well. Plus an iMX6 board. Though unless somebody is doing work behind closed doors, we still haven’t got a direction on how to deal with the other three cores in the Pi2. ;-)
One day… one day…

And congratulations Rick!

Thanks. Just goes to show how much of a life I don’t have, eh?

Do you get a gold star or something like on eBay?

<giggle>

In another post, you said:

We use serial all the time for talking to equipment at work so still heavily used in industry.

Speaking of industry…
Something that struck me as odd was the controller for the automatic roll/unroll doors. The doors are usually triggered by an infra-red sensor, like the ones used in burglar alarms. They roll up for a specified length of time (usually about 20 seconds) and then roll back down again. Around ankle height is a beam sensor to detect if anything is in the way of the door closing to inhibit doing so. It is also a useful way to get the door to reopen for those many times when it is closing just as you get to it – though the door will only reopen if it is more than a third closed. If it is less than a third closed it usually just freezes.
There is also a flashing yellow light that kicks in just before the door closes.

Seems like a fairly simple operation, right? I’m sure the techies here can mentally diagram a flow chart – it’s not a complex piece of hardware. Me? I’m stuck between whether this would be best implemented with a PIC/8051/etc and some firmware (best for multiples), or if it would be less expensive to forgo the programming and just build it with an R/C timer and some logic gates (best for a one-off).
Well, inside the controller box is a BIG board containing the circuitry for receiving input from the sensors and such, plus meaty relays and things for the motor and lights. That’s fair enough.
What is less understandable is the daughterboard with a large MCU (type unknown, no obvious part number when I looked) connected to what looked like Flash and SRAM. I have a vague recollection of trying to guess from the part number endings and arriving at 128KiB Flash and 512KiB RAM. There is a 7-seg LED and programming buttons and a bunch of I/O chips (I’m guessing I/O as they track out to the main board with the relays and stuff on it), only half of which appear to connect to anything. There is also another chip, slightly smaller than the MCU, that appears wired up to the memory. Jeez, don’t tell me that’s an MMU chip?!?
Anyway – I looked at this thing and whistled. Can anybody say overkill?

And it still behaves like a pile of logic gates. There’s absolutely zero intelligence in this thing…

One of the M series?

The Kinetis K22 and K60 from Freescale (I think…?). Cortex M4 with 120Mhz and 1MiB of memory. I joined when most of the low-level stuff had already been written (company uses quite a bit of ARM stuff in other devices and they ported most of the codebase to these new devices). My main task has been putting together a GUI on top of the previously written code…although I do occasionally have to delve into the lower level stuff but mostly it makes my head go fuzzy.

Seems like a fairly simple operation, right? I’m sure the techies here can mentally diagram a flow chart – it’s not a complex piece of hardware.

Years and years ago I did just this (albeit in a simulator) when I was at college. It was all written in ladder logic for an Allen Bradley PLC…although I’ve got no idea what the underlying hardware was – if I once knew it has since been forgotten…

Can anybody say overkill?

Could be worse – you could be using a Raspberry Pi…or desktop computer! :—P

As to which solution would be best its really up to what you are most comfortable with – I have very little experience laying out hardware so would go for a programmable solution (probably using some kind of FPGA or ARM chip with flash storage) but if I were better at doing circuits then I can see the attraction of doing it all with logic circuits…

I would love to see a CLI version of RISC OS for an ARM microcontroler. I’m sure that there is a market here (especially because of BBC Basic and good ASM tools).

I could give some money for this port, if the target is a low cost board, with remote access for monitor/CLI (network, serial, usb). Bounty?

I have not really looked at Thumb, but I suspect it is different enough that it may be more complicated than the port from 26 bit to 32 bit.

It will be a lot of work, but I don’t think it will actually be that complicated. In fact it may even be easier than the 32bit upgrade, because the assembler will catch most of the problems for you.

Basically the steps involved would be:

1. Convert all assembler sources to use UAL syntax (UAL is a relatively new syntax which in theory allows the same sources to be assembled to both ARM or Thumb instruction sets. Although there are some concessions since not all ARM instructions are available for Thumb, and there’ll also be some differences in functionality – e.g. conditional vs. unconditional, register restrictions, etc.)
2. Configure toolchain to produce Thumb output instead of ARM, fix any build issues it reports.
3. Fix all the runtime issues/code bugs (I’d imagine there’ll be several cases of jump tables not working correctly, anything which tries to be clever and store flags in the low 2 bits of code addresses won’t work, instruction decoding in FPEmulator & VFPSupport will need updating, etc.)

Of course once you’ve got a Thumb build of RISC OS you’d be stuck with the age-old problem of there not being any (compiled) programs which will run on it.

It would probably also be wise to make sure the ARM version of RISC OS is happy running Thumb programs, so that once you’ve got code recompiled for Thumb you’ll also be able to run it on ARM builds of the OS instead of being limited to just the Thumb build.

Or for step 1 I guess you could go the route of rewriting everything in C, which will help with the rather more pie-in-the-sky goal of producing an AArch64 version of RISC OS (which, ironically, the ‘unified’ UAL will be no help with whatsoever due to the 32 & 64 bit instruction sets being so completely different)

It will be a lot of work, but I don’t think it will actually be that complicated.

??!

Let’s see – from my small understanding of Thumb (from browsing the ARMv6-M manual):

• There are no conditional instructions, just a conditional branch +/- ~256 bytes. (ARMv7-M offers a few more, but nothing like 32 bit ARM)
• There may or may not be any processor modes. If there are, there is a privileged and a not-privileged. If not, it is always privileged.
• There may or may not be multiple R13s (some M series have a process stack pointer and a system stack pointer).
• You have R0 to R7 to play with. Oh, yes, R8+ exist but there are few instructions that can access them.
• Exceptions? Totally different. Ditto interrupts.
• Depending on the part, there may or may not be an MMU either…
• Are there banked registers? It looks like the exception handler can (does?) push R0-R3,R12,LR,PC to the stack automatically.
• There appear to be numerous types of PSR, plus some extra registers.
• SWI (now called SVC, bleugh, that’s a processor mode!) takes an eight bit value for the SWI number. RISC OS depends heavily on SWIs and in Thumb you can only directly specify 256 of ’em.

It is not insurmountable – though I do think it will be somewhat harder than “throw it at the assembler and see if it complains”. ;-) I think we may be looking at a rewrite-level task.

I was going to say that it might be a useful side project for somebody to get the basic kernel running on an M series processor, but I’m not so sure. What I/O? What filing system?
I guess I ought to get one of those cheap Arduino clones off eBay and play around with an actual M series ARM and see how it differs. If nothing else, I have an ancient washing machine that could do with some intelligence.

It would probably also be wise to make sure the ARM version of RISC OS is happy running Thumb programs

Would this actually be possible? Given the lack of graphics support and… pretty much anything else… we would likely expect a Thumb program to be a simple single-tasking process. That said, RISC OS doesn’t really have a concept of different processes (the Wimp fakes it nicely), so how would the system know at any specific time whether it is in ARM or Thumb state? This will matter for returning from the billion-or-so interrupts and events that take place every second. Indeed, a Thumb RISC OS may by necessity need to provide a very different API to the ARM version.Think of callbacks or CallEvery – the conditions of such a thing will be quite different; plus a different API will make it simpler to protect against problems such as having a 32 bit call branch into Thumb code and…ooops.
That said, how can you sensibly handle executing a Thumb program in a TaskWindow. ;-)

This might be something to consider as an “aside” when teaching RISC OS about different processes in order to support multiple cores at kernel level – once RISC OS knows that there may be multiple pieces of code running concurrently, flagging it as Thumb could be an alternative to flagging which core it is actually running on.

??!

Hmm. I guess I should have at least looked at some M-series docs before posting that.

As long as you’re targeting A or R series architectures, a Thumb-2 port is pretty straightforward, because Thumb-2 does cover 99% of the ARM-mode ARMv7-AR instruction set, and you do get all the usual processor modes available. But the ARMv6-M/ARMv7-M architecture is a completely different kettle of fish for many of the reasons you state (only two CPU modes, no MMU, etc.)

SWI (now called SVC, bleugh, that’s a processor mode!) takes an eight bit value for the SWI number. RISC OS depends heavily on SWIs and in Thumb you can only directly specify 256 of ’em.

OS_CallASWI :-)

That said, RISC OS doesn’t really have a concept of different processes (the Wimp fakes it nicely), so how would the system know at any specific time whether it is in ARM or Thumb state?

You can use the system control register to specify whether exceptions are taken in ARM or Thumb state. So as things are currently, a Thumb program which calls a SWI will automatically switch to ARM mode during the branch to the processor vectors. The SPSR will indicate that the caller was in Thumb mode, as long as it gets restored correctly the CPU will switch back to Thumb on exit from the SWI. Ditto for interrupts. The trickier bit will be where code/function pointers are passed around – any interfaces where a ARM <-> Thumb switch may occur will have to be careful to use interworking branches, and any Thumb code pointers will have to ensure the bottom bit of the address is set (since that’s what controls whether ARM or Thumb is used in an interworking branch).

If you’re set on porting RISC OS (or something like it) to a Cortex-M series CPU, you could probably write your own kernel which provides a subset of the main kernel SWIs, and module management facilities. That way there’d at least be some scope for programs written for a Cortex-M to be runnable on a regular ‘desktop’ ARM CPU (as pointless as that may be).