No related posts.

No related posts.

What I needed.

• Speed I had a project in mind that required an MCU. I tend to be a fairly impatient fellow, and like to see something happening pretty quickly. So I wanted something that gave me a quick development cycle. I also wanted to do C and not futz around in assembler, (until I had to optimize stuff).
• Short learning curve I’m an old hand at the classic CPUs 6502, 8051, 8086. However, that was some time ago, and I’ve been out of it for long time. I needed to come up to speed again pretty quick. So I needed something easy on the head.
• Low cost I didn’t want to have to start shelling out mega bucks for compilers, assemblers, yadda, yadda, yadda. I certainly don’t have one of those money trees in my backyard.
• Linux support What’s this new fangled windows thingy anyway? Give me a shell anyday.

Microchip PIC

PROs:

• History: PICs have been around for a long time. Consequently, there’s a huge amount of info on the web, code people have written, forums. You name it. A good resource is the piclist.
• Boot loader: I know, not all PICs are capable of this. But some are, and this is definitely a PRO. As long as a PIC is self programming, you can chuck a boot loader on it, to ease the pain of development. You don’t need a programmer once you have a boot loader present. You simply program via the UART port of the PIC.
• Options: This is the big thing I like about PICs. There are a huge amount of options with PICs. A lot more than with the AVRs. You have PICs that can do RF, PWM, timers, A2D, interrupts, USB, I2C, counters, etc. I know a lot of these appear in the AVRs as well, but the PICs have a lot more of these options contained on each PIC. The PICs, for example, have the ability to interrupt on pin level changes, (basically a glorified interrupt), but the AVRs only seem to have 2 interrupt inputs.
• Current drive: The PICs ara really good at driving current. You can whack an LED straight off an output without issue.
• Power saving: The power saving modes are nice on the PICs. You have more options than the AVRs. On some PICs you can slowly downgrade the internal clock, so you could have some code that would increase the clock rate on demand. Also, a lot of PICs can run at 3v, more than the AVRs.

CONs:

• Pages: PICs cannot address all of it’s I/O space. So, to be able to get to all of it’s registers and memory it has to page. It does this with a special register that is present across all pages, (of course it has to be). This means that yo
  u have to ensure that you are referencing the correct page. This makes it especially difficult when you have interrupts going off, as you have to ensure that the old page is set when exiting the ISR or just ensure the correct page is set for every memory/register access. To make matters worse, there’s no way of telling what page you’re on! Also, if you want to move data around you are forced to use
  the ‘w’ register. Why?
• Interrupts: PICs do not have vectored interrupts. This essentially means that your code will be more complex. Once an interrupt has fired, you need to poll all the registers to find out who the hell made the noise. This slows things down a LOT.
• Clock cycles: The execution cycle of a PIC is 1/4 that of the oscillator speed. This means a PIC running with a 20MHz clock will execute instructions every 200nS, (roughly), and not every 50nS. This one bit me in the bum when I started out.
• Instruction set: The PICs have a very small instruction set, (35 instructions). They don’t have any compare, (huh?), they have very simple branching instructions. Gawd, the hassle you have to go through just to compare two numbers takes 4 instructions, and bearing in mind that each instruction is 1/4 clock frequency it all adds up.
• Locking: You can lock a PIC chip to avoid people downloading your code. However, once done that’s it! You can’t change it, game over, throw it out if you got it wrong.

Atmel AVR

PROs:

• No pages: Flat memory model, aaaaah. Nice! No stupid paging. Also, registers are mapped into memory as well, and they can be addressed as memory or register. Basically it’s all there – something compilers really like.
• Interrupts: Nice vectored interrupts. On some of the more recent AVRs, you can also select where you want to place your vectors!
• Clock cycles: 1 clock cycle is 1 instruction cycle.
• Instruction set: You have 130 instructions at your disposal. Also, combined with the memory layout aspect, it gives the MCU the feel of a real CPU. Also, (for me that is), the instruction set just felt a lot more complete.
• Boot loader: The boot loader support is much better in the AVRs. You can specify a boot section and lock it out to avoid overwriting. PICs have the lock ability, but you have to specify the whole darn memory.
• Locking: You can lock an AVR, then erase it, and restart over. Nothing is foreever in AVR land.

