Does the STM32 on the Espruino support UART with 7bit length?

Both USART_WordLength_8b and USART_WordLength_9b are defined in the header files. But USART_WordLength_7b is not. And since USART_WordLength_8b begins at 0x0 I suspect that the MCU does not support 7bit UART mode.

I know as much as you about this - but if it's possible in the STM32 then it shouldn't be a big deal to implement in Espruino.

I did a quick google and found the following - it looks like if you're happy with 2 stop bits then you can bodge it, but otherwise you can't do it.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fUART%207%20data%20bits&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=252

The need for 7bits comes from the IEC61107 specification. I was trying to port some code to read data from an Ultraheat 2WR5 energy meter into JS. As far as I remember, the standard it uses 2 stop bits. So the hack mentioned in the forum might be possible. I will make some minor modifications to the UARTinfo struct to add support for mode selection. If it work as expected I will do a pull request. Any preferences from you Gordon? char[4] with content like "7e2", "8n1", "8e1" etc? Or should we ignore mode select from mainline?

Great, let me know how it goes!

How about Serial.setup({databits:7,stopbits:2}) - you could add this to JshUSARTInfo in jshardware.h pretty easily, and it'd be nice and compatible with anything that didn't support it (or that supported other modes).

Maybe just add the following in jshardware:

if (databits==7 && stopbits==2) ...
else if (databits==8 && stopbits==1) ...
else jsWarn("Specified combination of stop and data bits is not available");

does that sound ok?

Sounds good. I will implement it and try it out in the next couple of days.

Thanks! It'd be awesome if you could contribute it back when it's done - Espruino could really do with a bit more control of its peripherals.

Could you also check it compiles on ESPRUINO_1V1=1 ? :)

But of course :-). Another thing I was playing around with was menuconfig support for the build environment. Is this something you are interested in Gordon? Like the menuconfig system used for the Linux kernel. It would be nice to have an easy way to configure the build environment and what to include in your own build.

Thanks!

As far as build goes, if the build could be completely based on boards/XXX.py, that would be awesome. I think it's probably more useful than menuconfig as there's a lot of duplication at the moment between the Makefile and the py file.

Of course if menuconfig was just a kind of 'where's your compiler', 'what board do you want to build for' - that could be pretty handy...

Even better would be 'you don't seem to have an ARM compiler, would you like me to install one?' :)

I've got it working on an STM32VLDiscovery board. Having a hard time to decide if we should handle 7bit in C or in JS code. As we could easily do:

function handleData(v) {
    for(var i=0; i < v.data.length; i++) {
        print( String.fromCharCode( v.data[i].charCodeAt(0) & 0x7F ));
    }
}

To handle 7e1 mode in JS code.

Great!

It's probably best to handle it in C (the less people writing in JS have to be aware of the better). Perhaps you could do something like data & ((1<<databits)-1) and then it'd be vaguely compatible with any number of bits.