Arduino IDE 1.0 Released

Arduino IDE 1.0 has been released (previous rev was known as 0023). The release notes provide insight into the new functionality. It will be interesting to see if I can use this new capabilities in my Ham Radio Projects.

To be compatible and consistent, Teensyduino, Version 1.06 was also released.

I have not downloaded either yet, as I am in the middle of a Multi-day Timing Test on my Teensy GUI Protoboard, but will download soon.

--

Teensy Clock Fixed

Paul - the creator of the Teensy has provided a software update (Rev 1.04), that fixes the clock problem that I observed (see previous post) After a 24 hour test, my Teensy has only gained about 1 second (as compared to a wall clock) that is only about 11 ppm error, which is good considering ambient temp and generic 16mHz cpu crystal.

Another test with a known good reference clock is necessary for more resolution.

Thanks Paul, for your efforts to provide a fix.

--

Teensy Programming Shield

I had some time this morning to install the headers on the Teensy Programming Shield which I just received from the FAB Shop (see previous post). With plated through holes, soldering of parts (headers) is much easier than experienced with Homebrew double sided boards.

Headers Installed

Bottom

Top

--

DorkBotPDX in Portland

Monday night Jeff - KO7M and I attended the 7-11pm  DorkBotPDX meeting in Portland, there were many projects available to review and interesting people to meet.

An unexpected pleasurable encounter was with Paul - the creator of the "Teensy", which is the cpu board that I have mentioned in previous posts (see search label: Teensy). Paul also, video taped some of the high lights of the meeting. My GUI Development Board and 9 Volt Micro Transmitters can be seen.

http://youtu.be/seyTMkTGZ3E

It was a great meeting, even thought I did not get back to Seattle and home until 3:30am, I plan to attend often.

--

Teenys Clock Trouble

The only time I have had to work on other projects was late a night. My Teensy (an Arduino work-a-like, see previous posts) has been giving me fits. The clock is FAST by about 24 seconds per 6 hours. All previous efforts to correct the problem resulted in No Change.  Jeff - KO7M and I had some time to review my progress (or lack there of) and found that the Teensy does not use the same Clock file (wiring.c) as used by the Arduino (I was modifying the wrong file), in fact it not even named the same under the Teensy directory structure (pins_teensy.c).

void TIMER0_OVF_vect()
{
        asm volatile(
                "push   r24"                            "\n\t"
                "in     r24, __SREG__"                  "\n\t"
                "push   r24"                            "\n\t"

                "lds    r24, timer0_fract_count"        "\n\t"
                "subi   r24, 256 - %0"                  "\n\t"
                "cpi    r24, 125"                       "\n\t"
                "brsh   L_%=_fract_roll"                "\n\t"

        "L_%=_fract_noroll:"                            "\n\t"
                "sts    timer0_fract_count, r24"        "\n\t"
                "lds    r24, timer0_millis_count"       "\n\t"
                "subi   r24, 256 - %1"                  "\n\t"
                "sts    timer0_millis_count, r24"       "\n\t"
                "brcs   L_%=_ovcount"                   "\n\t"

        "L_%=_millis_inc_sext:"
                "lds    r24, timer0_millis_count+1"     "\n\t"
                "sbci   r24, 255"                       "\n\t"
                "sts    timer0_millis_count+1, r24"     "\n\t"
                "brcs   L_%=_ovcount"                   "\n\t"
                "lds    r24, timer0_millis_count+2"     "\n\t"
                "sbci   r24, 255"                       "\n\t"
                "sts    timer0_millis_count+2, r24"     "\n\t"
                "brcs   L_%=_ovcount"                   "\n\t"
                "lds    r24, timer0_millis_count+3"     "\n\t"
                "sbci   r24, 255"                       "\n\t"
                "sts    timer0_millis_count+3, r24"     "\n\t"
                "rjmp   L_%=_ovcount"                   "\n\t"

        "L_%=_fract_roll:"                              "\n\t"
                "subi   r24, 125 - %0"                  "\n\t"
                "sts    timer0_fract_count, r24"        "\n\t"
                "lds    r24, timer0_millis_count"       "\n\t"
                "subi   r24, 256 - %1 - 1"              "\n\t"
                "sts    timer0_millis_count, r24"       "\n\t"
                "brcc   L_%=_millis_inc_sext"           "\n\t"

        "L_%=_ovcount:"
                "lds    r24, timer0_micros_count"       "\n\t"
                "subi   r24, 256 - %2"                  "\n\t"
                "sts    timer0_micros_count, r24"       "\n\t"
                "brcs   L_%=_end"                       "\n\t"
                "lds    r24, timer0_micros_count+1"     "\n\t"
                "sbci   r24, 255"                       "\n\t"
                "sts    timer0_micros_count+1, r24"     "\n\t"
                "brcs   L_%=_end"                       "\n\t"
                "lds    r24, timer0_micros_count+2"     "\n\t"
                "sbci   r24, 255"                       "\n\t"
                "sts    timer0_micros_count+2, r24"     "\n\t"

        "L_%=_end:"
                "pop    r24"                            "\n\t"
                "out    __SREG__, r24"                  "\n\t"
                "pop    r24"                            "\n\t"
                "reti"
                : 
                : "M" (TIMER0_FRACT_INC), "M" (TIMER0_MILLIS_INC),
                  "M" (TIMER0_MICROS_INC)
        );
}

