AltSoftSerial question

[jhendrix]

If I'm using AltSoftSerial on a teensy 3.2/3.6 and I'm only using it as a receiver (using pin 20), can I use pin 21 (normally used for TX) as a digital pin?
I'm using the ILI9341 library and I need all the uarts (so I can't use pins 9 and 10 for the lcd screen).
That leaves pins 15, 20 and 21. If pin 20 is used for RX on the soft uart, is pin 21 also used (even if I don't need to TX with the soft uart).

 

[defragster]

On T_3.2 with the bottom pin 26 you can use Serial2 UART with alternate RX - then specify 31 for TX2 and not use it. This would free 9 and 10 and perhaps remove the need for softSerial?
On T_3.6 there may be enough pins/uarts to use the hardware Serial 4 or 5 directly instead?

 

[KurtE]

As defragster mentioned on T3.6 you have 6 Uarts and many of these have alternate pins that can be used, so hopefully on that board, you can simply use hardware UART.

On the T3.2, it may depend on what all of your other pins are needed/used for. You can also often get away with some cheating. For example if you do Serial2.begin(38400); it will use up Pins 9 and 10 by default. But after this if you never do any output to Serial2, you probably can get away with
doing a pinMode(10, OUTPUT) or INPUT or... Which will change that pin back to mode 1 which is GPIO...

Also the main library ili9341_t3 needs two hardware CS pins to work. My version ili9341_t3n only requires 1, which is used for DC. Which may help or not...

 

[jhendrix]

On my project, I need as many serial ports as I can get. My prototype uses a 3.2 and I have a mux on one of the hardware uarts and SPI pins with a bunch of chip selects to potentially use spi to uart chips.
I'm using the softSerial to decode a 300 baud fsk signal. Since it's so slow, I chose a softSerial for the input to save another hardware uart.
Using the T3.6 give me some more, much needed, uarts. The ili9341 screen will save me a serial port (I was originally going to use a serial LCD screen), and if Paul can get the 2nd USB port to read a USB flash drive, it will save me another serial port (was going to use the FTDI Vdrive).
Good to know about the hardware CS pins, I couldn't figure out why it was locked to those 5 pins.
What changes did you make to ili9341 library to only require 1?

 

[PaulStoffregen]

If I'm using AltSoftSerial on a teensy 3.2/3.6 and I'm only using it as a receiver (using pin 20), can I use pin 21 (normally used for TX) as a digital pin?

Yes, you can. Just use pinMode on pin 21 after AltSoftSerial is running, to return the pin back to GPIO mode.

However, this will not work with analogWrite, which will interfere with the timer AltSoftSerial is using. Only digitalRead & digitalWrite will work.

I need as many serial ports as I can get. My prototype uses a 3.2

Maybe time to step up to Teensy 3.5 or 3.6...

 

[KurtE]

The main ili9341_t3 library requires 2 unique hardware CS pins, one for CS and other DC. When I say unique it is because there are something like 5 or 6 max hardware cs pins (per SPI bus), To use these you encode which one(s) you wish to use when you do a pushr to the SPI. But some of these cs channels may have multiple IO pins that can be used for that channel. So for example if you look at the SPI class you will see a function pinIsChipSelect

uint8_t SPIClass::pinIsChipSelect(uint8_t pin)
{
	switch (pin) {
	  case 10: return 0x01; // PTC4
	  case 2:  return 0x01; // PTD0
	  case 9:  return 0x02; // PTC3
	  case 6:  return 0x02; // PTD4
	  case 20: return 0x04; // PTD5
	  case 23: return 0x04; // PTC2
	  case 21: return 0x08; // PTD6
	  case 22: return 0x08; // PTC1
	  case 15: return 0x10; // PTC0
#if defined(__MK64FX512__) || defined(__MK66FX1M0__)
	  case 26: return 0x01;
	  case 45: return 0x20; // CS5
#endif
	}

    return 0;
}

So pins 9 and 10 work as they map to different bits in the mask. But for example you can not use 21 with 22 as they both map to 0x8

My ili9341_t3n library I did the updates to allow it to work on all three SPI buses of the T3.6. But ran into issue that unless you take over the SDCard pins SPI1 only has 1 cs pin exposed... So I updated the library.

long story short: the ili9341_t3 library gains it speed by encoding both of these pins into the SPI registers. It gains it's biggest speed by allowing you to encode the DC pin into the command and not on the data outputs, such that if a command has something like: <cmd> x1 x2 <cmd> y1 y2 <cmd> color
As one logical command, such as setting a pixel, We can push the first command on with both bits set, then push x1 with just CS set... And not have to wait for the queue to empty to toggle the DC bits. The CS more or less stays set for the whole logical output. So really did not lose much by having the ability to simply do a digitalWrite(CS, LOW) at the start and HIGH at the end and simply encode the DC...

My changes are up in my github/kurte/ili9341_t3n library which also requires my spin library. I have done the changes to allow this to the main library (still only SPI) and it is part of an outstanding pull request to main library.

 

[jhendrix]

Paul, I'm planning on respinning my board to use a T3.6 (I got a 3.5 and 3.6 from your kickstarter).
I want to test out as much as possible on the T3.2 (so I can discover things like what pins work with the LCD library), before I get new boards built.

I've also been following some of your progress on the 2nd USB port. Are there plans to build a library to make it read/write to USB flash drives? (this would save me from needing to use a VDrive)

KurtE, I like your ili9341 library, I might end up using it.

I could easily use 10 or more uarts on my project. I just end up muxing some of the mutually exclusive devices and using some in parallel (with a nand gate on the return path)

 

[PaulStoffregen]

Are there plans to build a library to make it read/write to USB flash drives?

Yes, this is planned, but you should not expect it to be usable anytime soon. A tremendous amount of work is still required before anything like this will be even ready for testing, not to mention stable enough for use in real projects.