STM32 serial port access for OS operation?

[davotron]

I was just had a thought having worked on various embedded systems where I used to work: how nice would it be to have a serial port on the STM32 core that you could hook up to a PC comms terminal (or via ethernet to a telnet connection?!) that could be used to access a "higher level" version of MIOS.  Instead of editing config files, then compiling/assembling etc, config files could be edited from a terminal within the file structure of the OS whilst "online" so to speak - could be really useful for frontpanel debugging, editing patch files/ensembles etc

I was playing with a very simple low level command line version of embedded linux once, thought how cool would that be.. I don't know anything about FreeRTOS, is there any implementation of this in the pipeline? Sorry if its been talked about before or implemented etc!  It's a shame there is no version of an embedded RiscOS...

David

[lucem]

You can do that over telnet.

[davotron]

cool, that's awesome, I must have a play with one of these things!

[TK.]

Yes, the telnet access is already available, and a COM access (either via RS232 or USB COM) is prepared as well.

Even a text based console via MIDI is feasible (and very comfortable, as it would allow an USB connection under Windows, where USB MIDI and USB COM cannot be used in parallel... MIOS Studio already provides a terminal window, which is currently only used to display debug messages)

Examples:

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Fethernet%2Ftelnetd%2F

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Fcom_console%2F

Only missing thing is a command set for the shell.

If you would like to help out, you are welcome to join the team :)

Best Regards, Thorsten.

[davotron]

I think I need to walk before I can run!  I'm definitely interested though, certainly an eye opener knowing this exists now.  I'll have a bit more of a play when I've got my first midibox SID finished - it works, just need to sort out a nice enclosure for it etc.  I like the idea of terminal control via midi though, I guess it is essentially just RS232.

Thinking of going for a stereo version next, but it will most certainly have an STM32 core.  Had considered using an atmega 32 ARM a couple of years ago to control a SID chip, but the STM32 definitely has a few more plus points.

[TK.]

Alright, I gave you access to the programmers section of this forum (third board from the top, only visible when you are logged in)

It will take some time until I will start with MBSID V3 for the STM32 module. However, SID access routines are already prepared and tested:

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fsid%2F

I also experimented with a "CAN<->OSC proxy", which allows me to access MBSID V2 via ethernet by using the OSC protocol. STM32 acts as a bridge between Ethernet and the CAN network of a MBSID V2:

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fmbsid_can_osc_proxy%2F

Best Regards, Thorsten.

[davotron]

Thanks for that, if I can help out I shall!  I've done the odd bit of assembler, C/C++ and BASIC over the years, quite like the usage of the linux style terminal shell and associated commands.

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?  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)  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. 

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?  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!)

[TK.]

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.