Teensy 3.6

L

lafleur

Member
Thought of you who have programed the 3.6 board, I have a few question...

It seems that there are primary and a few secondary selection for each pin on the board...
How do I select the what pin I want for what function?

Is the IDE able to support 2 or more SPI channels?

(I'm waiting for my boards)

Thanks
 
Yes most pins have the option of doing several different things. If you take a look at the pinout card that is on the page: http://pjrc.com/teensy/pinout.html
You will get a good indication of some of these capabilities.

Yes the 3.6 has multiple (3) SPI busses and yes you can access them through the IDE. Note a lot of the libraries that use SPI are hard coded to use the first spi with SPI object. So you may need to update some of the libraries to use SPI1 or SPI2. For some of my own stuff, I created a simple library SPIN which makes a virtual class and then subclasses for each SPI buss. I then made a version of the ILI9341_t3 library where I can pass in which SPI buss I wish to use... Others have taken different approaches.
 
When you use Wire.begin(), SPI.begin(), Serial1.begin() and similar, the pins for those ports automatically switch to their alternate functions.

Using pinMode() switches a pin to digital I/O mode.
 
Teensy 3.6 SPI

@1bit, if you look on the page that KurtE pointed to, you'll see some pins shown in dark black and some in grey. The dark black should be the default pins, so s/b 0,1,31,32.
------------

I just received my 2/ea new T3.6 modules 10-minutes ago ... thank you, Robin :).

I have a question: is pin 31 the only pin that SPI1-CS1 can map to? So. use SPI1 and lose Serial4? Or can Serial4 be remapped?

Also, the schematic shows the SD card connected to PTE0..5. Does that mean the T3.6 actually has a 4th "invisible" SPI port, and not supported by the SPI libary?
 
oric_dan said:
I have a question: is pin 31 the only pin that SPI1-CS1 can map to?
Click to expand...

If you're using special code that needs the hardware CS pins, then it is a conflict where you lose Serial4.

But are you really using the hardware CS feature? Almost all SPI code uses ordinary digital I/O for chip select. So it depends on the code you're using, but with the vast majority of applications you can use any pin. The CS1 pin is only required if you're using the special hardware control of CS.
 
@Paul -- I will use ordinary CS. I may need a CTS from the particle though ;). Maybe this port is too useful for other purposes for some people. I may move to pins clockSPI1 = 20; MisoSPI1 = 5; and mosiSPI1 = 21; after testing and board layout considerations.


SPI1.setMISO(misoSPI1);
SPI1.setMOSI(mosiSPI1);
SPI1.setSCK(clockSPI1);

https://forum.pjrc.com/threads/3905...ing-Teensy-3-x?p=121888&viewfull=1#post121888

@oric


PTE0..5???

See PIN TABLE I don't know if this is old but I like the lib references...

https://forum.pjrc.com/attachment.php?attachmentid=8155&d=1473631354

On a different note...

I might be nice for someone to be able to reconfigure an application remotely. I have a pretty good idea of what hardware I will put on the teensy and if I can drive the behavior through data configuration only; then I can manage the system remotely. I do wish some option for a remote downloading of the teensy.....

http://www.pjrc.com/teensy/beta/load_linux_only.c

I guess I could put a PI zero to the FONA for a remote loader??? with FTP...but this seem like a lot of HW...
 
Last edited:
In teensy 3.6 there are 3 channels spi,what are the default pins for each channel(mosi,miso,sck)?
 
Look at your Teensy card - linked on K66_Beta thread post 8.

check out pins 11,12 and 0,1 and 45,44 and then look for the SCK#'s that are there too.

Those in BOLD are the ideal defaults - those with the same indications in lighter gray font are possible alternatives where possible.
 
defragster said:
Those in BOLD are the ideal defaults - those with the same indications in lighter gray font are possible alternatives where possible.
Click to expand...

I have looked defragster that's why i asked.
I connected mosi1(21),miso1(5) and sck1(20) and do not work.Why?
 
Last edited:
thanos said:
I have looked defragster that's why i asked.
I connected mosi1(21),miso1(5) and sck1(20) and do not work.Why?
Click to expand...

AFAIK, the ports are good, so did you have a good CS. I could not find a SPI1.begin(CS) (or so) in your code before beginTransaction.
 
Don't see any notes about the code in use or the hardware . . .

Are there any other devices connected to the SPI lines?

Those alternate pins will work - if the code you are using takes them as parameters to use them versus any hardcoded defaults like for SPI0.
 
WMXZ said:
AFAIK, the ports are good, so did you have a good CS. I could not find a SPI1.begin(CS) (or so) in your code before beginTransaction.
Click to expand...

I have written

SPI1.begin();
SPI1.setSCK(20);
SPI1.setMOSI(21);
SPI1.setMISO(5);

