Saturday, December 29, 2012

Last Day, Tindie Fundraisers

This is the last day for my #tindie fundraisers.

eeZee Prop is a breadboard friendly Parallax Propeller for $24 + shipping. Programmable with your Prop Plug or FTDI cable/breakout, your choice. If you haven't tried the 8 core (cog) Propeller this is a good way to get started.

eeZee microSD is different than other microSD breakouts because you plug it in right next to your breadboarded ATmega328P/Arduino, no jumpers and 5V safe! $5 + shipping.

Both have met their goals, so you'll get one if you support either/both. I'll be ordering boards and components shortly after the 31st.

There's another fundraiser that caught my eye...

MicroFTX USB Serial breakout from Jimparis. A mere 8 boards short of the goal, 25% off at only $9 + shipping. Features include...


  • FT230XQ (websitedatasheet) from FTDI's new X-Chip series
  • Tiny footprint -- only 0.4" x 0.64" including Micro-USB B connector
  • Standard 0.1" headers expose all signals
  • Easy solder-jumper configuration
  • Supports I/O voltages from 1.8V to 3.3V, with 5V tolerance
  • UART baudrates up to 3 Mbaud
  • Solid FTDI driver support for Windows, OS X, and Linux
  • Programming interface is similar to the FT232R
  • Internal reprogrammable EEPROM for VID/PID and other customization
  • Professionally manufactured, with gold plating for easy solderability
  • Unique pre-programmed serial number
  • Open design
  • Low cost! [features excerpted from Tindie listing]

I have one on order so I hope he meets the goal (which is part of why I'm posting) :)

Back to your regularly scheduled projects... my JeeNodes came in so I can start playing with real radios soon, and I'm working on a telepresence robot with a Raspberry Pi. I also just got some upgraded parts for Data Bus including an Xbee pair and a new motor.

Thursday, December 27, 2012

Tindie, Wireless Project, Data Bus

Wireless Project

I've been working with Amplitide Shift Keying receiver and transmitter radios for a home sensor project but there are issues.

One problem is that the automatic gain circuit on the receiver puts a lower limit on baud rate (signal changes per second).

If the signal stays the same for long, the AGC sensitivity changes and starts picking up noise instead of the real carrier signal.

I've tried using Manchester code to ensure a minimum baud rate. I've also worked at transmitting square waves of two frequencies.

The latter could improve noise resistance but I haven't worked out the receiver software yet. Frankly, I'd rather just get the project working so I've ordered a pair of JeeNode transceivers from Jee Labs which are Arduino-compatible and based on the RFM12B radio.

Jee Labs has an excellent blog. I've learned a ton of interesting things from that blog in the last couple weeks since I subscribed. Highly recommended.

Christmas for Data Bus

Thanks to my very generous mother in law, I'll be soon purchasing an XBee radio pair from Radio Shack with a gift card. The radios will eventually find their way onto Data Bus for wireless telemetry and configuration.

I am still planning on entering the 2013 AVC. I may switch from the mbed platform (a ton of work but with some significant advantages). More important is improving accuracy of position estimation even at ludicrous speeds.

Assuming the same type of race next year, speed will once again be critical. Next year, 25 mph won't cut it. Will speed double again?  Or just increase significantly? Above 30 all sorts of things start to get really hard.

It's likely that I'll upgrade the chassis for improved handling. I will definitely be upgrading the motor, ESC, and battery for higher speeds.

Duratrax DRX8E (pic from Duratrax website)
I suspect 1/8th scale may be the way to go in the Peloton class, especially with the new budget options available. The Duratrax DRX8E is a 1/8 buggy roller for $200. ECX now has the 1/8 Revenge brushless buggy for $400.

I think (hope?) 1/10 scale still stands a chance, depending on the terrain. I hope so. No one makes a 1/8-scale school busy body. :)

Tindie News

I'm really excited about the Tindie Fundraisers. A couple of them are doing pretty well.


