All Projects → grisp → grisp-software

grisp / grisp-software

Licence: other
Toolchain and Examples for GRISP

Programming Languages

python
139335 projects - #7 most used programming language
c
50402 projects - #5 most used programming language
shell
77523 projects
Makefile
30231 projects
GDB
78 projects

Projects that are alternatives of or similar to grisp-software

react-zendesk
A component simplifies Zendesk widget usage in your React application
Stars: ✭ 34 (+21.43%)
Mutual labels:  embedded
NuttX
Official micro-ROS RTOS
Stars: ✭ 63 (+125%)
Mutual labels:  embedded
Sub-IoT-Stack
Sub-IoT: Open Source Stack for Dash7 Alliance Protocol
Stars: ✭ 123 (+339.29%)
Mutual labels:  embedded
dtask
DTask is a scheduler for statically dependent tasks.
Stars: ✭ 17 (-39.29%)
Mutual labels:  embedded
xtrix
xtrix OS repo
Stars: ✭ 23 (-17.86%)
Mutual labels:  embedded
flutter-desktop-template
Template for https://github.com/Drakirus/go-flutter-desktop-embedder.
Stars: ✭ 50 (+78.57%)
Mutual labels:  embedded
northstar
Embedded container runtime
Stars: ✭ 82 (+192.86%)
Mutual labels:  embedded
BIPES
BIPES: Block based Integrated Platform for Embedded Systems allows text and block based programming for several types of embedded systems and Internet of Things modules using MicroPython, CircuitPython, Python or Snek. You can connect, program, debug and monitor several types of boards using network, USB or Bluetooth. No software install needed!
Stars: ✭ 72 (+157.14%)
Mutual labels:  embedded
pydevmem
Python interface to /dev/mem
Stars: ✭ 41 (+46.43%)
Mutual labels:  embedded
EmbeddedScrollView
Embedded UIScrollView for iOS.
Stars: ✭ 55 (+96.43%)
Mutual labels:  embedded
micropython-epaper
Driver for 2.7 inch Adafruit and Embedded Artists e-paper displays
Stars: ✭ 53 (+89.29%)
Mutual labels:  embedded
CML
Fast, safe and easy to use Cortex-M HAL Library, written in C++ 17
Stars: ✭ 17 (-39.29%)
Mutual labels:  embedded
orange-pi
Orange pi Kicad libraries and footprints.
Stars: ✭ 13 (-53.57%)
Mutual labels:  embedded
rust-radio-sx127x
Rust driver for the Semtech SX127x series of Sub-GHz LoRa/ISM radio transceivers
Stars: ✭ 21 (-25%)
Mutual labels:  embedded
embLua
Lua for microcontrollers
Stars: ✭ 23 (-17.86%)
Mutual labels:  embedded
IOsonata
IOsonata multi-platform multi-architecture power & performance optimized software library for fast and easy IoT MCU firmware development. Object Oriented design, no board package to define, just pure plug & play any boards
Stars: ✭ 40 (+42.86%)
Mutual labels:  embedded
gpio-cdev
Rust interface to the Linux GPIO Character Device API (/dev/gpiochip...)
Stars: ✭ 153 (+446.43%)
Mutual labels:  embedded
kalman-clib
Microcontroller targeted C library for Kalman filtering
Stars: ✭ 43 (+53.57%)
Mutual labels:  embedded
js-docker
Container deployment of TIBCO JasperReports® Server
Stars: ✭ 115 (+310.71%)
Mutual labels:  embedded
adskalman-rs
Kalman filter implementation in Rust
Stars: ✭ 22 (-21.43%)
Mutual labels:  embedded

GRISP

Prerequisites

  • the xz decompression tool needs to be installed

  • the zlib development files are necessary

  • bison, flex and texinfo

  • to check for some of RTEMS source builders prerequisites

    git submodule init
    git submodule update rtems-source-builder
    cd rtems-source-builder
    ./source-builder/sb-check

Quick Start Guide

You can build the whole toolchain by running ./build/build.sh. See [Building] for more details.

To build the simple RTEMS sample application, go to grisp-simple-sample and call make.

If you want to use OpenOCD, you have to make sure that you have read and write access to the USB device. On a Linux system using udev, you can copy the udev-rule from build/99-grisp.rule to /etc/udev/rules.d/ for that. The rule also provides a fixed name for the serial console (/dev/ttyGRiSP).

Directory Structure

