All Projects → WebFreak001 → Avrd

WebFreak001 / Avrd

Embedded Systems in D - Port of avr-libc headers and most avr-gcc processor defines

Programming Languages

c
50402 projects - #5 most used programming language
dlang
54 projects

Projects that are alternatives of or similar to Avrd

Helios
The free embedded operating system.
Stars: ✭ 223 (+1211.76%)
Mutual labels:  avr, embedded
Llvm
[MERGED UPSTREAM] AVR backend for the LLVM compiler library
Stars: ✭ 222 (+1205.88%)
Mutual labels:  llvm, avr
Libhydrogen
A lightweight, secure, easy-to-use crypto library suitable for constrained environments.
Stars: ✭ 247 (+1352.94%)
Mutual labels:  avr, embedded
xForth
Experimental Forth cross compiler for tiny devices
Stars: ✭ 53 (+211.76%)
Mutual labels:  avr, embedded
Tinygo
Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
Stars: ✭ 9,068 (+53241.18%)
Mutual labels:  llvm, avr
Platformio Core
PlatformIO is a professional collaborative platform for embedded development 👽 A place where Developers and Teams have true Freedom! No more vendor lock-in!
Stars: ✭ 5,539 (+32482.35%)
Mutual labels:  avr, embedded
Swupdate
Software Update for Embedded Systems
Stars: ✭ 711 (+4082.35%)
Mutual labels:  embedded
Swift Llvm
Stars: ✭ 802 (+4617.65%)
Mutual labels:  llvm
Rust Python Example
Example of using Rust to Extend Python
Stars: ✭ 699 (+4011.76%)
Mutual labels:  llvm
Llvm
Library for interacting with LLVM IR in pure Go.
Stars: ✭ 670 (+3841.18%)
Mutual labels:  llvm
Jucipp
A lightweight & cross-platform IDE supporting the most recent C++ standards. This project has moved to https://gitlab.com/cppit/jucipp.
Stars: ✭ 887 (+5117.65%)
Mutual labels:  llvm
Grin
GRIN is a compiler back-end for lazy and strict functional languages with whole program optimization support.
Stars: ✭ 834 (+4805.88%)
Mutual labels:  llvm
Numba
NumPy aware dynamic Python compiler using LLVM
Stars: ✭ 7,090 (+41605.88%)
Mutual labels:  llvm
Inkwell
It's a New Kind of Wrapper for Exposing LLVM (Safely)
Stars: ✭ 732 (+4205.88%)
Mutual labels:  llvm
Fprime
F' - A flight software and embedded systems framework
Stars: ✭ 8,642 (+50735.29%)
Mutual labels:  embedded
Paper collection
Academic papers related to fuzzing, binary analysis, and exploit dev, which I want to read or have already read
Stars: ✭ 710 (+4076.47%)
Mutual labels:  embedded
Swift Llbuild
A low-level build system, used by Xcode and the Swift Package Manager
Stars: ✭ 836 (+4817.65%)
Mutual labels:  llvm
Platformio Vscode Ide
PlatformIO IDE for VSCode: The next generation integrated development environment for IoT
Stars: ✭ 676 (+3876.47%)
Mutual labels:  embedded
Raylib
A simple and easy-to-use library to enjoy videogames programming
Stars: ✭ 8,169 (+47952.94%)
Mutual labels:  embedded
Atomvm
Tiny Erlang VM
Stars: ✭ 834 (+4805.88%)
Mutual labels:  embedded

avrd

Ported defines of avr-gcc and headers of avr-libc.

Enables you to use D with -betterC on embedded devices.

Port Status

Not all device specific header files are ported yet. When trying to import avr.io for the default device names this will result in an error in avr.io for any unported device.

Ported board headers:

  • ATmega1284P
  • ATmega168P
  • ATmega328P

Project structure

