Teensy 3.1 Changes To Green PCB

Status
Not open for further replies.
Hi Paul,
Thank you for the reply. I am not sure but yes, I do agree the problem is with the automated testing. I have some knowledge on Image processing and, I think that is where the problem lies with testing the black board. You see when we take the images of black board it is very diffcult to make out the tracks but the with green board it is very easy to spot the tracks and this is why it is easy to do automated testing with green board rather than black board and also track the short circuits and open circuits. Although I am not sure how does the PCB material affect the tracks.
I also do agree with you "Functionality and software are far more important". I mean when making a project no one is gonna look into the colour of the board that you used by that, I mean no one will be impressed with the colour of the board but a person like me would rather look into the efforts put and the output and ofcourse the functionality of it, rather than the packing.
So keep up the good work.
I am new to ARM myself though, I have done a lot in AVR. I would also request you to please update the "how-to tips" page. It seems to have all about AVR(like how to access DDRx and PORTx in AVR in C-language) and very less or almost nothing on ARM. I mean, I basically want to know how to access port in ARM. Is the architecture similar to AVR both being based on RISC architecture or There is some other way. Its very difficult to find this in the datasheet. Also please suggest some book like mazidi where, I can find all this as the datasheet is very less helpful.
 
Last edited:
Green is better anyway. I can follow the traces on the board much more easily. Black annoyed me because it was difficult to find them and cut them when I needed to do JTAG.
 
Parth Chauhan said:
Hi Paul,
Is the architecture similar to AVR both being based on RISC architecture .
Click to expand...
Ports: The ARM/Teensy3s use the same conventions as AVR / Arduino: digital.write(pinNumber), etc. The SPI support at the library level is the same coding as for AVR, Paul has library code that makes it transparent. But, for example, there is a new library for SPI that exploits the FIFO based hardware in the Teensy 3. This example is typical.

I'd like to see some users organize to help write more on the Teensy 3 usage. Paul is generous to a fault with his time on this forum answering questions and add software sustaining/developing plus running a business must be all-consuming.
 
stevech said:
But, for example, there is a new library for SPI that exploits the FIFO based hardware in the Teensy 3.
Click to expand...

Since Teensyduino 18 the "standard" SPI includes SPIFIFO . Well at least int includes:

Code: 
#if defined(__arm__)
#include "SPIFIFO.h"
#ifdef  HAS_SPIFIFO
#define USE_SPIFIFO
#endif
#endif

in W5100.cpp ;-)
 
Hi Stevech,
I am really interested in helping you and the Teensy community with the documentation but, I need some one to guide me as, I am very new ARM(By new, I mean, I can program teensy using the libraries compatible with arduino but beyond that, I am helpless). Please mail me on my mail ID(chauhanparth26@gmail.com) for any help with documentation. I have read the datasheet but, I am unaware of how to program ARM in C. I mean, I am fine with all the arduino libraries that PAUL has worked to make compatible with Teensy3.x but to extract more out of teensy3.x, we would require more libraries and in some cases more info on the IC than just Arduino compatible software/libraries because Teensy3.x is at hole another level, there is lot more that needs to extracted from this controller.
 
ARM, AVR. The libraries do abstract the hardware so that the newbie can just follow example programs to learn, slowly modify these examples, then adding his/her own new code.
 
Parth Chauhan said:
I can program teensy using the libraries compatible with arduino but beyond that, I am helpless).
.....
but, I am unaware of how to program ARM in C. I mean, I am fine with all the arduino libraries that PAUL has worked to make compatible with Teensy3.x but to extract more out of teensy3.x, we would require more libraries and in some cases more info on the IC than just Arduino compatible software/libraries because Teensy3.x is at hole another level, there is lot more that needs to extracted from this controller.
Click to expand...

Arduino is really just C and C++ with a tiny bit of preprocessing and easy to use libraries.

As a first small step, I'd recommend using File > Preferences to turn on verbose info while compiling. Then you will see the actual gcc compiler commands Arduino is using.
 
As much as colored PCBs add 'cool factor', the first priority for the thing is to work in the first place.

