i.MX RT1062: Getting Started, on a Raspberry Pi?

[AaronD]

It's actually a Teensy 4.1, but since it's essentially a breakout board for that chip (as far as I can tell, all Arduinos are, plus an easy programming interface), I thought I'd see if I can ditch the (somewhat opaque) Arduino environment and go direct to baremetal.

NXP has their own IDE, SDK, and related tools, but they're either online or for x86/64 only.  I'm on a Raspberry Pi 4 with the official RasPi OS.

The Raspberry Pi Pico has an AWESOME SDK and documentation, and makes it plumb easy both to make something work now, and work well, and to dive into the details.

8-bit PICs and AVRs are simple enough that I can start with the details and build from there.  My typical project with those is:

Code: [Select]

#include <avr.h>    //figures out from the project definitions, which chip-specific header to #include
                    //same idea for pic
void main()
{
    register = value;    //register matches a name in the header file, which in turn matches the datasheet
    register = value;
    //etc.

    while(1)
    {
        //non-blocking state machine for each logical function, to keep the loop running

        //lots of polling interrupt flags, and explicitly clearing them, because they don't actually need an *immediate* response
        //most things only need to be handled "before the next event", for which polling is plenty
    }
}

void isr()
{
    //only used if absolutely necessary, so that an immediate response is *actually* immediate
}

For both 8-bit projects and desktop applications, I've come to like Code::Blocks and GCC.  But I'm not finding much on how to set that up for an RT10xx.  Help?

[Nominal Animal]

It's actually a Teensy 4.1, but since it's essentially a breakout board for that chip

Actually, it's not.  (I'm not nitpicking, just trying to help, as I read that as conflicting expectations of exactly what Teensy 4.1 is.)

Teensy 4.x have a proprietary NXP MKL02 bootloader chip, which is connected to the JTAG and SWD pins.  Basically, you can only program the i.MX RT1062 through the properietary PJRC bootloader, unless you desorder the MKL02 chip off the board.

Teensy LC, 3.x, 4.x, and MicroMod Teensys use Teensyduino, with the core sources at Paul Stoffregen's github repository (teensy4 tree).  The toolchain is a standard ARM GCC toolchain with newlib C library.  Teensyduino can be used on the command line, although it will still use Arduino machinery to do so.  Although the GUI version of the Teensy Loader is easiest to use, one can also use the open source teensy_loader_cli to upload non-encrypted firmware images to any Teensy.  So, even though you do need Arduino stuff installed, you can definitely write Teensy code in Code::Blocks (and you will be using GCC), using the Makefile example at the Teensyduino page.  (Name your sources with .c/.cpp/.h extension, and they won't be preprocessed using the Arduino preprocessor, like .ino files are, IIRC.)

Teensy cores are pretty darned good (as you can see from the generated code, if you look at the disassembly of the ELF object files that are linked into the final HEX firmware image), and since it uses GCC, you can use both C and C++ with it (with the standard embedded C++ limitations, i.e. no exceptions etc.).
However, it is not really suitable for bare-metal programming.  The i.MX RT1062 is pretty complicated for that anyway; even the Teensy core supports a relatively simple subset of its features.  Using Teensies/Teensyduino within your own design requires buying the preprogrammed MKL02 chips off PJRC (but Paul and Robin are good people (based on how they treated their employees and the community during the pandemic, for example), and Paul is very often on the PJRC forum discussing future plans, helping with technical issues, etc.), but they're cheap and PJRC definitely does not price gouge.

I personally have used Teensies for many years (as a hobbyist) starting with a Teensy 2.0++, and it is my favourite microcontroller by far.
But, because of the proprietary bootloader connected to the JTAG and SWD pins, it really isn't at all a "break-out board for i.MX RT1062".
However, it is an excellent platform to test and experiment with, even if you relatively quickly end up making your own board (with or without the PJRC bootloader chip).  (In particular, SparkFun MicroMod Teensy is such a derivative (with trademark agreements between PJRC and SparkFun for the "Teensy" use), with SparkFun getting the MKL02 chips from PJRC, but otherwise making their own Teensy-compatible boards.)