These are all designs I made for myself so I could spend less time dinking around with annoying, fiddly things, and more time getting to firmware. And, they're also as budget-friendly as I can make 'em.

Instead of just another microSD breakout board, the eeZee microSD plugs right in next to an Arduino/ATmega328P so I don't have to remember which line is MISO, MOSI, SCK, and CS. I've designed it to plug into the breadboard power strip too. And, it's designed to be 5V safe.

The eeZee Propeller is much cheaper than the PropStick but breadboardable unlike the QuickStart and I can reuse my FTDI breakout board or prop plug without taking up yet another (virtual) COM port.

The eeZee crystal means I never have to fiddle with crystals and caps on the breadboard again. just plug it in and get busy making stuff.

I figured others would benefit too while at the same time helping to supplement my meager "allowance" from "the boss" for hobby electronics. :)

Monday, December 24, 2012

Happy Holidays

Happy Holidays and Merry Christmas to those who celebrate it. Hope your holidays are full of fun, friends, family, etc.

Friday, December 21, 2012

ATtiny Software Serial TX in Assembly

ATtiny13 in one of my eeZee Tiny boards
Assembly language is way more fun than I remember. I implemented a very rudimentary software serial transmit on an ATtiny13. Really just to see if I could.

Receive is harder. I didn't do that because I don't really need it right now. If you dare me I might do it. But for now the communication is in one direction.

TTL Serial Protocol

Most typically, serial communication involves 8 data bits, no parity, and one stop bit (8N1). When sending TTL level (5V and 0V) serial, the idle state of the line is 5V. A start bit, 0V, is sent as the first bit, followed by the LSB of the data byte up through the MSB. After this, the stop bit is sent, a 5V signal.

I started with the code that would send the data byte. I planned to use a timer interrupt handler for timing the bits, but as an initial baby step, I just created a loop that would shift bits out one at a time.

I used r16 as the 1-byte buffer. The data placed in here is shifted out. A counter register, r17, counts the number of bits to send. It's set to 8 to begin with

.include "tn13Adef.inc" ; definitions for ATtiny13A
.def txreg = r16 ; transmit 'buffer'
.def bitcnt = r17 ; bit counter
.equ TXPIN = PB0 ; TX pin is PB0
.cseg
.org 0x00
rjmp start ; executed after reset

start:
ldi r16, 0x6D ; 'm' 
ldi r17, 8 ; put 8 in counter register
txloop:
lsr r16 ; shift off the next bit, LSB first
brcs Send1 ; if it is 1 (C=1) then send 1
Send0:
cbi PORTB, TXPIN ; send a 0=low
rjmp BitDone
Send1:
sbi PORTB, TXPIN ; send a 1=high
BitDone:
dec bitcnt ; bitcnt--
breq start ; if bitcnt == 0, start over
rjmp txloop ; else do the next bit

I used the Simulator debugger platform to watch the code and make sure it did what I wanted it to. In AVRStudio 4, choose Select platform and device... from the Debug menu and select Simulator and your device.


Next I added the logic to send the start bit. Instead of setting r17 to 8 I set it to 9 and then added special logic to send the start bit as the first bit.


start:
ldi r16, 0x6D ; 'm' 
ldi r17, 9 ; put 9 in counter register
txloop:
cpi r17, 9 ; if r17 == 9 (first bit)
breq Send0 ; send start bit (low)

lsr r16 ; shift off the next bit, LSB first
brcs Send1 ; if it is 1 (C=1) then send 1
Send0:
cbi PORTB, TXPIN ; send a 0=low
rjmp BitDone
Send1:
sbi PORTB, TXPIN ; send a 1=high
BitDone:
dec bitcnt ; bitcnt--
breq start ; if bitcnt == 0, start over
rjmp txloop ; else do the next bit


