64 pin MCU upgrade to 80 pin

Status
Not open for further replies.
X

Xenoamor

Well-known member
Hi guys!

I've been hoping to stick with these chips for a while but have realised I I've ran out of I/O on the Teensy's MCU. As well as needing both SPI0/1.

Is the MK20DX256VLK10 80Pin package HEX compatiable with the sourcecode generated by Teensyduino?

Thanks,
 
Xenoamor said:
Is the MK20DX256VLK10 80Pin package HEX compatiable with the sourcecode generated by Teensyduino?
Click to expand...

Whenever a similar question has come up in the past, Pauls answer was basically, 'no'. The issue is that every chip has very specific properties that the makefiles have to take into account. So unless Paul supports it officially, I would not expect Teensyduino to support it. That said, you may very well achieve the same effect at lower cost with a mux/demux chip add-on to a Teensy. Or use a LC chip as a IO expander and talk to it via EasyTransfer I2C.
 
Thanks for the feedback Constantin.
I've been skimming through the header files for the two chips and can confirm that the PORT, SIM, SMC and SPI memory locations are the same.
Obviously I'm not going to go through all 14000 lines of it but if there's going to be a descrepency I imagine it would be in the clock speeds so I'll have a rummage around there

I unfortunately don't have the luxury of mux or demuxing as I need very fast parallel port writing/reading. The 80pin package is actually the same price as the 64 pin one so it's kind of a no brainer
 
AFAIK the mini54 will not program any but the chips used in the teensys. If you hoped to use the mini54 for programming, this won't work. You'll need a different way of downloading the hex file.
 
Well, I'd try it and see, if you have the hardware (i.e. Segger link, toolchain, etc.) set up. For me, the whole point of Teensy is the ease with which it can be set up and run. Getting a rig working that goes down to bare metal is (IMO) more trouble than it's worth. For a single-chip solution, I'd look at using the DUE chip, that thing is ginormous and has copious I/O, is supported, and so on. More importantly, with the help of VisualStudio and Visual Micro, you can dive into that thing as deep as you want (incl. debugging via SWD with Visual GDB) without having to go super exotic. Atmel ships a SAM version of VisualStudio with all those boards/chip built in.
 
I'll give it a whirl yeah. I don't mind rewriting things using the kinetis header they supply if need be. This is actually for a commercial project. It's not really good practice but we're on a unit budget so the K20 chips are more preferable as they can be heavily overclocked. I need both the I/O and high clock speed. I could perhaps shift a lot of this over to the CPLD I have on the board though.

I've actually been using Visual Micro in Atmel Studio since I started with Teensy. I came from a heavy AVR background so it seemed like the logical thing to do. If I do have to step away from the teensyduino library though, I'll probably use sublime and makefiles on Linux. Windows handles serial communication rather awkwardly.
 
Status
Not open for further replies.
Back
Top