For true bare metal, you should look at NXP MIMXRT1060-EVKB, MIMXRT1064-EVK, MIMXRT1160-EVK, or MIMXRT1170-EVK, whichever best matches your intended processor.  They are a lot more expensive, of course, but it is a much more complete evaluation kit.

Others have started with Teensy 4, then manufactured their own boards based on what they learned and decided they needed; both with and without using Teensyduino support via the PJRC MKL02 bootloader chip.  The main issue is that the chips only come in BGA footprints, but there is some advice about that on the MKL02 bootloader chip page.  I suggest you go and read the related threads at the PJRC forum, Project Guidance and Technical Support & Questions sub-boards, looking for "custom teensy" and similar subjects.  We're not allowed to use "Teensy" when naming of our own custom boards and products, though, because that would be trademark dilution.

[westfw]

It's actually a Teensy 4.1 ... I thought I'd see if I can ditch the (somewhat opaque) Arduino environment and go direct to baremetal.

Most Arduino "cores" include a copy of the appropriate gcc, CMSIS, and newlib tools, in addition to the code that makes them "Arduino.'  You could just copy them to a more dignified-sounding directory, add them to your paths, or whatever.

[luiHS]

You can't use a Teensy outside of the Arduino environment, because you don't have SWD access to be able to program it directly.

You are better off making your own board or purchasing an evaluation board from NXP.

[Nominal Animal]

You can't use a Teensy outside of the Arduino environment, because you don't have SWD access to be able to program it directly.

You are better off making your own board or purchasing an evaluation board from NXP.

luiHS, you only needed two sentences to say what I tried to convey in a page full of text.  Well said, and I fully concur. 

[mac.6]

Just use the header file from NXP SDK, they are monolitic and easy to integrate in your build.
Same with peripheral code generated by tools (at least clock and pinmux), you are not obliged to use them in a pre-generated build like on STM32cube.
Then you can roll your own driver code from this (or reuse NXP one).
But remember that RT family is quite a set-up from arduino or rpi pico, in fact they are much more MPU than MCU (especially the big ones).

[AaronD]

It's actually a Teensy 4.1, but since it's essentially a breakout board for that chip

Actually, it's not.  (I'm not nitpicking, just trying to help, as I read that as conflicting expectations of exactly what Teensy 4.1 is.)

Teensy 4.x have a proprietary NXP MKL02 bootloader chip, which is connected to the JTAG and SWD pins.  Basically, you can only program the i.MX RT1062 through the properietary PJRC bootloader, unless you desorder the MKL02 chip off the board.

I guess they've gone much farther beyond my impression of them early on.  I got started with 8-bit PIC's in high school, using a third-party IDE and toolchain that I came to understand later was probably pirated, and the surrounding circuit design just soon enough to have gotten good at it when the first Arduino's came out.  I looked at what they were then, and concluded that they were just a UART bootloader with self-writable flash, and a USB <-> UART chip wired directly to the AVR.  Otherwise a breakout board.  I could do much better, smaller, and cheaper than that, and so I didn't need to concern myself with them.  If I did end up using one, I could set up a baremetal project for that chip that didn't know any different, and just run the HEX file through the standard bootloader.  Never got to test that theory.

I just assumed that the modern concept was still the same thing: that I could set up a baremetal project for that chip that doesn't know any different, and use the provided (now unbrickable) bootloader and corresponding host app to put the resulting HEX file into it.  No?

Teensy cores are pretty darned good (as you can see from the generated code, if you look at the disassembly of the ELF object files that are linked into the final HEX firmware image), and since it uses GCC, you can use both C and C++ with it (with the standard embedded C++ limitations, i.e. no exceptions etc.).
However, it is not really suitable for bare-metal programming.  The i.MX RT1062 is pretty complicated for that anyway; even the Teensy core supports a relatively simple subset of its features.

