K66 Beta Test
- Thread starter Paul
- Start date
- Status
Exciting news, here is the list of things I'd like to do:
1. General beta testing (i.e. responding when someone says 'can someone else check this works?'). I've got time for this.
2. Get the 1588 hardware timestamping working, perhaps then porting an existing 1588 library implementation to use the K66 driver. Paul can then fork this on Github and clean it up to his standard.
3. Beta test the IP stack Paul decides to use. Hopefully there is a reference Kinetis SDK stack with 1588 API methods in it already. I can imagine it'll be a few months before this is working.
4. Use the additional memory to finish my 128x128 OLED graphics driver (this keeps a framebuffer in memory, sent via DMA SPI, and can apply any screen rotation with decent anti-aliasing rather than being limited to 0/90/180/270, great for use with the Prop shield)
For anyone wondering what 1588 will give you:
- Multiple teensy on an Ethernet network that will very tightly synchronise an internal timer to each other, allowing you to issue commands like 'All Teensy - Set this pin high (i.e. trigger an interrupt) at exactly 09:00:00.000 tomorrow' and they'll all do it to within a few microseconds of each other.
- Multiple teensy on an Ethernet network can monitor inputs and upon a change, generate a very high resolution timestamp that is synchronised to GPS time, using only 1 GPS receiver on the network.
1. General beta testing (i.e. responding when someone says 'can someone else check this works?'). I've got time for this.
2. Get the 1588 hardware timestamping working, perhaps then porting an existing 1588 library implementation to use the K66 driver. Paul can then fork this on Github and clean it up to his standard.
3. Beta test the IP stack Paul decides to use. Hopefully there is a reference Kinetis SDK stack with 1588 API methods in it already. I can imagine it'll be a few months before this is working.
4. Use the additional memory to finish my 128x128 OLED graphics driver (this keeps a framebuffer in memory, sent via DMA SPI, and can apply any screen rotation with decent anti-aliasing rather than being limited to 0/90/180/270, great for use with the Prop shield)
For anyone wondering what 1588 will give you:
- Multiple teensy on an Ethernet network that will very tightly synchronise an internal timer to each other, allowing you to issue commands like 'All Teensy - Set this pin high (i.e. trigger an interrupt) at exactly 09:00:00.000 tomorrow' and they'll all do it to within a few microseconds of each other.
- Multiple teensy on an Ethernet network can monitor inputs and upon a change, generate a very high resolution timestamp that is synchronised to GPS time, using only 1 GPS receiver on the network.
defragster
Senior Member+
Looks like 35 instances there - I can test and do a pull request for those as that is one of the displays (multi with 3?) I'll want to plug in when Beta_K66 shows up.
They all seem to be simple T_3.2 usage that should be 1::1 with K66/K64 at least until their alternate SPI may come into play. Only hard part will be knowing what to call it in the comment
I still see T_3.4 and T_3.6 as most usable as those #defines grow:
Code:
#elif defined(__MK20DX128__) || defined(__MK20DX256__ || defined(__MK6[B]4[/B]FX512__ || defined(__MK6[B]6[/B]FX1M0__)//(arm) Teensy 3.0, 3.1, 3.2, 3.[B]4[/B], 3.[B]6[/B]
if ((_mosi == 11 || _mosi == 7) && (_sclk == 13 || _sclk == 14)) {
SPI.setMOSI(_mosi);
// ...<edit>: "#if defined(KINETISK)" could work here too and catch all four of those if it will work to clarify SPI hardware as needed?
Last edited:
Oh, i have something similar for my C64 Emulation (ili9341) - currently DMA for single lines , but i change it to "Full Screen DMA" when i have the beta-board..
manitou
Senior Member+
IRremote:
I think IRremote will work with addition of the K66 (and K64) conditionals in IRremoteInt.h probably in the zip file described in
https://www.pjrc.com/teensy/td_libs_IRremote.html
but Paul also has an out-of-date? repository at https://github.com/PaulStoffregen/Arduino-IRremote
and then there is the master repository https://github.com/z3t0/Arduino-IRremote
KurtE
Senior Member+
Wonder if many of the #ifdef looking for the processors, can be handled by some of the more generic ones like:
or in some cases like just looking at __arm__
I see several cases in the current release with these types of testing and it sure looks better than something like:
It will be interesting.
Paul: Do you have a list of things showing what has been ported/tested/working?
Also I assume somethings may be done in stages. Example USART support. Make sure current stuff works like other T3s, but then there may be new functionality like the Transceiver Driver using RTS that may be interesting to take advantage of.
Code:
#if defined(__arm__) && defined(CORE_TEENSY)I see several cases in the current release with these types of testing and it sure looks better than something like:
Code:
#elif defined(__MK20DX128__) || defined(__MK20DX256__ || defined(__MK64FX512__ || defined(__MK66FX1M0__)//(arm) Teensy 3.0, 3.1, 3.2, 3.4, 3.6Paul: Do you have a list of things showing what has been ported/tested/working?
Also I assume somethings may be done in stages. Example USART support. Make sure current stuff works like other T3s, but then there may be new functionality like the Transceiver Driver using RTS that may be interesting to take advantage of.
There are already existing defines like KINETISL (Teensy LC) and KINETISK (other Teensy 3.x)
Which to use depends on the use-case and what Pauls plans for the future are.. for FastCRC I tend to use KINETISK (is that ok Paul?), but for other purposes..(like SPI2) this is not possible..
Which to use depends on the use-case and what Pauls plans for the future are.. for FastCRC I tend to use KINETISK (is that ok Paul?), but for other purposes..(like SPI2) this is not possible..
Last edited:
defragster
Senior Member+
Indeed you did:
"The set of implemented algorithms provides excellent support for network security
standards, such as SSL and IPsec. Additionally, using the CAU efficiently permits the
implementation of any higher level functions or modes of operation, such as HMAC,
CBC, and so on based on the supported algorithms"
PaulStoffregen
Well-known member
Either is fine.
Eventually I want to expand the HAS_KINETISK_XYZ defines. One should probably exist to tell whether the CRC peripheral is present. For now, all KINETISK chips have it.
Not yet....
Like so many things, it is both amazing and underwhelming, depending on how you look at it. My understand so far is it's a small compute engine with with own (not so well documented) assembly-like language. It doesn't actually do all the work of a cipher, just the heavy lifting of the "rounds" some. Compiled examples exist for popular ciphers. Apparently there's also examples for various types of interpolation of data which can be used for arbitrary sample rate conversion, which is more interesting to me than crypto. I feel it may be quite a while until I can spend serious time fiddling with this hardware.... the SDIO controller is my top priority. The new USB controller and ethernet will also consume my time before I get to play with the CAU.
That's a good idea.
I think ethernet + SSL is most useful, so maybe related? ;D
PaulStoffregen
Well-known member
Here's the pinout info.
Code:
Outside edge pads (counterclockwise)
------------------------------------
Pin ADC Ser PWM SPI I2C CAN Touch I2S Eth Native
--- --- --- --- --- --- --- ----- --- --- ------
GND
0 RX1 MOSI1 TOUCH B16
1 TX1 MISO1 TOUCH B17
2 PWM D0
3 PWM SCL2 TX0 txd0 RXD1 A12
4 PWM SDA2 RX0 lrclk RXD0 A13
5 tx1 PWM D7
6 PWM CS1 D4
7 RX3 PWM mosi0 scl0 D2
8 TX3 PWM miso0 sda0 D3
9 RX2 PWM CS0 BCLK C3
10 TX2 PWM CS0 C4
11 MOSI0 MCLK C6
12 MISO0 C7
3.3V
24 CLK E26
25 bclk RXER A5
26 tx1 txd1 RXDV A14
27 rx1 rxd0 TXEN A15
28 rxd1 TXD0 A16
29 PWM tx0 TOUCH bclk B18
30 PWM rx0 TOUCH lrclk B19
31 A12 RX4 B10
32 A13 TX4 SCK1 B11
33 A14 TX5 scl0 TX1 E24
34 A15 RX5 sda0 RX1 E25
35 A16 PWM mclk C8
36 A17 PWM C9
37 A18 PWM SCL1 C10
38 A19 PWM SDA1 rxd1 C11
39 A20 mclk TXD1 A17
DAC0 A21
DAC1 A22
GND
13 SCK0 RXD0 C5
14 A0 PWM sck0 D1
15 A1 CS0 TOUCH txd1 C0
16 A2 scl0 TOUCH MDIO B0
17 A3 sda0 TOUCH MDC B1
18 A4 SDA0 TOUCH TIMER B3
19 A5 SCL0 TOUCH TIMER B2
20 A6 PWM CS0 D5
21 A7 rx1 PWM CS0 D6
22 A8 PWM TOUCH TXD0 C1
23 A9 PWM TOUCH LRCLK C2
3.3V
AGND
VIN
Interior pads (same location as Teensy LC & 3.2)
-------------
A10
A11
AREF
VUSB
Interior pads (located between pin 27 & 38/A19)
-------------
Reset
Program
GND
3.3V
Vbat
Interior pads (meant for 5 pin header)
-------------
VUSBHOST
Host D-
Host D+
GND
GND
Host Power Enable = PTE6
On-board SD card (decicated 4-bit SDIO)
----------------
DAT2 (PTE5)
DAT3 (PTE4)
CMD (PTE3)
3.3V
CLK (PTE2)
GND
DAT0 (PTE1)
DAT1 (PTE0)
TBD: extra pads if they fit on bottom side
------------------------------------------
Pin ADC Ser PWM SPI I2C CAN Touch I2S Eth Native
--- --- --- --- --- --- --- ----- --- --- ------
GND
DBGEN
SWCLK
SWDAT
54 D15
55 D11
56 SDA3 txd0 E10
57 SCL3 lrclk E11
40 A28
41 A29
42 A26
51 D14
52 D13
53 D12
43 CS2 B20
44 MOSI2 B22
45 MISO2 B23
46 SCK2 B21
GND
3.3V
47 RX6 scl0 D8
48 TX6 sca0 D9
49 A23 TIMER B4
50 A24 TIMER B5
Last edited:
manitou
Senior Member+
If I look at cores/teensy3/touch.c, I don't see that pins 3 and 4 are configured as touch?? Is there a newer touch.c, or ?
PaulStoffregen
Well-known member
PaulStoffregen
Well-known member
Yes, and also on Teensy 3.2. But my #1 focus is on correct software support and compatibility. Especially updating peripheral code for more F_BUS options is a much lower priority.
- Status