Arduino Forum

Development => Other Hardware Development => Topic started by: westfw on Sep 05, 2012, 09:45 am

Title: Teensy 3.0
Post by: westfw on Sep 05, 2012, 09:45 am
Well, Paul seems to be particularly circumspect in tooting his own horn, so I thought I'd mention this for him:

http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a

Based on a Freescale Kinetis Cortex M4 microcontoller (ARM with DSP extensions.)  128k flash.
Title: Re: Teensy 3.0
Post by: retrolefty on Sep 05, 2012, 11:04 am
Wow, very impressive project/product. Thanks for posting, I made a pledge.


Lefty
Title: Re: Teensy 3.0
Post by: TonyD on Sep 05, 2012, 11:28 am
Cool a Cortex-M4 stamp
Title: Re: Teensy 3.0
Post by: PaulS on Sep 05, 2012, 12:28 pm
Quote
Wow, very impressive project/product. Thanks for posting, I made a pledge.

Me, too.
Title: Re: Teensy 3.0
Post by: 48X24X48X on Sep 05, 2012, 01:03 pm
Freescale are also coming up with a $13 Arduino form factor board using the same series ARM.

But, I'm sure Paul's work on the software side is the winner!
Title: Re: Teensy 3.0
Post by: Jantje on Sep 05, 2012, 05:42 pm
Thanks for sharin
Looks really cool and real
Best regards
Jantje
Title: Re: Teensy 3.0
Post by: cyclegadget on Sep 06, 2012, 04:39 am

Quote
Wow, very impressive project/product. Thanks for posting, I made a pledge.

Me, too.


Me, three pretty cool board!
Title: Re: Teensy 3.0
Post by: fat16lib on Sep 06, 2012, 03:09 pm
I have been using lots of Cortex boards including M4 boards and this is the most elegant board I have seen.

I pledged and can't wait to see the Teensy 3.0.

The Freescale Kinetis processor is an excellent choice.  It's amazing to see that 64 pin part on such a tiny board.  It truly is Teensy.

I hope this mean it will be open enough so I can port a RTOS like ChibiOS to it.
Quote

Teensy 3.0, an affordable 32 bit ARM Cortex-M4 board, for development in Arduino or C/C++.


I have been using ChibiOS and really like having the same RTOS on all boards.
Title: Re: Teensy 3.0
Post by: skyjumper on Sep 08, 2012, 02:26 am
Looks like a great board, but what tool chain will be used to code for it?
Title: Re: Teensy 3.0
Post by: fat16lib on Sep 08, 2012, 04:17 pm
You should be able to use any tool chain that supports Cortex M4 processors.  

The only problem could be how Paul's boot-loader works on Teensy 3.0.  You need a hook to load you hex file.

The easy way is to use what ever Paul has packaged with his software.  His stuff is always easy to use and reliable.

I am hoping to make ChibiOS a library for Teensy 3.0 using his tools.  That way I can use his tools and have a RTOS.

I did that with the Arduino IDE for AVR processors.

I really like Freescale's documentation.  Here is a good overview of true bare metal use of the device http://cache.freescale.com/files/32bit/doc/quick_ref_guide/KQRUG.pdf (http://cache.freescale.com/files/32bit/doc/quick_ref_guide/KQRUG.pdf).
Title: Re: Teensy 3.0
Post by: Jantje on Sep 08, 2012, 05:22 pm

The only problem could be how Paul's boot-loader works on Teensy 3.0.  You need a hook to load you hex file.

This is what the page says about the boot-loader (not sure what it means but it sounds like it does not impact the tool chain 8) )
Quote
Teensy 3.0 features an off-chip bootloader design.  On Teensy 2.0 and all Arduino(R)** brand boards, the bootloader consumes a small portion of the available flash memory.  On most boards, the bootloader executes briefly before your own program.  By storing the bootloader in a separate chip, your code can use all of the flash memory.  Your code can also run immediately after a reset event, without bootloader interference.


Best regards
Jantje
Title: Re: Teensy 3.0
Post by: fat16lib on Sep 08, 2012, 07:16 pm
I wasn't very clear, I am sure you can generate a hex file with any Cortex M4 tool chain.

Here is my question.   How easy is it to load an arbitrary hex file?

I read this also
Quote

Teensy 3.0 features an off-chip bootloader design.  On Teensy 2.0 and all Arduino(R)** brand boards, the bootloader consumes a small portion of the available flash memory.  On most boards, the bootloader executes briefly before your own program.  By storing the bootloader in a separate chip, your code can use all of the flash memory.  Your code can also run immediately after a reset event, without bootloader interference.


I wonder how you start the boot loader?

My guess is that the button copies the boot-loader into RAM.  The boot-loader can then program all flash.

Perhaps the boot-loader uses FlexMemory.  I don't have a clear understanding of FlexMemory.

The next question is how do you send the hex file to the boot-loader?
Title: Re: Teensy 3.0
Post by: Jantje on Sep 13, 2012, 11:52 am
All
Paul has been pledged $58,442. That is 11 times the requested amount.
He will be busy the next months  ]:D

Best regards
Jantje
Title: Re: Teensy 3.0
Post by: pico on Sep 17, 2012, 04:22 pm
If anyone here has any experience with the Leaflab Maple boards, you will know what a massive undertaking the porting of much of the AVR-based Arduino code over to the ARM architecture is. The Leaflab boards are great little Cortex-3 prototyping boards, with an Arduino derived IDE and a "wirish" port of the basic wiring stuff, but much of the promise of the hardware (DMA, advanced interrupt handling etc.) even to this day has yet to be really fully realised because of the at times painfully slow rate of porting across (or creation from scratch) of many of the libs we take for granted on the Arduino.

I have developed using the Maple boards, and to be honest, despite the raw hardware advantages, the Mega2560 is in many ways far more capable prototyping platform, apart from some niche applications. As a sage once said, "it's the software, stupid."

So, recent history ponts to where the challenge is. Building a good ARM dev board -- certainly not trivial, but pales into comparison to the effort required in building a complete software development environment that would be comparable to the Arduino ecosystem.

Having said all this, I might add I'm not surprised that the announced "team Arduino" development effort for an ARM based Arduino product is today a year old -- and not a public beta release in sight.