i use the pin 31 for cs1.
 
thanos said:
I have written

SPI1.begin();
SPI1.setSCK(20);
SPI1.setMOSI(21);
SPI1.setMISO(5);

i use the pin 31 for cs1.
Click to expand...

I assume you must tell the system that pin31 is your CS.
OK, begin seems to be without parameter, but then
there should be a SPI1.setCS(31);
 
Sorry, I may be confused but is thanos and 1bit are we talking about same thing or two different setups.

Thanos:
Code: 
SPI1.begin();
SPI1.setSCK(20);
SPI1.setMOSI(21);
SPI1.setMISO(5);
SPI1.setCS(31);
Should work either way, but have you tried:
Code: 
SPI1.setSCK(20);
SPI1.setMOSI(21);
SPI1.setMISO(5);
SPI1.setCS(31); 
SPI1.begin();
Not sure what you mean when you say:
Code: 
I connected mosi1(21),miso1(5) and sck1(20) and do not work.Why?
Is there any additional information, like: what is hooked up to the pins? Do you have code here that does things like: SPI1.??? or are you using some library? If so which library? Many libraries are not setup to handle SPI1...

CS pin - How are you driving it? the setCS may or may not help you. That is if you are using the underlying hardware setup for SPI, where you are pushing stuff onto the queue (depth of 1), where the command allows you to specify what to do with the CS states, then yes this is necessary, otherwise you may have to drive the CS pin yourself using digitalWrites.

Again without seeing what code you are trying to use. If you are translating from using SPI to SPI1, you may run into other issues, like SPI has a queue with depth of 4 items, where SPI1 and SPI2 have a depth of 1.

So for example in my version of the ILI9341_t3n library I had to setup to handle depth of 1. Example there is readPixel code that would keep pushing stuff onto the output queue, until full and then keep reading the input queue until there were 3 items on it, which it then read and construct the pixel color from. That code does not work when queue size is 1...

Edit: Another example I have a modified version of Radiohead library where I can configure it up for SPI1 and on one board I have a LoRa (RF95), that works on SPI1. I am using Miso=5, Mosi=21, SCK=20, cs=31
 
Last edited:
KurtE said:
Should work either way, but have you tried:
Code: 
SPI1.setSCK(20);
SPI1.setMOSI(21);
SPI1.setMISO(5);
SPI1.setCS(31); 
SPI1.begin();
Click to expand...

With this change now works,thank you very much for your help.

KurtE said:
Is there any additional information, like: what is hooked up to the pins? Do you have code here that does things like: SPI1.??? or are you using some library? If so which library?
Click to expand...

I have connected a gyroscope,not use some ready library to read the gyroscope,use only spi library
 
Last edited:
Glad you got it working: Re-looking over SPI, the code is setup to expect that you set the pins before the begin. Some of the other subsystems were setup to handle it either way.

But: it is better to do it this way in either case. What happens, when you do the begin, is it configures the currently configured pins to be in SPI mode. Then if you change them, it then un-configures the current defined pins and then enables the new pin.
 
Last edited:
I have still a problem,now i use spi0 channel and i have written the following

SPI.setMOSI(11);
SPI.setMISO(12);
SPI.setSCK(13);
SPI.begin();

and do not working.But if you change the pin sck(13) at sck(14) it works.

Code: 
#include <SPI.h>

byte lowByte, highByte;
double gyroscope_roll;
double gyroscope_pitch;
double gyroscope_yaw;

void read_gyroscope();
void print_output_gyro();

void setup() {

  GPIOE_PDDR |= (1<<26);
  PORTE_PCR26 = PORT_PCR_MUX(1); 
  
  Serial.begin(9600);
  while(!Serial); 

  SPI.setMOSI(11);
  SPI.setMISO(12);
  SPI.setSCK(14);   if you write [COLOR="#FF0000"]SPI.setSCK(13);[/COLOR] not working
  SPI.begin();

  GPIOE_PCOR |= (1<<26);
  SPI.transfer(0x20 & 0x7F);
  SPI.transfer(0x8F);
  GPIOE_PSOR |= (1<<26);

  GPIOE_PCOR |= (1<<26);
  SPI.transfer(0x23 & 0x7F);
  SPI.transfer(0x90);
  GPIOE_PSOR |= (1<<26);

  delay(250);
 
}

void loop() {
  
  read_gyroscope();
  print_output_gyro();
  delay(250);

}