Teensy Clock Code from Original File

The Teensy Clock file is "pin_teensy.c", which is mostly written in Assembly Language. I unfortunately do not know Assembly Language well enough to make modification to attempt to correct the Clock. Jeff suggested we replace a section (the clock) with known working "C" code from Arduino.

The first attempt included a section to try to slow the Clock by an amount equal to the previously observed error. After 6 more hours, the clock was NOW slow by about the same amount as it was FAST before. Jeff suggested we remove the correction and obtain a new base line with just the "C" code installed.

SIGNAL(TIMER0_OVF_vect)
{
 // copy these to local variables so they can be stored in registers
 // (volatile variables must be read from memory on every access)
 unsigned long m = timer0_millis_count;
 unsigned char f = timer0_fract_count;

 m += MILLIS_INC;
 f += FRACT_INC;
 if (f >= FRACT_MAX) {
  f -= FRACT_MAX;
  m += 1;
 }
 
 timer0_fract_count = f;
 timer0_millis_count = m;
 timer0_overflow_count++;
}

Copied Arduino Clock Code

Due to the work in the Shop (listed above) I did not get back to the Clock project for 29 hours. After 29 hours, the base line results indicated that the Clock was spot-on, only less than a second difference could be observed when compared to a wall clock. Wow!

But, the "C" code replacement did something to the "Interrupts" for the Teensy, my push buttons no longer work as expected. We damaged something by removing the Assembly Language code. More investigation will be needed.

For now, I have reverted to the Assembly Language Clock routing, so that all of my GUI development environment works correctly, but with a Clock that runs a little fast.


UPDATE: The new release of Teensyduino 1.04 fixed the problem.

--

Teensy Programming Shield - To FAB Shop

After a little rework on the previous circuit board, we got it working. The +5V trace was broken at the header pin. This type of problem is always a concern with Homebrew Double Sided Boards as they are not through hole plated, and therefore must be soldered on the pads of the two sides. The pad and connecting trace are very fragile.

As Designed and Sent to DorkBotPDX

To make the board more useful (and rugged) we decided to have it sent to my favorite fab shop; DorkBotPDX. The boards should be back (in less than 2 weeks) by Thanksgiving.

The Back Side

The board has been changed a little, as the fab shop can do useful things, that are avoided when doing HB PCB's.


The board is .7'' x 1.8" with 8 mil traces, 6 mil ground grid, and the text font is 3pt.

 I enjoy building very small projects!

--

Teensy Programming Shield