So good luck to Paul. But he's going to need more than good luck -- he's also going to need considerable community support if this platform is really going to take off.
Title: Re: Teensy 3.0
Post by: westfw on Sep 30, 2012, 03:27 am
Mine has shown up and is blinking (and the IDE works, so I've modified the blink rate and whatnot, and it uploads/etc.)  I've soldered pins on "upside down" for easier access to the extra backside signals, although this hides the reset button and I'll have to remember to be really careful when trying to remove the board from the protoboard.
Pretty cool.  It's very tiny (teensy!)
(http://farm9.staticflickr.com/8033/8037622065_491b62b9da.jpg) (http://www.flickr.com/photos/58843278@N00/8037622065/)
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 05, 2012, 10:56 pm
I just started porting SdFat to Teensy 3.0 and am really pleased with Teensy 3.0.  Paul's modified IDE works well.

SdFat has about 8,500 lines of code and it took me about an hour to get it to compile.  I commented out about 100 lines of AVR SPI code.

I found SPI examples on the Freescale website and am starting implementation of SD/SPI access routines.  This should not take long.

The biggest problem is also the biggest opportunity.  With AVR everything was based on the fact that SdFat would mostly be used on 328 processors with 2KB of memory.  This really limited how caching was implemented and what SD command sequences could be used.  Now I need to redesign SD access to take advantage of more memory and processor speed.

I am starting to redesign SD access for better performance.  While waiting for the Teensy 3.0 I experimented with a Mega.  I was able to increase write speed by almost a factor of three by using more memory and multi-block SD commands.

One shock was the old SdFat first ran much slower with more memory.  This is because I had multiple blocks in the cache and user memory and was not writing them in sequential order.  This slowed the write speed from 200KB/sec on an Uno to 90 KB/sec on a Mega.  SD cards love streaming multi-block writes and die with random writes.  Writing the blocks in the correct order increased the speed for this example from 90KB/sec to over 500KB/sec.

The Teensy will have 24 MHz SPI, a faster processor, and more memory so I hope to get 5-10 times faster file write speeds than SdFat on a Uno.

ARM for Arduino is great!

I have started looking at porting ChibiOS/RT to Teensy 3.0 and it also looks easy.  I will make the RTOS a library so you can use it with Paul's core routines and other ported libraries in a multi-tasking environment.
Title: Re: Teensy 3.0
Post by: Jantje on Oct 06, 2012, 12:15 am
Is there a place where I can download teensyduino for 3.0?
I havn't found a new version on the PCR site.
I would like to see the differences I need to make the elf file and how to upload. This to asses the impact on my eclipse plugin for when my teensy 3.0 and due arrive.
I asked paul but he is way to bussy with other things.
Best regards
Jantje
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 06, 2012, 12:48 am

Is there a place where I can download teensyduino for 3.0?
I havn't found a new version on the PCR site.
I would like to see the differences I need to make the elf file and how to upload. This to asses the impact on my eclipse plugin for when my teensy 3.0 and due arrive.
I asked paul but he is way to bussy with other things.
Best regards
Jantje


http://www.pjrc.com/teensy/beta/arduino-1.0.1-teensy3-beta2-macos.zip
Title: Re: Teensy 3.0
Post by: Jantje on Oct 06, 2012, 12:42 pm
@cyclegadget
Great thanks
Jantje
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 06, 2012, 06:13 pm

Your welcome Jantie! Here are all the links that I have, I had to look through my email....I ordered a 3.0 and should have it next week.

http://www.pjrc.com/teensy/beta/arduino-1.0.1-teensy3-beta1-windows.zip
http://www.pjrc.com/teensy/beta/arduino-1.0.1-teensy3-beta1-linux64.tar.gz
http://www.pjrc.com/teensy/beta/arduino-1.0.1-teensy3-beta1-macos.zip

Qoute:
If you're using Windows and you've never used a Teensy before, you'll need the "serial installer" to add the driver (really just an INF to tell Windows to use its built-in driver).  If you're using Linux, you'll need to install the udev rule to allow non-root access.  They're available at the normal Teensyduino page:

http://www.pjrc.com/teensy/td_download.html
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 06, 2012, 06:14 pm

@fat16lib

I meant to say this last night but, thank you for working on porting your SDfat library to the 3.0! I really enjoy using your SDFat library and I am glad it can be used with the 3.0!
Title: Re: Teensy 3.0
Post by: pico on Oct 06, 2012, 07:05 pm

I am starting to redesign SD access for better performance.


Ultimately you could go to using DMA to get the maximum performance. Might want to look at some of the Leaflabs Maple code to get some ideas on how that is done on the Cortex3.

LFNs an option with the additional memory?
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 06, 2012, 08:49 pm
I have this Maple version of SdFat http://code.google.com/p/maple-sdfat/ (http://code.google.com/p/maple-sdfat/) and it doesn't use DMA.

I have examples of Kinetis SPI DMA and plan to try it but it won't help much.

SD, DMA, and SPI don't work too well together.  The problem is the SD SPI protocol.  SD cards indicate busy in SPI mode by holding MISO high so you can't just setup a DMA transfer and go away.  The protocol uses control tokens in the data stream which is a pain.

The good news is that Kinetis has a four deep FIFO on SPI so I should be able to send/receive at 24 MHz easily.  That's only 3 MB/sec.

The real winner is having an SDIO controller like high end STM32 and the Due if these pin are brought out.

I plan on LFN.  I implemented most of LFN but didn't put it in the AVR version of SdFat because flash is so precious on 328 Arduinos.
Title: Re: Teensy 3.0
Post by: retrolefty on Oct 06, 2012, 09:42 pm
So can anyone explain the steps better to be taken once I've downloaded the windows zip file. I can't seem to find any installation instructions other then
1. Be sure arduino 1.0.1 is installed first
2. If windows, run serial installer first
3. Download Teensy 3.0 zip file


So where and how do I install/unpack the Teensy 3.0 zip file to?

Lefty

Title: Re: Teensy 3.0
Post by: Jantje on Oct 06, 2012, 11:12 pm
Lefty
I just downloaded "arduino-1.0.1-teensy3-beta2-windows"
It actually contains the whole environment (that is including the arduino stuff). So you just can unzip it at the locattion of your choice.
Given cyclegadget comment the driver is the same as for the teensy2.
Best regards
Jantje
Title: Re: Teensy 3.0
Post by: retrolefty on Oct 06, 2012, 11:42 pm

Lefty
I just downloaded "arduino-1.0.1-teensy3-beta2-windows"
It actually contains the whole environment (that is including the arduino stuff). So you just can unzip it at the locattion of your choice.
Given cyclegadget comment the driver is the same as for the teensy2.
Best regards
Jantje



Thanks for that. I installed the zip file and the IDE seems to work fine and the the Teeney board is listed in the board selection menu. I then ran the serial installer and it seemed to load OK.

Then a show stopper. What kind of USB connector is that on the Teeny 3.0 board? I've owned a Seeeduino mega board ( http://www.seeedstudio.com/depot/seeeduino-v30-atmega-328p-p-669.html?cPath=132_133) for eons that uses a:
Quote
The Seeeduino Mega uses a 4 Position mini-Type B Jack while the rest of the Arduino family uses standard 4 Position Type B Jack.


But this Teeny 3 seem to be some other kind of miniture USB connector. Anyone know what I need and a link to it. The PJRC lists a seperate mini-Type B cable avalible but that appears to be what I already own but which doesn't fit the Teeny3. I'm confused.....

Thanks;
Lefty
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 07, 2012, 12:10 am
Quote

The USB port on Teensy 3.0 is capable of USB host mode.  A Micro-AB connector allows future use of USB host mode.

Initially, Teensy 3.0 will ship with only USB device support.  USB host support, integrated in the Arduino(R)** environment with easy-to-use objects, is planned as a software-only upgrade in 2013.  Programming a project using USB host mode will require a second Teensy 3.0 and a board-to-board link using the I2C pins (2 wires and ground), to provide a path for the Arduino IDE to upload code.

Teensy 3.0 uses a Micro AB connector, not a Mini connector.
Title: Re: Teensy 3.0
Post by: retrolefty on Oct 07, 2012, 12:18 am

Quote

The USB port on Teensy 3.0 is capable of USB host mode.  A Micro-AB connector allows future use of USB host mode.

Initially, Teensy 3.0 will ship with only USB device support.  USB host support, integrated in the Arduino(R)** environment with easy-to-use objects, is planned as a software-only upgrade in 2013.  Programming a project using USB host mode will require a second Teensy 3.0 and a board-to-board link using the I2C pins (2 wires and ground), to provide a path for the Arduino IDE to upload code.

Teensy 3.0 uses a Micro AB connector, not a Mini connector.


Thanks for that. I didn't see it mentioned anywhere on their site and on their existing Teeny boards they state:

Quote
The Teensy is a complete USB-based microcontroller development system, in a very small footprint, capable of implementing many types of projects. All programming is done via the USB port. No special programmer is needed, only a standard "Mini-B" USB cable and a PC or Macintosh with a USB port.


So you can see my confusion? Or not.  ;)

Lefty
Title: Re: Teensy 3.0
Post by: westfw on Oct 07, 2012, 12:55 am
I think that people interested in experimenting with Teensy 3.0 should read the kickstarter page and "updates."
Paul has been posting a lot of high-content messages there, and they are readable even if you're not a "contributer."

The main description says:
Quote
The USB port on Teensy 3.0 is capable of USB host mode.  A Micro-AB connector allows future use of USB host mode.


http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a?ref=live

(They also seem to be setting records for "shortness of timeframe" between kickstarter campaign and getting the product into people's hands.  Woot!  (alas, kickstarter apparently frowns on this sort of use of KS as an advertising/sales channel for products you were going to produce anyway.))
Title: Re: Teensy 3.0
Post by: retrolefty on Oct 07, 2012, 01:00 am

I think that people interested in experimenting with Teensy 3.0 should read the kickstarter page and "updates."
Paul has been posting a lot of high-content messages there, and they are readable even if you're not a "contributer."

The main description says:
Quote
The USB port on Teensy 3.0 is capable of USB host mode.  A Micro-AB connector allows future use of USB host mode.


http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a?ref=live

(They also seem to be setting records for "shortness of timeframe" between kickstarter campaign and getting the product into people's hands.  Woot!  (alas, kickstarter apparently frowns on this sort of use of KS as an advertising/sales channel for products you were going to produce anyway.))



Well lets just not tell them.  :D
Title: Re: Teensy 3.0
Post by: westfw on Oct 07, 2012, 01:34 am
Quote
Well lets just not tell them

They caught on anyway.  New policies prohibit "rewards" that are multiples of the product.

That's a shame, because a lot of the need for funding in electronics projects comes from the "scaling up" of manufacturing to larger quantities...  (to build 2 of something small, I get my PCBs from dorkbotpbx, my parts from sparkfun, and use my trusty soldering iron.  For 20, I (might) get the PCBs from itead or Seeed, parts from digikey, and start looking into stencils and hotplates.  For 2000 ... I have no idea, but I'm pretty sure the up-front costs would be pretty significant.

Title: Re: Teensy 3.0
Post by: retrolefty on Oct 07, 2012, 01:45 am

Quote
Well lets just not tell them

They caught on anyway.  New policies prohibit "rewards" that are multiples of the product.

That's a shame, because a lot of the need for funding in electronics projects comes from the "scaling up" of manufacturing to larger quantities...  (to build 2 of something small, I get my PCBs from dorkbotpbx, my parts from sparkfun, and use my trusty soldering iron.  For 20, I (might) get the PCBs from itead or Seeed, parts from digikey, and start looking into stencils and hotplates.  For 2000 ... I have no idea, but I'm pretty sure the up-front costs would be pretty significant.




Yes, I can see where some start-up capital is really needed to get going. Even then I don't know if the profit margin from the first batch would be high enough to finance the next large batch? The Kickstarter idea was pretty unique and maybe it will still be somewhat useful but it's too bad that a few bad apples have made them be more restrictive in their policy/rules. I recall in the 70s when the micro revolution was just getting started, many start ups would just go ahead and announce the price and avaliblity of a product and accept orders with no product yet to ship, Using the funds from orders to finance the production. It was given the name of  'vaporware' and many a buyer had horror stories about not getting any product ever and no return on money sent, etc.
Title: Re: Teensy 3.0
Post by: graynomad on Oct 07, 2012, 03:03 am
Those new rules seem to have stirred the hornet's nest.

No way I'm going to read all the comments but the gist of it seems to be that people are angry about the "multiple rewards" and "rendering" bits.

I get why they have done it but it seems we have an example here of the law of unintended consequences, if you have a small and cheap item how are you supposed to reward a $500 pledge?

The rendering is not as clear cut IMO, I know all too well how easy it is to knock up a flash-looking render and some blurb but have nothing of substance behind it (heck that's what I do :)). But as someone pointed out we are visual beings, we want to see a picture and without that we are unlikely to pledge. I know I never buy anything off the web unless there's a good photo or two of the item.

Fortunately this has no affect on me because Kickstarter is not available to non-US citizens :(

______
Rob
Title: Re: Teensy 3.0
Post by: pico on Oct 07, 2012, 07:37 am

New policies prohibit "rewards" that are multiples of the product.


Does that mean a backer can't pledge more than once? E.g., if I'm a backer, and pledge $20 (or whatever) and get one widget as my reward, does that mean I can't later pledge another $20 (and get another widget as a reward for the second pledge?)

I was surprised to read this because I was under the impression many current projects are/were still offering multiples as rewards.

I agree that idea that scale matters considerably in bring per unit price down (and thereby making a product commercially viable or not) is a crucial barrier in production of electronics. Seems to fit with the original kickstarter "mission" very well. Maybe there will eventually be an exception made for electronics?
 
Title: Re: Teensy 3.0
Post by: pico on Oct 07, 2012, 08:00 am

I have this Maple version of SdFat http://code.google.com/p/maple-sdfat/ (http://code.google.com/p/maple-sdfat/) and it doesn't use DMA.


Oops! Well, that's embarrassing. I was under the assumptions a) that the Maple port used DMA, and b) that someone else besides yourself had done the port! :smiley-red:


I have examples of Kinesis SPI DMA and plan to try it but it won't help much.

SD, DMA, and SPI don't work too well together.  The problem is the SD SPI protocol.  SD cards indicate busy in SPI mode by holding MISO high so you can't just setup a DMA transfer and go away.  The protocol uses control tokens in the data stream which is a pain.


Oh well, at least I've learned something. Anyway, thanks for your continuing support on both these fronts!

Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 07, 2012, 11:30 am
 Look here for DMA mod of Maple: https://github.com/polpla/Maple-SDFat-DMA

Discussion: http://forums.leaflabs.com/topic.php?id=112&page=8

Related: https://github.com/leaflabs/libmaple/blob/master/libmaple/stm32f1/dma.c#L261
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 07, 2012, 02:19 pm
Maple-DMA is not very interesting.  It polls using single byte SPI reads while the card is busy then sets up DMA and polls while DMA runs. This does not save any CPU cycles or reduce the write latency.  In fact there is a huge amount of unnecessary code due to the fact that this is an old version of SdFat.

Using the Freescale Kinetis SPI fifo should be as fast or faster.  A loop to deliver 3 MB/sec to the SPI fifo for 24 MHz SPI should be easy with the Freescale Kinetis.

Improving use of cache and multi-block SD commands will produce a much larger gain than DMA.  I can already get about twice the performance of the Maple-DMA version of SdFat on a AVR Mega with these improvements.  I hope to get about another factor of three on Kinetis.

DMA could be useful with a multi-threaded RTOS.  You could then build a true driver thread with the driver sleeping while DMA ran.

I plan to port ChibiOS and FreeRTOS to Cortex boards.  ChibiOS and FreeRTOS already runs on Maple.  I plan to integrate the RTOS kernels as a library so you can use the IDE core functions and other libraries in multi-thread mode.

Unfortunately my Teensy 3.0 seems lost in the mail so I can't start testing.  I ordered two more from Adafruit so something should arrive soon.  
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 07, 2012, 05:18 pm

Thank you for the explanation!
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 08, 2012, 02:24 pm
Paul has now provided SD access for Teensy 3.0 in his beta 4 release. 

This is done by very clever emulation of the AVR SPI registers.  There is also an emulation of AVR PORT and PIN registers.

Look at arduino-1.0.1/hardware/teensy/cores/teensy3/avr_emulation.h to see how this is done with C++ classes.
Title: Re: Teensy 3.0
Post by: pjrc on Oct 08, 2012, 03:19 pm
LOL, I'm just now seeing this thread.... been far too busy shipping the rewards and writing software!

I was wondering if anyone would ever notice those C++ classes?!  I did some looking at libraries that use SPI, and sadly most of them directly access the AVR registers.  The official SPI library arrived relatively late in the development of Arduino, so it hasn't been widely adopted.  It also changed its own API at least once, causing at least one library author to dump it and go directly to the registers.  The existing SPI library isn't much of an abstraction (eg, able to support the fifo, dma, or automatic chip select signals).  Fortunately, the compiler optimizes away pretty much all of the C++ stuff because it's inline functions.  The SPCR part isn't highly efficient, but the data register and status flag compile to the equivalent registers accesses.  It was pretty painful having to clear the fifo every time SPDR is written, but that's necessary to faithfully emulate the AVR registers.....

For your sdfat library, at least making good use of the fifo should be much faster.  Would you prefer to put the Freescale registers directly into your sdfat library, or work with the a new SPI library that supports the fifos and other features (and might be adaptable to other new chips with similar SPI features)?
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 08, 2012, 03:45 pm
Paul, I am doing a major redesign of SdFat to use better caching and faster SD commands so large writes/reads will be much faster.

I plan to support SPI and 4-bit SDIO on various Cortex M chips.  I also want to make SdFat RTOS friendly when using DMA.

I would love to have a better low level SPI library for each chip.

I need a way to restore the SPI speed and mode each time I access the SD.  I need single byte read and write for sending commands, receiving status, and polling for busy.

I need fast block read and write routines.  These could use a fifo or DMA.

I am ready to start testing with some prototype SPI functions I have done but for some reason my Teensy 3.0 has not arrived in California yet.

Edit:  I need the equivalent of these AVR functions.
Code: [Select]

//------------------------------------------------------------------------------
/**
* Initialize hardware SPI
* Set SCK rate to F_CPU/pow(2, 1 + spiRate) for spiRate [0,6]
*/
static void spiInit(uint8_t spiRate) {
 // See avr processor documentation
 SPCR = (1 << SPE) | (1 << MSTR) | (spiRate >> 1);
 SPSR = spiRate & 1 || spiRate == 6 ? 0 : 1 << SPI2X;
}
//------------------------------------------------------------------------------
/** SPI receive a byte */
static uint8_t spiRec() {
 SPDR = 0XFF;
 while (!(SPSR & (1 << SPIF)));
 return SPDR;
}
//------------------------------------------------------------------------------
/** SPI read data - only one call so force inline */
static inline __attribute__((always_inline))
 void spiRead(uint8_t* buf, uint16_t nbyte) {
 if (nbyte-- == 0) return;
 SPDR = 0XFF;
 for (uint16_t i = 0; i < nbyte; i++) {
   while (!(SPSR & (1 << SPIF)));
   uint8_t b = SPDR;
   SPDR = 0XFF;
   buf[i] = b;
 }
 while (!(SPSR & (1 << SPIF)));
 buf[nbyte] = SPDR;
}
//------------------------------------------------------------------------------
/** SPI send a byte */
static void spiSend(uint8_t b) {
 SPDR = b;
 while (!(SPSR & (1 << SPIF)));
}
//------------------------------------------------------------------------------
/** SPI send block - only one call so force inline */
static inline __attribute__((always_inline))
 void spiSendBlock(uint8_t token, const uint8_t* buf) {
 SPDR = token;
 for (uint16_t i = 0; i < 512; i++) {
   uint8_t b = buf[i];
   while (!(SPSR & (1 << SPIF)));
   SPDR = b;
 }
 while (!(SPSR & (1 << SPIF)));
}
Title: Re: Teensy 3.0
Post by: pjrc on Oct 08, 2012, 04:32 pm

Edit:  I need the equivalent of these AVR functions.


I can do those, using the fifo for good speed.

Is there a version of your library which already uses these?  Or some test code that calls them to do something simple, like read and print the MBR or Volume ID sector?

I need some sort of test code that I can compile and run.
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 08, 2012, 04:45 pm
This beta of SdFat uses the above functions: SdFatBeta20120825.zip http://code.google.com/p/beta-lib/downloads/list (http://code.google.com/p/beta-lib/downloads/list).

The functions are at the top of Sd2Card.cpp

It also has the following function to initialize AVR SPI pins:
Code: [Select]

/**
* initialize SPI pins
*/
static void spiBegin() {
  pinMode(MISO, INPUT);
  pinMode(MOSI, OUTPUT);
  pinMode(SCK, OUTPUT);
  // SS must be in output mode even it is not chip select
  pinMode(SS, OUTPUT);
  // set SS high - may be chip select for another SPI device
#if SET_SPI_SS_HIGH
  digitalWrite(SS, HIGH);
#endif  // SET_SPI_SS_HIGH
}


This version of SdFat does not have the new stuff to speed up large reads and writes.  That involves changes to use multi-block SD commands.
Title: Re: Teensy 3.0
Post by: pjrc on Oct 08, 2012, 05:07 pm
I'm looking that the beta code now....

One minor but important point for compiling on 32 bit platforms is the use of packed structs.  By default, the compiler will align 32 bit types to 4 byte boundaries on 32 bit processors.  That's definitely not what you want in SdFatStructs.h.  It's necessary to add "__attribute__((packed))" to each struct definition, so the compiler packs the struct as intended.

For example.

Code: [Select]

struct masterBootRecord {
           /** Code Area for master boot program. */
  uint8_t  codeArea[440];
           /** Optional Windows NT disk signature. May contain boot code. */
  uint32_t diskSignature;
           /** Usually zero but may be more boot code. */
  uint16_t usuallyZero;
           /** Partition tables. */
  part_t   part[4];
           /** First MBR signature byte. Must be 0X55 */
  uint8_t  mbrSig0;
           /** Second MBR signature byte. Must be 0XAA */
  uint8_t  mbrSig1;
} __attribute__((packed));
Title: Re: Teensy 3.0
Post by: pjrc on Oct 08, 2012, 05:38 pm
The 32 bit compiler does not like many things in your iostream headers.  :-(

I'll work on this more later today or tomorrow.  For now, I need to focus on getting the rest of the kickstarter rewards shipped.
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 08, 2012, 07:32 pm
Sorry, I forgot to mention the packed attribute. for FAT structs.

I replaced the name fpos_t with FatPos_t

I had problems with types like uint16_t in extractors and inserters so I changed them to C types int, long...

The diff file that makes SdFat compile is:
Code: [Select]

diff -rb ArduinoOldVer/SdFat/SdBaseFile.cpp Arduino/libraries/SdFat/SdBaseFile.cpp
335c335
< void SdBaseFile::getpos(fpos_t* pos) {
---
> void SdBaseFile::getpos(FatPos_t* pos) {
1110c1110
<   fpos_t pos;
---
>   FatPos_t pos;
1794c1794
< void SdBaseFile::setpos(fpos_t* pos) {
---
> void SdBaseFile::setpos(FatPos_t* pos) {
diff -rb ArduinoOldVer/SdFat/SdBaseFile.h Arduino/libraries/SdFat/SdBaseFile.h
32c32
<  * \struct fpos_t
---
>  * \struct FatPos_t
36c36
< struct fpos_t {
---
> struct FatPos_t {
41c41
<   fpos_t() : position(0), cluster(0) {}
---
>   FatPos_t() : position(0), cluster(0) {}
201c201
<   void getpos(fpos_t* pos);
---
>   void getpos(FatPos_t* pos);
205c205
<   void setpos(fpos_t* pos);
---
>   void setpos(FatPos_t* pos);
diff -rb ArduinoOldVer/SdFat/SdStream.h Arduino/libraries/SdFat/SdStream.h
122c122
<   void getpos(fpos_t* pos) {SdBaseFile::getpos(pos);}
---
>   void getpos(FatPos_t* pos) {SdBaseFile::getpos(pos);}
138c138
<   void setpos(fpos_t* pos) {SdBaseFile::setpos(pos);}
---
>   void setpos(FatPos_t* pos) {SdBaseFile::setpos(pos);}
185c185
<   void getpos(fpos_t* pos) {SdBaseFile::getpos(pos);}
---
>   void getpos(FatPos_t* pos) {SdBaseFile::getpos(pos);}
193c193
<   void setpos(fpos_t* pos) {SdBaseFile::setpos(pos);}
---
>   void setpos(FatPos_t* pos) {SdBaseFile::setpos(pos);}
diff -rb ArduinoOldVer/SdFat/bufstream.h Arduino/libraries/SdFat/bufstream.h
61c61
<   void getpos(fpos_t *pos) {
---
>   void getpos(FatPos_t *pos) {
72c72
<   void setpos(fpos_t *pos) {
---
>   void setpos(FatPos_t *pos) {
diff -rb ArduinoOldVer/SdFat/istream.cpp Arduino/libraries/SdFat/istream.cpp
70c70
<   fpos_t pos;
---
>   FatPos_t pos;
143c143
<   fpos_t endPos;
---
>   FatPos_t endPos;
231c231
<   fpos_t pos;
---
>   FatPos_t pos;
264c264
<   fpos_t endPos;
---
>   FatPos_t endPos;
323c323
<   fpos_t pos;
---
>   FatPos_t pos;
384c384
<   fpos_t pos;
---
>   FatPos_t pos;
407c407
<   fpos_t pos;
---
>   FatPos_t pos;
diff -rb ArduinoOldVer/SdFat/istream.h Arduino/libraries/SdFat/istream.h
138a139
>
144c145
<   istream &operator>>(int16_t& arg) {
---
>   istream &operator>>(int& arg) {
153c154
<   istream &operator>>(uint16_t& arg) {
---
>   istream &operator>>(unsigned int& arg) {
162c163
<   istream &operator>>(int32_t& arg) {
---
>   istream &operator>>(long& arg) {
171c172
<   istream &operator>>(uint32_t& arg) {
---
>   istream &operator>>(unsigned long& arg) {
256c257
<   int16_t getch(fpos_t* pos) {
---
>   int16_t getch(FatPos_t* pos) {
264c265
<   virtual void getpos(fpos_t* pos) = 0;
---
>   virtual void getpos(FatPos_t* pos) = 0;
271c272
<   virtual void setpos(fpos_t* pos) = 0;
---
>   virtual void setpos(FatPos_t* pos) = 0;
diff -rb ArduinoOldVer/SdFat/ostream.cpp Arduino/libraries/SdFat/ostream.cpp
158a159,160
>   putStr(str);
>   /*
164a167
>   */
diff -rb ArduinoOldVer/SdFat/ostream.h Arduino/libraries/SdFat/ostream.h
137c137
<   ostream &operator<< (int16_t arg) {
---
>   ostream &operator<< (int arg) {
145c145
<   ostream &operator<< (uint16_t arg) {
---
>   ostream &operator<< (unsigned int arg) {
153c153
<   ostream &operator<< (int32_t arg) {
---
>   ostream &operator<< (long arg) {
161c161
<   ostream &operator<< (uint32_t arg) {
---
>   ostream &operator<< (unsigned long arg) {


I suggest you try the bench example.  Remove this line to get it to compile:
Code: [Select]
  cout << pstr("Free RAM: ") << FreeRam() << endl;
Title: Re: Teensy 3.0
Post by: MichaelMeissner on Oct 08, 2012, 10:11 pm

Well lets just not tell them.  :D

Well given kickstarter has now changed the rules, and Teensy 3.0 as it was funded would not have been allowed under the new rules.  So it may not make any difference whether you tell them or not.  Paul himself has spoken out against the new rules, and I imagine hardware projects like the Teensy will just go elsewhere.

Kickstarter can go back to being a tip jar to fund art projects, as it evidently wants to do so.  As I said in their blog, I wish them a good life, but I have stopped looking at KS for interesting tech projects to fund.  The only things I do on KS now is to check on updates to the 4 tech products I recently backed (RadioBlock, Teensy, Digispark, and JumpShot) as well as the one non-tech product (Deck of Extraordinary Voyages)
Title: Re: Teensy 3.0
Post by: pjrc on Oct 09, 2012, 01:37 am
I believe the recent rule change was motived mainly to protect Kickstarter from liability, rather than protecting backers from failed projects.  I haven't seen anything really conclusive about the Hanfree lawsuit, but the plaintiff publicly said he asked the court to rule the nature of the transaction was an ordinary sale.  I'm an engineer, not an attorney, so I'm not going to speculate what that might mean?

It could also be purely coincidental that the "not a store" rule change came about just as the Hanfree lawsuit was making it's way through the legal system.

Here's the failed Hanfree project, where you can read all the ugly details in the comments.

http://www.kickstarter.com/projects/831303939/hanfree-ipad-accessory-use-the-ipad-hands-free/comments

Title: Re: Teensy 3.0
Post by: pico on Oct 09, 2012, 08:43 am

I'm an engineer, not an attorney, so I'm not going to speculate what that might mean?


It's the legal analog of Brooks' law: "Adding lawyers to an already bad situation is only going to make things worse."
Title: Re: Teensy 3.0
Post by: retrolefty on Oct 11, 2012, 06:55 pm
Just wanted to let others know of my progress so far on using my new Teensy 3.0 board. I had to order a micro USB cable and it arrived yesterday. I had previously loaded the modified IDE and the Teensy driver thingee, so I just attached the Teensey to the cable and plugged it in. PC seemed to be happy with the attachment and a led on the Teensey was blinking away so I assumed they ship it with the blink sketch loaded. I opened the IDE, selected the Teensey 3.0 board, loaded the mimumSketch example and it upload. I was a little surprised when the Teesey loader pop window sprung up, as I had no idea how the Teensy works with the arduino IDE, but the loader has a option to follow a scrip log and it seemed to all be working correctly, even though in the IDE results window is says something about compile size is zero bytes, but the Teensy loader pop-up log shows all the correct size info and a lot of other stuff. Anyway the Teensy board did stop blinking it's led, so everything seemed to upload and run OK. I then loaded blink sketch example in the IDE and hit upload and everything worked again and the board did indeed start blinking it's led again.

So I guess the report is that the Teensey 3.0 seems to work right out of the box as designed even for this software-installing-challenged kind of guy that I am. I still haven't a clue what I might do with this board yet. And Paul seems to be releasing a new IDE version every other day to add some new arduino library update, so it seems kind of silly to rush into anything. But it's a great little product with a lot of promise ahead for it I think. I kind of hope a Teensey forum might start up to help support this product, if one is not already around somewhere?

I'm still getting over the shock of how....well teensey this thing is, so small.

Lefty
Title: Re: Teensy 3.0
Post by: pjrc on Oct 11, 2012, 07:51 pm
@Lefty - glad it's working.  I fixed the size reporting in beta4.  This evening I'm going to publish beta5, with a master-only port of Wire (slave mode to be filled in next week), and Serial1, Serial2, and Serial3 working.

@fat16lib - I applied the patch.  Now the code compiles.  :)  It's not quite working, but that's probably a bug on my end.  I'm investigating now.  Will try to get those 24 Mbit/sec optimized routines written for you.
Title: Re: Teensy 3.0
Post by: Jantje on Oct 11, 2012, 07:53 pm
Lefty
Quote
I'm still getting over the shock of how....well teensy this thing is, so small.

I know how you feel. When I got my first teensy in hands I was also going like "this small"? And indeed it all worked great out of the box and the blink sample is preloaded (This is part of Paul testing the boards).

I would really advice Arduino to look at what Paul is doing (more often). For instance:  Even though the teensy 2 uses the same chip as the Leonardo it does not have the 2 com ports issue which is very distracting. The due has 2 com ports. I guess if they had used halfkay (the window that popped up during upload) like Teensy they would not need 2 com ports.

Best regards
Jantje
Title: Re: Teensy 3.0
Post by: DuaneB on Oct 11, 2012, 07:59 pm
My Teensy is on its way. I got a friend to order from Ireland where it has arrived, looking forward to it finishing the final leg of its journey to Dubai next week.

Duane B.
Title: Re: Teensy 3.0
Post by: pjrc on Oct 11, 2012, 09:29 pm
I've been working with the SdFat beta for the last hour, digging into why it's not working.  Turns out __attribute__((packed)) bit me yet again.  Forgot I've started from a clean copy to apply the patch.
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 11, 2012, 10:13 pm
Paul,

I mailed you a version with mods for faster reads/writes.  It compiles for Teensy 3.0 but is not tested on Teensy 3.0 since I have not received the replacement for the missing Teensy 3.0 that Robin sent yesterday.

The results for a AVR Mega with 4096 byte writes and reads are promising.

Quote

Type any character to start
Free RAM: 2666
Type is FAT16
File size 5MB
Buffer size 4096 bytes
Starting write test.  Please wait up to a minute
Write 536.40 KB/sec
Maximum latency: 10336 usec, Minimum Latency: 6908 usec, Avg Latency: 7592 usec

Starting read test.  Please wait up to a minute
Read 595.04 KB/sec
Maximum latency: 7984 usec, Minimum Latency: 6804 usec, Avg Latency: 6877 usec
Title: Re: Teensy 3.0
Post by: pjrc on Oct 12, 2012, 03:08 am
Here's my first attempt at 24 Mbit/sec speed in SdFat.  It still needs work (block send it's working at all), but even this makes a pretty substantial speedup.

Code: [Select]

//------------------------------------------------------------------------------
/**
* Initialize hardware SPI
* Set SCK rate to F_CPU/pow(2, 1 + spiRate) for spiRate [0,6]
*/
static void spiInit(uint8_t spiRate) {
  // See avr processor documentation
#if defined(USE_NATIVE_MK20DX128) && 1
  SIM_SCGC6 |= SIM_SCGC6_SPI0;
  SPI0_MCR = SPI_MCR_MDIS | SPI_MCR_HALT;
  // spiRate = 0 : 24 or 12 Mbit/sec
  // spiRate = 1 : 12 or 6 Mbit/sec
  // spiRate = 2 : 6 or 3 Mbit/sec
  // spiRate = 3 : 3 or 1.5 Mbit/sec
  // spiRate = 4 : 1.5 or 0.75 Mbit/sec
  // spiRate = 5 : 250 kbit/sec
  // spiRate = 6 : 125 kbit/sec
  uint32_t ctar;
  switch (spiRate) {
   case 0: ctar = SPI_CTAR_FMSZ(7) | SPI_CTAR_DBR | SPI_CTAR_BR(0); break;
   case 1: ctar = SPI_CTAR_FMSZ(7) | SPI_CTAR_BR(0); break;
   case 2: ctar = SPI_CTAR_FMSZ(7) | SPI_CTAR_BR(1); break;
   case 3: ctar = SPI_CTAR_FMSZ(7) | SPI_CTAR_BR(2); break;
   case 4: ctar = SPI_CTAR_FMSZ(7) | SPI_CTAR_BR(3); break;
#if F_BUS == 48000000
   case 5: ctar = SPI_CTAR_FMSZ(7) | SPI_CTAR_PBR(1) | SPI_CTAR_BR(5); break;
   default: ctar = SPI_CTAR_FMSZ(7) | SPI_CTAR_PBR(1) | SPI_CTAR_BR(6);
#elif F_BUS == 24000000
   case 5: ctar = SPI_CTAR_FMSZ(7) | SPI_CTAR_PBR(1) | SPI_CTAR_BR(4); break;
   default: ctar = SPI_CTAR_FMSZ(7) | SPI_CTAR_PBR(1) | SPI_CTAR_BR(5);
#else
#error "MK20DX128 bus frequency must be 48 or 24 MHz"
#endif
  }
  SPI0_CTAR0 = ctar;
  SPI0_MCR = SPI_MCR_MSTR;
  CORE_PIN11_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);
  CORE_PIN12_CONFIG = PORT_PCR_MUX(2);
  CORE_PIN13_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);
#else
  SPCR = (1 << SPE) | (1 << MSTR) | (spiRate >> 1);
  SPSR = spiRate & 1 || spiRate == 6 ? 0 : 1 << SPI2X;
#endif
}
//------------------------------------------------------------------------------
/** SPI receive a byte */
static inline __attribute__((always_inline))
  uint8_t spiRec() {
#if defined(USE_NATIVE_MK20DX128) && 1
  SPI0_MCR = SPI_MCR_MSTR | SPI_MCR_CLR_RXF;
  SPI0_SR = SPI_SR_TCF;
  SPI0_PUSHR = 0xFF;
  while (!(SPI0_SR & SPI_SR_TCF)) ;
  return SPI0_POPR;
#else
  SPDR = 0XFF;
  while (!(SPSR & (1 << SPIF)));
  return SPDR;
#endif
}
//------------------------------------------------------------------------------
/** SPI read data - only one call so force inline */
static inline __attribute__((always_inline))
  void spiRead(uint8_t* buf, uint16_t nbyte) {
#if defined(USE_NATIVE_MK20DX128) && 1
  SPI0_MCR = SPI_MCR_MSTR | SPI_MCR_CLR_RXF;
  uint32_t status, txcount=0, rxcount=0;
  while (txcount < nbyte) {
    status = SPI0_SR;
    if (((status >> 12) & 15) < 4) {
      SPI0_PUSHR = 0xFF;
      txcount++;
    }
    if (((status >> 4) & 15) > 0) {
      *buf++ = SPI0_POPR;
      rxcount++;
    }
  }
  while (rxcount < nbyte) {
    if (((status >> 4) & 15) > 0) {
      *buf++ = SPI0_POPR;
      rxcount++;
    }
  }
#else
  if (nbyte-- == 0) return;
  SPDR = 0XFF;
  for (uint16_t i = 0; i < nbyte; i++) {
    while (!(SPSR & (1 << SPIF)));
    buf[i] = SPDR;
    SPDR = 0XFF;
  }
  while (!(SPSR & (1 << SPIF)));
  buf[nbyte] = SPDR;
#endif
}
//------------------------------------------------------------------------------
/** SPI send a byte */
static inline __attribute__((always_inline))
  void spiSend(uint8_t b) {
#if defined(USE_NATIVE_MK20DX128) && 1
  SPI0_SR = SPI_SR_TCF;
  SPI0_PUSHR = b;
  while (!(SPI0_SR & SPI_SR_TCF)) ;
#else
  SPDR = b;
  while (!(SPSR & (1 << SPIF)));
#endif
}
//------------------------------------------------------------------------------
/** SPI send block - only one call so force inline */
static inline __attribute__((always_inline))
  void spiSendBlock(uint8_t token, const uint8_t* buf) {
#if defined(USE_NATIVE_MK20DX128) && 0  // This does not work... why??
  uint32_t status, txcount=0;
  SPI0_SR = SPI_SR_TCF;
  SPI0_PUSHR = token;
  while (txcount < 512) {
    status = SPI0_SR;
    if (((status >> 12) & 15) < 4) {
      SPI0_PUSHR = *buf++;
      txcount++;
    }
  }
  while (1) {
    status = SPI0_SR;
    if (((status >> 12) & 15) == 0) break;
  }
  while (!(SPI0_SR & SPI_SR_TCF)) ;
#else
  SPDR = token;
  for (uint16_t i = 0; i < 512; i += 2) {
    while (!(SPSR & (1 << SPIF)));
    SPDR = buf[i];
    while (!(SPSR & (1 << SPIF)));
    SPDR = buf[i + 1];
  }
  while (!(SPSR & (1 << SPIF)));
#endif
}
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 13, 2012, 04:36 pm

I received my Teensy 3.0 yesterday, it is awesome! I downloaded the latest beta and got the board going on first try! I have used Teensy 2.0 before so maybe that has a bit to do with it working so quickly but, I am impressed!

So far, I have just changed and reloaded the blink code a few times, and found the reload of a sketch is blazing fast!

Here is the latest link to the beta code:

http://www.pjrc.com/teensy/beta/arduino-1.0.1-teensy3-beta5-linux32.tar.gz

http://www.pjrc.com/teensy/beta/arduino-1.0.1-teensy3-beta5-linux64.tar.gz

http://www.pjrc.com/teensy/beta/arduino-1.0.1-teensy3-beta5-macos.zip

http://www.pjrc.com/teensy/beta/arduino-1.0.1-teensy3-beta5-windows.zip
Title: Re: Teensy 3.0
Post by: DuaneB on Oct 13, 2012, 04:42 pm
Paul should keep a map of how far Teensy 3.0 has spread, can anyone beat Dubai ?

Duane B
Title: Re: Teensy 3.0
Post by: pjrc on Oct 14, 2012, 12:13 pm
I'm glad Teensy 3 is working out well, especially the fast upload process.

I actually put months of work into optimizing the upload speed.  I spent quite a bit of time analyzing the Teensy 2.0 upload process.  The 2.0 bootloader is quite simple (it needs to be, since it fits entirely within 512 bytes of code).  It receives a chunk of data, then programs it to the flash, then sends an ACK.  That works well, but it doesn't achieve the best speed.  First, the entire chip needs to be erased when the first write request shows up.  Erasing the chip earlier isn't an option, because users expect to be able to go into bootloader mode, but if nothing is transmitted the chip is expected to remain unmodified.  So there's a lag while erasing, and then while writing the first chunk.  Then when the ACK is sent, the software on the PC sends the next chunk.  Because it's a user space program, it's subjected to ordinary scheduling delays, which can average several milliseconds before the next chunk is sent.  Over the span of writing many chunks, those USB latencies and operating system scheduling delays add up.  More time is spent waiting than writing.

In 3.0, I implemented quite a lot of buffering in RAM.  So while the chip is erasing, several chunks of data are buffered into RAM.  Once programming begins, there's plenty of data buffered to keep the speed constrained only by the flash writing.  The operating system's userspace scheduling delays result in bursts of incoming data to refill the buffers.  With enough on-chip buffering, the flash writing never stalls waiting for more data.  So the upload speed runs at very close to the maximum possible speed imposed only by the flash itself.  I used the chip's fast DMA engine to copy from the buffers to the flash controller, to minimize the non-writing time.  But overall, buffering in the chip's RAM is the key to avoiding delay.

There's another speedup I've designed, which isn't currently in use on Teensy 3.0.  While the loading speed is nearly as fast as the flash memory allows, there is about a 1 second delay (longer on some windows machines) from the instant the compiler produces the .hex file to the upload actually beginning.  When Teensy reboots into bootloader mode, the USB disconnects, and then it reappears as the new device which accepts the download.  Leonardo does the same.  Each operating system does USB enumeration slightly differently, but there are delays associated with USB reset signals and other USB stuff, which add up to about 1 second or more.

My hope is to eliminate all that delay by "rebooting" into the bootloader code without disconnecting the USB.  The support for it is all in place in Teensy 3.0, so I hope to enable this with a software update sometime next year (2013).  But this is a lot of difficult software work to implement successfully on the computer side.  The loader needs to deal with requesting the "reboot" and then checking to see if it was successful.  There are a number of complications with basically switching a USB device at runtime without going through the proper enumeration process.  If it doesn't work, of course the fallback is to disconnect.  Success or failure needs to be determined in a matter of milliseconds to be of any value.  All that needs to be done times 3, because each operating system has dramatically different low-level USB APIs.  But if it is successful, the opportunity for speedup is pretty incredible.  That 1+ second USB enumeration is now the single largest delay (assuming your machine is fast and the build-dependency patch is avoiding full recompile).  I want to turn that last 1 second delay into only single-digit milliseconds!

Yes, I'm obsessed with upload speed optimization.......
Title: Re: Teensy 3.0
Post by: Jantje on Oct 14, 2012, 02:11 pm

Yes, I'm obsessed with upload speed optimization.......

I would say :"Paul wants to deliver quality"  :D
But then everything is perception  ]:D
Best regards
Jantje
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 14, 2012, 11:04 pm

To see a bench mark, I wrote a code to compare the Teensy 3.0 to the Uno. It calculates sin() of 0 to 400.

Rather impressive difference!

Code:
Code: [Select]
[code]
float sinanswers[401];

unsigned long time1 = 0;
unsigned long time2 = 0;
void setup()
{

  Serial.begin(9600); // USB is always 12 Mbit/sec
  delay(1000);
  Serial.print("Here");
  delay(4000);
  time1 = micros();
  for (int i = 0; i < 400; i++)
  {
    sinanswers[i] = sin(i);

  }
  time2 = micros();

  unsigned long elapsed = time2 - time1;
  for (int i = 0; i < 400; i++)
  {
    Serial.println(sinanswers[i]);
    Serial.print(" ");
    Serial.println(i);
  }

  Serial.print("time elasped = ");
  Serial.print(elapsed);
  Serial.print(" micros");
}

void loop()
{

}


Results:
Code: [Select]


  //time elasped = 29721 micros = teensy
  //time elasped = 47436 micros = Uno
[/code]
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 14, 2012, 11:06 pm

This code was only tested on the Teensy 3.0. It would not fit in the SRAM of the Uno.

Code: [Select]

float sinanswers[1001];
float conanswers[1001];
float tananswers[1001];
unsigned long time1 = 0;
unsigned long time2 = 0;
void setup()
{

  Serial.begin(9600); // USB is always 12 Mbit/sec
  delay(1000);
  Serial.print("Here");
  delay(4000);
  time1 = micros();
  for (int i = 0; i < 1000; i++)
  {
    sinanswers[i] = sin(i);
    conanswers[i] = cos(i);
    tananswers[i] = tan(i);
  }
  time2 = micros();

  unsigned long elapsed = time2 - time1;
  for (int i = 0; i < 1000; i++)
  {
    Serial.println(sinanswers[i]);
    Serial.print(" ");
    Serial.println(i);
  }
  for (int i = 0; i < 1000; i++)
  {
    Serial.println(sinanswers[i]);
    Serial.print(" ");
    Serial.println(i);
    Serial.println(conanswers[i]);
  }
  for (int i = 0; i < 1000; i++)
  {
    Serial.println(sinanswers[i]);
    Serial.print(" ");
    Serial.println(i);
    Serial.println(tananswers[i]);
  }
  Serial.print("time elasped = ");
  Serial.print(elapsed);
  Serial.print(" micros");
}

void loop()
{

  }


Results:
Code: [Select]
//time elasped = 278183 micros = teensy
Title: Re: Teensy 3.0
Post by: Nantonos on Oct 14, 2012, 11:46 pm
It won't fit in a Mega2560 either

Quote
Binary sketch size: 6,180 bytes (of a 258,048 byte maximum)
Estimated used SRAM memory: 12,747 bytes (of a 8192 byte maximum)
Title: Re: Teensy 3.0
Post by: retrolefty on Oct 14, 2012, 11:51 pm
May be OT,  but is the default int size on a Teensy 3.0 different then on a standard arduino? And if different any possible problems when using arduino libraries and others users sketches?

Lefty

Title: Re: Teensy 3.0
Post by: Nantonos on Oct 14, 2012, 11:54 pm

Rather impressive difference!

Code: [Select]


 //time elasped = 29721 micros = teensy
 //time elasped = 47436 micros = Uno


Is it?

Uno: 8bit, 16MHz, no FPU
Teensy 3.0: 32bit, 48 MHz, FPU (Cortex M4 has an FPU, right?)

Now, I understand that MPU clockspeed is not the only factor, there is also memory speed and instructions/cycle and address size and quality of implementation. But at 3x the clockspeed and with hardware FPU rather than software FP emulation, I would (naively?) have expected more than a 1.5x speedup.

Edit: you can't quote code? Really?
Title: Re: Teensy 3.0
Post by: Nantonos on Oct 14, 2012, 11:58 pm

May be OT,  but is the default int size on a Teensy 3.0 different then on a standard arduino? And if different any possible problems when using arduino libraries and others users sketches?


Yeah I would tend to use uint16_t and so on when benchmarking, to compare like with like.
Title: Re: Teensy 3.0
Post by: el_supremo on Oct 15, 2012, 12:30 am
Quote
(Cortex M4 has an FPU, right?)


Not necessarily apparently. From wikipedia:
Quote
The Cortex-M4 adds DSP instructions and an optional single-precision floating-point unit. If the Cortex-M4 has the floating point unit, then it is known as the Cortex-M4F.


Pete
Title: Re: Teensy 3.0
Post by: pjrc on Oct 15, 2012, 12:35 am
int is 32 bits on ARM and 16 bits on AVR.  You might think that would cause lots of compatibility problems, but so far it seems pretty rare.  There are some programs that depend upon rollover, but most of them use 8 bits with "byte", "unsigned char" or "uint8_t".  It seems most authors who use such tricks are pretty conscientious about declaring proper types for the expected number of bits.

On ARM, sometimes using 8 or 16 bits is actually slower than 32 bits.  The CPU registers are natively 32 bits, so in some cases the compiler is forced to insert logical and instructions to mask off the unused bits.

The M4 core on Teensy 3.0 does not have a FPU, so floating point isn't expected to be dramatically fast.
Title: Re: Teensy 3.0
Post by: Jantje on Oct 15, 2012, 12:37 am


Rather impressive difference!

Code: [Select]


 //time elasped = 29721 micros = teensy
 //time elasped = 47436 micros = Uno


Is it?

I had the same reflection. But looking at the code I think we are comparing apples with pears.
I see that sin is defined as
Code: [Select]
extern double sin(double __x) __ATTR_CONST__;
and double is not a fixed in bytes according to http://en.wikipedia.org/wiki/Double-precision_floating-point_format (http://en.wikipedia.org/wiki/Double-precision_floating-point_format)
I'm not sure how to fix this but If you would print the result of sin(1.2) with teensy 3 and uno I expect to get different numbers.
Best regards
Jantje
Title: Re: Teensy 3.0
Post by: Jantje on Oct 15, 2012, 12:44 am

int is 32 bits on ARM and 16 bits on AVR.  You might think that would cause lots of compatibility problems, but so far it seems pretty rare.  There are some programs that depend upon rollover, but most of them use 8 bits with "byte", "unsigned char" or "uint8_t".  It seems most authors who use such tricks are pretty conscientious about declaring proper types for the expected number of bits.

On ARM, sometimes using 8 or 16 bits is actually slower than 32 bits.  The CPU registers are natively 32 bits, so in some cases the compiler is forced to insert logical and instructions to mask off the unused bits.

The M4 core on Teensy 3.0 does not have a FPU, so floating point isn't expected to be dramatically fast.

Paul
From my coding experiences I would not expect many C/C++ issues because Arduino is all source and it communicates with very strictly defined protocols. It would be a different story if you had to link in real binaries (I mean .lib .a .dll .o ...) and not the sources (I mean .c .cpp .h ...) or you had to communicate with other running programs.
The troubles I expect would be with the code that uses the registries directly or uses hardware specific things. I have read you made some simulation code so that should solve most of the migration problems.
Great work I would say.
Best regards
Jantje
Title: Re: Teensy 3.0
Post by: Nantonos on Oct 15, 2012, 12:51 am
Paul, Pete, thanks for the clarification.

Jantje, I had just downloaded the source of avr-gcc and found the same thing. I also found sin.S which (once you get past the license and checks for redefinition) is just

Code: [Select]
#include "fp32def.h"
#include "asmdef.h"

/* float sin (float A);
    The sin() function returns the sine of A, where A is given in radians.
*/

ENTRY sin
push rA3
rcall _U(__fp_rempio2)
pop r0
sbrc r0, 7
subi ZL, -2
rjmp _U(__fp_sinus)
ENDFUNC
Title: Re: Teensy 3.0
Post by: Jantje on Oct 15, 2012, 01:34 am
Nantonos

Pual, Pete, thanks for the clarification.

Jantje, I had just downloaded the source of avr-gcc and found the same thing. I also found sin.S which (once you get past the license and checks for redefinition) is just

Code: [Select]
#include "fp32def.h"
#include "asmdef.h"

/* float sin (float A);
     The sin() function returns the sine of A, where A is given in radians.
*/

ENTRY sin
push rA3
rcall _U(__fp_rempio2)
pop r0
sbrc r0, 7
subi ZL, -2
rjmp _U(__fp_sinus)
ENDFUNC


This is just one level to deep for me. :~
This definition would be the one I would expect the UNO to use. Are you sure there is no definition of sin with long double as well?
What does the S in sin.S stand for? I googled it but it is to close to sin to find something relevant quickly.
Best regards
Jantje

PS being someone who doesn't give up easily I hope the S to stand for small or single memory model and then a sin.L (or something else) could stand for large memory model containing the long double version.  ]:D
Title: Re: Teensy 3.0
Post by: Nantonos on Oct 15, 2012, 02:05 am
It seems that .S is being used for assembler files. (And no, I don't particularly undestand the AVR assembler. Showing my age, last time I coded in assembler it was for the Zilog Z80).

It also seems that the (8bit) Arduino family consider float and double to be identical, and to mean 32bit IEEE floating point.
Title: Re: Teensy 3.0
Post by: DuaneB on Oct 15, 2012, 08:09 am
Hi,
   I had a look through Paul implementation of the Arduino libraries last night, there has been a massive amount of work

Hardware/teensy/cores/teensy3/

I found that fastest way to get upto speed on the AVRs was to read through the libraries.

Duane B
Title: Re: Teensy 3.0
Post by: Coding Badly on Oct 15, 2012, 08:43 am
I also found sin.S which (once you get past the license and checks for redefinition) is just...


Well, that's a bit of sin.  The code you posted prepares a small stack frame or preserves a working register (the push/pop), calls another function that actually determines the sin, then makes an adjustment for the sign.  In other words, the bulk of the sin function is somewhere else.
Title: Re: Teensy 3.0
Post by: pito on Oct 15, 2012, 12:19 pm
..not sure your measurement does reflect the reality

 //time elasped = 29721 micros = teensy
 //time elasped = 47436 micros = Uno

A typical 32bit float sin() on an CM3 takes ~1050cycles = ~22usec @48MHz so it seems you have to get something like 9000 micros max...

CM3 none FPU :
fZ = fX * fY; // 41 cycles
fZ = sqrt(fY); // 624 cycles
fZ = sin(1.23); // 1017 cycles

CM4 with FPU:
fZ = fX * fY; // 6 cycles
fZ = sqrt(fY); // 20 cycles
fZ = sin(1.23); // 124 cycles

http://www.micromouseonline.com/2011/10/26/stm32f4-the-first-taste-of-speed/?doing_wp_cron=1350295560.3099548816680908203125#axzz29MQwGQCw
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 15, 2012, 01:32 pm

  I can only say that my code saves the results to an array which is printed after the math has been timed. Could the saving to the array cause the time difference?
Title: Re: Teensy 3.0
Post by: pito on Oct 15, 2012, 02:09 pm
.. a clock2clock comparision says teensy shall be ~3times faster than Uno (@16MHz) and teensy is 32bit CM3, so a 32bit fp sin() cannot be "only" 1.6x faster than Uno.. saving to an array cannot create such overhead, indeed..
Title: Re: Teensy 3.0
Post by: Jantje on Oct 15, 2012, 03:01 pm

.. a clock2clock comparision says teensy shall be ~3times faster than Uno (@16MHz) and teensy is 32bit CM3, so a 32bit fp sin() cannot be "only" 1.6x faster than Uno.. saving to an array cannot create such overhead, indeed..

My 2 cents: A possible explanation may be that the compile options for teensy are not similar to those of UNO.
Best regards
Jantje
Title: Re: Teensy 3.0
Post by: pito on Oct 15, 2012, 03:22 pm
This is with STM32F100 CM3 @48MHz (Teensy compatible I think):
Code: [Select]

timer = millis;
         for (i=0;i<400;i++) {
           sinres[i]=sinf((float)i);
         }
timer = millis - timer;
printf("\rElapsed time float sin 400x into array: %u millis\n", timer);
         
timer = millis;
         for (i=0;i<400;i++) {
           sinresd[i]=sinl((long double)i);
         }
timer = millis - timer;
printf("\rElapsed time double sin 400x into array: %u millis\n", timer);


Elapsed time float sin 400x into array: 8 millis
Elapsed time double sin 400x into array: 19 millis
Title: Re: Teensy 3.0
Post by: pjrc on Oct 15, 2012, 03:41 pm
There are indeed some complex things going on with this test.

For example, this takes 138 us:

Code: [Select]

 for (int i = 0; i < 3; i++)
 {
   sinanswers[i] = sin(i);
 }
 time2 = micros();


But this takes takes 229 us.... almost twice as long, just because the input is offset by 400.  Clearly sin()'s execution time is not constant.

Code: [Select]

 for (int i = 0; i < 3; i++)
 {
   sinanswers[i] = sin(i+400);
 }
 time2 = micros();


I suspected the slowness was due to computing double precision.  But I tried changing sin() to sinf(), and amazingly sinf() takes MUCH longer.  Clearly newlib or libgcc is not optimized very well, or some settings aren't quite right.  I need to dig into that......


Title: Re: Teensy 3.0
Post by: pito on Oct 15, 2012, 04:29 pm
And your test with 1000x (actually 500x) sin cos tan (STM32F100 CM3 @48MHz):
Code: [Select]

timer = millis;
         for (i=0;i<500;i++) {
           fsi[i]=sinf((float)i);
           fco[i]=cosf((float)i);
           fta[i]=tanf((float)i);
         }
timer = millis - timer;
printf("\rElapsed time float sin cos tan 500x into array: %u millis\n", timer);

Elapsed time float sin cos tan 500x into array: 31 millis

Such big arrays do not fit into my 8kB RAM so double it for 1000x (=62 millis, yours is 278 ms). Double it again for a double precision fp result.
p.
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 15, 2012, 05:56 pm
First the Teensy Kinetis CPU does not have hardware floating point.  Hardware floating point is optional for Cortex M4.  Only the high end K20 processors have floating point http://www.freescale.com/files/microcontrollers/doc/fact_sheet/KNTSK20FMLYFS.pdf (http://www.freescale.com/files/microcontrollers/doc/fact_sheet/KNTSK20FMLYFS.pdf).

newlib math function are really old C functions.

newlib execution times depend on the value of the arguments.

Here are two examples for 32-bit sine:
Code: [Select]
float sinf(float);

I ran this code
Code: [Select]

float sinanswers[401];
float sinarg[401];
 for (int i = 0; i < 400; i++) {
   sinarg[i] = factor*i;
 }
 time1 = micros();
 for (int i = 0; i < 400; i++) {
   sinanswers[i] = sinf(sinarg[i]);
 }
 time2 = micros();

If factor is 0.01 so the range is from 0.0 - 4.0
Quote

time elapsed = 17110 micros



If factor is 1.0 so the range is 0.0 - 400.0
Quote

time elapsed = 105353 micros


The algorithms for 64-bit double are totally different than for 32-bit float.

Much of this dates back to work in the 1980s on BSD Unix at UC Berkeley.  I was at UCB when BSD Unix was developed.

Bill Joy was a key developer of BSD and used it at Sun Microsystems as the base for Solaris.
Title: Re: Teensy 3.0
Post by: DuaneB on Oct 15, 2012, 06:48 pm
Hi,
   I assume that most of us will use fixed point maths, but for those that have a reason to use float and double, is there an alternative implementation that can be included at compile time or some other work around that provide more recent and faster implementations ?

  Duane B

rcarduino.blogspot.com (http://rcarduino.blogspot.com)
Title: Re: Teensy 3.0
Post by: westfw on Oct 15, 2012, 07:06 pm
avr-gcc has floating point algorithms that have been carefully optimized for the AVR architecture.
arm-gcc using newlib presumably has generic algorithms...
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 16, 2012, 12:05 am
Thanks to Paul's help, I have first results for SdFat with large reads and writes.

Writes are slow since I am not using the full TX fifo yet.

Here are results for 4096 byte writes and reads using the SdFat bench.ino example.

Quote

Type is FAT16
File size 5MB
Buffer size 4096 bytes
Starting write test.  Please wait up to a minute
Write 723.07 KB/sec
Maximum latency: 21609 usec, Minimum Latency: 4929 usec, Avg Latency: 5625 usec

Starting read test.  Please wait up to a minute
Read 1255.56 KB/sec
Maximum latency: 3874 usec, Minimum Latency: 3204 usec, Avg Latency: 3260 usec


I think I know how to speedup writes by using all four bytes of the SPI fifo.

DMA may be required to achieve maximum speed since using the fifo has a bit more overhead than I first assumed.
Title: Re: Teensy 3.0
Post by: Jantje on Oct 16, 2012, 12:32 am
fat16lib
I don't know much about sdcards and read and write speeds but those read figures look impressive to me. :smiley-eek:
Best regards
Jantje
Title: Re: Teensy 3.0
Post by: MichaelMeissner on Oct 16, 2012, 09:49 pm

What does the S in sin.S stand for? I googled it but it is to close to sin to find something relevant quickly.

The GCC compiler passes .S files through the C preprocessor, so that you can use #ifdef and #define within assembly files (because of the #ifdef, you can have one .S file that has code for several different targets, and the defines are set based on the -m<xxx> options on the command line).  If the file is .s (lowercase), it is passed directly to the assembler and does not go through the preprocessor.
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 17, 2012, 05:18 am
Teensy 3.0 is great.  The hardware is a little gem and the way Paul did the software makes development really easy.

I now have optimized native SPI running in programmed I/O mode and performance is really good.  Here are my latest results for SdFat.

Quote

Free RAM: 4219
Type is FAT16
File size 10MB
Buffer size 8192 bytes
Starting write test.  Please wait up to a minute
Write 1801.74 KB/sec
Maximum latency: 80495 usec, Minimum Latency: 4398 usec, Avg Latency: 4543 usec

Starting read test.  Please wait up to a minute
Read 2017.82 KB/sec
Maximum latency: 4473 usec, Minimum Latency: 4048 usec, Avg Latency: 4057 usec


This is with the CPU overclocked at 96 MHz.  I used an industrial SD designed for embedded use.
Title: Re: Teensy 3.0
Post by: TonyD on Oct 17, 2012, 11:37 am
Great board.

Is there any news when we get buy one? Are there any European distributors stocking it?
Title: Re: Teensy 3.0
Post by: pjrc on Oct 17, 2012, 12:48 pm
Quote

Is there any news when we get buy one? Are there any European distributors stocking it?



It's in stock in the Netherlands now.

http://www.pieterfloris.nl/shop/category.php?id_category=45

Soon it'll be in stock in Germany...

http://www.hitechstore.de/produkte/3/
Title: Re: Teensy 3.0
Post by: Nantonos on Oct 17, 2012, 01:19 pm

It's in stock in the Netherlands now.

http://www.pieterfloris.nl/shop/category.php?id_category=45


Ordered.

Paul, feel free to ignore my earlier pm about UPS shipping rates from US to Europe.  ]:D
Title: Re: Teensy 3.0
Post by: TonyD on Oct 18, 2012, 11:45 am
Thanks Paul, ordering one now.
Title: Re: Teensy 3.0
Post by: DuaneB on Oct 18, 2012, 01:39 pm
Hi,
   Mine arrived in Dubai last night

(http://2.bp.blogspot.com/-LfWQKxIAOoI/UH_pGCmXrVI/AAAAAAAAAnI/9G3JTkFxgzU/s1600/tDubai.png)

Looking forward to trying some of the RCArduino projects on the board.

Duane B

rcarduino.blogspot.com (http://rcarduino.blogspot.com)
Title: Re: Teensy 3.0
Post by: pico on Oct 19, 2012, 05:29 pm
Ordered one just now! Didn't get in on the KS in time, but now I can be one of the cool kids with a teensy 3.0.  :smiley-mr-green:

Looking forward to trying out the new SdFat16, and having a play with Paul's new development environment. BTW, Paul, thanks so much for providing the makefiles! Really appreciated by this recalcitrant emacs/command line tools user. Icing on the cake!
Title: Re: Teensy 3.0
Post by: hrh1919 on Oct 20, 2012, 01:33 am
Can the Teensy 3.0 USB interface be used to obtain a higher data acquisition rate than is possible with the serial interface?   If yes, could you provide one or more links to help me get started in the right direction?

Thank you for your sharing your expertise.

Howard
Title: Re: Teensy 3.0
Post by: pjrc on Oct 20, 2012, 01:37 am
Perhaps the words "obtain a higher data acquisition rate" are meaningful in the context of some specific project?  Certainly the USB virtual serial is MUCH faster than ordinary serial.

This post has results of USB speed testing I did.  Maybe this is the sort of info you're asking about?

http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a/posts/317933
Title: Re: Teensy 3.0
Post by: pico on Oct 20, 2012, 08:00 am
BTW, Paul, the page

http://www.pjrc.com/store/teensy3.html

isn't navigable from the pjrc.com home page, you have to go to it directly (I picked up the link from the KS page).

Perhaps this is intentional to limit orders until you can restock, but just in case it had fallen through the cracks, I thought I'd mention it.
Title: Re: Teensy 3.0
Post by: Nantonos on Oct 20, 2012, 05:39 pm

BTW, Paul, the page

http://www.pjrc.com/store/teensy3.html

isn't navigable from the pjrc.com home page, you have to go to it directly (I picked up the link from the KS page).


Same for
  http://www.pjrc.com/store/teensy3_pins.html
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 20, 2012, 09:31 pm
I have posted a version of SdFat that supports Teensy 3.0 as SdFatBeta20121020.zip http://code.google.com/p/beta-lib/downloads/list (http://code.google.com/p/beta-lib/downloads/list)

I recommend using an industrial SD like this one http://www.newegg.com/Product/Product.aspx?Item=9SIA12K0CT6829 (http://www.newegg.com/Product/Product.aspx?Item=9SIA12K0CT6829)

I ran the SdFat bench.ino example with this card at 96 MHz.  I used the following defines for the test:

Code: [Select]

#define FILE_SIZE_MB 10
#define FILE_SIZE (1000000UL*FILE_SIZE_MB)
#define BUF_SIZE 8192


Here is the result of the test with this low cost 1GB ATP card:

Quote

Free RAM: 4207
Type is FAT16
File size 10MB
Buffer size 8192 bytes
Starting write test.  Please wait up to a minute
Write 1934.99 KB/sec
Maximum latency: 11333 usec, Minimum Latency: 4144 usec, Avg Latency: 4228 usec

Starting read test.  Please wait up to a minute
Read 2111.61 KB/sec
Maximum latency: 4220 usec, Minimum Latency: 3870 usec, Avg Latency: 3877 usec
Title: Re: Teensy 3.0
Post by: Nantonos on Oct 22, 2012, 08:55 am
I see that Alpha-Crucis in France (http://www.alpha-crucis.com/fr/microcontroleurs/4060-teensy-30-header-3700386510441.html) has Teensy 3.0 (with pins) listed as a new product, at 28,75 € TTC (which means 'including tax'). Although they haven't translated the info into French yet.
Title: Re: Teensy 3.0
Post by: jbeale on Oct 22, 2012, 06:59 pm
Quote
I recommend using an industrial SD like this one http://www.newegg.com/Product/Product.aspx?Item=9SIA12K0CT6829


I'm curious what the term "industrial SD" means. I gather this is not SDHC, but is there something specific about this particular SD card that makes it better for use with Arduino and sdfat ?
Title: Re: Teensy 3.0
Post by: Nantonos on Oct 22, 2012, 09:26 pm

Quote
I recommend using an industrial SD like this one http://www.newegg.com/Product/Product.aspx?Item=9SIA12K0CT6829


I'm curious what the term "industrial SD" means. I gather this is not SDHC, but is there something specific about this particular SD card that makes it better for use with Arduino and sdfat ?


Quote
Industrial-grade cards are made to endure severe operating conditions such as high impact, continuous vibration, low  and/or high operating temperature. These cards are durable and can last intensive reads/writes. Certain cards are even made to be moisture-resistant. Consumer-grade memory cards are not as durable. For most of the industrial applications which normally require intensive I/O cycles, the consumer-grade cards tend to fail prematurely.

reliable storage of 2,000,000 write/erase cycles and 10-year data retention,
http://www.psism.com/industrialsd.htm
Title: Re: Teensy 3.0
Post by: westfw on Oct 22, 2012, 11:34 pm
Quote
Consumer-grade memory cards are not as durable.

I'm not very convinced.  If you think the chips inside come off of some different fab or have substantially different characteristics, or if they're assembled using any substantially different techniques, I think you are easily deceived.  You MIGHT be getting "industrial temperature range" chips rather than "commercial temp range" (which itself is somewhat ambiguous as to meaning), and you might be getting better pre-sale testing...
Title: Re: Teensy 3.0
Post by: pjrc on Oct 23, 2012, 12:49 am
I don't know if "industrial" is different, but I can tell you there is a huge difference in performance between SD cards sold for consumer use.  The SDHC speed class is often unrelated to the real-world performance when small, random access is made.

I recently tested several of my cards, while trying to use a Raspberry Pi.  I used one of the PC disk benchmark, which does large and small sequential and random reads and writes (8 tests in total).  On the random write test, many of the cards had about 10 kbytes/sec speed, which incredibly slow.  My fastest card was a 32 GB Sandisk Ultra, at well over 1 Mbyte/sec in the random 4k write.  I had another 32 GB card, I believe Patriot or PQI, which ran at about 10 kbytes/sec in the random write.  It performed very well with sequential access, but very poorly for random reads or write.  Since then, I sold a camcorder with that card included.

Sadly, the Raspberry Pi has a bootloader bug that makes it incompatible with some cards.  My only really fast card is one of those.  Since then, I've been too busy with Teensy 3.0 to do much with Raspberry Pi, but I plan to look at it again in a couple months.

The "industrial" card might be just marketing, or it might actually mean the card has whatever better chip is in that Sandisk Ultra that makes it so capable of managing small, random accesses that other cards service at only glacial speeds.

Title: Re: Teensy 3.0
Post by: el_supremo on Oct 23, 2012, 01:52 am
The Teensy 3.0 I ordered is on its way. In the meantime I have some questions.

- is there a forum for the Teensy 3.0 or is this thread the best place to ask questions?
- I notice in the Beta5 IDE Tools menu that you can choose one of three CPU speeds - e.g. to overclock at 96MHz. Is this selection all you need to do or do you also have to make some sort of hardware change?
- I'd like to play around with the ARM's DSP instructions. Is there any support to allow use of them in a sketch or do I have to get my hands dirty with assembler?

Thanks
Pete
Title: Re: Teensy 3.0
Post by: westfw on Oct 23, 2012, 02:25 am
Quote
there is a huge difference in performance between SD cards


Have you seen the conversation about many formatting utilities not formatting SD cards "correctly" ?

http://www.adafruit.com/forums/viewtopic.php?f=31&t=20861&start=0
Title: Re: Teensy 3.0
Post by: jbeale on Oct 23, 2012, 02:48 am
Quote
Sadly, the Raspberry Pi has a bootloader bug that makes it incompatible with some cards.


Somewhat off topic, but just FWIW, the R-Pi has been reported to show about 20 MB/sec both reading and writing to a "SanDisk Extreme SDHC  4GB class 10" according to http://elinux.org/RPi_Performance#SD_card  
Somewhere around June/July 2012 there were some bug-fixes to the SD card I/O routine firmware in the R-Pi, which improved compatibility with several different types of cards.  Most cards perform slower than the above example.
Title: Re: Teensy 3.0
Post by: jbeale on Oct 23, 2012, 02:59 am

- I notice in the Beta5 IDE Tools menu that you can choose one of three CPU speeds - e.g. to overclock at 96MHz. Is this selection all you need to do or do you also have to make some sort of hardware change?


My experiments indicate that the menu selection alone does in fact change the clock speed, nothing else required. See for example http://dangerousprototypes.com/forum/viewtopic.php?f=2&t=4606#p45080
Title: Re: Teensy 3.0
Post by: el_supremo on Oct 23, 2012, 03:08 am
Thanks very much John.

Pete
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 23, 2012, 04:56 am
The main difference is that industrial cards use SLC flash and consumer cards use MLC flash.

SLC flash tends to perform better in embedded applications.  For example wear leveling remaps occurs more frequently for MLC flash since each cell has a lower maximum number of write cycles.

A comment on bus speed. 

The Teensy uses 1-bit wide SPI at 24 MHz.

Common Version 2.0 SD and SDHC cards support the 4-bit SD bus at 50 MHz.  This is about eight times the bandwidth that Teensy has.
Title: Re: Teensy 3.0
Post by: farmvilleduck on Oct 23, 2012, 02:48 pm
fat16lib  , integration of the chibios to the teensy sounds very interesting. Thanks for the work.

How compatible do you think it will be with other arduino libraries ? And what's the estimated latency, generally speaking ?
Title: Re: Teensy 3.0
Post by: farmvilleduck on Oct 23, 2012, 04:47 pm
fat16lib  , another  question:

How compatible is the chibios library to standard arduinos(atmega 328/1280/2560) ?  and what's the latency ?
Title: Re: Teensy 3.0
Post by: Nantonos on Oct 23, 2012, 06:32 pm


It's in stock in the Netherlands now.

http://www.pieterfloris.nl/shop/category.php?id_category=45


Ordered.


It arrived this afternoon, along with a Teensy 2.0 which I briefly tried and will use as a USB MIDI output for my controller project. Have not yet tried the 3.0, about to do that now.
Title: Re: Teensy 3.0
Post by: maujabur on Oct 25, 2012, 04:43 pm
Hi!

I successfully connected teensy 3.0 to the WIZ812 Adaptor Kit (edit: via breadboard, of course) and WIZ812 Ethernet Module!

(http://0xff.com.br/_generic/t3_w5100.jpg)

I can use DHCP and ran several of the server examples.

There's a problem for now, and I'm still looking into it, but if somebody else has something to add, it would be good!

The problem is that it can't connect to websites, as in DnsWebClient. I don't know yet if it's not resolving the DNS or if it's another issue...

here's my results:

localIP: 192.168.1.113
subnetMask: 255.255.255.0
gatewayIP: 192.168.1.1
dnsServerIP: 200.162.196.29
connecting...

UPDATE: It's not resolving DNS names, I used IPAddress serverName2(74,125, 234, 243) for google and it went through! I'll check my DNS server now...

UPDATE 2: It was my DNS server (but it works on my win7 machine...) Now I'm using openDNS and it works...

localIP: 192.168.1.113
subnetMask: 255.255.255.0
gatewayIP: 192.168.1.1
dnsServerIP: 208.67.222.222
connecting...
connected
HTTP/1.0 200 OK
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 26, 2012, 03:42 am

I have this SD card breakout board in the color red. https://www.sparkfun.com/products/544

I want to hook it to the Teensy 3.0, I think I can hook it directly to the SPI pins without any added resistors or such. Can anyone tell me if that is correct or if I need additional parts?


Thanks,
Mark
Title: Re: Teensy 3.0
Post by: fat16lib on Oct 26, 2012, 04:39 am
Yes you can connect it directly.
Title: Re: Teensy 3.0
Post by: cyclegadget on Oct 26, 2012, 04:47 am

Yes you can connect it directly.


Thanks, I will report hopefully tomorrow on my results!
Title: Re: Teensy 3.0
Post by: el_supremo on Nov 08, 2012, 01:02 am
I tried a benchmark of my own using a function which computes the bearing between two locations specified as lat/long. It produces essentially the same kind of timing as seen before.
In summary, compared to a Duemilanove (=2009) the result of calling the function 10000 times is:
2009 @ 16MHz 12.57secs
T3    @ 48MHz   8.30 secs
T3    @ 96MHz   7.82 secs

The interesting thing I noted was the difference in the size of the code.
The Duemilanove code is 4764 bytes whereas the T3 code is 19984 bytes! I presume that the T3 is hauling in different libraries but it seems to be a bit excessive. OTOH it is 19984 bytes of a 131,072 byte maximum so there's plenty of room to spare :-)

Pete
Title: Re: Teensy 3.0
Post by: Coding Badly on Nov 08, 2012, 02:28 am
I tried a benchmark of my own using a function which computes the bearing between two locations specified as lat/long.


Using float or double?
Title: Re: Teensy 3.0
Post by: Nantonos on Nov 08, 2012, 02:50 am

- is there a forum for the Teensy 3.0 or is this thread the best place to ask questions?


This is a good place to ask questions and there is also now a Teensy forum (http://forum.pjrc.com/forum.php).


- I notice in the Beta5 IDE Tools menu that you can choose one of three CPU speeds - e.g. to overclock at 96MHz. Is this selection all you need to do or do you also have to make some sort of hardware change?

I believe that is all you need. Beta7 IDE was just released btw.
Title: Re: Teensy 3.0
Post by: el_supremo on Nov 08, 2012, 02:59 am
Quote from: Coding Badly
Using float or double?

float.


@Nantonos. Thanks for the info. I've now found the forum and also discovered just how trivial it is to run a sketch overclocked at 96MHz.
I suspect that sorting out the DSP stuff is gonna be a bit less than trivial though :-)

Pete
Title: Re: Teensy 3.0
Post by: Nantonos on Nov 08, 2012, 03:52 am

I suspect that sorting out the DSP stuff is gonna be a bit less than trivial though :-)


Yes, hence my lack of reply on that point.