Secondly, I can also understand why Paul would prefer to source his PCBs and assembly locally. It gives him better control of his supply chain, it shortens turn-around time, reduces WIP, and adds recourse in case something goes terribly wrong. Paul also has likely reached a scale where producing in the US is no longer as disadvantageous as it is for low volume production. US PCB manufacturers and assemblers by and large appear to have transitioned to a model where they either offer reasonable turnaround at very high prices (catering to commercial customers) or producing at scale. Hobbyists pretty much have to avail themselves to shoe-horned board sizes (pcb123, for example) or paying a premium to make a board with Laen, etc. to make it in the US.

Ditto for stencils. I can get a framed stainless steel stencil that's good for 0.5mm pin pitch for the same money that Pololu charges for a similarly-sized laser-cut mylar sheet. Both work... but the stainless stencil certainly is going to give me a much longer life than mylar... the only downside is that the mylar is available in different thicknesses - to accommodate fine or coarser pitches. Oh, and I suppose there is a theoretical possibility of adding new pad holes to the mylar sheet with an xacto knife if you only have a very minor board revision (i.e. add a single resistor) - but you can also solder those outliers by hand, if need be.

FWIW, I have been very happy with iteadstudio and Laen's services. My (comparatively crude) PCBs have come out fine in green, blue, red, and (in Laen's case) purple. I've chosen red as my base color simply because I like it. Were the color to lead to issues, then I'd switch back to green in a heartbeat. And I totally agree on steering clear of 'clear' boards. All you'd see on a board like that is the glassfibers encased inside. If you want to see through the board, you'd have to specify something like mylar (flexible Teensy!) at a high premium. I'm not sure 4-layer mylar is available either, nor whether I'd trust it to maintain all the connections despite being bent, etc.
 
"As a first small step, I'd recommend using File > Preferences to turn on verbose info while compiling. Then you will see the actual gcc compiler commands Arduino is using"

I always do that. I try a little more to explain what exactly, I want. Please consider the following programs:

In GCC for Led Blink:
#define F_CPU 160000000 // AVR clock frequency in Hz, used by util/delay.h
#include <avr/io.h>
#include <util/delay.h>

int main() {
DDRD |= (1<<DDD1); // set LED pin PD1 to output
while (1) {
PORTD |= (1<<PORTD1); // drive PD1 high
_delay_ms(1000); // delay 1010 ms
PORTD &= ~(1<<PORTD1); // drive PD1 low
_delay_ms(1000); // delay 1000 ms
}
}

Where in Arduino/Teensy Same code would be written as:

//Assuming Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {
// initialize the digital pin as an output.
pinMode(led, OUTPUT);
}

// the loop routine runs over and over again forever:
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}

Now if you observe both the codes, I am am able to understand at the hardware level in the 1st code what excatly is happening(which DDR and PORT are changing) and more understanding on the processor and on compilation in GCC less space shall be required as compared to the 2nd Code.
But in the second code, I have no idea what is happening(I mean, I don't even know which port is being toggeled).
I am actually more accustomed to writing code in GCC and Arduino/teensy makes it very easy like when a person writes Serial.Begin(9600) he is not aware how many registeres(UCSRA,UCSSRB and UCSRC) are changed or why the number 9600 and not 9000. I love programming the way when, I am aware of everything. Its like, I know every nerve,part and heart of that processor and, I know how to control them .
Anyways for now, I think it shall be better that, I explore the libraries and when, I exhaust them then, I will switch to getting more into ARM getting to know the registers.
Just one more question "Can we get the assembly code or GCC code that is compiled from Arduino" , I mean From the 2nd code that, I wrote above can we get the 1st one or the assembly of the same. I basically want to understand what is happening at register level.
 
Last edited:
maybe your:
#define F_CPU 160000000 // AVR clock frequency in Hz, used by util/delay.h
has too many zeros ;-) Nice, a atmega with 160MHz

To get the assembler of an arduino-sketch, just do this:
http://rcarduino.blogspot.de/2012/09/how-to-view-arduino-assembly.html

Of course, arduino has some kind of an abstraction layer, with all its pros and cons.
And one pro is: You don't have such hardly readable values like 16000000, that could easily be wrong :D
But it's nice to have the ability to use all the registers directly. Imho are the manuals of the ARM-controllers quite usefull.
 
