Help me get started with Teensy-2

Status
Not open for further replies.
F

fligen

Member
Folks,

I don't realy want to use the C-compiler - I want to do this in assembler.
Can anybody direct me to an assembler download?

A lot of the literature I have seen says to load the Teesyduino programming environment, but that seems to be mostly on the more popular Teensy-3. I don't know if it's called for on the Teensy-2. I have seen YouTube clips of a Teensy piggy-backed on an Arduino, but I don't understand why. I haven't used either previously - this is my first foray into microcontroller programming, but from the chip specification (Atmega32U4), the Teensy-2 seems adequately capable for the project I want to build (to drive a Triac for speed control for a universal motor with tacho). My track record is in C, but I will find this one easier if I can calculate timings by the number of instructions executed, so I'd like to do it in assembler. Can I do that? - by getting an assembler, and the means to download the code (a hex file?) through the USB, without the C-compiler?

Thanks
fligen
 
I just searched 'assembler' and found this similarly titled post: Program Teensy 2.0 in assembly?

You'd probably be in a better starting place to move to the $12 Teensy LC - just from the power in the processor/RAM/FLASH and higher percentage of active adopters here - and it would relate directly to the T_3.1 and future Teensy's as well.

In any case - it all starts with The Teensy Loader for device and software support.
 
"You'd probably be in a better starting place to move to the $12 Teensy LC"

That reminds me of the tourist who asked "How can I get to <name your place>?"
The local replied - "Well if I was going there, I wouldn't start from here"

Thanks for the advice (very probably good advice), but the Teensy-2 is what I have now, and I chose it because it has enough pins for the bit of IO that I want, and has adequate capability. Apart from the extra popilarity of the more capable chip, I can't see any advantage to it for my application. It has loads of capability I don't need. Come to that, so does the Tensy-2.
 
And indeed - no need to go someplace else - when you are where you want to be - I was "just sayin"

That example - or similar - should show you how to get the standard tools to use assembler when needed for timing - but if you pick up the "C" as glue between you'll spend a lot less time on mundane details - and can use the 'stock' tools. I've seen a few snippets on the Forum though they were not T_2 ARM - still using C myself. If you install TeensyDuino the software included will have examples of " asm volatile("nop"); " in use as needed for "nop" and longer pieces too. You'll just have to find the AVR Teensy_2 relevant pieces. Might help to learn the compiler switch to eject an ASM file for your code (expect it should) - as well as the instruction set of course.

Since it is AVR you can hit up standard resources like this: http://playground.arduino.cc/Main/AVR where I found this: http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
 
First, please understand the Teensy Loader program simply reads a .HEX file and programs it onto your Teensy. There's no requirement to use C. So far, go to the stand alone Teensy Loader page and get Teensy Loader working. Use the 2 LED blink samples for testing.

Once you're able to program .HEX files onto your Teensy, then you just need to figure out how you'll create the .HEX file.

Here's two prior messages about using assembly.

https://forum.pjrc.com/threads/25317-Assembly-coding-for-Teensy3-1?p=43724&viewfull=1#post43724

https://forum.pjrc.com/threads/27938-Using-Assembler-with-Arduino-and-Teensy3-1-or-Teensy2

There are many other ways to do assembly. Long ago, I used TAVRASM. It really doesn't matter what assembler you use. Virtually all produce .HEX output.

But if your purpose is to read a tachometer and control a triac, you could probably complete this project with little effort by using Arduino with the FreqMeasure library and a very simple program that controls a pin with digitalWrite(). FreqMeasure uses the hardware timer input capture, so you get perfect (within the clock speed resolution: 16 MHz on AVR, 48 MHz on ARM) measurement of the frequency, even if you have lots of software overhead. Even if you write the tightest possible AVR code, you can't possibly hope to achieve that by code reading the pin, since several instructions and branching take more than 1 cycle. The hardware timer always captures the elapsed time with 1 cycle performance.

Triacs switch 120 times per second in the USA or 100 in the rest of the world. One degree phase accuracy on 50 or 60 Hz is pretty slow timing, relative to the speed of even AVR. There's little need to resort to the extra effort for assembly for such an undemanding project.

But if you really want to micromanage every instruction and register, for a project that's easy to do with excellent performance using already-written libraries, you certainly can. Maybe those links above will help you get started. Just know that I can't do much more to help on the assembly side. You'll have to figure out how you're making the .HEX file. Teensy Loader will get the .HEX file onto the hardware for you, regardless of whether you painstakingly produced it one instruction at a time in assembly, or tossed it together casually in Arduino. But unless you put a lot of work into leveraging those hardware timers, odds are the easy Arduino way will probably outperform the best you can do in assembly with tightly coded I/O.
 
Many thanks to defragster and to PaulStoffregen for your full and friendly answers. Sorry for the delay - my PC went down, and moving into another has slowed me down quite a bit. I probably won't get back to this properly for a week or two. However, when I do, I'm quite sure the links you have given will give me everything I need.
Paul, your description, and the description in the links given by defragster were just what was needed. Yes, I am already aware that a 16meg uController chip controlling what is going on on a 50Hz line, will spend most of its time kicking its heels. The reason I wanted to do it in assembler instead of C had more to do with whim than practicality. I agree- I'll probably wind up doing it inline, if I finally use assembler at all. Trying to be a purist can be a big mistake.
I once designed a voice interface for a PC. I wrote the driver in C, but with all of the hardware handling for my card in inline assembler, so I have a bit of experience - though that's a while ago, and this is a new chip with a new environment, so the helping hand is much appreciated.
 
Status
Not open for further replies.
Back
Top