I personally have used Teensies for many years (as a hobbyist) starting with a Teensy 2.0++, and it is my favourite microcontroller by far.
But, because of the proprietary bootloader connected to the JTAG and SWD pins, it really isn't at all a "break-out board for i.MX RT1062".
However, it is an excellent platform to test and experiment with, even if you relatively quickly end up making your own board (with or without the PJRC bootloader chip).  (In particular, SparkFun MicroMod Teensy is such a derivative (with trademark agreements between PJRC and SparkFun for the "Teensy" use), with SparkFun getting the MKL02 chips from PJRC, but otherwise making their own Teensy-compatible boards.)

I was thinking to use the Teensy 4.1 to absorb what a 20MHz AVR is currently doing, in addition to live audio DSP.  My first attempt at audio DSP was on a RasPi Pico (RP2040), but it couldn't keep up with much more than a signal generator at 48kHz, even if I dedicated a CPU core to just that.  So I got the Teensy instead.

• The AVR to absorb is a custom LED backlight controller for an LCD monitor with dead fluorescent tubes, that currently communicates with a Raspberry Pi 4 via UART for some automation.
• For the audio, I want to receive stereo from the same Raspberry Pi, either I2S or USB UAC2, apply some processing (encoder-adjustable highpass, dynamic range compression, crossover filters, per-driver EQ and limiting, etc.), and send the result to some 24-bit DAC's on TDM.  Also transport some TDM ADC channels back to the Pi as a "microphone".

The DAC's do need to be 24-bit, not 16-bit like the Teensy Audio Library appears to be fixed at, because the main volume control is in the *middle* of the DSP chain, not the end, and I want it to have a lot of useful range.  So it can't just change the DACs' on-chip gain while continuing to send them full-scale data.  It really does send an all-zero MSB if you pull the main volume down enough, and it still needs to be decent quality at that low level, hence the longer words.  (full-scale is LOUD too, so an all-zero MSB might not be as quiet as you'd normally imagine, but still a ways down)

So it looks like I can't use the pre-fab and working Teensy Audio Library, because it's only 16 bits.  Which is fine, because I'm also using this and some other projects to build the tools and skills to make a bigger one, which will have a *very* tight maximum latency from analog in to analog out.  (so the converters' group delay is also important)  I'm wondering if I need to write my own just to guarantee that minimal latency, even if it's not as processor-efficient.

Or if someone has already created a library that has a 3-frame pipeline with local I/O - clock in, process, clock out - where a given sample really does go all the way through that quickly regardless of how long the processing chain is, and at least 24 bits for that local I/O (probably more internally), plus USB Audio (which is *not* included in the ultra-low-latency requirement), I'd be tempted to use that.

[SiliconWizard]

You can't use a Teensy outside of the Arduino environment, because you don't have SWD access to be able to program it directly.

Uh, yes you can.
I have a Teensy 4.1 and used it without Arduino whatsoever, using the NXP SDK.
You just need the "Teensy loader" to upload firmware. Comes with a GUI app and a CLI.

[Kalvin]

It's actually a Teensy 4.1, but since it's essentially a breakout board for that chip

Actually, it's not.  (I'm not nitpicking, just trying to help, as I read that as conflicting expectations of exactly what Teensy 4.1 is.)

Teensy 4.x have a proprietary NXP MKL02 bootloader chip, which is connected to the JTAG and SWD pins.  Basically, you can only program the i.MX RT1062 through the properietary PJRC bootloader, unless you desorder the MKL02 chip off the board.

PJRC is protecting their IP, or what is the purpose of this MKL02 chip?

[westfw]

PJRC is protecting their IP

PJRC is protecting their "boot IP."  It's actually really clever, giving you bootloader-like functionality (load over USB) with zero program memory footprint (or impact, like needing to change the start address) in the the target microcontroller.

[josip]

I guess that MKL02 is not only for updating firmware. It is connected also to DCDC_PSWITCH and POR_B.

Is there any open (simple) schematic beside NXP boards and  Teensy? Adafruit Metro M7 NXP iMX RT1011 is not.