Jeff - KO7M and I have been working on several Arduino and Teensy projects, to control QRP and Beacon Transmitters. To expand and progress to the point where we will use raw chips in planned projects we decided to produce a Teensy Programming (under) Shield. For several projects we have used the Teensy as the development platform.

As Designed in DipTrace

The Teensy will plug into the top of the Shield. After several iterations and corrections of schematic I we have a layout.

Today, I used the Toner Transfer Method to create the board. High resolution two sided boards are tough but they can be done. The Teensy Programming Shield is .75" x 1.75" with 8 mil traces.

Etched and Ready for Inspection

There are not many traces so it was not hard to route or build. If I had need for more than a few boards I would have sent it out for FAB.

The Etch Looks Good
and both sides look like they are in good alignment
These are 8 mil Traces, and 6 mil Ground Grid

After Laser Toner Resist is remove, the board is cleaned and polished, and then placed into a small dish of Tinnit. In about 5 minutes the board is bright and shiny.

Tinnit was used for Tin Plating

Tinnit works well, with good coverage,
but it is very thin (.004").

The Results:

Parts Loaded

Double sided HB board are difficult as the socket pin are typically used to transfer the traces between sides and therefore both sides of the socket pins require solder. With care this can be done by raising the socket a small amount and soldering with a very sharp iron. Also, small errors of alignment between the image of each side make for difficult drilling and therefore pad are not always centered on the component pins.

Cut, Drilled and Parts are loaded, in this case Headers and one jumper.

Ready to Use !

As you can see the Header were raised about 1/10" to facilitate top side soldering the few pads which are connected via traces. Raising the parts would not be necessary if this board was from a FAB shop, plated through holes would make loading parts much easier.

In use, the Teensy will cover the first 24 pins (far end), short jumpers will be used if need for the none standard Teensy pin locations. For ISP Programming effort, only one jumper will be required - the RST pin.

With the Teensy plugged in hopefully there will be enough space to plug in the programmers? To use the Shield to program the Teensy, a short jumper is still needed between the RST pin (on end of the Teensy) and the third pin on the near open socket holes. That hole, is connected to the RST pin on the 6 pin Programming Header. We could have included dedicated RST pin and socket as part of the Shield, but that would require we alter the Teensy with a dedicated pin, disallowing it to be used directly with simple circuits on protoboards.

The Teensy is Installed, Ready for Programming,
It can be used
In or Out of a Protoboard

Now it is time to do some Direct AVR Programming - Jeff!

--

Tennis Ball Launch Trigger Program

Finally, Jeff - KO7M and myself got together to work on my Tennis Ball Launcher Trigger Program (see previous post). The launch trigger program will help avoid accidental firing of the launcher. The launcher, of course, will be use to string antenna lines into the trees. So far, the weighted tennis balls have been shot over 160' trees. Tess, my dog loves the launch activity!

Jeff came prepared with his subroutines to perform most of the required functions. Our time together was used to assemble the mainline program and test the firing sequence functions. My Teensy Test Jig as describe in previous posts, was used to test the program. A few things are yet to be resolved, but progress was good.

An unanticipated value; was the opportunity to watch over Jeff shoulder, as he programmed the task in the Arduino IDE. A lot can be learned by watching a programming Master - Jeff is good! (it is his day job) The interaction is worth much more than just the resulting program listing.

The lessons learned will be used in my future embedded micro projects. - Thanks, Jeff

--

Teensy Test Jig Schmatic

Here is the Teensy Test Jig Schematic that I am using for the programs shown in previous posts.

Teensy Test Jig

Teensy  Test Jig Schematic
Rev: F

Teensy Test Jig - In Fritzing Format

Note: The Rotary Ecoders are show as "Trimmer Pots" with two extra pins at the top for the push button switch, the encoder part is not available in the Fritzing Library, I may need to create a custom part. I have updated the Fritzing diagram above - I had to build a custom Fritzing Rotary Encoder part.

I had to re upload the schematic, the first and second were flawed.

Note: The Photo, Schematic, and the Fritzing view are NOT all "exactly" the same.

This is a "work-in-progress" project.

--

ISR Lessons Learned

If you follow my Blog, (see previous posts) you will know that I have been playing with an Arduino work-a-like known as the Teensy. The plan is use it to help make my Homebrew Projects smarter and maybe more interesting.

So far, I have been "playing" with it to build multi-tasking template for future projects. The first hurtle was to write a predicable Rotary Encoder Test routine. Which I have done and published on the previous post. Actually, the code that I published has been replaced three time as I learn more. Finally I think the code is solid and would not mind others to commit or post reviews.

It was a struggle getting to this point. I have several chats with my friend Jeff - KO7M, about several major issues that were . . . just kicking my butt. The program just did not operate the way I had in mind. But in the end, it now works better than expected.

There were several lessens learned along the way, many are simple and probable known by heavy software types, but for me they were large stumbling blocks.

The lessons learned:

• When writing software it is very important to have a friend to review your code. The process of expainning code bring new eyes on the problem.

• Interrupt Service Routines (ISR) should be as short as possible, I instinctive knew this, but initially did not follow my own advice. It is just too easy to add one more line to the ISR. Note: only the second (PinB) needs to be read here as the other (PinA) is already known to be HIGH, as the RISING edge of the pulse is what created the Interrupt.

void doEncoder0() {    // Rotary Encoder
    digitalRead(encoder0PinB) ? g_encoder0Pos++ : g_encoder0Pos--;
    return;
}

• The variable used by the ISR should be declared as global and type "volatile byte", as:

// Set Initial Encoder Values
volatile byte g_encoder0Pos = 0;

• Jeff suggested the "g_" conventions for global variables.

• The main program routine that takes advantage of the data from the ISR should read it with one machine instruction, so that the process can NOT be interrupted by yet another ISR event. For an 8 bit processor that means use an assign statement between two variables of type byte. In my case, the flag that indicates that the assignment was complete (ISR data extracted), was another byte assignment of value zero to the source variable. Once the data is assigned, it can be accumulated or used as necessary.

int doGetEncoderValue() {
    byte tmp;

   // Get Encoder input
   tmp = g_encoder0Pos;
   g_encoder0Pos = 0;

   . . . . 

}

• Each of these two assignments are NOT interrupt able and therefore does not pose a problem if another ISR event occurs. Yes, there is a very-very narrow window where one event may be lost, but for my Rotary Encoder application that will not be a problem. If I had used; "int", "long", or  "float" data type multiple machine instructions would have been necessary to complete an assignment. And then, if an event occurred during the the assignment, there would have been a good chance the data would have be corrupt.

The methods used within the test program, have already been incorporated into another more complex multi-tasking program that I am working on.

The following is an excerpt from that program:

        byte btmp; int itmp;

        lcd.setCursor(0,0);
        lcd.print("Adj Backlight");
        // Get and Decode Rotary Encoder Data
        btmp = g_encoder0Pos;
        g_encoder0Pos = 0;
                
        if(btmp < 128) itmp = btmp;
        if(btmp > 127) itmp = (btmp - 256);
          
        level += itmp * 16;
        
        if(level < 0) level = 0; // Constrain
        if(level > 256)level = 256;

        lcd.setCursor(0,1);
        if(level<10) lcd.print("0");
        if(level<100) lcd.print("0");
        lcd.print(int(level));
        
        // Some Sound Feedback, just for fun
        if(itmp) {
            tone(speaker, 2000 + 2 * level, 10);
            analogWrite(lcd_BL_pin,min(max(level,4),255));
            g_HoldOffReset = true;
            state=1;
        }

It will be just more fun stuff.


--

Decoding a Rotary Encoders - Cont'd

See previous posts.

Here is my Arduino Encoder Code for my archive, and others to review.

The input circuit is a pull up resistors and a cap to ground on each leg of the Encoder pins, the center Encoder pin is grounded. One pin is configured for interrupt while the other is configured for just input.

One interesting observation, there are two interrupts for each detent of the Encoder, rotating the knob very slowly will show an interrupt half way between the detents. The Encoder doc's do not imply this should be expected. Maybe I have the wrong doc's??

This interrupt handler works, it is my adaption of the published (original) code which is shown further below. I just futzed with the code to remove problems that I observed. I do not understand all that I know, maybe I just need more futzing.

///////////////////////////
// Interrupt Handlers
///////////////////////////
void doEncoder0() {          // This works !!! but not sure why??!!!
    static volatile byte _previous = 0;
    volatile byte _this = 0;

    volatile int junk = 2000, junk2; 
    while (junk--) junk2++;    // Delay for Debounce

    _this = digitalRead(encoder0PinA);

    if (_this != _previous) {
        _previous = _this;  
        if (_this == digitalRead(encoder0PinB)) {  
            encoder0Pos++;
        } 
        else {
            encoder0Pos--;
        }
    }
    return;
}

The following suggested Handler does NOT work for my simple Encoders.

void doEncoderX() {  // This should work but does NOT !! but not sure why??!!!
   
    if (digitalRead(encoder0PinA) == digitalRead(encoder0PinB)) {
        encoder0Pos++;
    } 
    else {
        encoder0Pos--;
    }
    return;
}

The Setup is just three lines:

    pinMode(encoder0PinA, INPUT);    
    pinMode(encoder0PinB, INPUT);

    attachInterrupt(INT0, doEncoder0, CHANGE);

The Encoder Interrupts accumulate in "encoder0Pos", The shift (>>1) divides the value by two,  which is necessary as I want to count "detents" and there are two interrupts per detent. Setting "encoder0Pos" to zero, indicates all Encoder Interrupts have been accepted. Note: there is a very narrow window between these statements where a Interrupt could be lost, which is not big deal for my app.

 // Get Encoder input
 if (abs(encoder0Pos) > 5) chr += encoder0Pos; // For Accelerated Action
 chr += encoder0Pos>>1;
 encoder0Pos = 0;

Perhaps I need more desecrate component debounce, i.e., more capacitance on the input port.


--

Decoding a Rotary Encoders

Decoding a Rotary Encoder is more difficult to use than I had thought. My test environment for the encoders is as described in the previous post.

A google search found several articles describing the problem, suggested solutions all seem to be less than optimum.

http://practicalusage.com/?p=267

More coding, breadboarding, and research is necessary.

One problem may be that I am using less then optimum quality encoders, they were purchase on ebay for about $1.60 each. A quick search of Mouser Catalog lists many similar parts at the same price. Each have the same 20 (or so) pulses per revolution. Expensive (>$50) optical encoders typically have many more pulses per revolutions (>128) and therefore should provide more resolution. I don't think my projects require that much resolution (or expense).

I am going to check my car radio's volume and channel controls,  they seem to feel right and would be usable for most of my projects.

Of course, this is all necessary if the encoders are to be used in my future QRP projects. I am sure there is a workable solution, I just have not found it, yet!

---

UPDATE
My car radio Volume control appears to be an analog pot, with 32 indents over its range (about 300 degs). The Channel control appears to be an continuous rotating encoder with 16 detents per revelation, which is less than the 20 detents per revolution of encoders that I purchased.

-

LC Display and Encoders Received

I received my ordered LC Displays and Encoder/Switches (see previous post).

Simple Development and
Test Configuration

It has been several years since I have programmed a PIC or other Micro Processor. The following is a quick build to provide a test circuit for getting back up to speed. The processor is the green circuit board on right side of photo. It is a Teensy 2.0 , which is a Arduino look/works-a-like.

The connection to the PC for programming and interaction is via the mini-USB. Power is supplied via the USB or external battery as shown here.

Add on software allows the Arduino Interactive Development Environmental (IDE) to work with the Teensy. In fact most Arduino Sketches (a C like program) run without alterations. I chose the Teensy because of it small size,  it is similar in size to my normal projects.

The Sketch that I have put together is to test and exercise of these parts. It is a simple multi-tasking Scheduler and State Machines. My goals is to develop and provide a simple template for my future multi-tasking Sketches. I plans to merge the Arduino or Teensy with my micro 9-Volt Transmitters (as previous posted) to create interesting more complex projects.

The two Rotary Encoders (center photo) are not completely hooked up yet. My plan is to use Interrupts to decode their input.

As seen by the photo, several tasks (4) provide sample text within several fields on the two line display and controls the LC BackLight Brightness. So far, the multi-tasking Scheduler and State Machines are working as planned.

I wrote several macros to implement Task Switching, Checkpointing, and Scheduling. I remember doing something similar in Assemble Code many years ago by counting clock cycles. These implementation in C was easy in comparison.

No, it is not a full featured multi-tasking Scheduler implementation, but it will do the multiple tasks/things that I require.

---

UPDATE
There appears to be an old and raging debate about the use and license of the Teensy and it's bootloader, see:

http://www.adafruit.com/blog/2009/10/05/teensy-atmega32u4-usb-dev-board-in-stock/

I do not know the current status of the concerns?

More research is necessary.

--

Project Parts

I found a couple of inexpensive parts on eBay, which will be used for a planed and future projects.

Links and photos are bookmarked here for later reference.

16 X 2  LCD 

http://www.ebay.com/itm/ws/eBayISAPI.dll?ViewItem&item=270633029608

2-Bit Gray Code Rotary Encoders
with Push Button

http://www.ebay.com/itm/ws/eBayISAPI.dll?ViewItem&item=130545810600

I hope the sellers do not mind as the Photos were copied here from their eBay web page.


UPDATE
I found a interesting Post on Arduino and Encoders, saved here for later use:

http://practicalusage.com/?p=267

--

In PIC Heaven

OK, I am now in PIC Heaven.

Long ago, I have used the Microchip 12C509 for many projects, but it is time to update.

In an attempt to find a PIC for some future projects, I ordered and received a few of the most popular.

• Microchip - PICkit-2 with a PIC16F690 Evaluation Proto Board ~ $40.00

• ATmel  - Arduino Duemilanove Development and Evaluation Board ~ $30.00

• Solarbotics -  Ardweeny Backpack  (a small Arduino compatible) ~ $10.00, Requires USB-to-6Pin Programming Adapter ~ $14.00

• Texas Instruments - MSP430 Launch Pad, Development and Evaluation Board = $4.30 with shipping at Mouser (how can they afford that!!!)

• PJRC - Teensy USB Development Board - $18.00

Each Kit has a lot to offer; these are my initial reactions:

• Microchip - has a lot of supporting chips and I think they have be around longer. Multiple programs to install and/or download. This should be easy, but I am have a hard time getting anything to work.  The Docs and Examples refers to different PIC than received?

• ATmel Arduino - is VERY easy to program and it is quick to have something useful running. Just download one ZIP file and execute the main program.  The program contains links to read-only example files and a link to your project work space - very nice!

• Solarbotics Ardweeny - is very small and the same ease of use as the Arduino and can be reduced to just the chip. A 6-pin programmer is needed, that is - a special USB to Serial Adapter (now on order).

• Texas Instrument  MSP430 - Very inexpensive (evaluation board most function per $) - a little more difficult to program, but the chip has many built-in features, like on chip temperature. Two software packages are necessary to download and install; C and the Assembler. Demo code is a little difficult to find and set up - I will have to learn more.

• PJRC Teensy - USB Development Board - It has onboard USB for programming and data transfer (I have this board on order)

Each of the above can be reduced to just an inexpensive PIC, for inclusion into a final project. Most PIC's are less than $2.00 - $3.00, availability, support (i.e., demo code), and easy-of-use (i.e., programming) will be the deciding factors.

I will update this post as I learn more.

.