Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: Making a proof-of-concept device

  1. #1
    Junior Member
    Join Date
    Oct 2020
    Posts
    8

    Making a proof-of-concept device

    My questions may be confusing because I'm still sorting out information. I'm interested in making a proof-of-concept device out of a teensy 4.0 board, also to learn how to use it. In case this works, I'm interested in making my own devices with the same processor, maybe with the help of an engineering company like pjrc. So if I understand this correctly, the processor is from NXP:

    https://www.digikey.com/en/products/...2DVL6A/9607560

    Teesy board also has a flash chip (2MB) and a USB-UART chip (bootload new code), no SDRAM since the processor has 1MB onboard.

    For normal operations, the bootloader will read in the new code, save it to the board, and run it if you press a button, or maybe power cycle. This bootloader belongs to teensy/pjrc, but may have been based off some NXP reference design, working with boot rom? For IP reasons, I can't use teensy's bootloader. So if things work with teensy, I need a software toolchain provided by NXP to replicate my success. Everything is pretty low-level USB host and device stuff so I don't need any class drivers etc.

    What I found on NXP website was that there is an open-source SDK:

    https://www.nxp.com/design/software/...MCUXpresso-SDK

    Seems to have RTOS as well. Is this what I should use past proof-of-concept stage? Seems quite complex from their videos. Anyone else using this for projects? My need to have both high speed USB host and device has pushed me out of the AT90-class MCUS and there's no intermediate devices in sight to reach high speed. Cortex-M7 seems a huge leap.

  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,230
    Don't you think it would be best to ask NXP? NXP has boards, too, for learning, education and testing purposes.
    I don't see anything from PJRC what would be involved here..
    They Teensy-Arduino libraries will not work anyway, so no need to spend time with that.

    BTW; any Teensy, even the 3.2 has way higher speed than AT90

  3. #3
    Junior Member
    Join Date
    Oct 2020
    Posts
    8
    Probably but arduino is easier to prototype and comes at no cost so a good idea to make a proof-of-concept device before investing heavily in NXP toolchain, time and money wise.

    Sorry I said high speed but that is USB 2.0 HS, not the processor's own speed. Teensy 3.x seems to have only USB FS not HS. The M4 core on 3.x is also too slow to process data at HS. 3.6 has introduced a HS host but FS device. I need both to be HS.

    What do you mean Teensy-arduino libraries not working, do you mean the USB library not working? I don't need other libraries. Is the USB device port used by bootloader so I can't do low-level stuff on it without breaking the boot loader?

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,737
    Starting with a Teensy 4.0 or 4.1 would likely be a great way to see working code and get a working prototype with all the power of the NXP 1062.

    What do you mean Teensy-arduino libraries not working, do you mean the USB library not working?
    But starting with Teensy will provide useful tools and support like this not available on other Arduino boards and not available with NXP development toolchain.

    If a T_4.x could be incorporated into the final design then the hardware issues would be solved and the software would be like the prototype.

    But if then going to a bare NXP processor - there is no other set of useful libraries and support like PJRC provided for the 'prototype' using the Teensy 4.x.

    In some months PJRC will release the bootloader for DIY Teensy 4.x incorporating a 1062 into a custom PCB - but that is built around the PJRC bootloader chip which when released would allow full functionality as provided by the Teensy itself. In the end that bootloader chip will function and work with encrypted firmware stored on the external flash to make that stored code safe from pirating - a feature that is not yet available until that is complete.

    So for proof of concept a Teensy would be perfect. Moving beyond that would entail staying with Teensy as it develops or starting all over building the needed tool and code needed to complete the task at hand.

  5. #5
    Junior Member
    Join Date
    Oct 2020
    Posts
    8
    OK thanks for explaining with some timelines. Do you mean that NXP has no library to support its own USB features, not even low-level calls such as control requests and BULK IN and OUT, and some device-class calls like returning a requested descriptor? So here is a thought experiment:
    On Teensy, boot, reset USB on host controller, see if any device is attached, do a simple get dev descriptor, set device address, set config. I think there is a USBhost_t32 library that does that.
    On bare chip using the MCUXpresso's IDE and SDK, perform the same functions. Will I be unable to perform the functions as described above on MCUXpresso due to not having any library code to call? Do I rely on register-level manipulation instead?

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,737
    Expect there are examples for most if not all hardware elements on NXP. Indeed some folks have used SDK examples to understand chip functions as it compliments what is released as documentation.

    Integrating and refining them from Device USB to USB Host is what Paul and the forum group and the rest of the compatible Arduino world has been doing for some years for general utility.

  7. #7
    Junior Member
    Join Date
    Oct 2020
    Posts
    8
    I appreciate your responses. I bet I would benefit greatly if I were using general usb device/host drivers. I've done simple projects say emulating a keyboard, etc. using general drivers on Arduino. What you guys have been doing, including the Arduino LLC folks, has really bridged a technical divide between those serious engineers with USB know-hows and those casual developers and hobby electronics people.

    Unfortunately for my project at hand, it needs more than general utility such as emulating a flash drive or hosting a keyboard. The device I'm making has many non-common features. I've been using an earlier version of Arduino's USB device-class library with heavy modifications. I heard that the library was based off ATMEL's usb device library but I've not read ATMEL's code. I've also been heavily modifying the USB HOST SHIELD library V1 for MAX3421E host controller to satisfy my needs on the host side of things.

    This has been hard, coming from no USB backgrounds other than the casual ones but I also learned a whole lot about USB. I'm also reading LUFA library that is specific to ATMEL processors. I'd say, every software developer has their own taste how to handle certain tasks and focus heavily on what they consider most important. I've acquired some unique tastes myself due to my project's requirements and experimenting with different things. I have a full-speed solution and now wish to build my High Speed (480MHz) solution with this processor and low-level library by writing all the necessary high-level device and host class code myself, IP purposes aside. Every hardware seems different, total endpoints, buffer memory arrangement, pipes, etc. I think Teeensy's general drivers will give me some quick experience with this processor and confidence that I can handle the stuff, given time. The proof is also important to steer the project development.

    What I will do is to read a few simple class drivers and example code Paul and the group wrote to see how things are set up at low level and try to make my own code. This way I have a clutch to hold on to I'll probably be back with more specific questions starting with the host side of things. I recommend anyone trying to learn USB to get a protocol analyzer. I have Beagle. It turns things unseen into parsed out information.

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,978
    This thread is so mysterious. I really don't understand what you're asking here. It kinda reads more like stream of consciousness.

    But to try to answer the specific hardware question, yes, both USB ports on Teensy 4.0 & 4.1 (and IMXRT1062 in general) are 480 Mbit/sec speed. Both have the PHY built in, so you just connect the USB signal wires directly. Most microcontrollers offer only 12 Mbit full speed. Of those which do have HS, some have HS PHYs, others require you to add a PHY chip which usually involves 12 digital signals between the 2 chips.

    I hope you can understand this forum is absolutely the wrong place to ask for help with MCUXpresso or ask technical questions about the inner working of NXP's SDK code. We generally don't use any of that on Teensy. NXP has their own forums:

    https://community.nxp.com/

    As much as I'd like to sell you a Teensy, to be honest, if you are 100% decided that you must use MCUXpresso and NXP's SDK, that you absolutely can't use the toolchain we publish for use with Teensy, then Teensy probably isn't the best choice for you.

  9. #9
    Junior Member
    Join Date
    Oct 2020
    Posts
    8
    Paul,

    Thanks for your patience to read this thread. I wonder if you ever encountered any project that's got a lot of unknowns and trying to ask questions is just as hard to as doing the actual development because you don't know what exactly to ask because you don't know enough to form a question. I think I was going through that process regarding "can I achieve a proof-of-concept" using teensy 4.x and its arduino compatible libraries". I think I'm just a bit more clear on the answer now, along with a few other things. I think that I could use Teensy for the proof, despite you saying I shouldn't. Maybe you were thinking, "what a waste of time if he just made something with teensy and has to scrap that and start over on a different IDE/SDK?". I think that is a part of my learning process on how this processor works so some repeated/wasted efforts may be necessary.

Posting Permissions

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