Dear Nerds,

I am sending two battery packs (including charge circuit & DC-DC step up to 5.5V) to you today, one has 650mAh 3.7V capacity, the other one has 400mAh, 3.7V capacity. These li-poly batteries are the ones I bought for prototype. For my project in production, I will use 1500mAh 3.7V li-poly battery, which is a little bit bigger - 60mm x 50mm x 5mm .

You can plug in USB mini cable to the USB socket to charge the battery from the PC (the LED will turn on). The data lines are available on the USB socket, you need to be a bit careful of soldering wires onto it. For power up your PIC/eeprom, I'd think you better use a proper LDO regulator - like the AMS1117 - step down 5V to 3V3; because the battery outputs anywhere between 3.6V to 4.2V directly.

Regards,
Xing

Any day now, we should have a conclusion to the debate "lipos - good, bad or ugly?"

...especially when they're attached to a Nokia 6610 breakout board. This little fella provides 4-axis input (plus a "fire" button) using a single input pin. It's quite clever really, but simply uses a load of resistors, to change the input voltage depending upon which direction has been pressed.
Put the input from the miniature joystick on the Arduino Nokia board onto pin A0 of a PIC microcontroller and read the input values.



The Oshonsoft PIC18 the command for reading an analogue input is:

Adcin 0, joystickvalue

This takes the input from analogue channel zero (in our case, PORTA.0) and writes it to the variable "joystickvalue".
During testing, with an open connection (joystick centred, no movements made) the joystick value wavered between 169-170. At first this seems odd, but looking at the schematic datasheet we can see that the reference voltage from the joystick is between 0v and 3.3v.

Taking the average value of 170, and given that we're storing this data into a byte variable, we can see that (170/255)*5v = 3.3v.
So it all makes sense again - with no joystick movement, we expect to receive 3.3v from the joystick onto our analogue pin. And the value 170 does indeed represent a 3.3v signal when our PIC is powered by a 5v supply.

A simple routine was put together to write the value of the joystick input onto the Nokia screen. The following was determined:



This translates quite nicely into a simple subroutine for any project that uses this board. The routine waits for the joystick to be moved, stores the direction into a variable then waits for the joystick to be released again.
The routine can be called from anywhere in the program, though it might work quite nicely if called from a timer interrupt, since the user input is stored until the microcontroller is free to process it.

Dim joystickvalue as Byte
Dim jstick(5) as Byte
Dim buttonpressed As Byte

jstick(1) = 126 'right
jstick(2) = 88 'up
jstick(3) = 60 'down
jstick(4) = 26 'fire
jstick(5) = 4 'left

---

getbuttonpress:
  'single input ADC for joystick press
  Adcin 0, joystickvalue

  'compare current joystick value to stored values
  'at rest returns 172-168, first value is 120-122 for "right"

  If joystickvalue < 140 Then
    For i = 0 To 4
      If joystickvalue < jstick(i) Then
        buttonpressed = i
      Endif
    Next i

    'debounce the button press
    WaitMs 1
    Adcin 0, joystickvalue
    If joystickvalue < 140 Then
      'wait for the button to be released
      While joystickvalue < 140
        'keep sampling the joystick to see whether it's been released
        Adcin 0, joystickvalue
      Wend
    Else
      buttonpressed = 0
    Endif

  Else
    buttonpressed = 0
  Endif

Return

---

One thing that quickly comes to light when working with the Nokia 6610 display - it has no libraries of its own to use: that means that you have to hand-code pretty much everything for it, including making your own fonts and writing your own bitmap display routines.
This means that your code bloats up pretty quickly.

In fact, to demonstrate using bitmaps, drawing strings of text, and including USB support (in order to send commands to the display to test different combinations of things) our code is already a whopping 9.4kb in size.
That leaves around 15kb of space for actually coding that the device should do (on a 18F2455 chip anyway). So almost half of the available program space is taken up with libraries for controlling the display! (ok, it also includes a routine for reading/writing to eeprom, but that it itself is only a few hundred bytes big!)

In fact, forgetting about the eeprom routines could be quite a mistake - instead of hard-coding menu data into the program memory (which strings to display and in which order) it makes a lot of sense to put these strings into external memory.
This offers two distinct advantages: firstly, you're not filling all your program space with strings of characters that make up the menus (you can just use a double-byte word to keep track of the eeprom address that contains the string to draw for each menu item). Secondly, it means porting your device to another language (it's wishful thinking, but there's a massive European market for electronic golf scorecards too) is a relatively painless task: simply update the strings held in eeprom using an external app and your original device code does not need to keep being amended and recompiled. Interesting idea....

Taking this idea a step further, instead of just storing strings in memory, I've decided to store the entire menu structure in eeprom.
The block diagram looks something like this:

• Each menu begins with a title
• C = count the number of items in this menu
• X/Y = position on screen this menu should be displayed at
• goto = pointer to eeprom address of the next menu to be displayed

The "variable" C has two functions:
The upper three bits are flags to tell us:

• Clear the entire screen before drawing this menu?
• Remove this menu after selecting an item?
• (reserved)

The remaining lower bits contain the value (1-31) telling us the number of items in the list.

The variable "goto" has some special/reserved values:
0 = do nothing when any item in this menu is selected
65535 (0xffff) = go into edit mode when any item in this menu is selected

"Edit mode" puts the device into a special state, where each character of the menu item can be highlighted and changed, individually. This means that, for example, player names can be put into a menu (so that a player can be selected) but at the same time, player details can be updated (e.g. change the letters of a players name).

If the variable "goto" has a valid value (i.e. a number between 1-65534) then this is the eeprom memory address containing the next menu. The current menu is cleared from screen (if necessary) and the new menu is drawn.

Here's a sample menu, converted to a byte array and written to eeprom

84, 105, 116, 108, 101, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 12, 20, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 49, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 50, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 52, 0, 0, 0, 0, 0, 0, 0, 0, 0

You'll see how the first byte is 84 (ascii 84=letter T), followed by 105 (ascii 105=i) and so on, spelling out the word "Title" and some padding bytes. The values 4,12,20 are the C,X and Y values, followed by the next line item in the menu: ascii 77=letter M, ascii 101=letter e (and so on, spelling out "Menu item 1").
Here's the resulting menu, drawn on the Nokia 6610 screen: