Web site could use a few updates :)

Status
Not open for further replies.
I assume it will be done at some point, but it would be nice if the pinout card back had the same information as the other Teensy pinout cards, with the qspi memory pin layout (and the SD pins).

For the psram chips, it may be useful to maintain an online list of places that sell those chips, since there are only a few places.

And for the flash memory chips, it would be helpful to have a list of the known chips that work that are still in production (possibly having a list of the older chips as well). When I got my first flash memory chips for the audio shield, several of the chips listed were no longer in production. I don't know if it would worth it if PJRC.COM offered one of the chips for sale.

Obviously when the NAND support comes in, that will need a new paragraph.

I know the problem of having too many SKEWs, and of soldering the chips on to boards, but I imagine some users soldering skills are not up to SMT soldering, and it would be nice if there was a Teensy 4.1 with pins soldered on and with 2 chips (psram and flash). While I can now solder at least SOIC connections, I do recall one of the things that led me down the Teensy path in the 3.0 days was the board came with the 28 pins soldered in as an option.
 
Last edited:
I assume it will be done at some point, but it would be nice if the pinout card back had the same information as the other Teensy pinout cards, with the qspi memory pin layout (and the SD pins).

For the psram chips, it may be useful to maintain an online list of places that sell those chips, since there are only a few places.

And for the flash memory chips, it would be helpful to have a list of the known chips that work that are still in production (possibly having a list of the older chips as well). When I got my first flash memory chips for the audio shield, several of the chips listed were no longer in production. I don't know if it would worth it if PJRC.COM offered one of the chips for sale.

Obviously when the NAND support comes in, that will need a new paragraph.

I know the problem of having too many SKEWs, and of soldering the chips on to boards, but I imagine some users soldering skills are not up to SMT soldering, and it would be nice if there was a Teensy 4.1 with pins soldered on and with 2 chips (psram and flash). While I can now solder at least SOIC connections, I do recall one of the things that led me down the Teensy path in the 3.0 days was the board came with the 28 pins soldered in as an option.

Paul is working on a T_4.1 backside layout as it is time to print new cards.