Finally I added logic to send the stop bit after the last data bit is sent or when bitcnt == 0. The stop bit is a high signal. Then, I reworked the code to run within an interrupt service routine.

  • The routine sends a stop bit (high/idle) whenever bitcnt == 0 or on bitcnt == 1
  • To send data, load the character into txreg then set bitcnt to 10: 8 data bits, 1 start bit, 1 stop bit
  • The routine will send a start bit then shift out 8 bits of data, then a stop bit



Timing

Tuned Delay Loop

A simple way to deal with timing is to implement precision delay loops. Here's a link to my latest version that simply pauses after setting a bit and pauses in between bytes. Works great.


I used this delay calculator. In this tool under Wine I could not generate a loop based on time input, but I could generate a loop by calculating cycles. A delay of 1000 cycles at 9.6MHz will give a 9600bps output assuming the chip's internal oscillator is correct. After tuning the loop, my Saleae Logic analyzer tells me the bitstream was clocking in at 4800.77Hz while sending out "U" (binary: 01010101) repeatedly. That's plenty close.

Timing With Timer

In the original version which I can't find now, the transmit routine runs off a timer interrupt handler. The ATtiny13 has one timer and you can set up an interrupt to occur on compare match.

In other words, you put the timer in Clear on Timer Compare (CTC) mode and then set the compare register OCR0A to some number, and when the timer counter TCNT0 reaches that number, it fires an interrupt and then resets the counter. This is the method to schedule interrupts to occur at fixed intervals.
  • Divide the clock by some value, 1, 8, 64, 256 or 1024 to prescale the timer
  • Select CTC mode and set OCR0A as a second divider
  • For a 4800Hz interrupt frequency from a 4.8MHz clock use /8 and /125
I set up the timer, put in the code to transmit a byte. And it didn't quite work. The bit pattern looked right on the oscilloscope, so I pulled out my newly purchased Open Bench Logic Sniffer.

4347 baud is nowhere close! No wonder this didn't work.
It told me the data was right but the baud rate was incorrect, 4347bps instead of 4800bps! I had to change the OCR0A from 125 to 112 to get 4826bps, then the correct data appeared on my serial terminal program. Will it be close enough to work with the transmitter? I'll test that later.

Close enough for the PC serial terminal to get the right data
The ATtiny13A is running off an internal 4.8MHz oscillator that's roughly calibrated at the factory. I'm finding that the oscillator frequency is very temperature sensitive. As the chip will be braving the Colorado elements, I'll have to hope I can find a more stable clock source.

Time Delay

Here's a nice tool for calculating and creating a fixed time delay routine

http://bretm.home.comcast.net/~bretm/avrdelay.html

That's it for now. I'll post more about the sensor project as I progress.

Monday, December 17, 2012

Fundraisers on Tindie

Tindie is now doing fundraisers, where makers can find out if there's any demand for their product before they order parts.

I have a few items up as fundraisers for the next two weeks.

Like everything else I put on Tindie, these are items I am using, have used, or plan to use, myself. I figure they can help out other makers, too. Here's what I've got.

The eeZee Propeller, a breadboardable 36-dip format 0.8" wide Parallax Propeller on a board. I used this board to ring a bell when you visit the site, an earlier version runs RoboTurkey, and I have plenty of other plans to play with the awesome capabilities of the 8-cog 80MHz Propeller. This one is targeted at lower budget range ($24) and DIP form factor.



Remote I2C ADC expands ADC capabilities over I2C, runs at 2.7-5.5V and up to 9 can live on the same I2C bus. I needed a way to expand ADC, and measure 5V output with a 3.3V MCU. This is the result and it costs only $5.

The eeZee MicroSD breakout plugs right into a breadboard next to your Arduino, no need for MISO, MOSI, SCK, or CS jumper wires. Optionally power it off the breadboard rails with 5V or 3.3V. It's got an onboard regulator. This one's only $5 too and features a hinged lid socket.




There are some other neat projects on Tindie as Fundraisers right now.

USB Tester

