Which is exactly what I am hoping to do for my AudioSDR software: run the heavy DSP stuff in the M7 core within the Audio Library framework, and the UI and display code in the M4, with shared memory for communication. No RTOS.
Future Teensy features & pinout
- Thread starter PaulStoffregen
- Start date
Which is exactly what I am hoping to do for my AudioSDR software: run the heavy DSP stuff in the M7 core within the Audio Library framework, and the UI and display code in the M4, with shared memory for communication. No RTOS.
These things are easier and work better with an rtos.
Without you have many busy waits, as we have now. Worst case ever would be the fast core waiting for the slow core because it does blocking spi or such things...
- the situation we have now.
I see this comming.
I guess you never scanned through the libraries or core files. Count the calls of yield() and delay().... yes, this is lost time - burning current and time for nothing.
I bet some things would be faster on a 3.2 than on 4.1 if the 3.2 had an rtos.
Every time I see a delay() in a library, the hairs on the back of my neck stand up.
I don't want to imagine what it would be like if the PC had constant blocking waits for USB, disk, graphics, network.... It would be unusable. The disk would have to wait because the user moves the mouse?
On the Espressif you can write programs without even noticing the running rtos (If one wants)... so if you want you don't need to use it - and that's how it should be.
Without you have many busy waits, as we have now. Worst case ever would be the fast core waiting for the slow core because it does blocking spi or such things...
- the situation we have now.I see this comming.
I guess you never scanned through the libraries or core files. Count the calls of yield() and delay().... yes, this is lost time - burning current and time for nothing.
I bet some things would be faster on a 3.2 than on 4.1 if the 3.2 had an rtos.
Every time I see a delay() in a library, the hairs on the back of my neck stand up.
I don't want to imagine what it would be like if the PC had constant blocking waits for USB, disk, graphics, network.... It would be unusable. The disk would have to wait because the user moves the mouse?
On the Espressif you can write programs without even noticing the running rtos (If one wants)... so if you want you don't need to use it - and that's how it should be.
Last edited:
Thanks @Frank B. We may be a little OT, but this is certainly something I need to understand re the T4.x when it arrives.
My understanding was that in a dual core machine, the two cores run completely independently of each other and were basically unaware of each other - except when sharing I/O to common peripherals. On this basis, I was/am hoping to run only my existing Audio Library code on the M7 core - nothing else, so the only I/O would be to the codec. On the other hand the M4 core would deal with the display, tactile buttons, rotary encoders, etc, and deal with I2C and a separate SPI transfers. The two would communicate (occasionally) through the shared memory, otherwise run independently. User interactions (tuning, volume, etc) would deal directly with the M4 only. If one core is blocked by a delay(), does that affect the other?
Am I being naive here with respect to the T4x ???
Yup, off topic. Sry.
A delay blocks if the other core if both need to communicate and the 2nd waits for the answer, which is normally the case.
Sure, you can write nice code to do that and somehow make it non-blocking.. if core 1 is not in a delay it will answer soon.. not predictable.
An rtos handles that for you. better.
Lets turn the question: Why is a rtos bad for your szenario?
(Again, off topic.. Let's discuss this on another occasion.. it does not matter. An RTOS will not come.)
A delay blocks if the other core if both need to communicate and the 2nd waits for the answer, which is normally the case.
Sure, you can write nice code to do that and somehow make it non-blocking.. if core 1 is not in a delay it will answer soon.. not predictable.
An rtos handles that for you. better.
Lets turn the question: Why is a rtos bad for your szenario?
(Again, off topic.. Let's discuss this on another occasion.. it does not matter. An RTOS will not come.)
NXP's MCUExpresso SDK already includes a port of FreeRTOS as well as much other useful stuff like FATfs, Networking etc. Should not be too difficult to fold it into Teensyduino.
DavidWH1968
Active member
The sacrifice for no components on the bottom side of the board would likely be long term stability when utilizing the processor at the edge of it's performance limits. You probably also give up any hope of using overclocking to quickly finish short compute intensive procedures. Of course, this is because the decoupling caps end up too far away from the power pins beings decoupled. If they wend non-standard with the design and placed the power plane on the next layer to the ground plane (on the same side, of course) then there will be some level of decoupling capacitance induced there, but most likely not enough without the local decoupling capacitors when the chip is demanding more power.
DavidWH1968
Active member
Again, this is adding more complexity to the job of porting. Porting an operating system is absolutely not an easy task. (Unless you happen to know that OS inside and out ... maybe.) I think the job of porting the RT1176 to the Teensy/Arduino environment is a pretty big task already. Let's not try to add additional software development time where not really necessary. After all, those that want to use RTOS are probably already comfortable with the idea of using the MCUExpresso SDK directly and will therefore have no trouble getting RTOS into their firmware package. The remainder will do as usual: Bare metal. (My personal preference, although I do also use MCUExpresso sometimes.)
@PaulStoffregen: I for one understand how much work it is porting something the size of CMSIS and MCUExpresso to an MCU like the RT1176. Not a job I would willingly undertake. So thank you very much!
CMSIS & FreeRTOS are already part of MCUxpresso. MCUxpresso, a SDK rather than an Operating System, was ported to the RT117x MCUs & gcc last year.
Regardless, I was not suggesting that Paul do it. PJRC is not a software company and would get no revenue for that effort. I also don't think these features are going to be all that useful for the bulk of Paul's customer base, who are happy with Arduino. I was suggesting that anyone who needs FreeRTOS is likely sufficiently capable to do it on their own, given that the port has already been done for them by NXP.
DavidWH1968
Active member
@mlewus: I misunderstood. I thought you were asking for FreeRTOS up front. The good thing is it probably won't be long before someone has a version ported to the Arduino IDE posted on GitHub.
manicksan
Well-known member
defragster
Senior Member+
That shows as :: fork of Richard Barry's freeRTOS, optimised for the Arduino AVR devices.
It is on the ESP 1 and 2 core and on the NRF's to allow time for radio interruptions
<edit>: if an easy Arduino standard develops the needed ARM port may happen. Still trying to figure the formfactor requirements ... Pins and on board Features
> The dual core operation will have to have some 'Cool' support - some hardware in the MCU will facilitate the core comms that may be a good answer when we can see it working
Last edited:
A few suggestions for future Teensy boards:
(1) I would love to see a Qwiic socket, to make it easy for users to start tinkering with I2C devices.
(2) It would be awesome if the USB device port could also operate in host mode, so that you can use two USB devices without connecting a hub. (The hardware is already capable of this, but there need to be some software changes, and maybe also bootloader changes, I don't know.)
(3) Mounting holes (even just two of them, on diagonally-opposite corners) would be a good addition, if there's any way to make space for them.
(4) I would be fine giving up the microSD socket, since it's easy to read SD cards through a USB adapter.
(1) I would love to see a Qwiic socket, to make it easy for users to start tinkering with I2C devices.
(2) It would be awesome if the USB device port could also operate in host mode, so that you can use two USB devices without connecting a hub. (The hardware is already capable of this, but there need to be some software changes, and maybe also bootloader changes, I don't know.)
(3) Mounting holes (even just two of them, on diagonally-opposite corners) would be a good addition, if there's any way to make space for them.
(4) I would be fine giving up the microSD socket, since it's easy to read SD cards through a USB adapter.
A I2C socket open up a range of cheap, easily attached hardware, particularly good for beginners. SparkFun owns "Quiic", while Adafruit owns "STEMMA". The two systems are similar, generally compatible, but STEMMA has superior voltage level translation. See:
https://learn.adafruit.com/introducing-adafruit-stemma-qt/sparkfun-qwiic
Big +1 vote on mounting holes. There are several challenges to mounting a Teensy on a baseboard with connectors: 1) ethernet pin spacing is different from the I/O spacing - 2.0mm vs 2.54mm - which creates height differences, and 2) there's no simple, reliable way to hold the board down in high vibration environments like a CNC machine.
makegeneve
Member
Would like to be able to connect a debugger. The Rpi2040 makes this easy. I wouldn't even care if it was only Teensy specific, as long as I can set breakpoints, step through code reliably and use it with PlaformIO.
MichaelMeissner
Senior Member+
I've not used it, but there is this:
makegeneve
Member
Thanks. You're right. I'm hoping Paul can find a couple of pins for a tiny header for JTAG or SWD on a future Teensy ;-)
It's more than just routing the pins. The bootloader, a mcu in its own right, uses JTAG to communicate with the RT1062 MCU. There are also business considerations. Paul has previously said he is considering JTAG but has not committed one way or the other.
I have been spending some time with the RasPi Pico and one thing they did that I really like is a Schottky diode between VUSB and 5V outputs. While it does cause a diode drop on the power line, I think it is very much worth while. It allows one to add a PMOSFET between those for flexible power options. Their datasheet goes into detail on power options including battery charging. Starts at Page 19 of the Pico Datasheet
I know one can cut between VUSB and Vin on the T4.1 (to allow me to put a diode and PMOSFET on the base board) but my customers really don't like hacking up their Teensies.
I know one can cut between VUSB and Vin on the T4.1 (to allow me to put a diode and PMOSFET on the base board) but my customers really don't like hacking up their Teensies.
blackketter
Well-known member
That IS nice.
Another thing I noticed there is that they added a couple of voltage dividers connected to both USB VBUS and VSYS and connected them to a spare analog inputs to add voltmeters to both power supply lines, basically for free.
The Vdrop is intentional. The USB line goes to a 5 volt to 3.3 volt converter so the voltage drop on the 5v side is irrelevant. They could have just as easily used a p-mosfet as an "ideal diode" but there was no reason to do it and it would cost more. They do suggest using mosfet after the battery charger etc because it is 3.3 volts, where the voltage drop would be more significant. If you have multiple 5v supplies, a simple Shottky diode "or" connection is fine.
I'm not sure how many ADCs are on the NXT chip, but if it's more than just the two that the T41 uses, it would be sweet if more were available. Specifically, I'm working on multi-channel optical communications, so making analog reads in 4x,8x or 16x parallel would be great.
Like the RT1062, the Rt1176 has 2 ADCs. They are 4.2 Msps @ 12bits. It does also have 5 SAI (Serial Audio: I2S, TDM, etc) channels so you could add external high quality ADC/DAC hardware, like what Paul did with the audio board.
manicksan
Well-known member
@kdharbert
To create a multichannel parallel ADC you can use
a voltage comparator to create a "Counter type ADC"
https://www.tutorialspoint.com/line...ed_circuits_applications_direct_type_adcs.htm
With that approach you can in theory have as many parallel ADC inputs as you want by only using one DAC and one v-comp for each input, then together with some 74hc165 there is no limits, except the speed.
To create a multichannel parallel ADC you can use
a voltage comparator to create a "Counter type ADC"
https://www.tutorialspoint.com/line...ed_circuits_applications_direct_type_adcs.htm
With that approach you can in theory have as many parallel ADC inputs as you want by only using one DAC and one v-comp for each input, then together with some 74hc165 there is no limits, except the speed.