nanoframework/home

:house: The landing page for .NET nanoFramework repositories.

---

Document Language: English | 简体中文

.NET nanoFramework Home

This Home repository is the starting point for developers that want to learn about .NET nanoFramework, contribute to it or opening issues. It contains links to the various GitHub repositories used by .NET nanoFramework.

.NET nanoFramework goal is to be a platform that enables the writing of managed code applications for constrained embedded devices. Developers can harness the familiar IDE Visual Studio and their .NET (C#) knowledge to quickly write applications without having to worry about the low level hardware intricacies of a micro-controller.

It is part of the .NET Foundation.

Being a developer you'll probably will fit in one (or more than one😉) of the following profiles:

• You can enjoy to develop C# applications for micro-controllers.
• You can become a contributor as there are lots of areas to express yourself:
  • C/C++ native drivers working low level directly on the MCU with our Platform Abstraction Layer and Hardware Abstraction Layer, RTOS, developing .NET CLR for nanoFramework.
  • Managed C# to write new classes and drivers to add more bindings, libraries to .NET nanoFramework.
  • Managed C# to write tools like the Visual Studio Extensibility, debugger and others mostly .NET Core/.NET 5 CLI applications.
  • Help in setting up Azure DevOps pipelines to automate as much as possible.
  • Writing and improving our Unit Tests.
  • Helping others by answering their questions.
  • Writing and improving documentation, doing PR reviews or participating in the overall project organization.

.NET nanoFramework is a fun and interesting way to learn. It’s a complete project with a lot of deep engineering. You’ll find a vibrant community to help you and you’ll be able to help as well. We do welcome all kind of contributions and we aim to give visibility to our contributors.

Sponsoring .NET nanoFramework

Most of the core team members and contributors are embedded systems enthusiasts, passionate about coding and people that like challenges. The work on .NET nanoFramework is done mostly on their free time. Some of the core members happen to work on companies that sponsor heavily nanoFramework and offer their work hours to the project. If you use .NET nanoFramework for serious work or want to support it, please donate. This allow for paying the infrastructure cost and more time to be invested on the project. Besides monetary contributions, there are several other ways to contribute. Please read the documentation about this here.

This is how we use the donations:

• Pay for infrastructure costs.
• Develop public relation actions to get the project known.
• Support maintainers and contributors that invest a large amount of time in the project.
• Support projects that .NET nanoFramework depends on.
• Produce documentation, tutorials and other content to support developers using .NET nanoFramework.
• Organize events to demo .NET nanoFramework.

Sponsors

Sponsors will get their logo and link to a website on our GitHub readme and also on our home page.

Bronze Sponsors

Backers

Backers are individuals who contribute with money to help support nanoFramework. Every little bit helps and we appreciate all contributions, even the smallest ones.

Other backers and sponsors

There are other people and organizations that have contributed to .NET nanoFramework along the time in several ways: sponsoring the coding of a feature that was missing or needed improvement, paying for an expense, coding a feature or... We would like to acknowledge these sponsors.

Firmware for reference boards

Each of the following ZIP files contains the image files for nanoBooter and nanoCLR in various formats (HEX, BIN and DFU). They should be flashed in the target boards using an appropriate software utility.

The stable versions are continuous builds of the reference targets. They include the latest version of all features and bug corrections. They also have managed debugging features enabled along with detailed error messages, but exclude native debugging features and only minimal (or no) error messages.

For native debugging, please download the nf-interpreter repository and build locally.

Besides the firmware images below, you can find several others for community provided target boards. Check the available ones and download links on the Community Targets repo.

ESP32 modules and boards

Target	Stable
ESP32_PSRAM_REV0
ESP32_REV0
ESP32_PSRAM_XTAL26_REV0
ESP32_PSRAM_REV3
ESP32_REV3
ESP32_BLE_REV0
ESP32_BLE_REV3
ESP_WROVER_KIT
ESP32_PICO
ESP32_LILYGO
FEATHER_S2
KALUGA_1
ESP32_C3
ESP32_C3_REV3
ESP32_OLIMEX
XIAO_ESP32C3
ESP32_S3
ESP32_S3_BLE

M5Stack

Target	Stable
M5Core
M5StickC
M5StickCPlus
M5Core2
AtomS3

STM32 boards and chip based

Target	Stable
ST_STM32F429I_DISCOVERY
ST_NUCLEO64_F091RC
ST_STM32F769I_DISCOVERY
ORGPAL_PALTHREE

Silicon Labs Giant Gecko boards

Target	Version
SL_STK3701A
SL_STK3701A_REVB

NXP boards

Target	Stable
NXP_MIMXRT1060_EVK

TI boards

Target	Stable
TI_CC1352R1_LAUNCHXL_868
TI_CC1352R1_LAUNCHXL_915
TI_CC3220SF_LAUNCHXL

The above firmware builds include support for the class libraries and features marked below.

Click to expand!

Target	Gpio	Spi	I2c	Pwm	Adc	Dac	Serial	OneWire	Events	SWO	Networking	Bluetooth BLE	Large Heap	UI
ESP32_PSRAM_REV0	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️		✔️
ESP32_REV0	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️		✔️
ESP32_PSRAM_XTAL26_REV0	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️		✔️
ESP32_PSRAM_REV3	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️		✔️
ESP32_REV3	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️		✔️
ESP32_BLE_REV0	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️	✔️
ESP32_BLE_REV3	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️	✔️
ESP_WROVER_KIT	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️		✔️	✔️
ESP32_PICO	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️
ESP32_LILYGO	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️ Wi-Fi + Ethernet
FEATHER_S2	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️
KALUGA_1	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️			✔️
ESP32_C3	✔️	✔️	✔️	✔️	✔️		✔️	✔️	✔️		✔️
ESP32_OLIMEX	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️	✔️ Wi-Fi + Ethernet		✔️
M5Core	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️	✔️ Wi-Fi		✔️
M5StickC	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️	✔️ Wi-Fi		✔️
M5StickCPlus	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️	✔️ Wi-Fi		✔️
M5Core2	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️	✔️ Wi-Fi		✔️
ST_STM32F429I_DISCOVERY	✔️	✔️	✔️	✔️	✔️		✔️	✔️	✔️	✔️			✔️
ST_NUCLEO64_F091RC	✔️	✔️	✔️	✔️			✔️	✔️	✔️	✔️
ST_STM32F769I_DISCOVERY	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️	✔️
ORGPAL_PALTHREE	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️		✔️
TI_CC1352R1_LAUNCHXL	✔️
TI_CC3220SF_LAUNCHXL	✔️	✔️	✔️	✔️	✔️				✔️		✔️
NXP_MIMXRT1060_EVK	✔️						✔️		✔️		✔️		✔️

Repositories

Our GitHub organization holds the various repositories for firmware, class libraries, documentation and tools. You can find here a list and a description of each of them.

How to Engage, Contribute and Provide Feedback

Some of the best ways to contribute are to try things out, file bugs, and join in design conversations.

If you have a question, need clarification on something, need help on a particular situation or want to start a discussion, do not open an issue here. We ask you to open an issue only when you have a real and confirmed one. It is best to ask the question on one of our Discord channels. Make sure to select the channel that's most appropriate to the context so subject matter experts are most likely to answer promptly. Or you can go over to Stack Overflow and ask the question there, make sure to use the nanoframework tag.

If you can't use Discord, you should start a conversation at Discussion.

Looking for something to work on? Check the list of up-for-grabs issues on the Home repo, that's a great place to start.

See some of our guides for more details:

• Contributing Guide
• Contributing workflow

License

.NET nanoFramework libraries, firmware images, tools and samples are licensed under the MIT license.

Documentation

Docs

The project documentation is a great place to find information about .NET nanoFramework, no matter if you are newcomer or a veteran. It's organized in the following categories:

• API reference documentation for the various class libraries.
• Developing C# applications using .NET nanoFramework.
• Building an image to load on a target board.
• .NET nanoFramework architecture and how the different pieces fit together.
• Contributing to .NET nanoFramework includes an overview on how you can contribute to the project.

Blog

There is a blog where we try to post detailed updates about the development status, technical posts about a particular feature ou a design option.

YouTube channel

We also have a YouTube channel where with video tutorials along with feature demos and teasers about new ideas that we are experimenting with.

Code of Conduct

This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community. For more information see the .NET Foundation Code of Conduct.

home's Issues

CMake build

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#5

This is a feature plan for CMake-based build, individual tasks can be split into separate issues as needed.

• 🏃 Create a trivial sample that uses CMake for building C++ source
  • Visual C++ compiler (VS 2017 RC) #87
• Add support for configurations (Debug, Release)
• Add support for multiple toolchains
  • GNU ARM Embedded Toolchain
  • Optional: Bleeding Edge Toolchain
  • Clang
• Add support to configure target platform

Copyright notice for files that use original NETMF contents

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#62

In order to minimize the number of copyright notice headers, I suggest we use the following for all files that include any NETMF code:

//
// Copyright (c) 2017 The nano Framework project contributors
// Portions Copyright (c) Microsoft Corporation.  All rights reserved.
// See LICENSE file in the project root for full license information.
//

This should cover modifications to existing NETMF files, and also creating a new file with parts copied from [multiple] NETMF files.

Create a public room on gitter.im

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#51

...that should serve as a starting place for discussion with users, before an issue is filled etc.

• create a room on gitter.im,
• update documentation to ask users to start a discussion there before opening an issue,
• add badge to main README.

Correct naming throughout the documentation

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#73

The correct naming is "nanoFramework" (single word). There are inconsistencies throughout the documentation that need to be corrected.
All md files (on all branches) have to be corrected with the proper naming.
(suggest that we leave headers on the source files to be corrected as they are edited for some other reason)

Use standard C/C++ types

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#130

Replace the existing custom types with standard ones ([u]intN_t) from stdint.h.

Use existing STMCubeMX installation

From nf-interpreter created by Becafuel : nanoframework/nf-interpreter#20

Almost same issue as for FreeRTOS. Since CubeMX is a huge thing, it should be possible to use an already existing installation, at least for the repository.

If you have CubeMX, Keil and nanoFramework installed, that represents 3 times the same informations on the PC. And packages for each MCU flavor are really huge ( > 700MB for the F4 serie).

Rename TinyCLR to nanoCLR

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#104

To be consistent in source code and documentation (we are referring to nanoCLR, but code says TinyCLR) and to avoid confusion (and possible problems) with GHI's TinyCLR OS.

Add documentation about cmake-variants.TEMPLATE.json

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#115

• Add cmake-tools-cmake-variants.md to docs\cmake
• Explain the purpose of the file, the various entries and how a developer should tweak it.
• Add link to it on the items list at the upper level main document.

nanoCLR for ChibiOS doesn't run

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#152

nanoCLR is not running and seems to be trapped in a exception in ChibiOS code.
This has to be caused by some change introduced in a merge after #144.

Fix buffer overflow in wire protocol receiver

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#58

There seems to be missing a buffer size check while receiving the payload - especially when it was decreased (order of magnitude).

Setup organization repository

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#3

nano-framework.github.io

• Generate initial contents using automatic page generator
• master branch protected
• Setup custom domain http://nano-framework.net

Add support for USB communication in nanoBooter

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#44

This would be on the PoC test app.

Unneeded return value in nanobooter code

From nf-interpreter created by MikroBusNet : nanoframework/nf-interpreter#118

Nothing dramatic, however : the BlinkerThread() method is declared as returning void but it has a "return 0" statement at the end.

Allow use of an existing FreeRTOS install

From nf-interpreter created by Becafuel : nanoframework/nf-interpreter#18

During the initial build, CMake is downloading FreeRTOS files. It should be possible to use an already existing installation on the client PC to avoid a (useless) duplication.

Weaked functions need to actually exist, weak declaration only is not enough

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#165

Declaring "stub" functions with weak attribute is not enough.
Doing so makes the compiler happy but when actually running the code gets stuck on those calls.
In order to achieve the true purpose of this a weak function implementation has to exist.

• Chase all functions currently declared with __nfweak and provide implementation for each one with the __nfweak attribute. Group them by class (ex: Diagnostics_stub.cpp).

• Add ALL the stubs to CMake script.

• Update VS nanoCLR project to use these new "general" stubs instead of the current ones (private to the project).

Using floats in ChibiOS chprintf hangs an STM32F4xx board

From nf-interpreter created by piwi1263 : nanoframework/nf-interpreter#131

When using the chprintf function to print a float by using %f effectively freezes the MCU. In order to replicate the issue you have to set CHPRINTF_USE_FLOAT in chprintf.h to TRUE.

Separate implementation of transport interface from Wire Protocol

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#67

Change the current implementation so it has physical transport-specific part separated from Wire Protocol.

• move Wire Protocol command and receiver (state automaton) source files to source directory (src\CLR\WireProtocol)
• use an extension mechanism (callback functions?) to implement the actual transport - serial or USB
• check the need for (and how to) Initialize/Open, ReceiveBytes and TransmitMessage functions (maybe others?)

Add support for ChibiOS 'Community Overlay' in nanoFramework source tree

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#70

The motivation for this is to allow us to add "external" code (not in ChibiOS official source) without having to modify ChibiOS sources.
ChibiOS has this figured out with their 'Community Overlay' interface/source tree. Check it here.

The proposal is to add a 'ChibiOS community like' tree to the source directory so the code is stored there as it's added.

• add folder ChibiOS-nf-community to source tree
• update CMake modules to have the 'community' source files added to the build
• add documentation describing this

USB device doesn't show in Device Manager for F411RE and F427

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#141

Despite the ChibiOS driver configuration (following reference for Discovery4) and hardware configuration (using PA11 and PA12 pins) these boards don't show in Windows Device manager. It doesn't seem to be a fault in the configuration because the USB bus seems to don't even try to enumerate it.

Fix variable names in WireProtocol_Receiver.c

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#59

uint8_t m_receptionBuffer[256]; // was 2048
uint32_t m_lastPacketSequence;
uint8_t* m_szMarker;
WP_Message m_inboundMessage;
uint16_t m_lastOutboundMessage;

m_ prefix is used for members, static variables should have s_ (file scope) or g_ (global). Alternatively, don't use any prefix.

Adopt DCO as CLA

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#46

Implement Developer Certificate of Origin (DCO) as the Contributor License Agreement (CLA).

In the commit message of the contribution, the developer simply adds Signed-off-by statement and thereby agrees to the DCO:

Signed-off-by: Joe Smith <[email protected]>

• The project requires that the name used is your real name. Neither anonymous contributors nor those utilizing pseudonyms will be accepted.
• Every commit, that does not meet the criteria for an obvious fix, must have a Signed-off-by line.

References

• https://blog.chef.io/2016/09/19/introducing-developer-certificate-of-origin/
• Obvious fix https://docs.chef.io/community_contributions.html#the-obvious-fix-rule
• chef-boneyard/chef-rfc#213
• https://wiki.openstack.org/wiki/OpenStackAndItsCLA

Use of CORTEX_USE_FPU TRUE hangs MCU

From nf-interpreter created by MikroBusNet : nanoframework/nf-interpreter#121

In chconf.h, setting CORTEX_USE_FPU to TRUE compiles fine but hangs the board when flashed on a STM32F427 MCU using ChibiOS.

Please see this thread for more detailed informations if needed.

cmake-variants.json should be provided as template

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#26

Every developer needs to change this file according to its own setup and project at hand.
Having this file in the repo is prone to errors.

• cmake-variants.json should be provided as cmake-variants.json.TEMPLATE

• cmake-variants.json should be added to .gitignore

• add documentation explaining that developer should use cmake-variants.json.TEMPLATE to copy into it's own cmake-variants.json and change it as required

(thanks @piwi1263 for pointing this out)

Add check for "valid" nanoCLR image in nanoBooter

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#116

This is to prevent the CPU from jumping into the void when there is not a valid nanoCLR image flashed.
We are after a minimal check, not something overcomplicated and 100% failsafe.

A simple check would be reading what is pointed by the initial address of nanoCLR (the 1st word of the program) and comparing it with 0xE00C. Which should be constant for all Cortex-M parts).
An initial check would be reading the reset vector (the initial address of nanoCLR). If it reads 0xFFFF means that the flash is erased and we can just stop there.