The following directory structure is used in this project:

  • build: scripts for building the tool chain and libraries

  • grisp-XYZ: applications

  • libXYZ: non-RTEMS libraries

  • rtems-XYZ: software and libraries related to RTEMS

  • README.asciidoc: this document

Building

The complete toolchain is built by running ./build/build.sh. This will do the following:

  • check out the necessary git submodules

  • bootstrap RTEMS

  • build and install the toolchain

  • build and install the RTEMS BSP

  • build and install necessary libs

All installations are made inside the rtems-install subdirectory in the base directory of the repository. To change the install location edit the PREFIX in build/configuration.sh.

git Repository Structure

The grisp-software project pulls in a number of git submodules (like RTEMS). Most of these submodules have been forked with no or only minimal changes. The branches in the submodules follow the following guidelines:

  • master tracks the upstream development of the project.

  • If patches are necessary, they will be added on branches and the commits on the branch are referenced in grisp-software.

Here is an example for how a git tree of a submodule could look like:

 o---o---o---B'--o---o---o---o---o---o  master (clone of upstream/master)
      \               \
       \               A'--C'  grisp-20171110-xyz
        \
         A---B---C  grisp-20171020-xyz

In that example grisp-20171020-xyz is a version of the software with some adaptions for GRiSP. If for example a (maybe slightly modified) version of the patch B has been accepted in the upstream repository and GRiSP now wants to update to a newer version of the master, B is no longer necessary. Therefore the new grisp-20171110-xyx no longer contains B but (adapted) versions of A and C are still necessary.

The old grisp-20171020-xyz is still be kept so that a old version of the grisp-software repository can still access the commits.

That structure makes it relatively easy to see the exact differences to the upstream version and which patches might should be integrated into it in the future. The disadvantage is that it will leave quite a number of old branches that are still necessary so that older grisp-software revisions can reference them.

Re-Building only target specific RTEMS libs

Since building the toolchain takes a lot of time and since the toolchain changes less often than the rest of the system you can also just rebuild RTEMS and its libs.

To do that delete the rtems-install/rtems-4.12/arm-rtems4.12/atsamv directory and then do a

./build/build.sh --no-toolchain --no-bootstrap

Updating the submodules from github

When you want to rebuild with some new version from the Git repos you need to make sure that you update the sumodules:

git pull
git submodule update

Cleaning

Normally, running ./build/build.sh (or any other of the individual build scripts in the ./build folder) should rebuild without the need for cleaning.

However, if you want a clean start you can delete the rtems-install folder which will delete all created binaries, libraries and header files.

To make a complete reset of the whole repository, use the following commands:

git co .        # Reverts all uncommited changes
git clean -dxn  # gives a preview, what unversioned files would be deleted
git clean -dxf  # deletes everything that is not under version control

Boot Loader

The boot loader will try to initialize and mount the SD card. In case this is successful it tries to read the grisp.ini configuration file from the SD root directory.

Sample grisp.ini (showing the default values):

[boot]
timeout_in_seconds = 3
image_path = /media/mmcsd-0-0/grisp.bin

All values are optional and in case something is missing default values will be used (presented in the listing above). Once the timeout expired without user input the automatic application load sequence starts.

Updating the Boot Loader

For updating the bootloader build OpenOCD by running ./build/build-openocd.sh. You can then update the boot loader with the following call:

./build/debug-load-flash.sh grisp-bootloader/binaries/bootloader.exe

The process will need quite some time (about 30 seconds for loading and about a minute for verify).

If OpenOCD is failing due to libusb related issues, you might need to make adjustments specific to your operating system. Please see the libusb FAQ: https://github.com/libusb/libusb/wiki/FAQ

Debugging

It is possible to debug an application using the on-board FTDI to SWD adapter. First build and install OpenOCD by running ./build/build-openocd.sh.

Place a SD with some sample application into the target. This takes care that the bootloader starts an application. The debug scripts will wait for this and then overwrite the application that is booted by the bootloader with the one that should be debugged.

After that you should start openocd on one console using ./build/debug-start-openocd.sh. This starts an GDB-Server. Do not terminate the process. You can then start a gdb that connects to the server using ./build/debug-start-gdb.sh path/to/app.exe. The script adds a reset command to the normal gdb that restarts the target and reloads the application. Note that for bigger applications, that might need quite some time.

WiFi

By default, the wpa_supplicant.conf from the root of the SD card will be used. For a default WPA2 encrypted network, the file should look like follows:

network={
    ssid="mynetwork"
    key_mgmt=WPA-PSK
    psk="secret"
}
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].