CONs:

• Options: There aren’t as many options with AVRs as there are with PICs. It just seems that Microchip have a good sense of which pins to provide what functions. It seems to fit naturally. I found that with my project wanting to use a particular function on a pin, but couldn’t because it was being used for something else. I didn’t seem to have that issue with the PICs.
• Power: Not as many options with power management than you have with the PICs. You have less scaling options with the internal clock, and most AVRs demand 5v. [UPDATE]: Although now you can get AVRs that can go down to 2.5v!
• Price: Overall the AVRs are more pricey than the PICs, although this seems to be changing.

The summary

From the above info my decision was pretty much a no-brainer.

• The AVRs had the feel of a real risc CPU – real memory space, registers, interrupt vectors, 1 instruction per clock cycle.
• I could code up in C, and optimize in assembler.
• Pretty much no restrictions on code space, where to put things, and other bizarre things to confuse matters.
• The boot loader support is really cool.

However, the things I didn’t like with the AVRs:

• Price – A bit more expensive.
• Less pin options – Microchip are much better at function placement on pins.
• All the other CONs I could live with.

No related posts.

I tried getting a rough idea with the kid’s play-dough.


That didn’t work too well, the playdough kept on getting soft. So, then I went out and bought a couple of sheets of styrofoam to carve into a basic shape.


This ended up with a much better model of the final product. But I still wasn’t happy with it.

So I mixed up some plaster and moulded my hand to see if I could get a really comfortable natural grip to my keyboard.


And refined it a bit more.



But the end product would be really hard to manufacture, expensive, and also bulky. But it’d be really cool to have a moulded keyboard like that. Oh well – I’ll leave that for later. So something a bit simpler…..

So I cut up some more styrofoam to be a bit smaller and slimline. Simpler, easy to manufacture and I can chuck it in my pocket.



This is how to hold it and where the keys will be placed. This particular one was a bit small for me, (my fingers are too cramped), so I made a slightly larger one that I didn’t take a photo of. The flat bit where the balls of my hand are will also have the 1.5″
LCD screen, and will flip out to give extra support to my hands..



So now I have a design in mind, I’ll need to make a model of it. The rough procedure is this:

1. Create negative mould – similar to the styrofoam models I made, but I’ll make it out of wood. I find I can work with wood better, and can get more defined angles. I can also create the negative straight away instead of creating the positive, then the negative from that.
2. Paint the negative with wax – This will stop the epoxy from sticking to the mould.
3. Layer on the epoxy with fibreglass matting for strength.
4. Trim off excess bits, including the holes for keys, LEDs and joystick.
5. Drill holes for fixing./LI>

I’ll post up this when I do it.

No related posts.

First up. Why?
Well, the answer is that I’m getting tired of using the standard qwerty keyboard. Even though I can type fairly fast, I am not a touch typist, and only use 6 fingers anyway. With those 6 fingers I can get to 100wpm, but I have to look at the keyboard for finger placement.

What would be nice is to have a keyboard that I could take with me anywhere. Something I can put in my pocket, can connect to my Nokia phone via Bluetooth, or my iPAQ via bluetooth, IR or serial. Then there's my 12 odd PCs at home, and not to mention work. Something with a small screen would be nice so as to easily learn the new finger placement. Something that can last at least a week on batteries. Mmmm.

Requirements:

To that end here’s a list of requirements I’ve gathered:

1. Small, lightweight and cheap.
2. Low power drain – Should minimize the use of batteries as much as possible.
3. Minimize component count – simple design.
4. 8 dot Braille based – although flexible enough to support other ‘standards. Like 6 dot Braille, or GKOS
5. Two handed operation – After scouting around the net it would seem that the best performance comes from two handed operation. Being able to open a door while I type isn’t a priority for me.
6. Portable – Will have to use RF or IR for that.
7. Flexible – Should support USB, PS/2, or RS232 without device drivers.
8. Mouse support – Joystick or trackpoint is probably the best for that. Although I’m also thinking of touchpad, scroll wheels, trackball and accelerometers for future releases.
9. Needs a small display – for those times I need to attach to a serial console, and also for learning the new keys. I found these really cool color LCD modules which would be perfect.
10. Needs a PS/2 passthrough – for those people at work who can’t use it. This is imperative for computer rooms.
11. Quick development – I’ll need a self-programming MCU that can be re-programmed via serial. Of course the #1 micro producers is Microchip, and Atmel.
12. Recharging – Hassle free re-charging. I don’t want to have to take batteries out to re-charge. Even better would be connectionless charging, (like those electric toothbrushes).

Design:

I’ve decided the best way to tackle this is to modularize things. I’m a big fan of write once use many. So the idea here is to break down the conponents of the design into modules. This will also allow me to gradually develop and lead onto bigger things. The downside to this is that it’s slightly more expensive. I could make the whole keyboard by using one chip, but it’s not as flexible. This way I can use these modules in other projects later on.

NOTE: I originally was intending to use Microchip’s PIC MCUs, but found they were limited in various ways. So I’m going with Atmel’s AVR chipset – much better. If I get time, I’ll document the differences between the two, and why I chose the AVRs. This is the second design the initial design is here.

In the end I decided to use the recently released ATmega8 MCUs for the modules. This’ll mean that this design will be around for a long time. They cost a little bit more than the PIC chips, but have a whole swag of features. Big code space, lot’s of I/O options, self-programming, UART, I2C. All for $5! Really nice! Also no need for an external crystal, (like all PICs, and AVRs).

• Keyboard module – will have the eight braille keybord buttons, a MODE button, and a joystick, (easiest to implement). This will be the keyboard module, and can be plugged into either the PS/2 port or a serial port, (or serial to USB adapter). Also support I2C bus, so that it can be attached to other modules, and has an LCD display.
• Wireless module – Will provide the keyboard module with RF and IR transmission, and a PS/2 bridge. This means for a full wireless setup, I’ll need two of these modules and one keyboard module.

Keyboard module:

Excuse the ASCII art, but this is the rough design of the pinouts of the ATmega8 and their function. Note the mysterious lack of crystal! These chips are bloody good eh?!

                               ATmega8-KYB

                            +-------------+
                            |             |
        Key MODE         1 s> RST     SCL +- 28 - Wireless CLK
                            |             |
        UART/uLCD Rx     2 -> RXD     SDA +- 27 - Wireless DATA
                            |             |
        UART/uLCD Tx     3 -< TXD     PC3 +- 26 - PS2 kyb data
                            |             |
        PS2 mouse clk    4 -> INT0    PC2 +- 25 - PS2 mouse data
                            |             |
        PS2 kyb clk      5 -> INT1   ADC1 &lt;- 24 - Y-axis joystick
                            |             |
        LED status       6 -< PD4    ADC0 &lt;- 23 - X-axis joystick
                            |             |
        Vcc              7 -+ VCC     GND +- 22 - Gnd
                            |             |
        GND              8 -+ GND    AREF +- 21 - Analog Vref
                            |             |
        Key R2           9 -> PB6    AVCC +- 20 - Analog Vcc
                            |             |
        Key R3          10 -> PB7     PB5 <- 19 - Key R1
                            |             |
        Wireless INT    11 -> PD5     PB4 <- 18 - Key R0
                            |             |
        Enable uLCD     12 -< PD6     PB3 <- 17 - Key L3
                            |             |
        Enable UART     13 -< PD7     PB2 <- 16 - Key L2
                            |             |
        Key L0          14 -> PB0     PB1 <- 15 - Key L1
                            |             |
                            +-------------+