IMX RT is really great but too much pins are lost on power related stuff, and I dislike special power on / off sequence.

[newbrain]

I guess that MKL02 is not only for updating firmware. It is connected also to DCDC_PSWITCH and POR_B.

Yes, it also handles the power on sequencing that is a bit complicated in iMX Rts.

You can't use a Teensy outside of the Arduino environment

Simply false.
I don't have any Arduino stuff on my computers, but happily use Teensy 4.1.
I don't even have MCUxpresso 🤮 installed, though I use parts of the SDK.
I use picolibc instead of newlib(nano) or redlib.

The only needed special bit of SW is the Teensy.exe programmer.

Yes, making SWD (or JTAG) inaccessible is unfortunate (unless you recur to extremely delicate surgery - and then only JTAG).
Even more unfortunate is that also the Debug Monitor mechanism is out of reach.

To help with debugging, and as a bit of a challenge, I have coded a gdb stub server.
It's very loosely inspired by https://github.com/ftrias/TeensyDebug, though I have used none of that code - since it must be integrated with the applications, the GPL license would spread to it.
It simulates breakpoints with SVC instructions, it's not 100% complete, mostly because the use case sequences that gdb uses are not 100% documented, but works quite well, allowing setting breakpoints and C/instruction level single stepping. Integration with FreeRTOS allows reading thread list and per thread stack traces and local variables -thread single stepping does not work, though.

[Kalvin]

PJRC is protecting their IP

PJRC is protecting their "boot IP."  It's actually really clever, giving you bootloader-like functionality (load over USB) with zero program memory footprint (or impact, like needing to change the start address) in the the target microcontroller.

Thanks. I would say that in that case their bootloader is pretty cosmetic in that regard because modern chips have quite a lot of memory and the bootloader itself is typically only few KB, changing the start address in the linker script is trivial, and ARM-processors can relocate their ISR vectors. Of course, using an external bootloader chip will make the board brick-proof, but reflashing the bootloader is not too difficult (see below).

Is there any practical way which could bypass this proprietary MKL02 bootloader-chip? For example, would it be possible to flash the i.MX RT1062 using OpenOCD, or those cheap USB<->SWD dongles that are used for programming the Bluepills?

An update came to this thread while writing this message:

I guess that MKL02 is not only for updating firmware. It is connected also to DCDC_PSWITCH and POR_B.

Yes, it also handles the power on sequencing that is a bit complicated in iMX Rts.

Ok, now I understand much better.

[mac.6]

PJRC is protecting their IP

PJRC is protecting their "boot IP."  It's actually really clever, giving you bootloader-like functionality (load over USB) with zero program memory footprint (or impact, like needing to change the start address) in the the target microcontroller.

Well i.MX got also a ROM bootloader and secure boot, so that's a little bit weird to keep their architecture, but from a user point of view it's understandable, you keep the same sw solution across the boards without too much hassle.

[Nominal Animal]

You can't use a Teensy outside of the Arduino environment, because you don't have SWD access to be able to program it directly.

Uh, yes you can.
I have a Teensy 4.1 and used it without Arduino whatsoever, using the NXP SDK.
You just need the "Teensy loader" to upload firmware. Comes with a GUI app and a CLI.

Did you need to include any code to support firmware updates, or does the MKL02 chip do it all via SWD/JTAG when you press the physical programming button?

This is funny as hell to me, because I never even considered doing that. 

[newbrain]

Did you need to include any code to support firmware updates, or does the MKL02 chip do it all via SWD/JTAG when you press the physical programming button?

This is funny as hell to me, because I never even considered doing that. 

No need for Teensy specific code, and it is not even really hard to pull out (as others and I said).

The MKL02 will do everything on its own: it loads an USB capable downloader/flasher in RAM using JTAG (not SWD, for unknown reasons) then runs it, waiting for the PC side application to send data (or a reset command).

Once the SW is on Teensy's flash, there's no difference (well, some fuses are hard set) with a naked iMX RT1062, you just can't debug it (but see my post above).