I saw this product at the new PJRC Distributor ProtoSupplies: protosupplies.com/product/teensy-4-1-fully-loaded So this can be done - but so many options ...
> it is PSRAM and 16MB Flash.
Of course there are now 64MB NOR chips, and indeed is seems the 128MB NAND's seem to be working and early 2021 may see a 256MB NAND come to market - that Paul got samples of.
Note: I made a couple of orders from Ken at ProtoSupplies and got good products and attention. And he was responsive and got a supply of the 64MB Flash chips from Digikey quickly so I could add them to an order without going to DigiKey for just them - though I did end up ordering some MRAM and FeRAM chips from DigiKey the next week :( - he charged the same single chip price as DigiKey so isn't big on markup. Ken also sells the PSRAM and of course the FLASH chips.
 
For the psram chips, it may be useful to maintain an online list of places that sell those chips, since there are only a few places.

I'm not going to create a list on the PJRC website of 3rd parties (other than official distributors) selling specific chips. The website is already a huge challenge to keep updated. We already have a list of 3rd party products / projects, and it gets out of date pretty quickly. Really not wanting to pile chips and parts on top of that.

We currently have the list of distributors on the projects top-level page. I am planning to copy it to the product pages, but that involves some technical challenges given the way the website works. In my dream world we'd have a way to check which distributors actually have each of PJRC's products in stock, but that seems pretty unlikely to happen.
 
Note: T4.x - ADC library uses QTimer4 as well.
If I remember correctly 4.0 for ADC and 4.3 for ADC1

It uses them with XBar when the user setups up to read ADC by a timer.
XBARA1_IN_QTIMER4_TIMER3
: XBARA1_IN_QTIMER4_TIMER0
 
T_4.1 page looks good at a glance.

I've added "Compare detailed specifications of all Teensy models" link just below the specs on the Teensy 3.6 page.

https://www.pjrc.com/store/teensy36.html

Plan is to make all 8 product pages follow this format. Hopefully that will make the newest specs comparison table easy to find.

When I edit that other page, my plan is delete the very old specs table and put other content on that page.

Having that "Technical Specification" page link is a better table and good for folks coming to the wrong page first - if they are still deciding as that $price field links well to all the Teensy pages.
 
Teensy 4.1/4.0 product pages

Timing Section on PWM Timers: I appreciate the information about which timers controls what, like:
Code:
FlexPWM1 Module0 - Controls PWM pins 1, 44, 45.
But wonder if you should mention, that you can use all 3 of these pins for PWM, but all of them must use the same frequency.

Also not sure how beneficial it would be versus confusing, to mention what logical Pin it is on those timers:
Code:
FlexPWM1 Module0 - Controls PWM pins 1(X), 44(B), 45(A).
This case is probably not as interesting as 44 and 45 are on SDIO...

Again I mentioned above that the ADC library uses:
Code:
Note: T4.x - ADC library uses QTimer4 as well.
If I remember correctly 4.0 for ADC and 4.3 for ADC1

Under communication:
FleXIO - as mentioned needs additional information. I have some stuff up on my FlexIO github project: https://github.com/KurtE/FlexIO_t4
Readme file. Mostly so far just about the pins. Also some stuff up on the thread: https://forum.pjrc.com/threads/58228-T4-FlexIO-Looking-back-at-my-T4-beta-testing-library-FlexIO_t4

Like the details on the FlexIO pins:
Code:
FlexIO 1 - The three rows are: Teensy pin, Flex IO pin, and MUX setting for that pin:

    2,       3,    4,    5,  33,    49,   50,   52,   54
    4,       5,    6,    8,  7,     13,   14,   12,   15
    0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14

Ranges: 4-8,12-15

FlexIO 2

    6,       7,    8,    9,  10,    11,   12,   13,   32,   34,   35,   36,   37
    10,     17,   16,   11,  0,      2,    1,    3,   12,   29,   28,   18,   19
    0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14

So have bit ranges 0-3, 10-12, 16-19, 28029

FlexIO 3 - Note Flex IO 3 does not have DMA support

    7,       8,   14,   15,   16,   17,   18,   19,   20,  21,    22,   23,   26,   27,   34,   35,   36,   37,   38,   39,   40,   41
    17,     16,    2,    3,    7,    6,    1,    0,   10,   11,    8,    9,   14,   15,   29,   28,   18,   19,   12,   13,    4,    5 
    0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19 

Have ranges: 0-19, 28-29
Obviously not overly user friendly... The library I mention helps with some of this. Also there are some others who have extended to do like a display 8 pin buss...

Another section that you may want in the mention is what I might call the glue: XBAR (mostly XBARA). There is both the GLUE part where you might tie something like a Timer DMA through to a another subsystem.

Also with the XBAR you also have IO pins associated with XBAR that allow you to use the GLUE to tie some other sub-system to that IO pin. Example used it with test sketch to tie an external pin to use as the trigger for DMA requests... Example:
Code:
// Lets try to setup the DMA setup...
  // first see if we can convert the _pclk to be an XBAR Input pin...
  // OV7670_PLK   4
  _save_pclkPin_portConfigRegister = *(portConfigRegister(_pclkPin));
  *(portConfigRegister(_pclkPin)) = 3; // set to XBAR mode (xbar 8)

  // route the timer outputs through XBAR to edge trigger DMA request
  CCM_CCGR2 |= CCM_CCGR2_XBAR1(CCM_CCGR_ON);
  xbar_connect(XBARA1_IN_IOMUX_XBAR_INOUT08, XBARA1_OUT_DMA_CH_MUX_REQ30);
  digitalToggleFast(31);

  // Tell XBAR to dDMA on Rising
  XBARA1_CTRL0 = XBARA_CTRL_STS0 | XBARA_CTRL_EDGE0(1) | XBARA_CTRL_DEN0/* | XBARA_CTRL_IEN0 */ ;

  IOMUXC_GPR_GPR6 &= ~(IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_8);  // Make sure it is input mode
  IOMUXC_XBAR1_IN08_SELECT_INPUT = 0; // Make sure this signal goes to this pin...

  // Need to switch the IO pins back to GPI1 from GPIO6
  _save_IOMUXC_GPR_GPR26 = IOMUXC_GPR_GPR26;  // save away the configuration before we change...
  IOMUXC_GPR_GPR26 &= ~(0x0FCC0000u);

  // lets also un map the _hrefPin to GPIO1
  IOMUXC_GPR_GPR26 &= ~_hrefMask; //
Obviously too much to describe in the product page... But a powerful system.

Another maybe interesting sub-system to mention on T4.1 (not T4) is the CSI (Camera).
As we have enough pins defined for 8 bit camera interface.
Code:
CSI_D2-CSI_D9 (27, 26, 39, 38, 21, 20, 23, 22)  Note these are the 8 data bits used when in 8 bit mode
VSYNC  (17 or 34)
HSYNC (16)
MCLK  (41)
PIXCLK (40 or 35)
Probably enough for this message
 
Anther advanced programming of T4.x that maybe should be mentioned somewhere, as I know I have been bit by it more than once.

GPIO/IOMUXC

If programming some IO setup at the register level and you are not getting the inputs to the pin your think you should be. One of the first places you should look at is in the IOMUXC chapter to see if there is a Input Select register. That is if there are multiple pins that can be used for the same logical Input (example a different RX or TX pin on a Serial port), than you need to make sure that you have the right setting to route it through the pin you are using.

Example: If we look at Serial1 RX and TX pins we have the option on T4.1 to use either pin 0 or pin 52 as the RX pin.

You will find out that this is controlled by the register: IOMUXC_LPUART6_RX_SELECT_INPUT
It defaults to value of 0 which is NOT our pin 0

The values are:
Code:
0 GPIO_EMC_26_ALT2 — Selecting Pad: GPIO_EMC_26 for Mode: ALT2
1 GPIO_AD_B0_03_ALT2 — Selecting Pad: GPIO_AD_B0_03 for Mode: ALT2

And our Pin 0 is AD_B0_03 so we need to set this register to 1 to get the input...

Side note on TX - For most things may not need it, BUT if you set the TX into half duplex mode then TX pin is also RX so again you need to set its register: IOMUXC_LPUART6_TX_SELECT_INPUT

Again I am not sure where something like this should be documented. But it has hit me more than once! Also I know it has hit others as well. Luckily built in support for this in the different parts of core and SPI and ...
 
@PaulStoffregen:

I am playing with a Teensy 4.0 + ILI9341 Touchscreen + Audio Adapter Rev D. The text on the ILI9341 touchscreen display <page> is not very clear on when it may be appropriate to use the alternate pins. In the "Connections" area, it says "This ILI3941 display works well with Teensy 4.0 and 4.1, using the standard connections shown in the table." In the "Usage With Audio Board Connections" area, it says "To use the ILI9341 display with the Audio Board, connect the signals using the alternate pins shown above." I guess that this second entry should really specify "To use the ILI9341 display with the Audio Board on a Teensy 3.x, connect the signals using the alternate pins shown above.", or maybe even better yet, "To use the ILI9341 display with the Audio Board, connect the signals using the alternate pins shown above. Note that this *does not* apply to the Teensy 4.x."

Thanks,

Mark J Culross
KD5RXT
 
Paul (and all)

I am pretty sure that it is far too much details to show in a product page, but I do wish at times there were some form of extract of table or the like that for each Teensy pin it shows some of the details on how those pins can be configured. For example how do you configure Pin 0 and 1 to work as a Serial port...

For the heck of it I added another page to my Excel document, that has some of it in it: Currently the data looks like:
screenshot.jpg

Note: I did some quick and dirty color coding of some of the pins functions, but not all yet.
Also in the case of IMXRT... It might also be good to know more about how direct the info to that pin.

For example for Pin 0 we both need to set: IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03 to 2 (actually probably 0x12)

But the part that one might miss is you also need to set: IOMUXC_LPUART6_RX_SELECT_INPUT = 1

Not sure how best to put that in the excel table?
 
Also in the case of IMXRT... It might also be good to know more about how direct the info to that pin.

For example for Pin 0 we both need to set: IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03 to 2 (actually probably 0x12)

But the part that one might miss is you also need to set: IOMUXC_LPUART6_RX_SELECT_INPUT = 1

Not sure how best to put that in the excel table?

Possibly put it as a sticky note (the one that appears when you hover over the cell) ??

Mark J Culross
KD5RXT
 
Paul, I am not sure, how many people would be interested or not...

But when I see the memory information, like in the new T4.1 page: https://www.pjrc.com/store/teensy41.html#memory
teensy41_memory.png

I at times need to know the addresses of the different regions, that is:
ITCM starts at address: 0x00000000
DTCM looks continuous with the ITCM addresses in the diagram, but it actually starts at address: 0x20000000
The RAM2(OCRAM) starts at ox20200000
The Flash memory starts at 0x60000000

The optional PSRAM: starts at 0x70000000

And not sure if anything should be mentioned here about optional Flash?

Again I don't know how many look for this type of information, but I mention it now as was double checking PSRAM location to see why extended board appears to be screwing?
 
I think people who need to know this are smart enough to take a look at the linker files generated symbol files or can just print addresses in a sketch.. You can't document everything on such a page. It would need several pages if you want to go down to that level.
It is easy to confuse beginners with too much information.
 
Last edited:
Some information about that "LittleFs", as - what it is, -what is good for and how to use it would be more interesting ;)

