K66 Beta Test

[KurtE]

Hi Michael,

I was playing around with analog.c recently, trying a couple of ways to add the two other analog pins on 49 and 50 as A23 and A24. The main way was to add like the others and add another if statement to create index into array... Pull request: https://github.com/PaulStoffregen/cores/pull/167

Paul made a comment about the efficiency where I kept things in order, so made adjustment and then wondered about what the size/speed differences would be to do straight lookup table, where the code simply checks to verify that pin number is not too large and then loads value from array and then checks to make sure not invalid (I used 0xff). I also noticed that ADC library appears to be doing something similar, So I made a version of analog.c that I could compile either way and made tables for all of the chips. I used test program to try to verify all of the analog pins, which I tested on T3.6, T3.2 and TLC. Did not test T3.0 as I don't have any. Code was smaller on T3.6, I believe same size on T3.2 and slightly larger on TLC (8-10 bytes?) and speed differences weren't much... If anyone is interested in looking at that version up at: https://github.com/KurtE/cores/tree/T3.6-Add-A23-A24-lookup

While doing this, I wished there were some #define for the special analog pins like temp, that was defined depending on board. Something like how PIN_LED is defined.
Was not sure if it should be something like: A_TEMP, A_VREF or like PIN_TEMP, PIN_VREF or... Also was not sure if worry about adding new defines breaking things, so if they should be added under some #ifdef like: DEFINE_EXTRA_ANALOG_PINS

As you mentioned Could not be 38 as on the T36 pin 38 is a real analog pin: A19.

Kurt

 

[manitou]

I use the internal temperature sensor when creating the seed value for random numbers (along with some other stuff). A page that came out when the Teensy 3.0 was new mentioned this sensor: http://dangerousprototypes.com/forum/viewtopic.php?t=4606.

In case others also use it, I dug into the library (avr/cores/teensy3/analog.c), and noticed for 3.5/3.6, the sensor is now on pseudo pin 44 instead of 38.

Similarly, for Teensy 3.0, 3.1, 3.2, analogRead (39) gave AREF (the comments indicate LC gives the bandgap sensor). On the Teensy 3.5/3.6, it looks like this got moved to pseudo pin 45.

The K64 and K66 have hardware random number generator, really good for generating seeds for PRNGs. For crypto-strength, it is recommended to take one bit from each 32-bit read of the hardware RNG.

I've argued for symbolic names for the internal ADC channels (VREF OUT, temp sensor, bandgap, ...)

 

[manitou]

Perhaps it doesn't work if the wires are too long? RMII is 50 MHz.

I did digital IO check of beta3-breadboard to breadboard jumpers, and voltages were all OK, so I'm going with "breadboard/jumpers not so good at 50mhz" since defragster had success with female headers + shield on beta3. I actually get the PHY regs to read every so often, and occasionally see the shield LEDs flicker.

EDIT: as a test, i used jumpers from the K66 proto female headers to a breadboard with the ether shield. That also failed.

 

[KurtE]

Sorry if this question has been answered (somewhere in this really hard to search mass). Wondering about the number of independent timer blocks and which pins will be assigned to which timer, etc? Looking for information similar too:

Not sure if anyone answered this yet. You can probably deduce most of this from several places including my Excel document which I have posted up here a few times. I see that Defragster has a link to at least one of the postings up on posting #8, which points you to: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=112463&viewfull=1#post112463

If you look at chapter 45, you see number of channels per FTM (8, 2, 2, 8)

Here is a quick look through Excel, note: I may be off and did not double check things or verify duplicate pins. Those with ? are probably duplicates of others...

If I look over the T3.6 table and search for those with FTMn_CH I see things like:
For FTM0_ I see pins (5, 6, 9, 10, ?13, 20, 21, 22, 23, ?25 )
FTM1 (3, 4, ?16, ?17)
FTM2 (29, 30)
FTM3 (2, 7, 8, 35, 36, 37, 38, ?56, ?57)

