Wishlist: Card updates for T4 and T4.1

It would be nice to have the display work on a phone or tablet as my solder bench doesn't have a computer - though if designed in advance and pin table printed paper can work. Building a CUSTOM CARD

Glad you got usable images - they were good photos - the RAW image from PJRC might offer less advance JPG'gery or higher resolution - but those seem to have good fidelity. As noted the browser expands well on screen - I did that and got 24 color BMP's - but 22MB too large to post.

The rPi example KurtE linked seemed to have an elaborate set of features - not sure how many can be applied usefully to Teensy in your efforts.

KurtE also noted the other possible place to post for viewing - if the wiki can do that.
 
As mentioned and shown, there are tons of possibilities, of things I like seeing at different times, sometimes with more or less information, but best way to show that?

Things like:
a) When looking at the images, would like to see an indication of what different pins can do, like shown on the main Teensy card. Could be as simple as a set of color bands next to each pin, like one color shows it is a serial pin, another SPI, another Wire, another Audio, PWM/Timer, XBAR, CAN, Analog, ...

b) If I click on pin, maybe give me a lot more details about that pin, like for example I have pin 0 information like:
AD_B0_03 1.3 17 RX2 CS1 RX1 1X1 0
(It's actual native pin number, GPIO Port and pin, XBar pin 17, Can RX2, SPI CS 1-0, Serial1 RX, PWM on Timer FlexPWM module 1 sub module 1, Pin X )
Most of this data is easy to see right off of my XLS stuff or several others have done similar: As I showed in message 1 above.

c) Then simple groupings - like click on SPI, it highlights all of the SPI pins. Not sure if more than one of these on at a time? maybe again shown pins marked with color coded?
Wonder if for example I click on SPI, should it have some sub-buttons that allow me to choose seeing all of them, or just SPI, or SPI1 or SPI2?

d) Maybe show some higher level external grouping for things like Audio board, maybe a way to set some of these show that pin can still be used for other things as well. In particular SPI pins can still be used for SPI stuff... Again depending on how others might use this, do you have some way to lock a pins usage in. That is you say I am using Audio board, so show those pins as locked in?

e) Other groupings that you see that others look for? Show all pins or Port1(note not sure if you want to say 1 or 6?) i.e. the port number you will see in reference manual versus the port number you actually mostly use in code? But for example for those who wish to do N bits at a time it would be great to see:
Port 6, you can use the pins in this order to get these in one read/write...

f) More subtle and possibly more confusing, is details about things like PWM and timers. Example why Paul's example on the forum for multiple PWM frequencies uses some PWM pins and not others?
Example uses pin 2 but NOT pin 3? (could be other way around as well). That is because they are both on the same: FlexPWM Module(4), sub Module(2), but different pin. Each of these Module, SubModule can have up to 3 pins (A, B, X). Again my Excel document shows which timer is used.

Note: Not all PWM pins use the FlexPWM timers, some use Quad Timers, like Pin 10 uses Quad Timer module 1, Timer 0... Note: I like seeing this data as well as because there are other sub-systems who may want to use Quad timers for other things like (capturing Timer inputs and the like) so I like to see if I use PWM on pin 10... That timer is used. Note: I show that there are a few pins that actually have both types of timers on this. (Pin 6 and 9), in these cases PWM uses the FlexPWM timer.

I also marked in the PWM area but not in PWM colors, those pins that are connected up to General Purpose Timer (GPT). As maybe they may come in handy for other things...

...
 
Yes, this is item #3 on my to-do list.

The 'void' on the T_4.1 card backside will be nice when filled.

I've added this thread to my list of high priority issues. I'll carefully read the many suggestions when I'm farther along with items #1 & #2. But unfortunately, in the meantime we had to get another batch of the cards printed. So even if I wrap up those other things soon, it's going to be a while until more Teensy 4.1 cards are printed.

Those 2 other high priority items which are blocking documentation are #1: T4.x bootloader chip, which involves sorting out how we're going to support use of encrypted firmware written to the flash chip, and #2: updating the distributor list and showing it (somehow, maybe a sidebar) on the main website.
 
I have played with various ways to implement the interactive pinout card on a self-contained web page, but most approaches feel too clunky for me; that's why the long delay. However, I finally found a way that does not raise my own hackles too much. Unfortunately, I have only a Linux workstation, so I don't know if this works well in other browsers.

Would you (those interested in having such a web page they could use, including on a non-networked computer in their shop) try this test page?
When you open it, it should show a very simple page:
screenshot.png

