Search results for:

Hi, in fact what might impact others boards is mainly:

1-modified: ./Makefile
Where i added a NUCLEOF401RE section in order to get it working. By the way I had to create an uncommented line like "NUCLEOF401RE=1" in order to build correctly otherwise "BOARD=NUCLEOF401RE make" was always building for a LINUX configuration... I am wondering how to do a proper selection with "BOARD=NUCLEOF401RE make" without having to have a "NUCLEOF401RE=1" line predefined in the Makefile. Something unusual must happen in my system.

2-modified: ./scripts/build_platform_config.py
Where I had to use os.path.normpath otherwise neither "/../scripts" nor "/../boards" where correctly interpreted and I had a "module not found error" immediately at the import line. This change should not do anything to other boards since it is a standard python functionality for normalising path and file names. I also added a leading line "# -- coding: utf8 --" because my comments included some accentuated letters.

Everything else is actually new files added under ./boards/ subtree.

So, I think my changes are harmless for other boards while my additions should also be harmless although unreliable so far. No C code was written or modified...

By the way I found the contributing.md file which explains your requirements.

Two questions:
a- How do I compute the memory values used in the boards .py files under the 'saved_code' section and for the 'variables' under the 'info' section? I copied the values from the STMDiscovery file just changing the memory sizes according to the STM32F401xE manual.

b- The NUCLEO boards do have an hybrid connectivity which creates a conflict about pin names: Arduino's analog inputs are names A## and the Espruino names are also A## to H##. You, logically, shortened the names as defined in the STM32F401 manuals by removing the leading "P". This makes A1, for instance, a valid name for both standard naming rules although the actual pins positions and functionality are totally different. Do you have any suggestion about how to name the Arduino's pins and the Nucleo's pins without breaking the already applied rules for the different boards?

I am also surprised that, for instance, setInterval works perfectly while setWatch doesn't at all. Actually holding down the user button is correctly read ("analogRead(BTN1)" answers 0 if pressed down, 1 if not pressed). Or is it a reversed logic problem when compared to Espruino board's user button?

I confirm that save() won't make it although the console log shows that it did it correctly. A "reset()" followed by a "dump()" won't show anything saved.

Finally, the web IDE works correctly. I just have an other problem with a character left in the input buffer whenever a reset() is done. This a firmware problem not a web IDE problem.

Next step is a git pull request directly on your GitHub repo.

Hello,

I have started some development around the NucleoF401RE board and Espruino 1v71.
However, it is just not even to an alpha status so far: console on UART2 works, LED1 blinks, BTN1 reads correctly but setWatch and save() don't work yet, memory was left to an other board default values. Meanwhile writing this suggests me some clues...
Actually, it is more an approach to get some more RAM/Flash, use some ready made arduino's shields and potentially be able to do some step by step debugging with EmBlocks. It comes with the Nucleo support out of the box too and mbed exports to it since last week.

So contributing to the Espruino interpreter project is my intention.
Incidently, should I create a separate branch in the Espruino project and submit my commits to this branch? I read something somewhere about contributing: finding it again is uneasy.

I definitively will not attempt to provide a serious/permanent support for this board...

Linked file is a rough log, all keystrokes included, of a session with gtkterm... Still have to try Web IDE for instance.

Hello,

The Espruino and Espruino Pico are really interesting projects. So I supported you by backing an Espruino Pico yesterday and received an Espruino 1V4 from Limetrace last Monday.

The Espruino board is the best choice when it comes to battery operated applications such as data loggers.
A proper ESP8266 module, solving the very tight power management issues, is still my best choice to IOT. A GPIO could just shut it down until sending data is a necessity... This module is a game changer and Espruino is very well suited to interconnect it with sensors!

Go on with your projects!