TrH Meter Kit

Chainable Intelligent Stepper Driver
And no doubt more will appear...

Friday, December 14, 2012

Getting started with dsPIC33F


Here's how I got started developing on a Microchip dsPIC33F.

I wanted to speed up the flame-detecting vision system on Pokey from 3fps to 30fps by upgrading from an 8-bit, 20MHz ATmega328P to a 16-bit, 80MHz dsPIC33F. The main performance boost comes from the dsPIC's very fast ADC.

Pokey with Game Boy Camera
I chose a dsPIC33FJ128GP802-I/P in a 28-PDIP package. It features 128KB flash, 16KB RAM, 16 remappable pins, a bunch of peripherals, DMA, and 1.1MSPS 10-bit ADC, among other cool features that make it a good choice for a low resolution grayscale vision system.

If you're just starting out, this Dangerous Prototypes Introduction will be quite helpful. I'll cover some of the same stuff in this post.

MPLAB IDE

I'm using the MPLAB IDE v8.6.0 which features a pretty familiar interface not unlike AVRStudio, Netbeans, Eclipse, IAR EWARM, and the like.


The IDE features workspaces in which you develop projects. The left panel features a file explorer for the workspace. The bottom panel features various types of output.

Code is written in the big panel. Toolbar buttons are used to build code, program the MCU, manage files, project, and perform other routine tasks. As with AVR Studio and other standard IDEs, you can double-click on compiler errors to find the offending source.

Turning on line numbers is helpful, sometimes. Select Properties from the Edit menu, click the 'C' File Types tab, and click the Line Numbers check box.

Programmer 

I'm using the PICkit3. I took advantage of promotional pricing at the time. I figured, why hassle with a clone when I can increase my chances of success without spending much more.

They now cost around $45 so it's not exactly a bargain but it's acceptable compared to other programmers (I'm thinking particularly of the JTAG ICE MkII I've been using).

You could also get a Microstick for the dsPIC which has a built in programmer and debugger and costs $25.

Breadboard Setup

Taking baby steps, first is breadboarding the dsPIC. The hello world programs will come after that.

Breadboarding the dsPIC33FJ128GP802-I/P

In the picture above, Pin 1 is the lower left. That's the !MCLR (reset) pin. Note the tiny 10K pullup resistor, partially hidden.

Pin 8 is VSS (ground). Pin 13 is VDD (3.3V) with a 0.1uF decoupling capacitor installed.

Pin 28 is the AVDD (analog 3.3V) pin, 27 is the AVSS pin (the brown ground wire is hidden somewhat). I put a 0.1uF decoupling capacitor here, too.

The 10uF capacitor at pins 19 and 20 bypass VCAP to VSS.  And that's all you need. You don't even need an external crystal, although you could use one.

To program the chip you need power. I've used a Sparkfun FTDI breakout to provide 3.3V. It is also connected to UART1 which is setup for transmit on pin 25 (PB15), receive on pin 24 (PB14).

Here's the full pinout reproduced for educational purposes:

28-DIP dsPIC33 pinout

To program the device, connect the PICkit3. Pin 1 with the arrow connects to !MCLR, the green jumper above. Pin 2 is target VDD (telling the PICkit3 if the device is working), the red jumper at the bottom of the breadboard. Pin 3 is VSS, the bottom black jumper. Pin 3 is PGD (PGED1, dsPIC pin 4), the orange jumper. Pin 4 is PGC (PGEC1, dsPIC pin 5), the white jumper.

PICkit pinout


Hello World

The first version of Hello World for an embedded system is blinking an LED. You can learn a lot about an MCU just by getting it to that point. An AVR is dead simple, an ARM7 like the one on my LPC2103 breakout board, is a nightmare--it took days. The dsPIC33F is pretty easy.

MCU Setup