So the idea here is to keep the I2C and UART bus useable for either standalone use or attached to the Wireless or Display modules. It’s all pretty basic stuff, the only thing of note is that I am using the MODE key, (provides pullup to pin 6), to also supply power
to the joystick resistors. This is an attempt to minimize current drain. If I didn’t do this I’d have the joystick pots constantly draining batteries. This also means that I only sample the joystick ports when the MODE button is pressed, (no accidentally banging the joystick). It also means that I can switch the R1, R2, and R3 keys into ‘mouse mode’ in which they become the left, middle and right buttons. This is a natural fit for me since I’m a right handed mouse type person.

Just a plug here for a great prototyping place I found. Have a look at www.sparkfun.com. They are gadget made, and have a lot of cool gadgets. Fairly reasonable prices too.

I’ve ordered all the bits and while I’m waiting I started fooling around with boxes.

Wireless module:

                                ATmega8-WIRELESS

                            +-------------+
                            |             |
        Key MODE         1 s> RST     SCL +- 28 - Keyboard CLK
                            |             |
        UART/uLCD/IR Rx  2 -> RXD     SDA +- 27 - Keyboard DATA
                            |             |
        UART/uLCD/IR Tx  3 -< TXD     PC3 +- 26 - PS2 kyb data
                            |             |
        PS2 mouse clk    4 -> INT0    PC2 +- 25 - PS2 mouse data
                            |             |
        PS2 kyb clk      5 -> INT1    PC1 +- 24 -
                            |             |
        LED status       6 -< PD4     PC0 +- 23 -
                            |             |
        Vcc              7 -+ VCC     GND +- 22 - Gnd
                            |             |
        GND              8 -+ GND    AREF +- 21 - Analog Vref
                            |             |
        Disable HID      9 -+ PB6    AVCC +- 20 - Analog Vcc
                            |             |
        Enable IR       10 -< PB7     SCK >- 19 - RF (CLK1)
                            |             |
        Keyboard INT    11 -< PD5    MISO <- 18 - RF (DATA) <--
                            |             |
        Enable uLCD     12 -< PD6    MOSI >- 17 - RF (DATA) -->
                            |             |
        Enable UART     13 -< PD7      SS >- 16 - RF (CE)
                            |             |
        RF (PWR_UP)     14 -< PB0     PB1 >- 15 - RF (CS)
                            |             |
                            +-------------+

No related posts.

No related posts.

No related posts.

Requirements:

To that end here’s a list of requirements I’ve gathered:

1. Small, lightweight and cheap.
2. Low power drain – Should minimize the use of batteries as much as possible.
3. Minimize component count.
4. 8 dot Braille based – although flexible enough to sup
   port other ‘standards. Like 6 dot Braille, or GKOS
5. Two handed operation – After scouting around the net it would seem that the best performance comes from two handed operation. Being able to open a door while I type isn’t a priority for me.
6. Portable – Will have to use RF or IR for that.
7. Flexible – Should support USB, PS/2, or RS232 without device drivers.
8. Mouse support – Joystick is probably the best for that. Although I’m also thinking of trackpoint, touchpad, scroll wheels,
   and accelerometers for future releases.
9. Needs a small display – for those times I need to attach to a serial console, and also for learning the new keys.
10. Needs a PS/2 passthrough – for those people at work who can’t use it. This is imperative for computer rooms.
11. Quick development – I’ll need a self-programming micro that can be re-programmed via serial. Of course the #1 micro produc
    er is Microchip.
12. Recharging – Hassle free re-charging. I don’t want to have to take batteries out to re-charge. Even better would be connec
    tionless charging, (like those electric toothbrushes).

Design:

I’ve decided to the best way to tackle this is to modularize things. I’m a big fan of write once use many. So the idea here is to
break down the conponents of the design into modules. This will also allow me to gradually develop and lead onto bigger things. The do
wnside to this is that it’s slightly more expensive. I could make the whole keyboard by using one chip, but it’s not as flexible. This
way I can use these modules in other projects later on.

In the end I decided to use the recently released 16F88 for the modules. This’ll mean that this design will be around for a long ti
me. They also cost as much as the 16F84 and 16F628A chips, but have a whole swag of features. Big code space, lot’s of I/O options, se
lf-programming, UART, I2C. All for $4! Really nice! Also no need for a crystal, (like all PICs).