Note the T3.6 (Not T3.5) also has the Timer/PWM Module (TPM) which there are TPM1 and TPM2 each with two channels:
TPM1: (3=0, 4=1, 16=0, 17=1)
TPM2: (29=0, 30=1)

Back earlier #1043 I posted a Arduino Test app, that included a hacked up version of PulsePosition that uses TPM timers.

Hope that helps

Kurt

 

[MichaelMeissner]

While doing this, I wished there were some #define for the special analog pins like temp, that was defined depending on board. Something like how PIN_LED is defined.
Was not sure if it should be something like: A_TEMP, A_VREF or like PIN_TEMP, PIN_VREF or... Also was not sure if worry about adding new defines breaking things, so if they should be added under some #ifdef like: DEFINE_EXTRA_ANALOG_PINS
Kurt

I maintain my own config file for various Teensy's, Arduino Uno, Squarewear, ATtiny85, etc. I put it in there (I called it PIN_TEMP_SENSOR, but I don't care what the name is). But it would be nice if it was in pins_arduino.h. Either that or a new function that returns the internal temperature.

 

[defragster]

. . .
Nope, but that's next on my list after shipping some K64 beta boards. The cards take 1-2 weeks to print, so this is about the cut-off to have time for 1 redo if there's any problems.

Not sure if you are doing a full print for review? I was just looking for a printable doc file?

Have you considered edge printing a 0.10" index for the pin #'s? Or an index on a stand alone business card sized piece? I did that for myself and it helped get things working either the first time - or just after. 24 is too high to count and the non linear numbering isn't helpful.

 

[ceremona]

Thanks Kurt. This mostly answers my questions. I'm guessing that the table 3.4 is meant to be 3.5 and 3.5 is meant to be for the 3.6 teensy?? I did look at one excel sheet early on but I couldn't see any timer info. It looks like you are one of the people that is more focused on the timer stuff. I'm not clear what element of the timers is configurable at this point, and what elements are dictated by the chipset. Right now, I use the timers to take in audio data at 8kHz and spit it out in some (sometimes modified) form to a motor driver which can act as both a low resolution audio amp and also an actuator. I found the teensy audio library wasn't flexible enough for what I needed but, thankfully, Paul's IntervalTimer is straightforward enough to use in it's place. I 'm always looking for more flexibility (like aren't we all). So more independent timer blocks that can run at differing PWM carrier frequencies (analogWriteFrequency) is always a bonus.

 

[ceremona]

I can see getting more into multichannel ADC to DAC stuff via the timers, so again, more channels is better. More independent channels is better better better!

 

[KurtE]

Thanks Kurt. This mostly answers my questions. I'm guessing that the table 3.4 is meant to be 3.5 and 3.5 is meant to be for the 3.6 teensy?? I did look at one excel sheet early on but I couldn't see any timer info. It looks like you are one of the people that is more focused on the timer stuff. I'm not clear what element of the timers is configurable at this point, and what elements are dictated by the chipset. Right now, I use the timers to take in audio data at 8kHz and spit it out in some (sometimes modified) form to a motor driver which can act as both a low resolution audio amp and also an actuator. I found the teensy audio library wasn't flexible enough for what I needed but, thankfully, Paul's IntervalTimer is straightforward enough to use in it's place. I 'm always looking for more flexibility (like aren't we all). So more independent timer blocks that can run at differing PWM carrier frequencies (analogWriteFrequency) is always a bonus.

Yes, that version of the excel I had not yet updated to the change in Board names. There is a later one that I believe was updated:
https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=113075&viewfull=1#post113075

Or maybe better yet. Here is my current one.

I should have mentioned, that it takes sort of knowing the system to use the data.

That is if you are looking at Flex Timer Pins that can be used for input/output, they are labeled like FTM, you will see for FTM1, entries like on Pin 3, that the ALT3 functality is: FTM1_CH0

So it Flex Timer 1 Channel 0, and likewise pin 4 is FTM1_CH1 so it Channel 1. Note There may be Duplicates, example Pin 13 Alt7 is FTM0_CH2, but so is Pin 9 Alt4 (and 25 Alt 3). For the most part only one of these can be used at a time...

EDIT: This zip file was screwed up, reposted a few messages down!

 

[defragster]

Kurt - updated sticky link post 8 to post 1209

 

[ceremona]

Still has the old 3.4 and 3.5 board name tab labels.

 

[KurtE]

looks like the zip file got screwed up...

Killed the zip, rebuilt, looks better (I hope)

Sorry

 

[defragster]

Paul - other - has anyone confirmed/looked into the failure when flash code space used goes over 512MB? In my prior results - it seemed to work 3-10 times and then did not work after that as I tried it as below and subsequent simpler test.

<edit> this was noted and I missed it - see post 1214 below.

 

[manitou]

Paul - other - has anyone confirmed/looked into the failure when flash code space used goes over 512MB? In my prior results - it seemed to work 3-10 times and then did not work after that as I tried it as below and subsequent simpler test.

I think Paul confirmed it was a bootloader bug in https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=113130&viewfull=1#post113130

(my limited tests on ubuntu and macos successfully ran simple sketch with flash > 512MB)

 

[TelephoneBill]

I have not used an SD Card before with Teensy (or any other MCU). Where would be a good place to start learning - the Arduino IDE has some info - is this directly applicable to T3.6 Beta?

If someone could point me at a (relevant to T3.6) simple example, that would be most helpful. I found this - https://www.arduino.cc/en/Tutorial/Datalogger - but not sure if it would work directly with T3.6 ???

I am about to buy my first Micro SD Card - should I buy a 32 GByte or smaller? Should I buy SDHC or some other type? Which class is suitable - Class 10 or slower? Wondering here if T3.6 has some limits that will affect choices.

Obviously a FAT file system is useful on an SD Card, to be able to read data independantly on a PC etc. Should data always/invariably be written to SD Cards formatted with a file system? Or is there another technique?

When a SD Card is in use with T3.6, does this employ particular resources/Teensy pins that will not then be available for other general use? Thanks in anticipation...

 

[KurtE]

This weekend I've been working on the Teensy 3.5 testing. Took longer than expected, got the first board tested just now.

I'm planning to send out beta boards to about 6 people. Going to sent to Frank, KurtE, Manitou... who else (on the beta testers list) wants to play with the K64 chip over the next few weeks? Only 12 of these boards exist, so please only request one if you definitely have time to do useful testing.

Hi Paul and Others,

Looks like mine should arrive tomorrow

Some quick questions.

a) Should we post stuff about 3.5 on this thread or create a new K64 beta thread?

b) Looking through the documents, I am guessing that 5v tolerance for digital pins like T3.2 and Analog only pins probably like T3.2 are not 5v tolerant.
I sort of deduced that from: http://cache.nxp.com/files/microcontrollers/doc/data_sheet/K64P144M120SF5.pdf page 7, but wanted to verify.

This probably includes DAC0, DAC1, AREF, probably A10/A11. Actually I want to look these pins up in both manuals and update my excel document for these other pins.

c) Current Boards.txt only defines up to 120mhz in the menu, but looks like there are others that are defined minus the line to put them in the menu. i.e. sort of like the lines for the T3.2 which have a # in front. Should we stay at 120mhz or should we try some of the others like 144mhz or 168?

d) My priorities will be to try out some of the things I touched earlier like: Serial4-Serial6, SPI1/2, I2C,
Then may try some random stuff like Audio board, Propshield... Or let us know what other things you wish for us to bang on.

Should be fun!

 

[defragster]

Manitou - thanks I missed the update linked in post 1214.

KurtE - same here: USPS Wednesday. I need to get back in gear here. I could see a new T_3.5 thread for K64 being cleaner and easier to follow, much in common but the timing and other differences being separate and in a fresh thread might help it getting started. This will be post 1217 on page 49 ... with T_3.6 being stable I'll likely try the same on both and any differences or details could be noted.

Are there any pending Core changes that we should merge for T_3.5 use - or is there a new Teensyduino 1.30 Beta #4 in the works?

<edit> POST 8 UPDATE - the following post 1218 for CAN was added to DEVICE list.

 

[pawelsky]

Did not try two simultaneous instances working together yet, but that will be a next step.

Finished simultaneous dual CAN support and it seems to be working fine. I've used a simple tests that transmits whatever is received on CAN0 to CAN1 and vice versa at 1Mbps.

Tried all the clock frequencies and it worked down to 4MHz. 2MHz seems to be to slow

I've updated the library on github and added the dual CAN example.
https://github.com/pawelsky/FlexCAN_Library

P.S. In order to tests frequencies below 24MHz I had to tweak the boards.txt file as for Teensy 3.6 there is a mismatch in the speed.xxx and speed.xxx.build.yyy variables names (opt suffix is missing for 2, 4, 8 and 16MHz clock variables).

 

[PaulStoffregen]

a) Should we post stuff about 3.5 on this thread or create a new K64 beta thread?

Either's fine with me. Please understand I'm struggling to keep up with messages recently (more than usual) with the Kickstarter and lots of things going on here to get ready for production.

b) Looking through the documents, I am guessing that 5v tolerance for digital pins like T3.2 and Analog only pins probably like T3.2 are not 5v tolerant.
I sort of deduced that from: http://cache.nxp.com/files/microcontrollers/doc/data_sheet/K64P144M120SF5.pdf page 7, but wanted to verify.

Yup, that's my understanding.

c) Current Boards.txt only defines up to 120mhz in the menu, but looks like there are others that are defined minus the line to put them in the menu. i.e. sort of like the lines for the T3.2 which have a # in front. Should we stay at 120mhz or should we try some of the others like 144mhz or 168?

d) My priorities will be to try out some of the things I touched earlier like: Serial4-Serial6, SPI1/2, I2C,
Then may try some random stuff like Audio board, Propshield... Or let us know what other things you wish for us to bang on.

I'm most concerned with software bugs at the rated speed. But I know overclocking is fun.

Any chance you could look at Serial6 first?

 

[PaulStoffregen]

I've updated the library on github and added the dual CAN example.
https://github.com/pawelsky/FlexCAN_Library

Awesome!

Do you think we should use your copy as the official FlexCAN library? Looks like Teachop is long gone.

 

[KurtE]

Either's fine with me. Please understand I'm struggling to keep up with messages recently (more than usual) with the Kickstarter and lots of things going on here to get ready for production.

I totally understand! I was asking to see which way is easier for you. Makes little difference to me. May start a new thread as we can then find the specific things easier.

I'm most concerned with software bugs at the rated speed. But I know overclocking is fun.

Any chance you could look at Serial6 first?

Understand. I will start off mainly at the rated speed and yes will look at Serial6. I put in code for it earlie using Usart5, but obviously had no way to test it then.

 

[defragster]

Paul / KurtE / FrankB::
Regarding the MAC/Serial# read when in HSRUN - I just posted a short version of the change KurtE has a Pull Request for here : teensy-3-MAC-address

 

[pawelsky]

Awesome!

Do you think we should use your copy as the official FlexCAN library? Looks like Teachop is long gone.

If nobody finds any issues, then please do.

 

[manitou]

Should we post stuff about 3.5 on this thread or create a new K64 beta thread?

I would be inclined to start a new K64 beta thread in Announcements (though only PJRC can create Announcement threads), with links back to this K66 beta thread and kickstarter and an embedded table summarizing differences between K64 and K66. Postings for things that work as they did on K66 should be brief and possibly point back to any K66 sticky post. Emphasis should be on things that work differently or are broken.

Might also want to update your K66 posts with any K64 insights.

 

[KurtE]

As you mentioned only Paul (or other Admin) can create a thread in Announcements, but later today if there are not any new threads, I may create a place holder thread probably in General Discussion, with some of the information you mentioned there. Probably with links to K66 thread, Kickstarter, maybe cut and paste of some main things from K66 thread, like card layout and the maybe some of the differences between the two boards (mostly from kickstarter), but also things found.