This would be implemented at LaunchCLR(..)
This also requires a change in the code that precedes the call to LaunchCLR. As it is now it's stopping the RTOS and all drivers. It shouldn't do that before checking if it's going to jump.

Flash driver for ChibiOS

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#85

Develop a driver for ChibiOS to read/write/erase the internal flash of STM32 parts.

Remove source directory from root

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#86

Please move the source directory from root to a proper location, if still used. It's confusing to have two such directories. Thanks.

Update CMake so that the board name doesn't have to be listed

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#148

With the current CMake for ChibiOS (..\CMake\Modules\FindCHIBIOS.cmake) the board name is checked to exist in the ChibiOS source and at the nf Orverlay. That is OK.
The next step is to find out the board name in a list of the supported boards. This is to determine what is the series of that board so the proper CMake files are included.
This is necessary but it requires that for each board that is added/supported the name is added to this list. Not convenient for third party boards and others that are not in the repo because it requires that this CMake file is changed to support them. Doesn't work for automated build systems, for example.

Proposed fix: remove this list from the CMake and add a new parameter to the initial CMake that specifies the series of the board. This should be a general and broad series pattern to allow it's use it any vendor/series not only STM and the current STM32 series.

Win32 build fails due to missing target_board.h

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#142

target_board.h is included from nanoHAL.h, but does not exist (it's present only in ChibiOS targets).

MFDeploy reports NoConnection in ST_NUCLEO_F091RC

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#101

Despite this MFDeploy is able to receive the OEM info string!!??
This was working in the test app. Investigate what was changed.

It's still working with ST_STM32F4_DISCOVERY so it must be something related with the transport (serial USB vs serial).

Add ChibiOS board support for NUCLEO144_F746ZG

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#106

• being a "homebrew" support locate the required files in ..\targets\CMSIS-OS\ChibiOS\nf-overlay\

• suggest that one starts from a similar board from the official distribution (such as ST_STM32F746G_DISCOVERY)

• add board.c and h files

• update search path in CMake to include nanoFramework community overlay

Implement wire protocol receiver in C

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#42

Implement C functions for the receiver.

minimum required CMake is 3.7

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#82

• update root CMakeLists.txt

• update documentation (build-instructions.md) to mention this

improve handling of rules_STM32F7xx.ld linker file for F7 targets

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#154

The relative location of the file in ChibiOS and nanoCLR is different which is causing issues in the CMake for those targets.
Evaluate if it's better to just add a linker file for nanoBooter (despite it could use the one from ChibiOS source) or if the rules_STM32F7xx.ld file should be relocated inside the ChibiOS targets to match ChibiOS location.

SVN should not be mandatory

From nf-interpreter created by Becafuel : nanoframework/nf-interpreter#19

When specifying FreeRTOS in the CMake config, SVN is mandatory. Could this be avoided ?

List of hardware boards for nFI development

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#6

For the initial phase of nFI development a small number of hardware boards has to be chosen - these boards will be used for various design decisions, [automated] tests (!) and later also for showcase.

The obvious choices are STM's Discovery and NUCLEO, then Cortex-Mx from a different vendor. And one with completely different core - physical hardware not necessarily required at the moment, just something to keep in mind (so it can be easily added later).

Important requirement is RTOS support: the board must be supported by at least one of popular RTOSes (FreeRTOS, ChibiOS, mBedOS, NuttX etc.)

Please post your proposals in the comments, then let's pick boards with most votes - IMHO an ideal number would be 3, absolute max 5 (?) One extra slot for a custom board by a community maker :)

nanoBooter proof-of-concept

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#7

Implement bootloader proof-of-concept

• RTOS
• WireProtocol

Replace VS Code workspace var in launch.TEMPLATE.json

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#92

Using ${workspaceRoot} in the launch.json doesn't work after all.
Replace with hint for developer to replace with appropriate path.

Documentation cleanup

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#133

There seem to be duplicate documentation in docs and docs\building - please consolidate and remove the duplicates (build-instructions.md, vscode-debug-instructions.md).

Setup project repository

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#2

nf-interpreter

• priv branch for development until we go public
• /docs folder (can be set as source for GitHub Pages, if needed in future)
• main branch locked

Correct "source" directory references in <root>/CMakeLists.txt

From nf-interpreter created by piwi1263 : nanoframework/nf-interpreter#96

In CMakeLists.txt in the repo root there are still references to the "source" directory instead of the "src" directory.

Update gitignore for VS Code

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#91

Add section for VS Code and tidy up what's there today for VS Code.
Include what's in the "official" gitignore for VS Code from here:
https://github.com/github/gitignore/blob/master/Global/VisualStudioCode.gitignore

Add readme and license

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#4

• README.md
• LICENSE.md - Apache 2.0
• CONTRIBUTORS.md

Add documentation about using local RTOS source for build vs download during build

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#81

Provide information on the available options for the RTOS sources: use local or download from official repos during build.
Describe (with just enough detail) the differences between those and the advantages of using one over the other for diference use cases.
automated build: download
daily use on development cycle: use local

Relevant detail to include: when specifying a local source the Git clone has to have it's active branch "manually" set to the appropriate branch.

launch.json should be provided as template

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#76

Every developer needs to change this file according to its own setup and project at hand.
Having this file in the repo is prone to errors.

• launch.json should be provided as launch.json.TEMPLATE

• launch.json should be added to .gitignore

• add documentation explaining that a developer should use launch.json.TEMPLATE to copy into it's own launch.json and change it as required

Undefined reference(s) for F7 series

From nf-interpreter created by Becafuel : nanoframework/nf-interpreter#28

When building for the F7 serie (e.g. F746), I get some "undefined reference" error messages at link time.
Those are related to HAL_TIM_Base_Init() and HAL_TIM_Base_Start_IT(), which are located in stm32f7xx_hal_tim.c .

This file is indeed compiled (a dirty check with a volunteer syntax error shows that) but it does not seem to be linked.

It has to be noticed that there are no error when compiling for a F4 serie.

I have created an issue for two reasons : first because I think that it is an issue and second because it disappears quickly when posted on the Slack channel :)

