K66 Beta Test

Status
Not open for further replies.
manitou** - you just made the post 8 sticky list again - feel free to update that post if it evolves with more details or to 'friendly names'
ADC VREF selection for K66

** - when dropping the post # a link is handier - (right click on the post number) - I scrolled back to page 13 to get that in this case.
 
KurtE said:
... Defragster - Sounds like you did a pretty good test. With my testing, where I used a T3.5 to control it, I only tried as high as 2mbs. Also the max and min bauds it can do will depend on what CPU speed the processor is set to. Which Clock it chooses depends on CPU speed. It uses the PLLFLL stetting which was setup external and it figures out which clock setting from the register.

As for Priority stuff, I simply used the same stuff from the other Serial(x).c code. As I recall the code only bumps the priority if the queue is full and you are trying to output to the queue and it believes that your priority is such that it believes that it's interrupt handler may not be called, when the uart completes sending a character, which would then pull a character or characters out of the queue...
Click to expand...

KurtE - glad the Serial6 test looked good. I'll make a generic #ifdef changeable version allowing for each port of that when I get back to loop through #1-6. That generic version might also make it easy to quickly test with alternate pins and setting other than 'N81'. That sketch just happens to show the _PLL, _CPU, _BUS speeds as it evolved.
 
KurtE said:
Thanks,

I agree a symbolic name might be nice for the special ones. Also wondering if these analog channels are only on the Beta1/2 boards or will also be on the final boards.

Thanks again
Click to expand...
The VREF and temp sensor are not physical pins, but internal analog channels. Same for the two "DAC channels", they are internal paths to the outputs of the DACs
 
manitou said:
The VREF and temp sensor are not physical pins, but internal analog channels. Same for the two "DAC channels", they are internal paths to the outputs of the DACs
Click to expand...
Thanks, found them page 948 of the manual.

Probably don't need/want to do the MUXSEL selection for A/B channel selection here, so the only question on Analog updates for the new chips is maybe adding: Pin 49 and 50

So my Card data for newer and optional pins looks sort of 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									D8
48		TX6									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			E11
										
SDCard Pins:  Using my Pull request										
58	A?	tx1		CS1-1	SDA1						E0
59	A?	rx1		mosi1/miso1	SCL1					E1
60	A?			sck1								E2
61	A?			miso1/mosi1						E3
62		rx3		CS1-0							E4
63		tx3		cS1-2							E5
Sorry, things don't fully align in the above. Also is hurt as some of the SPI pins can actually do two different SPI functions, depending on Alternate. Example on 45, it can be MISO on SPI2 or it is a CS pin for SPI0

Probably all for now.
 
Last edited:
Single port Serial Loop back test

Updated my Serial_Test for single port loopback. Top line is : #define DO_SERIAL_6
Pick the device supported Serial number for the last digit to test and put a jumper across those pins Tx->Rx and #ifdef's do the rest, except adjusting the baud rate.
Very boring start it slowly prints letters. USB Enter 't' for turbo and it drops the wait to send the next character - min wait is 4ms. It you take this too fast before upping the character padding between letters it seems to stall as the routing through USB waits for full buffers. LED_BUILTIN toggles on each character.

To add padding in groups of 10 then USB Enter 'w' and the inter letter spacing widens. If something looks odd Enter 'r' to reset those t&w numbers to start fresh.

The PAD characters alternate after each letter group '!' or '|' when you see a newline - at the start of each readBytes I look for one of those chars and if I see it as [0], it gets replaced with single quote char so you can see the transfer group size. The pad characters are printed in groups of 10 from a string.

I only tested at 240MHz - and 2Mbaud is good for over 50K chars/sec (with 200 wide pad) with Tx chars hitting Rx on same port the getting pulled and shipped out USB to view. At 6Mbaud it seems to be okay at 105K cps. I compiled for all 6, but only tested on 1 and 6. To test alternate pins would take adding the code in setup after: SERIAL_TEST.begin(sharedBaud); I just saw Serial6 working some at 8Mbaud - but I assume the USB overhead to PC was stalling it?

Single Serial port loopback test: View attachment Serial_Test.ino
 
defragster: Sounds great. As I mentioned may want to test at different MHZ as for at least Serial6, it uses different PLL/FLL clocks depending on CPU speed. This is setup external to this code in mk20dx128.c around like 1050 when it sets SIM_SOPT2.

Paul: Earlier today I issued a separate Pull Request: https://github.com/PaulStoffregen/cores/pull/162
So you can get the Serial2 fix (.end() updates the actual TX/RX pins used not always 9/10) and Serial4.setTX, checks UART3 instead of UART2. So you can pick up these changes independent of the changes to allow SDCard pins...
 
F_CPU start at 240 MHz on Serial6 dropping to each lower speed. May as well test a few Baud Rates - Quick mod to my code below allows starting at higher rate and closing and restarting at a lowered rate. 8 MBaud worked at 240, but not 216 so starting tests at 4 MBaud.