However, you can drag the field around using the dot icon, and you can edit the text as well. The line is between the periphery of the field, and the center of the window. (The dot is just the standard font bullet character; better ideas for an icon? Right now the label is forced to plain text after you defocus it, but we could allow HTML markup when editing, for colors and/or super/subscripts et cetera.) The idea being that one can drag the pin labels/descriptions wherever they want, with the line pointing to the pin.

The implementation behind this test: we have a full-window SVG background containing the lines (and will contain the board image), with HTML elements on top. Each field is a DIV with two spans, one for the move handle, and the other containing editable text. Dragging uses the HTML5 drag-and-drop mechanisms for the label. It is a bit of a mixed bag, but this way it should be very fast even on small SBCs (Odroids, Pis, et cetera) as long as they have OpenGL or OpenGL ES acceleration; there is no Canvas, only HTML and SVG, which should be hardware-accelerated. This all should Just Work, but having confirmation (or bug reports!) from users of other browsers and OSes would be very useful, and ensure that implementing it this way makes sense. Online browser tests don't really work with interactive JS and DHTML, so actual browser testing is basically the only way to check. And I personally only have Linux machines; no Mac, no Windows...
 
@NominalAnimal:

I can report the following (all tests performed offline under 64-bit Windows 10 Pro version 2004, build 19041.610):

firefox (82.0.2 64-bit): display, editing, & moving work as described - cursor appears as an edit bar (indicating an editable field) over the text & as a hand (indicating moveable) over the dot

InternetExploder (11.572.19041.0 + update 11.0.210): display, editing, & moving work as described - cursor appears only as an edit bar (indicating an editable field) & not as a hand (indicating moveable) over the dot

Edge (86.0.622.51): display, editing, & moving work as described - cursor appears as a an edit bar (indicating an editable field) over the text & as a hand (indicating moveable) over the dot

Mark J Culross
KD5RXT
 
Thanks a lot, Mark! I think replacing the bullet character with a small image would help with that cursor issue. You don't happen to use Chrome, do you? (Although that version of Edge already uses the same engine, it'd be nice to be sure.. :eek:) Anyone with a Mac? Opera or Safari users?

I didn't mention above, but the test page itself validates fine as HTML5 + SVG1.1, and the only browser-implementation-specific thing in it was the rounded corners in the editable field.

Anyway, I think this is already promising enough to spend the time to make the full pinout page. I still need to test which implementation to use for "saving" the settings; I can trivially do so using a server-side script, but I'd love for users to be able to not only use the page offline, but also save their changes locally. (It really isn't that strange, as the only difference in "saved" pages would be in a Javascript array/object initialization block. Essentially, it works by opening what looks like the current page in a new browser tab or window; but the HTML5 source of that tab of window is generated by the JS in the original window, and saving it as HTML also saves the current settings. The server-side saver does the same thing; it just reloads the very same page with the current contents provided in a POST data block in that JS array/object, so that saving the page afterwards also saves the current layout and contents.)
 
You don't happen to use Chrome, do you? (Although that version of Edge already uses the same engine, it'd be nice to be sure.. :eek:) Anyone with a Mac? Opera or Safari users?

Sorry, I've previously tried Chrome in Windows, but (according to our IT folks) I have been warned that it loads too many additional "features" & leaves too many holes open. This is definitely not a bash against Chrome, it's just what I have been told & I have no reason to doubt the source of the warning. I'll have to leave Chrome testing for someone else.

Glad to be able to help with the testing !!

Mark J Culross
KD5RXT
 