I believe green is one of the most visible colors to the human eye. I am an avid shooter and they paint our indoor range green for this reason, also it is why green laser sights are a lot more visible then the red. The green boards seem to be the best for visibility on many levels.
 
Parth Chauhan said:
Just one more question "Can we get the assembly code or GCC code that is compiled from Arduino" , I mean From the 2nd code that, I wrote above can we get the 1st one or the assembly of the same. I basically want to understand what is happening at register level.
Click to expand...

Yes, you can get this code. In fact, if you've installed Teensyduino, you already have it. Just look inside Arduino, in hardware/teensy/cores/teensy3. On Macintosh, control-click on Arduino and "show package contents" to look inside. On Windows and Linux, Arduino is just ordinary directories and files.

The code is also available here:

https://github.com/PaulStoffregen/cores

Like with AVR, you'll need to refer to the manual that documents the registers. Here's the one for Teensy 3.1.

http://www.pjrc.com/teensy/K20P64M72SF1RM.pdf

The I/O registers are documented in chapter 49, starting on page 1331. Each port has 6 registers. Three are basically the same as the ones you're familiar with from AVR. The other 3 allow set, clear and toggle without having to read the current output state. In fact, I believe Atmel's newest XMEGA AVR chips have this same 6 register set.

One other register that is very different from AVR is the port config register. It's actually documented in chapter 11, starting on page 219. Every pin has its own 32 bit register that configures what that pin does. On 8 bit AVR, when you enable the UART, those pins are commandeered by the UART and no longer work with the 3 normal I/O. The SPI sort-of grabs control of the pins, except the DDR register still has some effect. Each peripheral has its own rules on AVR. On this Freescale chip, you explicitly control the function of every pin with these config registers. No pin automatically changes function when you enable some peripheral. You write to the config register for each pin to set exactly what it does. The pullup resistors, pin change interrupts and DMA requests and other pin specific features are also controlled here. The GPIO registers are considered to be just one of many peripherals that can control the pins, which is why this pin config stuff is in a different section than the GPIO registers.

If you really want to dig into the register level control of everything, you certainly can. All the code is published and everything in this chip is well documented. But some of these peripherals are dramatically more sophisticated than those found on AVR chips, with an incredible number of options and features.

One important feature that unfortunately isn't well documented in that manual is the ARM bitband addressing. It's mentioned in section 4.2.1. Currently it's only used in an Arduino macro compatibility layer I wrote. I do intend to use it more in future versions. There's plenty of great documentation on ARM's website, so I'm sure you'll find info on the bitband addressing if you use google. In fact, if you really want to get into knowing and understanding the very low-level details, you can find extremely detailed information about the ARM processor and its many subsystems that is far more descriptive than anything Atmel publishes for AVR. The main document you want is ARM code "DDI0403D". A quick google search can get you the PDF version.
 
Last edited:
PaulStoffregen said:
One important feature that unfortunately isn't well documented in that manual is the ARM bitband addressing.
Click to expand...

Hi Paul and All ;),

So a few beers into my night and was messing around with Bitbanding....., Question? when setting peripheral registers that are declared uint8_t, such as register LLWU_RST. Can I set their bits with this code actually borrowed from your avr_emulation.h:
Code: 
[COLOR=#78492A][FONT=Menlo]#define BITBAND_ADDR(reg, bit) (((uint32_t)&(reg) - [COLOR=#272ad8]0x40000000[/COLOR]) * [COLOR=#272ad8]32[/COLOR] + (bit) * [COLOR=#272ad8]4[/COLOR] + [COLOR=#272ad8]0x42000000[/COLOR])[/FONT][/COLOR]
[COLOR=#78492A][FONT=Menlo]#define BITBAND_U8(reg, bit) [COLOR=#ff0000](*(uint8_t *)[/COLOR]BITBAND_ADDR((reg), (bit)))[/FONT][/COLOR]

It seems to work for me, if delared as uint32_t, crash burn, uint8_t it works as usual. To me, single cycle writes should be the norm, so why is it not? and would the above example really be single cycle write?
 
It looks like the Teensy 3.1 is also available in purple at OshPark!
Is this a limited (for sure it will be collector value in a few years) edition?
 
Status
Not open for further replies.
Back
Top