> Initial string on USB of "ttwwttwww" gets to 5790 cps with 9 ms delay and 50 pads chars between letters. Then watch it work**,
> Enter 'd' and repeat a few times - testing down toward 200 Kbaud (takes 19 "d" steps of baud rate down), then recompile at slower speed::
> "Y" Means the display looked right as for the indicated F_CPU speed and baud as noted
> <edit>: Note in all cases the baud rate seemed properly specified - and some chars transmitted - but not usably at the tested 5790 cps! {although loopback function just says Rx and Tx agree}

Code: 
240: Y, 8M & below, tested down to 200,000 baud
216: Y, 4M & below, at 5790 cps 'ttwwttwww'
192: Y, ... {... means same as above}
180: Y, ...
168: Y, ...
144: Y, ...
120: Y, ...
 96: Y, 2M & below
 72: Y, ...
 48: Y, 1333333 & below
 24: Y, 800000 & below { worked down to 80000 baud }

NOTE: The buffer start char "replaced with single quote char" I added is very telling where the processor speed servicing exceeds the baud rate and only one character comes in per loop().
NOTE: baud rate digression tested is :: 4000000, 2000000, 1333333, 1000000, 800000, 666666, 571428, 500000, 444444, 400000, 363636, 333333, 307692, 285714, 266666, 250000, 235294, 222222, 210526, 200000

Code: 
      case 'd':
        SERIAL_TEST.flush();
        Serial.flush();
        bauddiv++;
        SERIAL_TEST.end();
        SERIAL_TEST.begin(sharedBaud / bauddiv);
        Serial.print( "\n\n--->>>>>>>    Baud Rate DROPPED =");   Serial.println( sharedBaud / bauddiv );
        delay(300);
        break;

Broken output like: ** anything like this defines 'does not work' - though lower cps may work
millis> 5A||||||||||||||||||||||||||||||||||||||||||||||||||B| {...}