• Basic keyer – will have the eight braille keybord buttons, a MODE button, and a joystick, (easiest to implement). This wil
  l be the basic keyboard, and can be plugged into either the PS/2 port or a serial port, (or serial to USB adapter). Also support I2C b
  us, so that it can be attached to other modules.
• PS/2 bridge – Can either provide a connection point for the Basic keyer via cable, or be connected to the Wireless module.
  This allows a normal keyboard and mouse to be connected to the PS/2 ports, and provides a passthrough for those. As an aside it could
  also provide translation for those of us who are bent on Dvorak or other layouts.
• Wireless – Will provide the Basic keyer with RF and IR transmission. The PS/2 bridge will have an identical unit as well.<
  /li>

• Display – When the basic keyer is attached to this module, it will extend it’s capabilities by providing: 1) charging cont
  rol, 2) LCD display, 3) USB and PS/2 connections. Able to re-program other modules either serially or via RF. Additionally, if the Wir
  eless module is connected, then it’ll use that.

Basic keyer module:

Excuse the ASCII art, but this is the rough design of the pinouts of the 16F88 and their function. Note the mysterious lack of cry
stal! These chips are bloody good eh?!

                                16F88-KYB
                            +-------------+
                            |             |
        key L2           1 -+ RA2     RA1 +- 18 - key L1
                            |             |
        key L3           2 -+ RA3     RA0 +- 17 - key L0
                            |             |
        key R0           3 s+ RA4     RA6 +s 16 - key R2
                            |             |
        key R1           4 s+ RA5     RA7 +s 15 - key R3
                            |             |
        GND              5 -+ Vss     Vdd +- 14 - Vcc
                            |             |
        key MODE         6 s+ INT     AN6 +- 13 - Y-axis joystick
                            |             |
        I2C data/LED A   7 -+ SDA     AN5 +- 12 - X-axis joystick
                            |             |
        UART Rx          8 -+ RX       TX +- 11 - UART Tx
                            |             |
        INT              9 -+ RB3     SCL +- 10 - I2C clock/LED B
                            |             |
                            +-------------+

So the idea here is to keep the I2C and UART bus useable for either standalone use or attached to the Wireless or Display modules.
It’s all pretty basic stuff, the only thing of note is that I am using the MODE key, (provides pullup to pin 6), to also supply power
to the joystick resistors. This is an attempt to minimize current drain. If I didn’t do this I’d have the joystick pots constantly dra
ining batteries. This also means that I only sample the joystick ports when the MODE button is pressed, (no accidentally banging the j
oystick). It also means that I can switch the R1, R2, and R3 keys into ‘mouse mode’ in which they become the left, middle and right bu
ttons. This is a natural fit for me since I’m a right handed mouse type person.

Just a plug here for a great prototyping place I found. Have a look at www.sparkfun.com. Th
ey are gadget made, and have a lot of cool gadgets. Fairly reasonable prices too.

I’ve ordered all the bits and while I’m waiting I started fooling around with boxes.

The bits arrived, and I managed to get to the penultimate milestone. I grabbed a copy of the Tiny PIC bootloader, and got to the boot prompt. Woohoo!

PS/2 bridge module:

Wireless module:

Display module:

No related posts.

t

h

e

q

u

i

c

k

b

r

o

w

n

f

o

x

j

u

m

p

e

d

o

v

e

r

t

h

e

l

a

z

y

d

o

g

.

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

p

q

r

s

t

u

v

w

x

y

z

Shift for alphabet:

0

1

2

3

4

5

6

7

8

9

.

,

;

:

?

!

‘

”

“

”

(

)

+

-

x

÷

=

[

]

{

}

<

>

$

¢

%

£

€

¥

*

#

_

\

|

/

&

@

^

`

~

ñ

Ñ

¡

¿

ç

Ç

enter

space

backspace

up

down

left

right

home

end

tab

shift

ctrl

alt

del

ins

F1

F2

F3

F4

F5

F6

F7

F8

F9

F10

F11

F12

F13

F14

F15

No related posts.