Most includes you would find in avr-libc (#include <avr/io.h> for example) have the same naming convention with this D package. So import avr.io; for your basic io header file.

You cannot currently use any custom processor definitions with the avr.io module.

Instead of defines like in avr-gcc this package defines enum values from the module avr.specs which describe the features of the processor. It's using enums instead of version statements so static if can be used with them, combined, etc. and also throws compiler errors if misspelling such a name.

The following defines are ported as enums:

/// Architecture automatically determined by the device name
/// This does not take into account the mmcu parameter and is solely based on the 
enum __AVR_ARCH__ = 2;

/// Assembler only
enum __AVR_ASM_ONLY__ = true;

/// Core have 'MUL*' instructions
enum __AVR_HAVE_MUL__ = true;
/// same value, but obsolete
enum __AVR_ENHANCED__ = true;

/// Core have 'CALL' and 'JMP' instructions
enum __AVR_HAVE_JMP_CALL__ = true;
/// same value, but obsolete
enum __AVR_MEGA__ = true;

/// Core have 'MOVW' and 'LPM Rx,Z' instructions
enum __AVR_HAVE_LPMX__ = true;
enum __AVR_HAVE_MOVW__ = true; /// ditto

/// Core have 'ELPM' instructions
enum __AVR_HAVE_ELPM__ = true;

/// Core have 'EICALL' and 'EIJMP' instructions
enum __AVR_HAVE_ELPMX__ = true;

/// Core have 'EICALL' and 'EIJMP' instructions
enum __AVR_HAVE_EIJMP_EICALL_ = true;
/// This also means this device has support for more than 128 KiB of program memory. This means that the program counter (PC) is 3 bytes wide
enum __AVR_3_BYTE_PC__ = true;

/// The program counter (PC) is 2 bytes wide. This is the case for devices with up to 128 KiB of program memory
enum __AVR_2_BYTE_PC__ = true;

/// This is an XMEGA core
enum __AVR_XMEGA__ = true;

/// This core has the RAMPD special function register
/// and thus also the RAMPX, RAMPY and RAMPZ registers.
enum __AVR_HAVE_RAMPD__ = true;
enum __AVR_HAVE_RAMPX__ = true;
enum __AVR_HAVE_RAMPY__ = true;
enum __AVR_HAVE_RAMPZ__ = true;

/// This is a TINY core
enum __AVR_TINY__ = true;

/// Offset where flash memory is seen in RAM address range or 0
/// NOTE: on avr-gcc this value is not set when __AVR_TINY__ is set, but instead it is named __AVR_TINY_PM_BASE_ADDRESS__
/// in avrd it is always called __AVR_PM_BASE_ADDRESS__ and trying to use the TINY version will not find the symbol
enum __AVR_PM_BASE_ADDRESS__ = 0;

/// Instructions that can address I/O special function registers directly like IN, OUT, SBI, etc. may use a different address as if addressed by an instruction to access RAM like LD or STS. This offset depends on the device architecture and has to be subtracted from the RAM address in order to get the respective I/O address
enum __AVR_SFR_OFFSET__ = 32;

See also GCC AVR Options for more detailed explanation of the here available values.

These specs are available from avr.specs but are also publicly imported by avr.io.

Additionally there is a __AVR_DEVICE_NAME__ value which is a string name of the currently used processor.

Device specific defines on the other hand are defined as version values. So far for most devices this is only the device name itself for C compatibility such as:

version (__AVR_ATmega1284P__)
{
	// on ATmega1284P
}

Installing LDC compatible with AVR

First follow https://wiki.dlang.org/Building_LDC_from_source additionally to using cmake on llvm with -DLLVM_TARGETS_TO_BUILD="AVR"

wget http://releases.llvm.org/9.0.0/llvm-9.0.0.src.tar.xz
tar xvf llvm-9.0.0.src.tar.xz
rm llvm-9.0.0.src.tar.xz

mkdir build-llvm && cd build-llvm # using a fresh new build dir is highly recommended whenever re-invoking CMake
cmake -G Ninja ../llvm-9.0.0.src \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_INSTALL_PREFIX=$PWD/../install-llvm \
  -DLLVM_BINUTILS_INCDIR=/usr/include \
  -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD='AVR' \
  -DLLVM_TARGETS_TO_BUILD='AArch64;ARM;Mips;MSP430;NVPTX;PowerPC;RISCV;WebAssembly;X86' \
  -DCOMPILER_RT_INCLUDE_TESTS=OFF \
  -DLLVM_INCLUDE_TESTS=OFF
ninja
ninja install


cd ..
git clone --recursive https://github.com/ldc-developers/ldc.git

mkdir build-ldc && cd build-ldc
cmake -G Ninja ../ldc \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_INSTALL_PREFIX=$PWD/../install-ldc \
  -DLLVM_ROOT_DIR=$PWD/../install-llvm
ninja
ninja install

You now have a folder called install-ldc with the ldc2 binaries with AVR target enabled. Use this ldc2 binary with the --compiler=path/to/ldc2 switch to make dub use this for compilation.

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