CheckValidCLRImage fails when nanoCLR is not flashed

From nf-interpreter created by josesimoes : nanoframework/nf-interpreter#162

Remove stcube_repository from root

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#97

Please move stcube_repository from the root to more appropriate location (under build ?), if used. If not used anymore (#20 ?), then simply delete it.

nanoBooter PoC does not respond to Ping request

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#33

This is a known issue that has to be fixed before other transports (such as USB) can be added. The response packed is received by MFDeploy, but payload is not processed which results in 'no connection' message, although technically the connection is established and data is received.

I2C support fails to compile on F42x MCU

From nf-interpreter created by MikroBusNet : nanoframework/nf-interpreter#124

As soon as you add I2C support for F42x boards (F427 & F429 so far), you get compilation errors about many missing declarations (e.g. I2C_CR2_ADD10) :

C:\dev\nf-interpreter\build\ChibiOS_Source\os\hal\ports\STM32\LLD\I2Cv2\i2c_lld.c: In function 'i2c_lld_set_address':
C:\dev\nf-interpreter\build\ChibiOS_Source\os\hal\ports\STM32\LLD\I2Cv2\i2c_lld.c:137:28: error: 'I2C_CR2_ADD10' undeclared (first use in this function)
if ((i2cp->config->cr2 & I2C_CR2_ADD10) == 0U)

Such declarations are available for many other MCUs but not F42x ones.

Implement DCO Signed-off-by verification bot

From nf-interpreter created by cw2 : nanoframework/nf-interpreter#54

The purpose of this bot is to check Developer Certificate of Origin Signed-off-by line in every commit of a pull request.

Use case

• github repository is configured to issue a HTTP POST request (pull-request webhook),
• bot receives this request and for a new pull request (action = 'opened') scans commit messages of every commit,
• for all commits that have Signed-off-by: User Name <email> a github status is created

context = "DCO", state = "pending",
description = "This commit has a DCO Signed-off-by. Pending human verification."

• for all commits, that have Obvious fix, the following github status is created

context = "DCO", state = "pending",
description = "This commit declared that it is an obvious fix. Pending human verification."

• for all other commits it creates error status

context = "DCO", state = "error",
description = "This commit does not have a DCO Signed-off-by."

(optionally, target_url can point to documentation about how to add it)

Requirements

• Configurable user credentials for github account (or use token?)
• Configurable description texts

Notes

• Use Azure Logic App ?
• Optionally, a comment can be created to provide a summary, extracted user names from the signoff lines for easy verification, or list steps required to add the signoff...