Interested in a HAL for GBA?

[LegalizeAdulthood]

I'm prototyping a Kvasir HAL for the GameBoy Advance for use with devkitPro. Is there any interest in having this in Kvasir master with a pull request?

[MaxClerkwell]

I can’t answer the pull request question, but have you heard of emBO in Bochum? I wonder if you may like to give a talk about this Project there? Von: Richard Thomson Gesendet: Montag, 20. November 2017 22:03 An: kvasir-io/Kvasir Cc: Subscribed Betreff: [kvasir-io/Kvasir] Interested in a HAL for GBA? (#114) I'm prototyping a Kvasir HAL for the GameBoy Advance for use with devkitPro. Is there any interest in having this in Kvasir master with a pull request? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[odinthenerd]

this kvasir repo was the proof of concept, which we consider to have succeeded. There is ongoing work (in fits and starts) on a decomposition of this huge monolithic monster into different repos (metapogramming went into mpl CMSIS-SVD went into chip and register stuff went into bit), bit is in a pretty unfinished state right now as its waiting for mpl to freeze.

In other words, we are anticipating support for many different architectures, not just ARM Cortex and we would love your help ;)

[Sickeroni]

help will be good.
i have just some questions for the port. i'm not sure what you exactly mean with prototyping for use with devkitPro. If we know Hardwareregisters for the Hardware, we will support the toolchain DevkitPro. In the newer Version of Kvasir, with support for the GBA, we should be able to use other toolchains as well.
if i remember the Hardware correctly, we just need to add two new arm-devices. The best way for this would be to create new SVDs and generate alle Hardwarefiles through this.
The more interesting Part of kvasir on gba is to modify "libgba" to use kvasir.

[LegalizeAdulthood]

The GBA is odd in that it uses an ARM7TDMI core with a bunch of SFRs for the GBA functionality. devkitPro is just an up-to-date toolchain that allows you to cross-compile to the GBA's processor. On top of that you need an appropriate set of build scripts in order to target the memory layout of the GBA using a suitable linker script. I've been using tonclib and it's associated Makefiles with devkitpro for building images that are suitable for an emulator or for a flash cartridge. Other people use other libraries and setups such as libgba.

I've been using the GBA as the subject of a presentation on embedded C++ because:

• people find the GBA interesting
• it is limited enough in resources that you have to think about typical embedded programming problems: interrupts, limited memory, limited code space, etc. This is in contrast to a Raspberry Pi which is just a small form factor Linux desktop system IMO. The Arduino would be closer to the GBA in resource limitations but requires additional hardware (shields) in order to make an interesting game platform.
• there are free tool chains that target the platform (devkitpro)
• there are free emulators (No$GBA) for the platform.

All of that combined makes it a great way to talk about embedded C++.

However, existing libraries are very much C style in flavor. I had presented some small ways in which modern C++ could help prevent you from making stupid mistakes (mostly the idea of using enum classes for SFR register field values and modeling the SFRs by hand through custom classes). Kvasir is very much the "ultimate" in what I was thinking was possible with modern C++ but is much more mature than any of my small attempts at applying modern C++ to the GBA. I plan to take my GBA HAL model for Kvasir, rework the tonc tutorials and revisit the GBA in another presentation.

The continued interested in the GBA is such that I feel contributing its HAL to the Kvasir repo would be a good idea.

Regarding a presentation to emBO in Bochum, I doubt this will happen, although I am flattered by the offer. GBA HAL is very much a side project for me and I don't feel I'm an authoritative developer in this space -- I haven't done embedded stuff for my day job since 1986 when coding 6809 assembly :) and I also haven't done GBA development for my day job either. I do like to use the GBA as a reference platform for discussing embedded C++ however.

[Sickeroni]

i read about it today have some recommentations.
get rid off devkiparm. it is a good toolchain, nothing to complain, but why do we need this specific one. Same for Makefiles.
Kvasir will use cmake-Files with examples how to use different toolchains. (https://github.com/kvasir-io/toolchain/tree/development)
I see 2 big things that must be done, generate chipfiles. We use SVDs to generate them. Thats why its the first step in implementing it. (https://github.com/kvasir-io/HardwareDescriptionFileGenerator/tree/development)
the next step ist to implement the linker scripts. That can be easy copied from devkitarm.
the last step is implementing a C++-Library for it. You can use libtonc, but many parts must be reimplemented. Half work will be done through th generated chipfiles.
The main work here is to rewrite examples in cpp (with namespaces) and use kvasirs apply for SFR-Modifications.
Here is a example of brin.demo.c

REG_BG0CNT= BG_CBB(0) | BG_SBB(30) | BG_4BPP | BG_REG_64x32;
REG_DISPCNT= DCNT_MODE0 | DCNT_BG0;

the cpp/kvasirversion will be something like

apply(
set(Kvasir::REG_BG0CNT::BGchar_1),set(Kvasir::REG_BG0CNT::BGscreen_30),
set(Kvasir::REG_BG0CNT::BG_4BPP,Kvasir::REG_BG0CNT::BG_REG_64x32),
set(Kvasir::REG_DISPCNT::DCNT_MODE0,Kvasir::REG_DISPCNT::DCNT_BG0)
);

The namespacestuff is no obligation, but helps to prevent conflicts with names. That Problem that happens if libgba and libtonc are used in one programm

[LegalizeAdulthood]

As I see it, the toolchain issues are not connected to Kvasir; I simply mentioned it for completeness. All that Kvasir needs is a HAL. In other words, Kvasir doesn't try to be everything you need for embedded development targeting a particular platform, it just attempts to supply HALs for various SOCs that are out there. After all, if I am doing custom hardware with my own SFRs, Kvasir will not know anything about that and I will need to write my own SFR definitions, etc. That's all I'm doing with the GBA HAL.

You can see WIP here: https://github.com/LegalizeAdulthood/Kvasir/blob/gba/Lib/Chip/Unknown/Nintendo/GBA.hpp