Shipping with a Bootloader for SD-Card ??

cebersp

Well-known member
Hi,
at the moment I have a project, which is of some interest for people, who are not familiar with programming, but do some electronics. T3.5 or now T4.1 is used and a SD card is used too.

Perhaps the following idea might be interesting not only here:
As a new Teensy is shipped with a blinking test software, it might be possible to ship it with a bootloader, which loads a program from a sd-card, if it finds a card and a certain filename in the root directory.

It would be possible, to buy a Teensy and just copy some files onto a sd-card to get a "special-function-chip".

Regards, Christof
 
I think If they can copy a hex-file to SD, they can start the teensyloader and select the hex-file, too..
 
I think If they can copy a hex-file to SD, they can start the teensyloader and select the hex-file, too..

Indeed - even if that were a supported way to upload - where today it only via USB upload - it would take some orchestration overhead to ONLY do it once and not reProgram every time if the SD card were not removed.

The Bootloader doesn't have access to SD on startup to check as it goes right to running the stored code on the Teensy. So that would take a program to stop running - look at the SD card and then choose to upload the program in a way not currently supported.

so agree with Frank B's note.
 
Start the Teensyloader. - Up to now I have installed Arduino first and then Teensy with all its compiler and libraries. Ok, I found now, that there is indeed a "Loader-Only-Installation." Good to know, because the idea would need some time...

(I have now downloaded the actual Arduino and once again lost things. I do not love this procedure....)

It would perhaps not be necessary to write the program into flash. Just load it from sd-card into ram, I think.

I am "a little bit surprized", that the idea is crushed down so very quickly. Just a way to sell a few more Teensies....
I am aware, that this would need some work. And perhaps the amount of work is not justified.

Nobody has to download, install and use a special loader on their PC to put a program onto Raspi. The sd-card holder is there, the sd-card is there, the filesystem is there, a test program is flashed onto the device anyways, just use the possibilities! :)
 
Did not "crush it down". Just said that I think that it is not really needed. There are TODOs with much higher priority.


Can Raspi do what Teensy can? :) Work without SD? :) Boot in a few milliseconds?
That's a comaprison of apples and oranges.
 
not crushed, i.e. discarded without reason - just noting a few hurdles making it non-trivial. One of which is the bootloader has one function and limited connectivity only to processor and none to SD card - it can "on request" put code on the Teensy to upload using USB. Outside of that the most the bootloader does AFAIK is help control startup timing on the 1062 Teensys.

There is another thread discussing a FLASHER - though not sure it takes input from SD card ? - that allows a sketch to stop doing stuff and upload code into FLASH - but that code is 'in the user sketch' - in fact Frank wrote one of those once reading code from SD CARD and programming a T_3.2 that I tested to function - but it had limiting issues, and danger of bricking.
 
Well, Frank, you answered negative within 4 Minutes to my idea, saying that there is no need for it, this felt to me like "crushed down". Have you been part of a group doing brainstorming in the past? There is an important rule: Never assess an idea directly! Take some time, play with it, vary it,....
Think of the motivation of the others saying their next idea. :)

I have a Forth (YAFFA-derivate) running on the T3.5 or T4.1. It gives an interactive operating system with console, compiler, editor running directly on it, very fast edit-compile-cycles, multitasking, files,... From that point of view it is totally natural to dynamically load applications from sd-card into the Teensy. And the distance to raspi is less far - apples and raspberries at least....
((I am blown away by the speed of T4.1! My forth is about 20 times slower than pure compiled C. But together with this hardware speed, the number of things, you cannot do in Forth is vanishing. And you still have all these great libraries of Arduino, if you need them.))

Thanks for pointing me to the separate Teensyloader.
 
Oh, I think it's not too difficult to write some code that loads a program from SD to RAM and executes it there. Might involve reserving some space in ITCM (via .ld file), some stack tricks, fiddling with the vector-table and a modfied (stripped to minimum) startup-code.
If you want to dig into that, pls make it public - I think there are a lot of people who are interested.

This way, you had your own "second stage" bootloader - can be flashed once.



Somewhere here is a thread here about flashing, too.
 
As noted in p#6 - Frank personally wrote such a 'code from SD' - so that was based on experience doing that and a great understanding of the Teensy programming process, not a coin toss - or anything that should be taken personally.

There are 'options' if forum posts are searched - but they are not likely to get direct PJRC support
 
Oh, I think it's not too difficult to write some code that loads a program from SD to RAM and executes it there. Might involve reserving some space in ITCM (via .ld file)
Somewhere here is a thread here about flashing, too.

First glance it should be easier on the 1062 with external flash? As long as all needed code for the Flash writes is RAM resident - which user code is by default. But again that is not how the Teensy bootloader or the normal Restart process works - so it would be in user code.