Good output like: { note buffered chars between ' : baud faster than CPU }
A!!!!!!!!!!!!!!!!!!!'!!!!!!!!!!'!!!!!'!!!'!!!'!!'!!B!! { ... }
millis> 234 cps= 5790.60

Good output like: { note one character per buffer read : baud slower than CPU }
A''''''''''''''''''''''''''''''''''''''''''''''''''B''''''''' {...}
millis> 234 cps= 5790.60
Click to expand...
 
Last edited:
My Board has arrived! Thank you!

I'll marrying up an audio board and testing raw processing power capabilities shortly.....

I'm going to start with a 16 channel principle of 16 * 44khz audio streams, and take it from there.
 
Paul: Is there an updated Boards.txt for the new Beta Teensyduino? For now I will probably use the last one you posted. But was wondering if there was one that was updated for Teensy 3.5 and Teensy 3.6.

Thanks
 
Hi hw999,

My guess is we might have better luck on this board, as the UARTS appear to have a setting for 1 or 2 bit stops.
Whereas bit 5 of the UARTx.BDH register is defined as a 0 for the Teensy 3.2 processor.

The new processor shows this bit as the field SBNS: Stop Bit Number Select (0=1, 1=2). This is likewise defined in the LPUART (Serial6) as bit 13 in the BAUD register.

So far I have not tried it out to see how well it works...
 
I have run into a weird problem while using the k66 and I can't find any mention of it on the forum. It has only occurred twice but it is potentially a big problem.
When I compile a usbMIDI sketch for the K66, just after it has uploaded, something goes berserk and starts generating vast numbers of pairs of processes named teensy_gateway.exe and conhost. The only solution in both cases was a reboot. With only two cases, it's hard to say what else is relevant. I was also using MIDI-Ox and I think that it was already open both times and had had the previous sketch's midi port open. Perhaps there's an interaction between the new sketch's midi port opening and something in MIDI-Ox? Or not.

Windows 7 Pro x64. Arduino 1.6.10 and TD 1.30-beta1 with the latest boards.txt.

Pete
 
HW999, Paul:

Serial Parity, Stop Bits, 7-8-9-10 bit...

I started looking at how the Serialx.begin(baud, format), on how the different formats are handled and what comes out of the IO pins. For the most part this is something I never worry about, as everything I use, is normally 8N1...

However thought I would take a look and see if my Logic Analyzer likes the data stream for the different parity, character bits. It didn't with several of them, example 8E1 or 8N1, the 9th (Parity) bit was stuck as a 1, so there were lots of parity errors. Currently I am only playing with the Serial4 code as it is common with the other SerialX objects (except 6), but only the beta boards have Serial4... Looks like by default the 0x40 bit of Serial4_C3 is stuck (initialized) as a 1, so always outputs HIGH. Setting C3 to 0 in the format code, appears to fix it, such that the calculated parity bit is output in this mode.

I think maybe I need to try some of the other Serial objects on T3.2 to see if similar issue.

As for 1 versus 2 stop bits, wondering if it makes sense to maybe change the format bits, in particular:
Code: 
// bit0: parity, 0=even, 1=odd
// bit1: parity, 0=disable, 1=enable
// bit2: mode, 1=9bit, 0=8bit
// bit3: mode10: 1=10bit, 0=8bit
// bit4: rxinv, 0=normal, 1=inverted
// bit5: txinv, 0=normal, 1=inverted
// bit6: unused
// bit7: actual data goes into 9th bit (only in optional #ifdefed out)
That Currently 2 stop bits is encoded into bit 2, wonder if it could be in it's own bit, as we actually have 32 bits to pass. For my playing/testing of things like 8E2, I did define bit 8 as number of stop bits. I currently still special case if: format & 0x0f == 4 as 8N2, but wondering if it would hurt anything to instead define it as 0x100
Code: 
#define SERIAL_8N2 0x0100

Now to test T3.2 to see what it generates.

Update: Testing on T3.2 8E1 and 8O1 appear to work without change
Likewise it appears to work on T3.6 on Serial1 without change

Update2: Tested on T3.6 with Serial1, 2, 3, 5 and have not gotten back into the state where the Parity bit was stuck high yet. Maybe the hardware got into some weird state yesterday...
 
Last edited:
KurtE said:
So my Card data for newer and optional pins looks sort of like:
Code: 
[FONT=courier new]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
[COLOR=#ff0000]47        RX6                                    D8
48        TX6                                    D9
[/COLOR]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            E11[/FONT]
Click to expand...

Kurt, this looks to be missing an I2C0 setting on pins 47/48 (ALT2). Specifically from the ref manuals for PTD8/PTD9:

K66:
screenshot.577.jpg

K64:
screenshot.578.jpg

I'm still unclear, are K64 and K66 boards going to be 1:1 pin compatible? Also, pins > 40 are all backside SMT, is that right? (guessing 9x2 grid)
 
nox771: Yes I missed that when I transferred data from my pages 2 and 3 of Excel document.

I believe that at least by source code that they are mapping the same pins.

Note on pins 56/57, The SCL3/SDA3 I believe are only on K66 boards, the K64 does not appear to have I2C3.

Kurt
 
KurtE said:
nox771: Yes I missed that when I transferred data from my pages 2 and 3 of Excel document.

I believe that at least by source code that they are mapping the same pins.

Note on pins 56/57, The SCL3/SDA3 I believe are only on K66 boards, the K64 does not appear to have I2C3.

Kurt
Click to expand...

Yes I'm aware of the Wire3. Thanks for verifying. So I'll recode i2c_t3 so K64/K66 map the same pins (edit: except Wire3 of course), and after that it will compile for K64. BTW - post #8 is out of date on the pin list, it needs to update using your table.
 
Is there a posting that gives the current mappings of the K64/K66 underneath pins? I think I'm about 2-3 revisions behind. It will be nice when this is officially announced, and there will be the official pinout descriptions.

Given there appear differences in K64 and K66, particularly with Serial6 and Wire3, I would hope at KurtE and nox771 could get K64 boards for testing as well before K64 starts shipping.
 
@defragster: I saw your post but my situation seems to be different - thanks. I don't get an error message. I just notice that the system isn't as responsive as it ought to be with 6 cpus. When I check with Task Manager there are dozens of Teensy_gateway and conhost processes and more on the way. I can't kill them fast enough.

@Paul: I should clarify that this also occurred a couple of days ago with the previous Arduino 1.6.9 and TD 1.29 (full release). I'm going to try the same code on a T3.2 to see if it's only the K66 or more widespread. I have only very recently started playing with MIDI and MIDI-Ox so this might have been lurking for quite some time.

Pete
 
MichaelMeissner said:
Is there a posting that gives the current mappings of the K64/K66 underneath pins? I think I'm about 2-3 revisions behind. It will be nice when this is officially announced, and there will be the official pinout descriptions.

Given there appear differences in K64 and K66, particularly with Serial6 and Wire3, I would hope at KurtE and nox771 could get K64 boards for testing as well before K64 starts shipping.
Click to expand...
I don't know if there are any Official updates. Also not sure yet if I can post my excel document here or not, but I just emailed you a copy of it. Hopefully the email address in your web page is correct...

Kurt
 
Hi KurtE

thanks for having a look at the 8E2 serial communication. Trying to solve the problem on my own is beyond my knowledge. Nonetheless your info
is interesting for me anyway.
Good to hear that 8E2 might be implemented in TD. For the time being I run 8E1 with own timing to mimick 8E2 as Paul suggested - seems to work. But it
is a workaround that I don't really like.

Andi
 
el_supremo said:
@defragster: I saw your post but my situation seems to be different
Click to expand...

I only threw that out as a baseline reference in case it starts doing it more often - only once have I ever been aware of teensy_gateway.exe - and I still don't know what purpose it serves or what provoked it. Our cases would have been Win_7 .vs. Win_10 and I wasn't likely doing anything Midi.

hw999 - looks promising for your 8E2 needs, KurtE's the man - I was just giving some test cycles. I'm amazed at how easy and effective serialEvent() processing is for receiving buffered serial data as long as loop() doesn't stall or yield() is called.

I updated the P_8 note on boards.txt and note on TD_1.29 or greater ... any other edits needed?
 
It is looking very likely that the problem lies with MIDI-Ox. Apparently, it doesn't play well with 64-bit Win 7 even when run in Win XP compatibility mode.
I'm writing a midi router of my own to see if I can workaround this.

Pete
 
Status
Not open for further replies.
Back
Top