I haven’t had a chance to look at the new MIOS studio beta; what level of i/o has already been implemented in the debugging terminal?
There is no solution to send strings to a STM32 via MIDI yet, mainly because I don’t have that much Java skills. I was happy enough to get the output terminal running (code is based on the MIDI monitor window). At the MIOS32 side, it wouldn’t be so that effort to support this (maybe 10 minutes to add this into the existing SysEx handler).
The output functions are quite powerful. E.g., you can send formatted strings (printf like interface) and memory dumps. Example:
How cool would it be to have small debugging commands to show MIDI i/o activity (like a midi ox terminal), button presses etc all in real time! (although I guess this is very possible with the current OS with the LCD display)
This was my initial idea, and it’s already used at many places 
Debugging is so much better with message/parameter output in plain text format.
Also the typical troubleshooting application to check the hardware are much more verbose than the old MIOS8 ones which are sending cryptical MIDI events to notify about the status.
I was thinking more a small file system set of commands, so you could edit front panel buttons, patches, midi/ethernet set up etc directly from a terminal.
A lot of programming effort to get it flexible enough, but it’s nice that you will take over this job
How is MIOS32 structured (trying not to sound too daft here!): do you have a form of “file system” hierarchy with a “root” then within there directories where progs/apps/commands are executed from and files are stored?
No, because such a file system which gives you access to HW resources as well would consume too much RAM. Another disadvantage: the string handling to access drivers (like known from uCLinux or eCos), generic pipes and/or block access layers, etc… consume some additional CPU time.
Resources are better invested into application features instead of emulating something which isn’t really relevant for our usecases.
However, the existing low-level functions don’t prevent you to setup a file system if you find this useful.
Files of a SD card are accessed via a DOSFS driver.
I suppose with MIOS8 it is very low level and more embedded so to speak, in the sense that you compile a program with your major hardware configuration set up, and it essentially just runs therein, all in one enclosed program with limited debugging i/o (unless a specific app was written to test i/o of course!)
Running a single binary is still prefered (due to realtime requirements), but debugging possibilities are much better.
MIOS32 itself doesn’t support multiple programs stored in internal flash, which then can be executed from a file system. It’s a nice idea, but not really applicable for a microcontroller without MMU (memory managing unit which maps address ranges)
Means in other words: for STM32 memory references have to be located during compile time (by the linker) anyhow.
Best Regards, Thorsten.
