How to program Espruino pico in a C environment?

Hi,

I am wondering if anyone has experience changing Espruino's coding environment to Embedded C?
Like using STM32CubeIDE.
Should I re flash the MCU again? Thanks

Realistically to be able to develop properly (with fast reflash, and debug) you'll want to use the SWD pins connected to an STM32Discovery board. Details at http://www.espruino.com/AdvancedDebug

You can just reflash using ST's USB DFU, but you won't get debug and it'll be a bit slower, requiring a manual reset for each upload: http://www.espruino.com/Pico#advanced-re­flashing

Thank you Gordon,

Sorry, I have no experience to flash a MCU before , to avoid unexpected situation and also can develop properly, would flash it through STM32Discovery board be the easiest and best way to do it?

I am using Espruino Pico which is chip STM32F401CDU6, should I choose the discovery board with the exact same chip? or would any discovery board comes with F3/F4 chip be fine? any recommendation on boards ?

A naive way I am thinking for the first option based what I read from the Advanced Debug is:

• Connect the discovery board to the PICO with ST-Link based on the table provided
  
• Modify the file based on the "Gachats"
  
• Install st-link tools from git
  
• Run the command line provided
  
  

But I am not very sure where those files "ESPRUINOBOARD.py or PICO_XX.py"are located, and how to use them. would this process be able to make the PICO code in STM32cubeIDE Embedded C environment?

I need to run the program in very fast speed, and inline C is also not fast enough, Arduino is very close to C, I think Arduino might be faster than inline C?, is it possible to flash PICO as Arduino? the costs might be cheaper for me if this is possible

Thank you

You can use any discovery board - it's the SWD programmer on it that you care about. However you can also use ST's nucleo boards and one of those has an almost identical chip: https://www.st.com/en/evaluation-tools/n­ucleo-f401re.html

If you want to use STM32cubeIDE you'd basically be starting completely from scratch though (without Espruino).

You could then start off getting everything working using just the Nucleo board and then move it over to the Pico when you're happy. If you've never flashed an MCU before then that's what I'd suggest as it's definitely a less steep learning curve!

inline C is also not fast enough

Inline C is C code compiled to native code with GCC, with optimisation. You're not going to get code to run substantially faster than that regardless of what you do (although it's always possible that the JS surrounding your inline C is slowing it down).

Worth bearing in mind as you may go to a lot of effort only to find there is no difference in speed.

is it possible to flash PICO as Arduino?

Not easily - if you want to use the Arduino IDE, I'd buy an Arduino board and it'll 'just work'

HI Gordon,

Thank you for your information.

It seems SWD can be connected using wires, correct me if I am wrong. I am wondering what role st-link play in this case

Thanks

I need to run the program in very fast speed,...

@user101931, you have to be a bit more specific about

the program

More specific in sense of structure... For example, you have to serve an even very fast: react very quickly - with out delay - and calculate/compose a result very quickly. The next question is: do you want to take advantage of Espruino as a system and how easy it is to use? Speeding up an application is not a linear street: for some things there is no speed up, such as serially communicated. Going fully 'raw - C native - you may squeeze out a lot of power from an algorithm, but communicating the result takes a while and the overhead caused by the simplicity of use / application is only a few %.

What @Gordon means w/

it's always possible that the JS surrounding your inline C is slowing it down).

is the switching between environments - JavaScript calling native/raw/inline C - and then go back out and in again. In JavaScript references are base on lookup where as on incline C / raw, native, references are resolved upfront. In JavaScript memory is dynamically managed by the (Espruino) system where as on incline C / raw, native, memory is application managed. Since JS is dynamic and passes the addresses in calls to (inline) C and they can change between invocations. So make your pick. Enhancing the garbage collected memory mechanism w/ areas to lock down (and allocation at the 'beginning' to not fragment the remaining memory can help curb dynamics. Memory handling and garbage collect is though Espruino specific and different to other implementations as used on other general purpose computer platforms.

With a smart setup / combination of Espruino (JS) firmware combined w/ raw, native C programming - inline or as firmware extensions w/ own build - you can co really do great.