Since I despise both Arduino (it has its place, but not for my needs) and MCUxpresso, I use just clang + gdb + CMSIS + SDK + Cmake + ninja + VS Code.

I also have an RPi Pico which I use as a dual USB-serial bridge and to control the Program and NMI pins (makeshift reset pin, with suitable init code in startup and handler) so I don't need to push the button and can do everything from scripts.

[SiliconWizard]

You can't use a Teensy outside of the Arduino environment, because you don't have SWD access to be able to program it directly.

Uh, yes you can.
I have a Teensy 4.1 and used it without Arduino whatsoever, using the NXP SDK.
You just need the "Teensy loader" to upload firmware. Comes with a GUI app and a CLI.

Did you need to include any code to support firmware updates, or does the MKL02 chip do it all via SWD/JTAG when you press the physical programming button?

This is funny as hell to me, because I never even considered doing that. 

Nothing at all to do.
There is a programming app for Windows, but also a CLI version that I use. Source code is provided (teensy_loader_cli.c) and can be built on pretty much any platform that has libusb.
It's not hidden - doc here: https://www.pjrc.com/teensy/loader_cli.html

[Nominal Animal]

No need for Teensy specific code, and it is not even really hard to pull out (as others and I said).

Yup, I agree; it is just funny to me that I never thought about doing it that way, even though I started with a Teensy 2.0++ on bare metal with just PJRC-provided header files and avr-gcc (and avr-libc), basically.

When you get comfortable inside a box, you can easily forget you're inside that box, and forget to look; even for someone like myself who doesn't usually fall into that trap.

The MKL02 will do everything on its own: it loads an USB capable downloader/flasher in RAM using JTAG (not SWD, for unknown reasons) then runs it, waiting for the PC side application to send data (or a reset command).

Right, that's what I expected/hoped.  The protocol itself is quite simple, and uses USB control messages.  (It is called "HalfKay", named after from the original AVR Teensy bootloader that fit in 512 bytes.)

I also have an RPi Pico which I use as a dual USB-serial bridge and to control the Program and NMI pins (makeshift reset pin, with suitable init code in startup and handler) so I don't need to push the button and can do everything from scripts.

Wouldn't it have been easier to just add the reboot code to your custom firmware?

See teensy_loader_cli/rebootor/usb.c:ISR(USB_COM_vect): when you receive an USB control message with bmRequestType==0x21, bRequest==HID_SET_REPORT, wIndex=0, with a payload consisting of one or more sequences of 'reboot' (6 bytes, no separators), reboot your Teensy.

Of course, that only works if you have an USB HID endpoint, otherwise you do need to use external hardware.  For that, I'd have used an DigiSpark clone, an ATtiny85 running V-USB HID code that does that, both hanging off the same USB cable hub; they're even cheaper than RP2040.

Did you need to include any code to support firmware updates, or does the MKL02 chip do it all via SWD/JTAG when you press the physical programming button?

Nothing at all to do.

Right, as newbrain explained above, the MKL02 overwrites the RAM with the necessary loader code when one presses the button.  Nice!

There is a programming app for Windows, but also a CLI version that I use. Source code is provided (teensy_loader_cli.c) and can be built on pretty much any platform that has libusb.