The dsPIC uses an interesting method of configuring the clock source, PLL, watchdog, and other options. One places a set of statements before your code. Then, in the main() routine, one sets up the PLL multipliers and divisors. The following code shows setting up a dsPIC33F for 80MHz operation.



LEDs and GPIO Pins

Three registers control GPIO on the dsPIC. A tri-state register, TRISx, controls direction, a latch register, LATx, and a port register, PORTx. You can write to the PORTx register which writes to the latch, or you can write to LATx directly. Reading from LAT reads the latch, reading from PORTx reads the actual pin state.

On the dsPIC33 I'm using, there's an A and B port. So you'd use TRISA and TRISB, PORTA and PORTB, LATA and LATB. Let's use RA0 for our LED.

All pins start out as analog inputs after a reset. To disable the analog functionality of a pin, write a 1 to the corresponding bit in the AD1PCFGL register.

Next, configure the RA0 pin as an output by writing a 1 to the TRISA register's bit for RA0. In C, use TRISAbits.TRISA0 to reference the A0 bit of the TRISA register.

In general you can reference bits of any register like this. To turn the pin on, write a 1 to TRISAbits.TRISA0  To turn the pin off, write a 0 instead.

You can toggle a pin using LATAbits.LATA0 = ~LATAbits.LATA0.



a shorter notation for the above bits is to use LD1_TRIS, LD1_I, LD1_O defined as follows in HardwareProfile.h

#define LD1_TRIS (TRISAbits.TRISA0)
#define LD1_I  (PORTAbits.RA0)
#define LD1_O  (LATAbits.LATA0)

Delays

If you want to blink an LED in a simple loop you need a delay. Ideally one that is carefully and correctly timed. Microchip provides such a function, and macros, through the C30 compiler. In the C30 compiler directory under the folder src, unzip the libpic30.zip archive to the folder pic30 and find delay32.s.

I copied this into my project folder. I also had to copy null_signature.s in as well. Then, add both files to the project source.

Then, in your C program, define FCY the instruction cycle frequency. If you're running a high frequency, define this as a long long.

After this definition, include libpic30.h  Finally, you can call __delay_ms() with an integer parameter representing the number of milliseconds to delay. Other functions include __delay_us() for microsecond delays and __delay32() delays the specified number of instruction cycles.


UART

The second version of Hello World actually prints the string "Hello World" over a serial connection. I like to play with UART next as it's useful for debugging, and you can learn a little about the MCU's peripherals without too much complexity. Set up the pins, the baud rate and maybe a couple other options, and then start sending data.

Setting baud rate with the UART peripheral can be done using the high precision baud rate generator for higher speeds or the low precision generator for lower speeds. Select which to use via the BRGH bit of the UxMODE register. Set it to 1 for high precision, 0 for low.

For the high precision generator, baud rate divisor, UxBRG, is calculated by (FCY/(4*baud)) - 1 where FCY is the frequency of the instruction cycle clock.


The low precision baud rate generator uses BRG = (FCY/(16*baud)) - 1

Here are the values I calculated given FCY=40000000ULL


BRGH=0 BRGH=1
Baud BRG
1200 2082 8332
2400 1040 4165
4800 519 2082
9600 259 1040
19200 129 519
28800 85 346
38400 64 259
57600 42 172
115200 20 85

Once baud rate is set, clear the status register, UxSTA, enable the UART with the UARTEN bit of the UxMODE register, setting it to 1. Finally, clear the receive flag, UxRXIF bit of the IFS0 register.

You're not quite ready. The dsPIC offers a really cool capability, namely, mapping any peripheral to any pin. Even the ARMs I've worked with can't boast that kind of flexibility! So, let's setup pin 14 as the UART receive pin, and 15 as the transmit. Set the pin assignment in the UxRXR_I and UxTX_O registers, respectively.



RP15_O is shorthand for RPOR7bits.RP15R and is defined in HardwareProfile.h