Yup, no worries; I can definitely understand why the IT folks said that. (I used to be one. I don't use Chrome either, and have a completely fake/dedicated email address to use with Google stuff – I do use an Android phone, you see.)

Thanks again, Mark!
 
I can test this for Safari and Chrome so I can say that while it does work the same as the other browsers I wish it was more fluid like the Audio System Design Tool where the line moves as you drag it instead of only updating it after you stop clicking. There's also the issue of it snapping back to it's previous position before moving to where your mouse dragged it to. Since these are both kind of based off of WebKit this may be something only happening on Safari and Chrome so here is a gif of what I am describing(you may have to open it to see it correctly).
Safari-Pinout-HTML-Test.gif
 
Thanks, vjmuzik! I know exactly why that happens. Indeed, it is very similar to what happens on Firefox; just with a much more noticeable delay.

I think I'll have to do a test page with sixty or so fields and lines, to try and find out if realtime dragging is fast enough.

The problem here is that using the drag-and-drop facility provided by HTML5 is basically guaranteed to be accelerated on all Linux SBCs with OpenGL or OpenGL ES acceleration (which is all that have a usable graphical desktop), but doing the full animation in Javascript may be too slow. In the current test page, that Javascript redraw stuff is only needed when the dragging ends, ensuring it isn't too slow on SBCs. However, I'd like it to be more fluid, even though it isn't a critical feature – things like gridding/aligning the fields to a grid when approximately placed so would be much more useful in practice – but still... Oh well, no way to know except to test and find out!
 
Hey Guys,

Coincidently I've been making my own using SVG and HTML.

https://dylanbrianbenton.github.io/Teensy4.1Pinouts/

It's only been started today so very much of a proof of concept to myself.

My idea being, choose the pin types from the dropdown menu and then have it display which pins are compatible while showing the pins and their uses on the grids next to it. None of the Pin types or descriptions are accurate but later tonight I'll go through and get some more sorted.
 
Hey Guys,

Coincidently I've been making my own using SVG and HTML.

https://dylanbrianbenton.github.io/Teensy4.1Pinouts/

It's only been started today so very much of a proof of concept to myself.

My idea being, choose the pin types from the dropdown menu and then have it display which pins are compatible while showing the pins and their uses on the grids next to it. None of the Pin types or descriptions are accurate but later tonight I'll go through and get some more sorted.
Looks good as a start. It can be a bit to tease out the details (particularly things like favored CS pins for SPI and SPI1).

You can easily get into nit-picking over whether a pin should be covered or not. For example in the power & ground pins, you need to consider whether to list the power pin in the inner USB host pins, since this pin doesn't deliver power until you enable the USB host support, and of course the power/ground pins in the micro-SD card and ethernet ports. Finally is VBAT a power pin? It isn't a pin that most of the Teensy uses, but the part of the Teensy that keeps the real time clock uses it.

Note you likely want to use different colors to identify different pins (or have the text show it). For example, yes pins 11-13 are the 3 main SPI pins, but you really want to know that pin 11 is MOSI, pin 12 is MISO, and pin 13 is SCLK. Then you get to the special CS pins (10, 36, 37) that are important for a few Teensy specific drivers. For SPI1, you have a pin that can be an alternate SPI1 pins. I.e. normally pin 1 is the MOSI1 pin but pin 26 can be MOSI1 if you call the override function.

One thing a lot of people trip on is the directional pins (i.e. RX and TX for serial uarts). You have to realize that for these pins, you have to sometimes swap things around to get them work. For example, RX is the Teensy receiving data, but when you hook it up to a remove device you want to hook it up to TX. But some devices are labeled to correspond to the name on the microprocessor.
 
Looks good as a start. It can be a bit to tease out the details (particularly things like favored CS pins for SPI and SPI1).

You can easily get into nit-picking over whether a pin should be covered or not. For example in the power & ground pins, you need to consider whether to list the power pin in the inner USB host pins, since this pin doesn't deliver power until you enable the USB host support, and of course the power/ground pins in the micro-SD card and ethernet ports. Finally is VBAT a power pin? It isn't a pin that most of the Teensy uses, but the part of the Teensy that keeps the real time clock uses it.

Note you likely want to use different colors to identify different pins (or have the text show it). For example, yes pins 11-13 are the 3 main SPI pins, but you really want to know that pin 11 is MOSI, pin 12 is MISO, and pin 13 is SCLK. Then you get to the special CS pins (10, 36, 37) that are important for a few Teensy specific drivers. For SPI1, you have a pin that can be an alternate SPI1 pins. I.e. normally pin 1 is the MOSI1 pin but pin 26 can be MOSI1 if you call the override function.

One thing a lot of people trip on is the directional pins (i.e. RX and TX for serial uarts). You have to realize that for these pins, you have to sometimes swap things around to get them work. For example, RX is the Teensy receiving data, but when you hook it up to a remove device you want to hook it up to TX. But some devices are labeled to correspond to the name on the microprocessor.

Yup it was just a test to see if it worked the way I wanted. I have changed the pin colours and the 2 boxes next to it update with which pin correlates to which function and the description in detail of what it does. Once I upload it a bit later I'll go into more depth.
Another thought was making a pin assignee that let's you map out what you're doing and have the ability to export to pdf.

Very early days!
 
Back
Top