Baremetal development using Teensy 4.0

Status
Not open for further replies.
If the user code never exits loop() - that is mostly baremetal - leaving loop() calls Arduino tyoe yield() before returning to loop().

There are just lots of libs and resources made active or linkable in an Arduino compatible way after a year or so of Paul's work.

There will be some buffers allocated for USB and Serial UARTS - clocks are running and systick is interrupting each ms.

If any of that is too much then edits to ResetHandler() in startup.c and related files can change or remove the init process that sets up minimal MCU function.

Tool chain is prepped and installed with TeensyDuino.

Hardware Debugging isn't directly supported or exposed at this time.

Not sure if that misses the define of bare metal - but other than systick _isr and currently mandatory USB code - a loop() { while(1); } doesn't do anything except spin in place and count millis().
 
I'm also interested baremetal development of the Teensy 4.0. I want to work at the register level so I can actually learn the hardware rather than abstracting away the lower level functionality through Arduino. Has anyone made any more progress on this?

I was thinking of using MCUXpresso (NXP's version of eclipse for embedded development), which supports the Teensy 4.0 processor MIMXRT1062DVL6A and configuring my project to use the GCC ARM toolchain to generate a Teensy compatible .hex file.
 
You can still use Arduino - just don't use libraries and do your stuff at register level ;)
MCUXpresso uses libraries, too.

If you still want to use MCUXpresso, I think you need to look at bootdata.c and the linker script in the teensy 4 core.
 
You can write inline assembly in gcc if you want to dive deep into bare metal coding. In general gcc does pretty good job, but there are some cases (e.g. tight high-performance loops) which you may want to write in asm by hand. Another option is to analyze the assembly code generated by gcc for potential optimization opportunities and restructure your c/c++ code so that the compiler does better job with it. I think it's better to start with the latter, so you can also keep your code portable and unlike asm many c/c++ level optimizations carry over to other MCU's as well.
 
You can still use Arduino - just don't use libraries and do your stuff at register level ;)
MCUXpresso uses libraries, too.

If you still want to use MCUXpresso, I think you need to look at bootdata.c and the linker script in the teensy 4 core.

Yes, I have register level code working in Arduino, but I want to use a modern IDE with full intelliSense, makefile control, and good project management. The Arduino IDE just isn't good.
 
Agreed :) It's a 80ies editor, not a IDE. Edit: No, the 80ie editors were better.
Have you looked at Platformio?
 
Agreed :) It's a 80ies Editor, not a IDE.
Have you looked at Platformio?

Lol very true. Yeah I have it downloaded for VS Code and I've spent some time playing around with it. Seems like I could use PlatformIO to get comfortable writing register level stuff without having to worry about the complexities of setting up an IDE from scratch. Then once I get more comfortable programming the teensy I can try to get something like MCUXpresso up and running.

Thanks!
 
Starting with the IDE is easy enough and allows testing and forum posting and support as needed: install IDE then TeensyDuino and it works.

@luni made a VsCODE addition that is great with Teensy with VsCODE IDE: github.com/luni64/VisualTeensy

Then perhaps start with that before PlatformIO as I expect - given it is Teensy specific customized and on VsCODE - it should be up and running. Though of course PlatfomrIO works and in use by folks here - so not a bad solution perhaps - just seems further removed.

The end result of PJRC Arduino support is just his years of work doing the bare metal work in a way that happens to be exposed to Arduino on the top end - all the low level code and net effect is making the bare metal usable.

I've suffered worse programming environments than the IDE - FrankB captured the windows command line build the IDE uses into a batch file that I extended to replace the TOOLS menu with another batch file in :: github.com/Defragster/Tset

If using Windows and an editor like SubLimeText that can run batch files to build or even the command line outside the editor - it works to use installed IDE+TeensyDuino with no changes - the IDE just preprocesses and does the make while you edit files in the editor of choice.

The result is a usable HEX file for Teensy. Paul's work on the IMXRT chip is now about 2 years in development making the bare metal hardware usable after the first year to put in Beta - lots of side issues like building boards and other software - but it all built on his prior years doing the same for AVR Teensys: 3, 3.1, 3.6, 3.5.
 
Looks like you're blinking the LEDs with busy loop delays.

Yes, you're right. This was just to get something working at all, though. I've been working on this some more and I got the timers working and had a more suitable LED solution at one point. Then I attempted to get the USB stuff working and I invested a lot of time in it. Without proper debugging tools it's hard, though, and at some point I was just thinking: why trying to recreate all the great stuff Paul has already done.. I mean, I learned a lot along the way but eventually I switched back to Arduino and PlatformIO. It's perfectly suitable for my needs and there's enough low-level work left for me in other parts of my projects.
 
Yes, you're right. This was just to get something working at all, though. I've been working on this some more and I got the timers working and had a more suitable LED solution at one point. Then I attempted to get the USB stuff working and I invested a lot of time in it. Without proper debugging tools it's hard, though, and at some point I was just thinking: why trying to recreate all the great stuff Paul has already done.. I mean, I learned a lot along the way but eventually I switched back to Arduino and PlatformIO. It's perfectly suitable for my needs and there's enough low-level work left for me in other parts of my projects.

Maybe you will end up with the realization, that Paul's cores is pretty much baremetal (OK, with all the #if defined, it is more MULTI-MCU baremetal).
BTW, I tried it, but realized it is not worth the pain and does not limit the knowledge and creativity. programming Teensy at register level is very common on this forum, especially if one introduces new devices. In fact, by using the MCU documentation, Teensy can be used for nearly everything.
Edit: I see you ended up with the realization.
 
Were you using a USB protocol analyzer or some other way to view the USB tokens & packets?

Every time this subject comes up, while I know it's extremely unlikely, I kinda do hope a little to see any fresh new ideas or perspectives on using the USB hardware. Especially in this chip with EHCI, the hardware is so very capable... but how to best make that available to users with a simple API?

There's also the matter of USB performance. On the simple lines/sec benchmark, I believe we're somewhere around 600K now, up considerably from ~150K at release 6 months ago, but still heavily influenced by the host side despite so much work I've done to speed up the Arduino serial monitor. However, 600K isn't even half of the theoretical maximum speed. So much more is (probably) possible.
 
Last edited:
Were you using a USB protocol analyzer or some other way to view the USB tokens & packets?

No, not at all. Just reading documentation and different implementations and nothing would work.

I kinda do hope a little to see any fresh new ideas or perspectives on using the USB hardware

Unfortunately, I've got too little experience for that and USB is pretty complex. Also, I've got no heavy requirements for a USB implementation myself right now, that's why I'd rather concentrate on other stuff. I've read your USB implementation for the Teensy platform and it seems to me you did well on focussing on the important parts. You did a lot of work and I think until someone has specific needs for a better implementation, not much is going to happen.
 
Status
Not open for further replies.
Back
Top