void read_gyroscope(){

  GPIOE_PCOR |= (1<<26);
  SPI.transfer(0x28 | 0x80);
  lowByte = SPI.transfer(0x00);
  GPIOE_PSOR |= (1<<26); 
  GPIOE_PCOR |= (1<<26);
  SPI.transfer(0x29 | 0x80);
  highByte = SPI.transfer(0x00);
  GPIOE_PSOR |= (1<<26); 
  gyroscope_roll = (int16_t)((highByte<<8)|lowByte);

  GPIOE_PCOR |= (1<<26);
  SPI.transfer(0x2A | 0x80);
  lowByte = SPI.transfer(0x00);
  GPIOE_PSOR |= (1<<26);
  GPIOE_PCOR |= (1<<26);
  SPI.transfer(0x2B | 0x80);
  highByte = SPI.transfer(0x00);
  GPIOE_PSOR |= (1<<26);
  gyroscope_pitch = (int16_t)((highByte<<8) | lowByte);
  gyroscope_pitch *= -1;

  GPIOE_PCOR |= (1<<26);
  SPI.transfer(0x2C | 0x80);
  lowByte = SPI.transfer(0x00);
  GPIOE_PSOR |= (1<<26);
  GPIOE_PCOR |= (1<<26);
  SPI.transfer(0x2D | 0x80);
  highByte = SPI.transfer(0x00);
  GPIOE_PSOR |= (1<<26);
  gyroscope_yaw = (int16_t)((highByte<<8) | lowByte);
  gyroscope_yaw *= -1; 
  
}

void print_output_gyro(){
  
  Serial.print("Pitch:");
  if(gyroscope_pitch >= 0)Serial.print("+");
  Serial.print(gyroscope_pitch/57.14286,0);               
  if(gyroscope_pitch/57.14286 - 2 > 0)Serial.print(" NoU");
  else if(gyroscope_pitch/57.14286 + 2 < 0)Serial.print(" NoD");
  else Serial.print(" ---");
  Serial.print("  Roll:");
  if(gyroscope_roll >= 0)Serial.print("+");
  Serial.print(gyroscope_roll/57.14286,0);                
  if(gyroscope_roll/57.14286 - 2 > 0)Serial.print(" RwD");
  else if(gyroscope_roll/57.14286 + 2 < 0)Serial.print(" RwU");
  else Serial.print(" ---");
  Serial.print("  Yaw:");
  if(gyroscope_yaw >= 0)Serial.print("+");
  Serial.print(gyroscope_yaw/57.14286,0);                 
  if(gyroscope_yaw/57.14286 - 2 > 0)Serial.println(" NoR");
  else if(gyroscope_yaw/57.14286 + 2 < 0)Serial.println(" NoL");
  else Serial.println(" ---");               

}
 
Last edited:
TEENSY/ELECTRON/RPI ZERO/FONA playpen.

I did get this board made. This is more of a note/strategy check.
PlantServer.JPG

It has headers for the Teensy 3. family, the Particle family, and a Raspberry header, and a FONA 3G header. I do have SPI1 working between the Teensy and the Electron. With the Electron as slave. I do have a DTR implemented for the ELECTRON so that the Teensy will know if it is available. I guess I will try to compile the Teensy bootloader CLI for the teensy loader for a Raspberry PI ZERO. I would build hex file on a windows machine and transfer to the RPI for loading to the TEENSY. I do Have the ability to load the ELECTRON with the particle CLI for a RPI. I guess I would like the Teensy to be the master of these busses because the Teensy does the realtime work and the others are peripherals to it. I will connect the FONA with a UART port if I am unsatisfied with the REST API for remote data link cloud) using the PARTICLE. The FONA is for direct CELL link to known clients (phone numbers) maybe just SMS to start.. The Rasberry is for local interface as well. I have built out the I2C busses for testing of slaves. I have a family of I2C boards for different functions like Steppers and Scales. I did make a pin compatible differential preamp for the teensy to take MV signals. I made it geoentrically pin compatible with the HX711 BOB. I did put Stereo jacks as signal inputs on the underside optionally, but 2.54 headers for the terminal blocks or angled plug headers for the 8 differential inputs. THese could be straped for bypass of the preamplifiers if they are not needed for direct AI. The DACS are hauled out to MONO jacks. 2 from the TEENSY and one from the electron. The ground plane has the appropriate cutout for the Photon WIFI. and no traces run under the reserved areas for the particle family.

TELEZ.JPG




Right now the USB cables to the Electron and the Teensy are a bit messy. I may switch the FONA and the RPI header locations to make the SPI lines shorter after I test/develop the RPI/TEENSY SPI link.
 
TELEZ BioReactor CONTROLLER

Packaged unit in a 3U rack. running pumps, scales, Modbus TCP graphics and I/O. Teensy 3.6 with two T3.2 i2C on I2C2 (slaves) and an ELECTRON SPI1 slave. Now to add the RS-485 RTU MFCs, and then the Cell modem on the Particle ELECTRON with ModbusDMA mapping.
 

Attachments

  • TELEZFERM.JPG
    TELEZFERM.JPG
    94.7 KB · Views: 216
Last edited:
You must log in or register to reply here.
Back
Top