+Questions like: Is there a tool to upload files there, like the one for ESP32? It can upload a "data" folder in the sketch directory automatically, from the Arduino-IDE. Or do I have to write a Sketch for that? What if I don't want to use MTP?
How to use a different "partition scheme" for a larger LittleFS? If not, how much space for storage has it?

2021-01-04 21_33_09-Suche.png and this? 2021-01-04 21_34_28-Suche.png

Just a general HowTo, that covers topics for Users comming from ESP who know LittleFS (+SPIFFS?) basics already.
What about SPIFS? Is it possible to use it instead of LittleFS?

I was a few moth away and do know nothing. Can imagine how beginners feel about these basics.. and not to find information. I don't want to read the large forum threads.
 
Last edited:
I liked the idea of showing the base address of the areas KurtE notes - but it got eliminated as TMI before when that page was created - still think having it there would be good reference.

Some information about that "LittleFs", as - what it is, -what is good for and how to use it would be more interesting ;)
...
Just a general HowTo, that covers topics for Users comming from ESP who know LittleFS (+SPIFFS?) basics already.
What about SPIFS? Is it possible to use it instead of LittleFS?

I was a few moth away and do know nothing. Can imagine how beginners feel about these basics.. and not to find information. I don't want to read the large forum threads.

LittleFS still just a beta concept - though working will need doc and support as possible. Not sure how far away 1.54 release or next beta# are? That would be a beta thread note or info on the LittleFS thread ...

As far as the _Program area [ from past note IIRC ] for now the bootloader will be wiping that on every upload, it will only survive across restarts until a new upload - Paul isn't planning to edit the bootloader or build to reserve space at this time. The Sketch allocates it on startup to create it in the desired space.

If the MTP stuff gets cleared to function that would be an easy way to add to drives.

As far as SPIFFS - the developer of that has gone quiet and SPIFFS is being deprecated according to posted notes @mjs513 and I saw ...
 
Yes but it works good :)
Zuse, von Neumann and others went away too..

An fs that gets wiped is'nt usable :(
In this case I'd delete it from the picture above.

It is like a advertisement for a car with 1000 HP but you if you try to buy it you realize you can only get 80HP
 
Last edited:
Status
Not open for further replies.
Back
Top