nanoframework / home Goto Github PK

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.

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

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

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.

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.

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.

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

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

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.

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

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 :)

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

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)

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.

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

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

This would be on the PoC test app.

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)

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

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

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

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

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

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

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

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.

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

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

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.

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

Implement bootloader proof-of-concept

• RTOS
• WireProtocol

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

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.

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

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.

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.

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 :)

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.

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.

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

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

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

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.

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.

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.

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.

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.

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

• update root CMakeLists.txt

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

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.

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

Implement C functions for the receiver.

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.

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.

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

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.

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