Not seeing T_4.x support in either of these?
pjrc.com/threads/43165-Over-the-Air-firmware-updates-changes-for-flashing-Teensy-3-5-amp-3-6
pjrc.com/threads/55469-OTA-Sketch-Updates-for-Teensy

But this subject comes up on a recurring basis - and some have solved it as time goes on for their needs.
 
Thank you both for the explanations.
The idea was: To ship the T4.1 with the SD-Bootloader already flashed to every customer.
For myself I can flash the Teensy and I can load an application written in Forth from sd-card, so I do not need this, if I have the device on my desk at the beginning. The benefit would be, that a customer can buy his Teensy somewhere and have a more easy way to bring or update software onto it. I have done updates for bought devices this way. Just insert a storage medium (perhaps press a key) and start the device.
 
You can add this functionality to your program.
Thats even better than to have it in the PJRC-bootloader (and other people may not want it)
You just have to make sure, that this part is íncluded to the program on SD, too.
 
This will be easier when Littlfs for "internal" flash is ready to use (on Teensy 4.x).
When it's ready, I'll look at this.
 
saying that there is no need for it, this felt to me like "crushed down". Have you been part of a group doing brainstorming in the past?

Well, yes. You might guess that from "Posts" count. In fact Frank has a long history of contributing not just good ideas, and a lot of pretty amazing code. So his voice & opinion does carry quite a bit of weight here.

Looking at what's been said on this thread, I think you're being a little overly sensitive about "crushed down". When you propose a feature with about 40 words and someone says (with an even shorter reply) they don't see any value, it's really up to you to explain why your idea is worthwhile, like who it helps for what sort of application. Yeah, this reply could have been said more positively, but as causal internet conversations go, I really don't see anything offensive here.

You should probably also keep in mind Frank is from Germany and communicating with us in English language.


I have a Forth (YAFFA-derivate) running on the T3.5 or T4.1. It gives an interactive operating system with console, compiler, editor running directly on it, very fast edit-compile-cycles, multitasking, files,... From that point of view it is totally natural to dynamically load applications from sd-card into the Teensy.

Well, let's talk about SD card code loading in the context of your Forth interpreter application. That is, if you're still willing to talk about this?

Would the code stored on the SD card be Forth language source? Or compiled binary file? I guess I don't understand why you wouldn't program the Forth runtime onto Teensy the normal way, and then have it read the SD card for Forth language files. Maybe I'm missing something?
 
No doubt there are some users who are able to "insert the SD card I mailed you" and not "install this software on your PC and then ....". You can start with "Flasher4" if you want to develop software to do this.
 
@Frank, no problem! Best regards from Esslingen. I just was not too happy, because I think the idea is not completely silly and because it takes some time for me to write - especially in English.

@Paul: This forth system has nothing to do with my suggestion. It is just my background: Seeing the sd as a central part of the system and loading code from it is just natural for me. Actually I was rather disappointed, when T4.0 came out without SD-Card....

I try to describe the idea better:
Background and intended usage in my case:
I have a program written with Teensy-Arduino running on T4.1. It uses a sd card for a configuration file. Part of the sketch is a Forth System, but that is irrelevant here. Teensy is used to control an analog Guitar Effect. Sets of Parameter- Values can be stored and recalled to achieve different sounds quickly. With Midi, it will be possible to do this for several units in parallel.
Perhaps google can translate: https://musikding.rocks/wbb/index.php/Thread/420527-Midi-und-Parameter-Steuerung-für-Analog-Effekt/. As you can see there, due to the Open Drain - high Frequency PWMs, the Hardware Interface to the Vactrols (LED+LDR) is really totally simple. Only RC. And it is very flexible, it can control anything, that has potentiometers up to 150 Volts. Once the program is in the teensy, you only need to adapt the configuration file to your analog effect. T4.1 has a large number of such PWM-channels, which is great. The high frequency is essential, because you can filter it easily and you cannot hear noise. Guitar electronics is very sensitive, because you have high gain. The sketch needs 85k code at the moment + 115k variables, which includes the big memory for the forth vocabulary. So this fits easily into Ram.

Need:
The people, who are active in this "Musikding" forum are very fond of analog guitar effects and tube amps. They do not program. Many can just solder and cannot read schematics. But some use Midi already with bought effects. I now have thought, how I could make the programmed controller available. I could buy some, program them, distribute them. But if I calculate some none-yoke hourly wages and the shipping, this will get expensive quickly. :)

So the idea would be:
If pjrc would bring a SD-bootloader into every T4.1, they sell, software-distribution and hardware-distribution would get independent as it is done for other sorts of computers. This SD-bootloader would search for a sd-card, search for a certain program name, load an executable program-file (written as Arduino sketch) from SD-card at every startup. Software-updates can be done without a PC connected. People, who do not program controllers, can turn a T4.1 into a fixed function chip more easily. (I do have the impression, that the number of people, who do programming is not increasing.)