Yup, I linked to it (https://www.pjrc.com/teensy/loader_cli.html) in my original reply, and that page has the link to the github repository, PaulStoffregen/teensy_loader_cli, where in other repositories you can find the Teensyduino cores and various Arduino libraries as well.

At the PJRC forums, Paul has explained that the only reason the MKL02 (and AVR Teensies' HalfKay bootloader, that uses the very same protocol) is proprietary, is to make it harder for Chinese manufacturers to clone the board (as happened to e.g. SparkFun's Pro Micro), and fund the development of the boards.  Similarly, while the schematics are shown, the board files are proprietary.  It is a very small company that treats its workers well (based on how they handled the pandemic) and interacts very well with its customers –– if you have a change to say the core that others benefit but does not break compatibility, Paul not only accepts such changes and patches, but is appreciative of it.  I know that from experience.  If you look at his GitHub repos, you'll find out that he's also the author for some of the Arduino libraries, published under very permissive licenses.   (I got a Teensy 4.1 with PSRAM, Ethernet kit, and extra Flash as a gift, just for helping others on the forums there, when Teensy 4.1 came out, but so did fifty or so others as well.  So, you could say I'm biased.)
I think for a development board in the Arduino environment, that's a very good balance between proprietary and libre/free-and-open-source.

Thus, I will amend my earlier posts about the subject, as Teensy 4.x can indeed be used for baremetal programming, with the only real drawback being JTAG/SWD disabled, and the benefit/quirk of the MKL02 handling the power-on sequencing (power rails enabled at the correct order and only when they reach the correct thresholds), which one would have to otherwise do in their own hardware.

To repeat, one can buy the preprogrammed MKL02 bootloader chips for USD $6.25 in singles (as of 2023-02-16), for ones own Teensy-compatible boards (but do not use the name "Teensy" in your product).  It also enables (but does not require) public-key based firmware verification/encryption.  The downside is that it currently only works with NXP IMXRT1062DV*6B or IMXRT1062DV*6A, and requires the Flash chip to be Winbond W25Q16JV*IM or W25Q64JV*IM; other chips may or may not work.

[newbrain]

Wouldn't it have been easier to just add the reboot code to your custom firmware?

Yes and no, as you say I'd need USB, but most of all, I'd need the FW not be locked up tight.

The use of NMI, with vector table and handler code in flash, makes sure* that bringing the pin high will invoke the handler and reset the MCU (and maybe save a stack trace in PSRAM or something like that).

And after all I wanted to be able to program the Teensy "hands free" (so e.g. from a remote location, I'm always going back and forth between SE and IT), so adding another GPIO was a no-brainer, and very little effort.

*not 100%, if code gets really crazy, it could modify the pin configuration. Quite a remote eventuality, though.

EtA, I forgot while answering:

Paul[...] If you look at his GitHub repos, you'll find out that he's also the author for some of the Arduino libraries

Another reason I appreciate his work a lot: my eyes do not bleed when looking at his code, as opposed to 93.7% of Arduino related stuff.

[AaronD]

You can't use a Teensy outside of the Arduino environment, because you don't have SWD access to be able to program it directly.

Uh, yes you can.
I have a Teensy 4.1 and used it without Arduino whatsoever, using the NXP SDK.
You just need the "Teensy loader" to upload firmware. Comes with a GUI app and a CLI.

---

I have the GUI version.  Seems to work well enough on my RasPi.  I like that it has an "auto-download" feature, that is triggered when there's a chip available to program, and a new version of the HEX file that it hasn't downloaded yet.  So I can just leave it running in that mode and forget about it.  Debug build to check for syntax errors without much effort to optimize, Release build to actually run it.  I do it that way anyway for the 8-bit stuff, with non-blocking debug spew from the UART because while debuggers are nice, breakpoints in a real-time system are often problematic.  (and I first learned without a debugger anyway)

The CLI version could also be a post-build step.  Same effect without the GUI running.  Not sure which way I'll end up going on that.

---

I guess that MKL02 is not only for updating firmware. It is connected also to DCDC_PSWITCH and POR_B.

Yes, it also handles the power on sequencing that is a bit complicated in iMX Rts.

---

The MKL02 will do everything on its own: it loads an USB capable downloader/flasher in RAM using JTAG (not SWD, for unknown reasons) then runs it, waiting for the PC side application to send data (or a reset command).

Once the SW is on Teensy's flash, there's no difference (well, some fuses are hard set) with a naked iMX RT1062, you just can't debug it (but see my post above).

---

...Teensy 4.x can indeed be used for baremetal programming, with the only real drawback being JTAG/SWD disabled, and the benefit/quirk of the MKL02 handling the power-on sequencing (power rails enabled at the correct order and only when they reach the correct thresholds), which one would have to otherwise do in their own hardware.

To repeat, one can buy the preprogrammed MKL02 bootloader chips for USD $6.25 in singles (as of 2023-02-16), for ones own Teensy-compatible boards (but do not use the name "Teensy" in your product).  It also enables (but does not require) public-key based firmware verification/encryption.  The downside is that it currently only works with NXP IMXRT1062DV*6B or IMXRT1062DV*6A, and requires the Flash chip to be Winbond W25Q16JV*IM or W25Q64JV*IM; other chips may or may not work.

---

Ooo!  Looks like an easy way to make my own projects with a capable chip, and have it "just power on and run my code" with a single power rail (into that module) like an 8-bitter does.  AND make it "brick-proof"!  I think I like that!  Well worth an extra $6.25 per processor, and the limitation to use those chips and that starting-point schematic.  (for one-offs, at least, which is all I'm thinking about at the moment)

The required processor is BGA-only, which I haven't done before, but I *have* done a QFN by hand with hot air, and I've made my own controller for a toaster oven to reflow solder paste.  I'm a stickler for detail when prepping the board for that, and I've never had a chip failure yet.  A handful of tombstoned 0603's, but that's about it.  Based on that, a BGA *should* work?  I don't think I could replace it if it doesn't, but if I don't need to, then...

If I do that for my custom boards, then both the toolchain and the code will be the same as for a real Teensy.  (just don't call it one)  So I think all that's missing is to get started on that collection of hardware.

---

To get started, I guess I need a fully functional example of a CLI build environment.  It's probably obvious once I see it, but I think I do need to see it.  Then I can copy/paste it into Code::Blocks like I did for the 8-bit and desktop projects.

I tried to find that on PJRC's site, but all of their examples are for 3.x or less.  Even their link that promises that for the 4.x, goes to the 3.x page instead.  Very different chip, different architecture, not likely to work.  Is the 4.x just too new?

What (well-documented) SDK and toolchain are you guys using for a non-Arduino IMXRT1062?  Preferably with the MKL02 "manager" involved too, but I don't think it makes a difference at that point?  (same HEX file either way)

[elecdonia]

The Raspberry Pi Pico has an AWESOME SDK and documentation, and makes it plumb easy both to make something work now, and work well, and to dive into the details.

Today I plugged in my brand-new Raspberry Pi Pico board for the first time and connected it to the Arduino IDE. Wow - It has a huge number of options listed under the "board" tab. I can tell there's going to be plenty of things to explore.

So far (all I've done() is to load the generic Arduino "blink" sketch. This was painless and the sketch works as it should.

On my RPi Pico the "blink" sketch consumes 53k bytes flash, 50012 bytes RAM. This suggests the RPi Pico is on a whole different scale than AVR MCU chips.

[AaronD]

This suggests the RPi Pico is on a whole different scale than AVR MCU chips.

Yes it is!  The major limits - Flash, RAM, and Clock - are pushed much farther out now, almost to where they feel infinite at first.  And with a native 32-bit core, big numbers and high-resolution processing are not a problem either.

You even get a second CPU in the same chip, in addition to the increased capability.  That can be both a blessing and a curse.  The blessing is that you can finally have *actual* parallel processing, instead of just single-threaded multitasking.  The curse is communication between the two physical threads, without clobbering stuff in ways that are mysterious at first.

Floating-point is still in software, so still relatively slow, even with the hand-optimized library in that chip's ROM that beats what GCC does.  If you really NEED floating-point, try to make it use that library, but also see if you can use fixed-point math instead.  (count a specific fraction instead of integers: the toolchain and the hardware still think it's integers, but you know different and write the code accordingly)


But with that all said, the i.MX RT chip that I'm looking at is about that much again more than the Pico.  Only a single CPU, but 600MHz instead of the Pico's 125MHz, and hardware floating-point!  That's enough to have a decent audio library, whereas the Pico can barely keep up with a single signal generator at 48kHz according to my experiments.

But that chip doesn't seem to have a well-designed SDK to go with it.  Arduino, yes, but the 'duino framework is too much of a "closed black box" for me.  For example, the loop() function is called from a user-inaccessible system loop.  What else does that system loop do?  How is it going to affect my loop time?  Is there some blocking I/O that's going to wreck the timing of something that I coded directly?  And how is it going to clash with my reading the datasheet and configuring X peripheral for my own use?

The Pico's SDK doesn't have that problem.  If you set up a project that way, *instead* of Arduino, then the SDK is documented and comprehensive enough that you can use it to just bare-metal configure everything.  Everything that you can do with each peripheral, has a sensible function call that covers the entire range of functionality, and an example/demo project that is known to work.  You can even follow the source code to see what it's actually doing, and do that yourself if you want, instead of calling the SDK function.  I did that to convert the SDK's blocking communication functions into my own non-blocking state machines.

NXP isn't there yet, as I've seen so far.  (if it exists, but not obvious and easy to get, then that statement is still true)  Too focused on their own in-house IDE and code generator, which used to be how everyone did it.  Not anymore, I hope, with the Pico paving the way.

[westfw]

the 'duino framework is too much of a "closed black box" for me.  For example, the loop() function is called from a user-inaccessible system loop.

It's not "closed" or "inaccessible."  All open source, installed as source on your computer when you add the core.
Admittedly some combination of Windows and Arduino policies can make it a bit hard to find, but in a standard windows install (using IDE 2.x), it'll end up in "C:\Users\USERNAME\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.57.2\cores\teensy4\"


It even looks like there might be instructions somewhere on using it with a Makefile and bypassing all of the Arduino code entirely...

Code: [Select]

extern "C" int main(void)
{
#ifdef USING_MAKEFILE


// To use Teensy 4.0 without Arduino, simply put your code here.
// For example:


pinMode(13, OUTPUT);
while (1) {
digitalWriteFast(13, HIGH);
delay(500);
digitalWriteFast(13, LOW);
delay(500);
}




#else
// Arduino's main() function just calls setup() and loop()....
setup();
while (1) {
loop();
yield();
}
#endif
}

[elecdonia]

With very little effort I succeeded at installing Micro Python on my Raspberry Pi Pico board. It is connected to the Thonny Python IDE which was also very easy to install on my Win 10 machine.

I've been wanting to get more familiar with Python and this seems to be a convenient way to combine two of my interests:
Fast/powerful/inexpensive small computing modules with I//O pins and Python

[AaronD]

It's not "closed" or "inaccessible."  All open source, installed as source on your computer when you add the core.
Admittedly some combination of Windows and Arduino policies can make it a bit hard to find, but in a standard windows install (using IDE 2.x), it'll end up in "C:\Users\USERNAME\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.57.2\cores\teensy4\"

It even looks like there might be instructions somewhere on using it with a Makefile and bypassing all of the Arduino code entirely...

Code: [Select]

extern "C" int main(void)
{
#ifdef USING_MAKEFILE


// To use Teensy 4.0 without Arduino, simply put your code here.
// For example:


pinMode(13, OUTPUT);
while (1) {
digitalWriteFast(13, HIGH);
delay(500);
digitalWriteFast(13, LOW);
delay(500);
}




#else
// Arduino's main() function just calls setup() and loop()....
setup();
while (1) {
loop();
yield();
}
#endif
}

I'll have to look at that.  Per the title, I'm on a Raspberry Pi, not Windows, but I'd imagine the folder structure to be similar, starting from the user's home.

With very little effort I succeeded at installing Micro Python on my Raspberry Pi Pico board. It is connected to the Thonny Python IDE which was also very easy to install on my Win 10 machine.

I've been wanting to get more familiar with Python and this seems to be a convenient way to combine two of my interests:
Fast/powerful/inexpensive small computing modules with I//O pins and Python

That's great!  But not really the topic of this thread.  I gave you a pass on the first one, and tried to bring the conversation back on topic.  If you wouldn't mind to start your own thread for that, it would keep the clutter down here.  Thanks!