Since prizm provides no threading support to addins, I am considering porting FreeRTOS to it.
One of the software timers can be used as SysTick to drvide context switch. I guess it is doable.

What do you think?

--
si

It might be possible, however custom OSes can't be guaranteed to have a good exam mode, so even if you do make it, I wouldn't go around spreading the word.
Unless you mean that you would make it as an addin, in which case go ahead and try it.

I did not make it clear. Official Casio OS will not be replaced. FreeRTOS as a software library works IN the addin process and is part of it.

That's exactly what I mean.

Ah, okay.
I've never tried using the timers for this purpse, but keep in mind that the actual precision of the timer is not in milliseconds, it appears to run at 25Hz. Time from 0-31ms is 1 tick, the assuming every 40 milliseconds afterwards is an additional tick (see wiki.

Bad
25Hz is way too slow..

Yeah, I don't think you would be able to multithread with that.
I don't think overclocking your calculator would make this any faster, nor am I sure if this is current information (if it is true for fx-CG50), but I don't think that it is ever going to be 50/60Hz so this doesn't really matter.

.. or it is not so bad. 25Hz is fast enough for human eye for example?

Hey @dr-carlos, do you think the timer callback has higher priority than normal add-in process? That is, are the callback and normal process running in parallel, or the callback preempts completely, and the normal process execution wont resume until timer callback returns?

I'm pretty sure they run in parallel...
Obviously, if you do too much in a timer it will cause delays because of it trying to run the timer again before it finishes.
You should also note that DD syscalls do not work in timers (they cannot safely be run concurrently).
There are a few other drawbacks, see the wiki.

Thank you for pointing those out! I would have to dig into it deeper -- today is my first day as a prizm programmer. Seems there are plenty of traps ahead

I'm surprised you managed to set up an SDK in a day - have fun programming

It'd better be (fun)
I have spent the last few days skipping through wiki pages and actually code sth until today. As for SDK thats the easy part. The readme explains well and example project builds fine.

Since this is a somewhat recurring question, I think I might share some of the experience.

Even regardless of the exam mode support, installing new OSes in ROM has limited applicability because it's so easy to brick a calc while doing that. Plus, it would require tricks that might allow to bypass exam modes, so communities won't necessarily like the initiative. On the other hand, using a different kernel in an add-in is possible. I think it's a much more reasonable approach; in fact, we've been doing it for years in the Planète Casio community, so I can attest that it's both possible and very stable!

Now, to address the potential XY problem. If you "just" want to have concurrency in an add-in, you don't necessarily need an OS/kernel-level support.

The most straightforward option is to stay at the PrizmSDK level and use the system timers. The system timers are locked to 40 Hz, which I believe is fine for threading (too much context switching will kill performance after all). The timer callbacks are asynchronous but there is no parallelism, ie. the normal flow of the program is interrupted and stopped while the callback runs. The actual problem with most timer/display related functions it thus not concurrent-safety but reentrancy.

If you want better precision than 40 Hz, you can use the hardware timers which can be either 32768 Hz or ~7.5 MHz depending on which you use (and you can use them without a custom kernel!), however you won't have interrupts (you will need some yield-style action in the threads). This is because hardware timers use hardware interrupts and to catch them you would basically need a custom kernel.

Yatis has worked on a threaded version of gint at some point, and his version had both software and gint's hardware context saves, allowing to switch tasks but also kernels for debugging and tracing syscalls. It's pretty involved, but I guess the bottom line is that mostly anything is possible.

Also if anyone is reading this without knowing about the specific hardware of the fx-CG, let's clear any doubts now that actual parallelism is impossible since there is only one CPU (unless someone manages to reverse-engineer the DSP cores of the SPU2 module) and thus any concurrency would be on the scheduling side. ^^

Now if you want to actually port on existing real-time OS that's a whole different matter and it sounds much more difficult.

Hi Lephe! Thanks for your invaluable experience sharing & info! On one hand you strengthened my confidence to the possibility of implementing a real threading environment, and on the other hand I will also look into Yatis and gint you mentioned.

Had a glimpse to gint and fxSDK. Very promising. To me myself, the only hesitation is documentation support. Planet Casio is in French (right?), which is totally alien for me..

Ah yes, if you want to dig there you will have to face some content in French. To be fair, the repositories and code are in English, and I make sure that machine translations of the tutorials (with DeepL in particular) are of good quality. So far, I've had about 5-10 non-French-speaking users so I think it's manageable.

I'm still very biased for obvious reasons, so you shouldn't believe what I say verbatim

In any case, I think the threading stuff is really interesting. Setting up CPU context saves could be done from the PrizmSDK as well, as long as you don't need too much direct access to the hardware. I'd be really excited to see a prototype and help. I've just come out of a seminar about multicore ocaml and I can imagine how fun it would be to have algebraic effects on the calc!

Wow!! An OCaml runtime or interpreter on calc? That would be really cool and interesting. Looking forward to it!
BTW a Java VM is on my TODO list. But that could change, although I like Java language very much. Any way I have to tackle the threading thing, one way or another. Item number 2 on my wish list is to have some online debugging mechanism, probably through the serial port.

Wait no I just mentioned algebraic effects as a general programming tool! An OCaml runtime, while interesting, would be a big endeavor! With possibly blocking problems for back-end support (I don't know exactly, I've never tried to look into it).

A JVM would also be very ambitious, I think it would definitely stretch the performance capabilities of the fx-CG (especially the fx-CG 10/20).

As for debugging, that is more realistic; you can do it on the emulator with Redoste's setup (topic in French, repository). One of our secret projects with Yatis is to use gint's USB driver to have gdb run with the calc. It would probably be doable since Yatis already has drivers that can set breakpoints etc., but it's not high on our priority lists.

You have really interesting goals and ideas though, I'd be very interested in seeing any of that take concrete shape!

Threading and debugging both are foundations for my final goal: JVM. Since gint seems has both already I probably should consider it seriously. Lets see what happens..

It'd be a stretch to say that gint has both; Yatis' threading worked AFAIK but it was experimental (and I think not up-to-date to the current version), and debugging hasn't been tested yet. I'm optimistic but I don't want to lie to you either!

gint does have some stuff that would be useful though like an extendable malloc(). Now that I think about it I wonder what the main requirements for the JVM are? :thinking: