Tale of my 1st Teensy 3.2 (questions which's answers helps the maidens)

Status
Not open for further replies.

10sy

Member
I'm not too skilled in electronics (I'm a programmer), but I started to build a custom keyboard based on Teensy 3.2. In the following tale here are 4 questions:

Pre-face:

- First I played a bit whith "the blinky example" successfully :) Then I soldered the crystal for RTC because I think it is better to do it before the headers. (yes, my keyboard will know the time...)
- After that Teensy can't goes into bootloader. I searched the forums and I tried to press "the button" right after powerup; holding button when power-on; double-click; etc. 1:10 times I successfully entered into bootloader. Total chaos...
- I tried out Teensy on another PC and was much better.
- When I brought back Teensy to my PC I did realized that I did used it on an USB-extender, so maybe that was the problem. OK, I hooked-up Teensy directly to my PC.
- After a while Teensy worked again - hurray!

I just wrote down this to be correct. The adventures continued:

- Then I made a small circuit with an additional MPC23S17 and tried to communicate with a GPIO pin as input without success :(
- Then I tried to test the pin as output - but a wire (the MPC23S17 output pin or the GND wire) unfortunately got under the PCB (and possibly contacted with any pin).
- Teensy did not flashing it's LED anymore...

- Of course I detached Teensy from the board and next day I powered it up and it did a few blinks and then halted.
- Next day I powered-up Teensy and it did a few blink and then halted.
- 2 days later Teensy worked 2 times more - then halted.
- Then I gave 4-5 days resting - moreover I shorted USB 5V to GND for several seconds then 3.3V to GND (let flush static charge). And then, Teensy blinked for several hours ; a half a day; and it works even now (!)

(Q1) So, what do You think about this symptom? Seems a big condensator inside that tiny Teensy? I'm not an expert, maybe it's absolute natural (?)

- Meantime I figured out that unfortunately I took shit on _reset line of MPC23S17... I fixed it and started to continue with the custom keyboard: SPI communication worked with the original MPC23S17, hurray! (even I used the alternative SPI ports)
- But seems INPUT_PULLUP pins 21,19,15 reads random LO/HIGH values (I used pin 20 as CS for MPC23S17). Used as OUTPUT they _works_.

(Q2) So, seems the shortcut I made damaged pins around 20 _as_input_, however as output they works - is this possible?

(Q3) I'm not dug into Teensy SPI deeply, but I not really understand why we can't using _any_ pin as CS? It is a HW "limit"?

(Q4) What the exact mechanism is behind this "Press Verify first time and press Upload afterwards" seen on Teensydoino install? (as a novice I think I pushed the first button I saw :D - no, not really, I just kidding. However not clear for me why can't press "Upload" first time?)

So, many thanks if You read all these long lines!

-Ati
 
you can use any pin as CS, the library your using for the MCP23S17 can digitalwrite/read any pin provided on teensy. What voltage you running the MCP23S17? what library your using? The reset line of the MCP23S17 should be tied high, either directly or with a pullup resistor always.
 
The on chip SPI hardware has access to the pins as shown on the reference card and with a carefully optimised library and multiple SPI devices it is theoretically faster to use those pins.

Since The Atmega 328 only has very limited hardware CS, and they are often needed for other things most Arduino libraries support software chip select for any GPI capable pin, the better written ones will actually use the hardware if availible and otherwise fall through to GPIO. Since chip select is set at the start of a message and (maybe) unset at the end the slowdown is minimal over the hardware doing it (couple of extra CPU cycles per message series sent).

Unless the library is very poorly designed (sets/unsets CS per byte) or you are trying to do something that requires moving data between SPI devices suggest not getting too deep.

If unsure what the library does putting an LED on the pin, or using a scope will indicate activity and possibly if things are amiss (left on while another device is using SPI for example/never activated).
 
I also feel that there is no HW limit on CS but then why PJRC docs shows CS only on specific pins?

For some libraries there is indeed a hardware limit. It really depends on how the library code is designed. The pins can be accessed by a special hardware mechanism where the SPI port controls them, or they can be accessed as ordinary digital output pins. When a library uses the first method, only specific pins are compatible.

The direct SPI control of the CS pin can give a tremendous speed boost in certain cases. ILI9341_t3 is one of the best examples. But in many other cases it gives little if any performance improvement. It costs quite a lot of extra complexity and hardware dependency within the code, as well as limiting you to only certain pins, so this method is only used by a small but important set of libraries where the performance matters.

Explaining these sorts of deeper details isn't feasible on such a small reference card. Adding more info & detail tends to also dilute everything else. So we try to give everyone the best info we can with the cards, but it's a trade-off against detail versus simplicity. Advising people to use those specific pins is the best advice that gives compatibility with all libraries, even though many (but not all) of them can use more pins.
 
Status
Not open for further replies.
Back
Top