Finally, you're ready to send and receive. The bit U1STAbits.URXDA indicates data is ready to be read out of the U1RXREG data register. When it's time to transmit, put a byte in the UARTxTX register to send it. Here's the code to do all the above.



That's All

So, that's about it. I'll post more articles as I progress, featuring other peripherals, tips, and tricks, and the like.

Tuesday, December 11, 2012

Jingle Bells 2012

Time to add some holiday cheer to the house! Every time you visit bot-thoughts.com a bell will ring in my office.

And there's that thing with the angel, too. Anyway...

This time around I decided to go with a complete self-contained solution, a great excuse to finally break out my Raspberry Pi and get it set up.

Yes, it's true, using an 8-cog microcontroller and a full on mini UNIX SBC constitutes absurd overkill for such a ridiculously simple task as ringing a bell...

To set up the Raspberry Pi I downloaded and installed Raspbian, then installed Apache.

I'm using one of my newly assembled eeZee Propeller boards to control the servo just like last time.

This time instead of a serial command, the Prop counts active transitions on one of its pins.

That signal comes from GPIO4 on the Raspberry Pi. The GPIO is toggled with a call to a REST service provided by webiopi whenever a python CGI script is called on the Pi's web server. The CGI script is called by an iframe on my blog.

Raspberry Pi GPIO pinout


Propeller Code

Here's the highlighted version, a screen capture from the Spin tool. One cog counts active transitions on P20 using a variable in hub memory. The main cog rings the bell by moving a servo back and forth count times. 


Here's a pastebin version of the code you can look through.


Python CGI Script

The python CGI script uses urllib2 to run an authenticated call to the webiopi REST API to send a pulse out of GPIO4. First it checks to see if the GPIO pin is set as an output. If not, it sets it as an output. Then it makes a call to the pulse function.




Source Code

Gotchas

I ran into a lot of gotchas along the way, like any project I undertake (I fail repeatedly so you can learn...). Between problems with iPhone/Dropbox/Picasa uploads, LDO regulator pinout problems on the new Propeller boards, anti-virus, user account control, a BSoD and a host of other problems on the new computer, and more, this took way longer than it needed to.

The worst was that my ActionTec M1000 router kept tacking on .domain.actdsltmp to every dns query so I couldn't test my Rasspi's web server with DynDns.com. The solution, after searching for quite some time, was to put the modem into transparent bridged mode and to go back to using my wireless router as the main router for the home network.

Friday, December 7, 2012

Eagle: Improved Silk Generation

I finally fixed silk_gen.ulp. The new, improved silk_gen2.ulp (download) provides the following improvements...
  • Copies polygons and circles from source layers (tplace, tnames, etc.)
  • Colors the bottom silk dark yellow (brown) so you can distinguish silk layers
  • Displays top, bottom, unrouted, pads, and vias layers at the end instead of hiding them
  • Preserves original unit setting instead of setting it to mil and leaving it
  • Silk wire preserve the source wires width (bugfix)
  • Correctly reproduce polygons without deleting the first wire (bugfix)
  • Disabled silking of dimensions by default
  • Selectable font (vector by default)
  • Reproduces text layer, orientation angle and spin
I start with a couple logos, the bot thoughts logo on the "top place" layer, the OSHW logo on the "bottom place" layer. They're both generated by ULP scripts. Also, a couple of polygons.


Starting with a couple logos and polygons

I run the original silk_gen.ulp and afterwards, I run into several annoyances.

Well that's not very useful... 
The script turns off the other layers. The bottom and top silk layers are the same color which is confusing.

It doesn't copy circles or polygons. I've hand-copied my logos way too many times.

Finally, it leaves the grid units set to "mil" regardless of what you had it set before.

After designing and re-designing a few dozen boards, I couldn't take it anymore. So I tweaked the ULP to fix the host of bugs and annoyances. Now I get this.



Ah, much better. My voices are happy for awhile longer.

Give it a try, share it, let me know if there are issues.

I'll likely post to the Eagle CAD website in the near future.