Of course this is a long-term suggestion.

Hoping, that I could make the idea more clear. Regards Christof
 
...thinking of it...

I could indeed contribute to the idea or a variation of it myself: If pjrc would want to ship T4.1 with a preloaded Forth as a bonus for every customer, which would just serve as a blinktest, if it does not find a sd-card and forth-startscript. People, who are interested could use the forth, people, who are not would just overwrite it with some other sketch like before. ...Certainly a breakthrough for this language after all these years. :). (For me Forth does make a lot more sense than Python for such systems.)
 
(For me Forth does make a lot more sense than Python for such systems.)

Form the pure technical standpoint maybe yes.
Try to find a youtube influencer that promotes it :) Doesn't it use the reverse polish notation (Or do I remember wrong)? "(A+ B) * C " is "A B + C *" ?
I'm afraid, however, that at the latest when the viewers see this, they get a crazy facial expression and turn off the video in panic.

Forth was very effective.

Edit: *attention, no rant against Forth. More an expression of my resignation when I see today's young people ;-) Read this forum and the attemps to get their things work by copying random pieces of code they found with google.


BASIC was easier..
..and then Python came..
 
Last edited:
For me Forth does make a lot more sense than Python for such systems.

Python is by far the most requested interpreted language. I know you love Forth, but I hope you can understand that viewpoint is relatively rare among the people who buy & use Teensy.
 
...I like the Idea of a pre-loaded Teensy. Whatever system it would be. Forth, Basic, Python..

I tend to disagree
what-ever system is pre-loaded, you will find people that complain or want something else.

I like the idea of having only the blink preloaded to prove functionality of a new system.
if users are experienced then they will immediately go on with own firmware
if users are not experienced and wanted to learn about use of teensy, then they should first follow Arduino IDE and examples until they learned sufficiently to code own programs. They may then also change IDE.
if users are not experienced and do not want to learn coding Teensy, then this is the niche of a clever guy that sells preprogrammed teensies and all options are open on how to handle functionality upgrades.
 
what-ever system is pre-loaded, you will find people that complain or want something else.
Valid argument!

I like the idea of having only the blink preloaded to prove functionality of a new system.
if users are experienced then they will immediately go on with own firmware
if users are not experienced and wanted to learn about use of teensy, then they should first follow Arduino IDE and examples until they learned sufficiently to code own programs. They may then also change IDE.
if users are not experienced and do not want to learn coding Teensy, then this is the niche of a clever guy that sells preprogrammed teensies and all options are open on how to handle functionality upgrades.
Nothing of this would be impossible by just an other blink that gets executed by Python or whatever.
It would be *preloaded* only. Removing it would be exactly the same as overwriting the pre-loaded blink.
So, on these points, I can't follow you.

I remember, when I was young I saw a ZX81 in a local store.
Young boys around it, typing in
Code:
10 PRINT "HALLO"
20 GOTO 10
or things like this. Later I was one of them, til I could talk my parents into giving me something like that.

I don't know If I today would do things with teensys, or computers.. If there had been nothing so devilishly simple as Basic and the simple ZX81. It was extraordinary expensive.
1 KB RAM. Z80 CPU. 1 MHZ. BASIC in a 8K ROM.
 
Last edited:
FWIW, the blink program we pre-load on every Teensy is slightly more than it seems. It's actually this code:

https://github.com/PaulStoffregen/USB_Tester/blob/master/extra/USB_Tester_Blink.ino

(Edit: looks like that is a slightly old version, before Teensy 4.1.... will update the github copy soon)
(Edit again: updated the copy on github)

It does 2 special things.

The USB test loads this special blink program. Then when Teensy reboots, it uses the USB port to send a RawHID message which controls the LED (overriding the blinking) and it waits for a reply with ID data. The tester just discards the ID info, but some sort of reply is required. Maybe that's redundant since the USB enumeration has happened twice, and the program was able to load, but this test is done anyway, just to be really sure the USB port is working. The tester also measures the total USB cable current and checks that turning the LED on/off changes the current by approx 3 mA. For a Teensy without pins soldered, this is our final test before it goes into the silver anti-static bag.

On Serial1, the special blink program listens for a request to read all the other pins. For the Teensy boards where we solder the pins, those pins are placed into a ZIF socket for testing. It drives every pin (though a 1K resistor) high with all the others low, and low with all the others high, and reads the result for each combination. The pins test is only possible because the USB connector test loaded that program.
 
Last edited:
That's a clever way to make the whole process efficient, and to create a Teensy "sign of live" for the user at the same time.
 
Back
Top