Forum Rule: Always post complete source code & details to reproduce any issue!
Page 19 of 20 FirstFirst ... 9 17 18 19 20 LastLast
Results 451 to 475 of 491

Thread: Future Teensy features & pinout

  1. #451
    Senior Member
    Join Date
    May 2016
    Posts
    256
    Quote Originally Posted by manicksan View Post
    about the dual core...

    One core can be used for the sound stream (specially for very big projects)
    and the other could take care of all the (user interface)/(loading saving files to/from sd-card)/(other comms.)
    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.

  2. #452
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,280
    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.
    Last edited by Frank B; 04-02-2021 at 09:03 AM.

  3. #453
    Senior Member
    Join Date
    May 2016
    Posts
    256
    Quote Originally Posted by Frank B View Post
    These things are easier and work better with an rtos....
    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 ???

  4. #454
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,280
    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.)

  5. #455
    Junior Member
    Join Date
    Mar 2021
    Posts
    4
    Quote Originally Posted by Frank B View Post
    . An RTOS will not come.)
    the coolest module without the coolest OS

  6. #456
    Member
    Join Date
    Jan 2014
    Location
    New Jersey, USA
    Posts
    63
    Quote Originally Posted by Frank B View Post
    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.

  7. #457
    Member
    Join Date
    Feb 2021
    Location
    Denver
    Posts
    29
    Quote Originally Posted by mlewus View Post
    ... I don't know how they avoided the need for decoupling caps below the BGA but it's worth looking into as an option for the I.MX RT1170 Teensy.
    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.

  8. #458
    Member
    Join Date
    Feb 2021
    Location
    Denver
    Posts
    29
    Quote Originally Posted by mlewus View Post
    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.
    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!

  9. #459
    Member
    Join Date
    Jan 2014
    Location
    New Jersey, USA
    Posts
    63
    Quote Originally Posted by DavidWH1968 View Post
    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.

  10. #460
    Member
    Join Date
    Feb 2021
    Location
    Denver
    Posts
    29
    @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.

  11. #461

  12. #462
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,907
    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 by defragster; 04-03-2021 at 10:58 PM.

  13. #463
    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.

  14. #464
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,280
    Unfortunately the RTOS is not enough, the main libraries need work too.

  15. #465
    Member
    Join Date
    Jan 2014
    Location
    New Jersey, USA
    Posts
    63
    Quote Originally Posted by lukexyz View Post
    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.
    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/introduci...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.

  16. #466
    Junior Member
    Join Date
    Dec 2019
    Location
    Ferney-Voltaire
    Posts
    7
    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.

  17. #467
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    4,029
    Quote Originally Posted by makegeneve View Post
    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.
    I've not used it, but there is this:

  18. #468
    Junior Member
    Join Date
    Dec 2019
    Location
    Ferney-Voltaire
    Posts
    7
    Quote Originally Posted by MichaelMeissner View Post
    I've not used it, but there is this:
    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 ;-)

  19. #469
    Member
    Join Date
    Jan 2014
    Location
    New Jersey, USA
    Posts
    63
    Quote Originally Posted by makegeneve View Post
    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.

  20. #470
    Senior Member
    Join Date
    Mar 2016
    Posts
    333
    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.

  21. #471
    Senior Member blackketter's Avatar
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    338
    Quote Originally Posted by PhilB View Post
    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.
    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.

  22. #472
    Member
    Join Date
    Jan 2014
    Location
    New Jersey, USA
    Posts
    63
    Quote Originally Posted by PhilB View Post
    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.
    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.

  23. #473
    Senior Member
    Join Date
    Oct 2019
    Posts
    131
    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.

  24. #474
    Member
    Join Date
    Jan 2014
    Location
    New Jersey, USA
    Posts
    63
    Quote Originally Posted by kdharbert View Post
    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.
    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.

  25. #475
    Senior Member manicksan's Avatar
    Join Date
    Jun 2020
    Location
    Sweden
    Posts
    277
    @kdharbert
    To create a multichannel parallel ADC you can use
    a voltage comparator to create a "Counter type ADC"
    https://www.tutorialspoint.com/linea..._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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •