K66 Beta Test
- Thread starter Paul
- Start date
- Status
TelephoneBill
Well-known member
Can anyone tell me what the "system clock" frequency will be for the K66? I'm trying to determine the clocking frequency (internal system) for the FTM timers. Chapter 45 says a lot about FTM and refers to "the system clock" as one of the common options to select, but it doesn't indicate where this comes from and how its frequency will be determined..
With the K20, the reference manual, the FTM timers always referrred to the "Peripheral Bus Clock" which was half of the cpu clock frequency. If 120 MHz selected in "boards.txt" then the peripheral Bus Clock would be 60 MHz.
My confusion arises from this new High Speed mode of 180 MHz. Does this mean that the FTM "system clock" will now be 90 MHz?
Another confusion is the term TPM timers in Chapter 43. Are these the same thing as FTM timers, or is this yet another set of flexible timers with "Channel" outputs/inputs?
With the K20, the reference manual, the FTM timers always referrred to the "Peripheral Bus Clock" which was half of the cpu clock frequency. If 120 MHz selected in "boards.txt" then the peripheral Bus Clock would be 60 MHz.
My confusion arises from this new High Speed mode of 180 MHz. Does this mean that the FTM "system clock" will now be 90 MHz?
Another confusion is the term TPM timers in Chapter 43. Are these the same thing as FTM timers, or is this yet another set of flexible timers with "Channel" outputs/inputs?
@TelephoneBill:
@180 MHZ, F_BUS is 60 MHz
See here: https://github.com/PaulStoffregen/cores/blob/master/teensy3/kinetis.h#L762
@180 MHZ, F_BUS is 60 MHz
See here: https://github.com/PaulStoffregen/cores/blob/master/teensy3/kinetis.h#L762
KurtE
Senior Member+
My guess is that Paul (PJRC) will give the complete foot print for the new processor when they are ready to: Put up a preliminary order form on the PJRC website and/or they launch the Kickstarter that he mentioned several pages ago.
As WMXZ mentioned, if you look at posting #3, you will see a reasonably complete pin listing. From other postings you know that the new board is 1" longer than the T3.2 boards. It also gives a you an idea where 5 pins are between Pin 27 and Pin 39 which has (Reset,Program, GND, 3.3V, Vbat), I am assuming in that order, but unsure if Reset is next to 27 or 39. But I using this information I made a stab in my Diptrace library for this part. There are still several other pins that so far have not been documented exactly where they are yet, but if you don't need those additional pins, you can probably safely generate a board. Posting #8 gives you an idea of what is on these additional pins.
Kurt
The timers run from F_BUS, which will be 60 MHz (the max officially rated speed) when F_CPU is 180 MHz.
F_BUS overclocking can be done by uncommenting lines in mk20dx128.c. I'm still debating whether to make any F_BUS overclocks available in Arduino's Tools menu.
To be honest, this is one of the parts of the chip I haven't really explored yet. My understand from only the ref manual is they're yet another 2 flexible timers which a total of 4 more channels.
They seem to share all the same resources as FTM1 & FTM2, so how you use them isn't perfectly clear to me. If anyone experiments with them, please share anything you learn. Is it really possible to get another 4 PWM outputs?
At this moment I'm concentrating on getting the Kickstarter written. Hoping to have it go live sometime next week.
xxxajk
Well-known member
Ok, some progress news on the HS USB side of things.
I've managed to sort of sloppy port one of the SDK demos, and, it works.
What I need to do next is to deconstruct it so that I can understand wtf is going on.
I've managed to sort of sloppy port one of the SDK demos, and, it works.
What I need to do next is to deconstruct it so that I can understand wtf is going on.
- Research and break thru the spaghetti code, which will be easier now that i can debug it.
- There is a lot of dependence on "RTOS" garbage that isn't needed within UHS3.0, since UHS30 manages that sort of thing. The controller provides a nice 1ms timer just like the Kinetis host controller, and can be used for the silly event polling and other RTOS cruft.
Code:
Attach.
Enumerated.
device cdc attached:
pid=0x42 vid=0x2341 address=1
cdc device attachedJust got my new toy in
Gonna start a basic footprint/symbol on eagle(will do Kicad at some point also). Will post once Paul gives the go ahead.
edit..
@Paul,
that's some crazy routing lol. Can you post pin assignments for pins 48-57 when you get a chance?
Gonna start a basic footprint/symbol on eagle(will do Kicad at some point also). Will post once Paul gives the go ahead.
edit..
@Paul,
that's some crazy routing lol. Can you post pin assignments for pins 48-57 when you get a chance?
Last edited:
KurtE
Senior Member+
From the Pin Table I believe that I sort of described all of these pins in #756
Which the MUX table looks like:
And the Cardish might look something like:
Sorry I probably don't have the tabbing set correctly as this was cut and past from my Excel document
I am also playing around with trying to setup footprint and the like for Diptrace.
Warning, When I put up things like CS, I have additional information like which CS, as you can only use 1 of each duplicate pin.
Again Paul, when it is OK I will post this document as well
Which the MUX table looks like:
Code:
# PIN ALT0 ALT1 ALT2 ALT3 ALT4 ALT5 ALT6 ALT7
-- --- ---- ------ --------- ----- --------- ------ -------- ---------
40 A28 PTA28 MII0_TXER FB_A25
41 A29 PTA29 MII0_COL FB_A24
42 A26 PTA26 MII0_TXD3 FB_A27
43 B20 PTB20 SPI2_PCS0 FB_AD31/SDRAM_D31 CMP0_OUT
44 B22 PTB22 SPI2_SOUT FB_AD29/SDRAM_D29 CMP2_OUT
45 B23 PTB23 SPI2_SIN SPI0_PCS5 FB_AD28/SDRAM_D28 CMP3_OUT
46 B21 PTB21 SPI2_SCK FB_AD30/SDRAM_D30 CMP1_OUT
47 D8 PTD8 I2C0_SCL LPUART0_RX FB_A16
48 D9 PTD9 I2C0_SDA LPUART0_TX FB_A17
49 B4 A1_10 PTB4 ENET0_1588_TMR2 SDRAM_CS1-b FTM1_FLT0
50 B5 A1_11 PTB5 ENET0_1588_TMR3 FTM2_FLT0
51 D14 PTD14 SPI2_SIN SDHC0_D6 FB_A22
52 D13 PTD13 SPI2_SOUT SDHC0_D5 FB_A21
53 D12 PTD12 SPI2_SCK FTM3_FLT0 SDHC0_D4 FB_A20
54 D15 PTD15 SPI2_PCS1 SDHC0_D7 FB_A23
55 D11 PTD11 SPI2_PCS0 SDHC0_CLKIN LPUART0_CTS_b FB_A19
56 E10 PTE10 I2C3_SDA I2S0_TXD0 LPUART0_CTS_b FTM3_CH5 USB1_ID
57 E11 PTE11 I2C3_SCL I2S0_TX_FS LPUART0_RTS_b FTM3_CH6And the Cardish might look something like:
Code:
Pin ADC Ser PWM SPI I2C CAN Touch I2S Eth Port
40 TXER A28
41 COL A29
42 TXD3 A26
43 CS2-0 B20
44 MOSI2 B22
45 MISO2/CS0-5 B23
46 SCK2 B21
47 RX6 SCL0 D8
48 TX6 SDA0 D9
49 A? B4
50 A? B5
51 MISO2 D14
52 MOSI2 D13
53 SCK2 D12
54 CS2-1 D15
55 CS2-0 D11
56 SDA3 txd0 E10
57 SCL3 lrclk E11I am also playing around with trying to setup footprint and the like for Diptrace.
Warning, When I put up things like CS, I have additional information like which CS, as you can only use 1 of each duplicate pin.
Again Paul, when it is OK I will post this document as well
The only problem I have is post #3 and #8 and even your post conflict on some of the pin features. Making it hard to tell what is right or wrong.
KurtE
Senior Member+
As Paul said in another post, The code wins!
If you look at the file https://github.com/PaulStoffregen/cores/blob/master/teensy3/core_pins.h Starting at about line 732 you will see the tables that define which pin is which. The new part
Code:
#define CORE_PIN40_BIT 28
#define CORE_PIN41_BIT 29
#define CORE_PIN42_BIT 26
#define CORE_PIN43_BIT 20
#define CORE_PIN44_BIT 22
#define CORE_PIN45_BIT 23
#define CORE_PIN46_BIT 21
#define CORE_PIN47_BIT 8
#define CORE_PIN48_BIT 9
#define CORE_PIN49_BIT 4
#define CORE_PIN50_BIT 5
#define CORE_PIN51_BIT 14
#define CORE_PIN52_BIT 13
#define CORE_PIN53_BIT 12
#define CORE_PIN54_BIT 15
#define CORE_PIN55_BIT 11
#define CORE_PIN56_BIT 10
#define CORE_PIN57_BIT 11
Code:
#define CORE_PIN40_PORTREG GPIOA_PDOR
#define CORE_PIN41_PORTREG GPIOA_PDOR
#define CORE_PIN42_PORTREG GPIOA_PDOR
#define CORE_PIN43_PORTREG GPIOB_PDOR
#define CORE_PIN44_PORTREG GPIOB_PDOR
#define CORE_PIN45_PORTREG GPIOB_PDOR
#define CORE_PIN46_PORTREG GPIOB_PDOR
#define CORE_PIN47_PORTREG GPIOD_PDOR
#define CORE_PIN48_PORTREG GPIOD_PDOR
#define CORE_PIN49_PORTREG GPIOB_PDOR
#define CORE_PIN50_PORTREG GPIOB_PDOR
#define CORE_PIN51_PORTREG GPIOD_PDOR
#define CORE_PIN52_PORTREG GPIOD_PDOR
#define CORE_PIN53_PORTREG GPIOD_PDOR
#define CORE_PIN54_PORTREG GPIOD_PDOR
#define CORE_PIN55_PORTREG GPIOD_PDOR
#define CORE_PIN56_PORTREG GPIOE_PDOR
#define CORE_PIN57_PORTREG GPIOE_PDOR(A29, A29, A26.....)
Then look at the K66 reference manual for the Port MUX table to get the rest of the information...
PaulStoffregen
Well-known member
When you get your round 3 board, you'll see all the pin numbers are labeled on the bottom side, pretty similar to how Teensy 3.2 looks.
After the Kickstarter is live pictures will become ok. Please keep holding off any pics or diagrams until then. I know it's inconvenient, but please hold out just a little longer. It's only a matter of days at this point....
After the Kickstarter is live pictures will become ok. Please keep holding off any pics or diagrams until then. I know it's inconvenient, but please hold out just a little longer. It's only a matter of days at this point....
defragster
Senior Member+
Post_3 is early stuff - p_8 should link the current - KurtE's bottom pins by the book tables and PJRC code as he notes for Alternate functions and should be supported in hardware. I'll link Kurt's latest to the pin ref list - and wait for updates.
<edit>
Updated post_8 to link the Round 3 bottom pins as shown in p_1035
Paul - does the noted serial # USB reporting code actually work on the T_3.6 boards? From your note that code needs to be run early before HSRUN is active and using a 64 bit read scheme? I glanced and the FM.pdf and missed locating the detail for that in the time I had.
<edit>
Updated post_8 to link the Round 3 bottom pins as shown in p_1035
Paul - does the noted serial # USB reporting code actually work on the T_3.6 boards? From your note that code needs to be run early before HSRUN is active and using a 64 bit read scheme? I glanced and the FM.pdf and missed locating the detail for that in the time I had.
Last edited:
TelephoneBill
Well-known member
Intriguing... what value fcpu freq was that running at?
bicycleguy
Well-known member
Is anybody working on the dual CAN_bus?
I see teachop the developer of the FlexCAN_Library's was on the original list of testers but as far as I can tell he hasn't been on the FLEXCAN git for 2 years.
Note: please use the word CAN_bus instead of just CAN because you can't search for just CAN on this site which is a real pain.
I see teachop the developer of the FlexCAN_Library's was on the original list of testers but as far as I can tell he hasn't been on the FLEXCAN git for 2 years.
Note: please use the word CAN_bus instead of just CAN because you can't search for just CAN on this site which is a real pain.
Last edited:
For T3.2, up to 144MHz
I played with f_bus=f_cpu on K66 too, but ..lol.. i don't remember..
edit: K66: just tested again (but with "blink" only) .. works up to 216 MHZ
Last edited:
KurtE
Senior Member+
Just for the fun of it I played around some with FTM1. In particular I hacked up a copy of PulsePosition library, to use FTM1 instead. Some of the things I have needed to do include:
Make sure to enable the right SIM_SOPT or you will fault touching any of the registers: SIM_SCGC2 |= SIM_SCGC2_TPM1;
Figure out how to setup the right stuff to enable the IRQs and which bits do you need to clear in the ISR so you don't spin and die....
Need to defer calculating things like loop counts per US or the like and not do as part of constructor as unsure if this will be done after the actual Timer is configured in system setup code. Using the PLL/FLL timer like LPUART, so which actual timer depends on selected CPU speed.
I made a copy of the loopback test that is starting to limp along. I made the "library" files as tabs as part of the sketch, such that it is easier to simply debug the code with editing in one place.
Anyway in case anyone is interested in the WIP I include a zip file of the sketch/library
Edit: I will probably play around with it some more and maybe allow it to work on TPM2 as well (pins 29 and 30).
Also I made this specific to this board, but may also be possible to add similar support for TLC
Last edited:
KurtE
Senior Member+
I am still playing around some with the TPM code. Was seeing how hard it would be to make it work with both TPM1 which has pins: Channel 0: 3 and 16 and Channel 1: 4 and 17
On TPM2 we have Channel 0: pin 29 and Channel 1: pin 30
Couple of notes/questions:
1) This will only work with T3.6 as T3.5 does not have TPM clocks...
2) Wondering about proper strategies for setting up interrupts here and actually more global. That is if a library such as this can use either tpm1_isr and/or tpm2_isr, is it best to continue code in the actual name here and have it set it self as the ISR for that interrupt even though I may only use one of them. Or should the code, use attachInterruptVector and only install the ones it actually uses.
My guess is the later. As maybe I want different library that uses one of these for PWM or ...
3) Also wondering globally, about doing code like: SIM_SCGC2 |= SIM_SCGC2_TPM2; // Enable the clock
Should we define some form of setup to use bitband setting of these values to make them atomic?
Kurt
On TPM2 we have Channel 0: pin 29 and Channel 1: pin 30
Couple of notes/questions:
1) This will only work with T3.6 as T3.5 does not have TPM clocks...
2) Wondering about proper strategies for setting up interrupts here and actually more global. That is if a library such as this can use either tpm1_isr and/or tpm2_isr, is it best to continue code in the actual name here and have it set it self as the ISR for that interrupt even though I may only use one of them. Or should the code, use attachInterruptVector and only install the ones it actually uses.
My guess is the later. As maybe I want different library that uses one of these for PWM or ...
3) Also wondering globally, about doing code like: SIM_SCGC2 |= SIM_SCGC2_TPM2; // Enable the clock
Should we define some form of setup to use bitband setting of these values to make them atomic?
Kurt
Well, we could probably come up with a function that does that - but is it necessary? Without having had a closer look at when exactly these flags are manipulated in a read-modify-write fashion, I'd guess that this is taking place when no ISR would modify them at the same time.
Regardless of the usefulness of such a function it seems that the destination register is in the 1 MB peripheral region at 0x40000000 ... 0x400FFFFF which is aliased to the 32 MB alias region at 0x42000000 ... 0x43FFFFFF (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDBIJJE.html), so it should be possible to use bit banding in this case.
Last edited:
Also, we had bit-banding before:
https://forum.pjrc.com/threads/31795-DMA-Scatter-gather-and-DMA-mux?p=89696&viewfull=1#post89696
and
https://forum.pjrc.com/threads/31795-DMA-Scatter-gather-and-DMA-mux?p=89733&viewfull=1#post89733
(same thread, two posts)
https://forum.pjrc.com/threads/31795-DMA-Scatter-gather-and-DMA-mux?p=89696&viewfull=1#post89696
and
https://forum.pjrc.com/threads/31795-DMA-Scatter-gather-and-DMA-mux?p=89733&viewfull=1#post89733
(same thread, two posts)
KurtE
Senior Member+
Thanks Chrisoph,
I sort of brought it up again, as earlier today I updated (Rebased) my probably never to be pulled in changes to allow SDCard pins to be used in both Core and SPI projects. And again touched serial2.c and serial4.c and all of these files have comments like:
Again not sure how many are interested, but I did get the TPM code that does the same stuff as PulsePosition to work now both with TPM1 and TPM2. Also uses attachInterruptVector.
That is probably all I will do with it for now, but appears to work.
I sort of brought it up again, as earlier today I updated (Rebased) my probably never to be pulled in changes to allow SDCard pins to be used in both Core and SPI projects. And again touched serial2.c and serial4.c and all of these files have comments like:
Code:
void serial_begin(uint32_t divisor)
{
SIM_SCGC4 |= SIM_SCGC4_UART0; // turn on clock, TODO: use bitband
...Again not sure how many are interested, but I did get the TPM code that does the same stuff as PulsePosition to work now both with TPM1 and TPM2. Also uses attachInterruptVector.
That is probably all I will do with it for now, but appears to work.
el_supremo
Well-known member
Arduino 1.6.10, TD 1.30b2
I've run into a problem when uploading a large chunk of code to the K66. In the latest incarnation of the vocoder, instead of storing just one sample loop, I have declared all eleven of them to be const so that they are stored in program memory. The IDE reports this for sketch size:
However, it won't upload properly. Teensyduino goes through the upload process and appears to complete but then the serial port disappears and I have to run Blink to get it back again. It will load if I remove enough loops to get the sketch size below 512kB but the K66 ought to handle up to a megabyte.
Is this a TD problem or mea culpa?
I've attached the version of the vocoder giving problems. View attachment vocoder_16rec_9fx_SF_6_rectify.zip
It is set so that it will upload by commenting loops 7 and 10 in loops.cpp. Uncommenting either of those pushes it over the limit and it won't execute.
The code only uses a microphone on the audio board and outputs to headphones so it shouldn't be too difficult to test - check that the micGain is right (I use a gain of zero for a MEMS microphone but you might need to set it to 30 or so for other microphone types). You can switch from one loop to the next by grounding pin 28.
Pete
I've run into a problem when uploading a large chunk of code to the K66. In the latest incarnation of the vocoder, instead of storing just one sample loop, I have declared all eleven of them to be const so that they are stored in program memory. The IDE reports this for sketch size:
Code:
Sketch uses 617,860 bytes (58%) of program storage space. Maximum is 1,048,576 bytes.
Global variables use 51,216 bytes (19%) of dynamic memory, leaving 210,928 bytes for local variables. Maximum is 262,144 bytes.Is this a TD problem or mea culpa?
I've attached the version of the vocoder giving problems. View attachment vocoder_16rec_9fx_SF_6_rectify.zip
It is set so that it will upload by commenting loops 7 and 10 in loops.cpp. Uncommenting either of those pushes it over the limit and it won't execute.
The code only uses a microphone on the audio board and outputs to headphones so it shouldn't be too difficult to test - check that the micGain is right (I use a gain of zero for a MEMS microphone but you might need to set it to 30 or so for other microphone types). You can switch from one loop to the next by grounding pin 28.
Pete
KurtE
Senior Member+
For what it is worth, I downloaded it, built it at 180mhz... It installed, I uncommented the two loops and built again:
Code:
Using library Bounce in folder: C:\arduino-1.6.10\hardware\teensy\avr\libraries\Bounce (legacy)
Sketch uses 617,828 bytes (58%) of program storage space. Maximum is 1,048,576 bytes.
Global variables use 51,024 bytes (19%) of dynamic memory, leaving 211,120 bytes for local variables. Maximum is 262,144 bytes.
Code:
C:\Users\Kurt\Desktop\vocoder_16rec_9fx_SF_6_rectify\vocoder_16rec_9fx_SF_6_rectify.ino
F_CPU = 180 MHzRunning 1.6.10... Beta2... On First round T3.6 beta board.
el_supremo
Well-known member
Thanks for trying it Kurt. Did it run properly when the code size was over 512kB?
You should see this sort of thing if it starts up properly:
I'm also using the first round T3.6/K66. I'm running the sketch at 180MHz.
Pete
You should see this sort of thing if it starts up properly:
Code:
C:\Users\Peter\Documents\Teensy\my_audio\k66\vocoder\vocoder_16rec_9fx_SF_6_rectify\vocoder_16rec_9fx_SF_6_rectify.ino
F_CPU = 180 MHz
Found 10 loops
Loop = CARRIER22
setup done
CASCADE_2
bp_base = 100.0, bp_width = 400.0
mixer18_gain = 4.0, mixera_gain = 3.0
Using MICROPHONE input
Proc = 55.79 (55.79), Mem = 25 (29)I'm also using the first round T3.6/K66. I'm running the sketch at 180MHz.
Pete
- Status