Datalogging with uALFAT-TF and Hi2c

BCJKiwi

Senior Member
Datalogging with uALFAT-TF and Hi2c

This Post is intended to demonstrate the application of uALFAT-TF for datalogging with PICAXE.

uALFAT information is available on the developers website;
http://www.ghielectronics.com/products.php

uALFAT supports serial, i2c and spi interfaces
GHI3232 supports serial and spi and is a specific optimised datalogging system
uALFAT and GHI3232 are alternative firmware that can be loaded on the same chip.
The advantage of GHI3232 is the software is simple with filename, write management including dataflush and closing, all automatic.
The disadvantage is that many pins are required for handshaking to allow the simplified software to work.
The main application of uALFAT appears to be supply of the core chip to OEMs and developers for including in products for sale.

GHI Electronics also supply OEM boards for USB and SD including their latest uALFAT-TF for microSD (or Transflash - TF).

Why uALFAT instead of VDrive2?
VDrive2 supports serial and spi only. Serial was not available in my application (being used for another device), and all my attempts to implement VDrive2 with HSPI failed.

The standard uALFAT firmware on the uALFAT-TF board is discussed here as there simply were not enough free I/O for GHI3232. The 'TF' board is the smallest (35mm x 26mm) and the cheapest US$39.95 for one and US$26.95 ea for 2, direct from the manufacturer.

uALFAT has a number of specific hardware and software requirements;
Hardware,
1. For USB, both 5V and 3,3v supplies are required.
2. For SD, 3.3v supply is required.
Software,
1. The card must be told each time it powers up which interface mode to set up in. There are no specific jumpers for this but some of the I/O lines can be tied high/low with pullup/down resistors to achieve this function, however the Reset line on the device must be toggled after it has powered up in order to set the interface mode.
2. All commands take the form of a single letter followed by a space then the parameter(s) then the CR/LF combo in the form of $0D.
3. All responses (and there is one for every command) take the form !xx where if xx is 00 then all is normal else the are a large number of different responses indicating the specific error.
If there is further informational data such as the number of bytes written to file, this is returned in the form $000000A1.
4. All commands and responses are in ASCII but this is not what you might expect.
for example to set the date/time in uALFAT (it has its own clock for date/time stamping the files) the date time has to be calculated in a specific format of a 32bit DWORD which is hex. e.g. the code for 07/12/25 23:59;00 (YY/MM/DD HH:MM:SS) is 3799BF60 but this must be sent as ASCII "3799BF60". Similarly the number of bytes to be written - say 19 which is hex13 must be sent as ASCII 13.
*5. SD devices do not detect datacard insertion/removal - must be handled via software response error checking.
*6. Does NOT handle i2c sequential reads - not really an issue for this application as only interested in error checking and have to test data as it arrives but could be an issue if large data reads required.
***but does support block read for data - The number of bytes to be read must be specified in the read command and it will read that many bytes, It always reports the actual number of bytes read so if there are insufficient bytes it reports the actual number read and pads the data returned to the number specified with 'Z" characters.
The error handler is separate you just pull all the data there is a byte at a time until there is no more (DATARDY line high if there is data to get)

Features of the following demonstration program;
Devices utilised are;
PICAXE 28X1 FW VA.0 (some issues with the ptr handling, resolved in FW A.2)
Maxim/Dallas DS1307 RTC
GHI Electronics' uALFAT-TF OEM board and AData 1Gb microSD card

1. Utilises an Input to handshake the DATARDY to control reading of all responses/datareads
2. Utilises an output to toggle the reset line to set up for i2c operation
3. Reads the RTC
4. Sets the uALFAT clock with the time from the DS1307. uALFAT has it's own clock which can have its own battery backup but as this application already has the DS1307 it seems preferable to have a single time base and set the uALFAT to match on power up.
5. Initialise file system, create files, write to files, flush data. Reads not required in this application but function is similar to write, and read functionality is demonstrated with error/response message handling.
6. File Names are created in the form YYMMDD_xxxx where xxxx is 0001 to 9999 and is sequentially increased each time a new file is opened on the same date and starts again from 0001 on each new date. Index number retained over power cycles.
7. Files are created in .CSV format.
8. Filename and column headers are written to each file when created.
9. Currently writes date and time as often as the demonstration program cycles, reading a new time from the DS1307 each cycle.
**9 writes per second with serTXD off and 28X1 at 8Mhz internal resonator with uALFAT error checking.
**18 writes per second with serTXD off and 28X1 at 16Mhz external resonator with uALFAT error checking.
10. Checking for errors and managing errors if they arise - response to errors to be developed.
11. Files are date/time stamped by uALFAT automatically in the standard FAT32 style (created, last modified etc)

Code in following post;
 
Last edited:

BCJKiwi

Senior Member
Code:
'####################################################################################
'# PICAXE 28X1,  GHI Electronics uALFAT-TF,    DALLAS DS-1307 RTC    #
'####################################################################################
#picaxe 28x1
setfreq em16
'####################################################################################
' Interfacing a uALFAT module to PICAXE-28X1
' Hardware Setup for i2c
'
' uALFAT Standard FW      - PICAXE-28X1
' **** NOTE:-  # Denotes Active Low ****
' 1  UART_TX/DATARDY O - Input0 (errors & responses)C0 Leg 11
symbol uADat = Input0
' 2  UART_RX/BUSY  O - NC  (Device Busy)
' 3  i2c_SCL   I - i2c_SCL      C3 Leg 14
' 4  i2C_SDA          I/O - i2c_SDA      C4 Leg 15
' 5  SPI_SCK   I - NC @ uAlfat Tie low ( 0V ) via 10K Interface mode select
' 6  MISO/RTS    O - NC
' 7  MOSI/CTS    I - NC  
' 8  SPI_SSEL#    I - NC @ uAlfat Tie High (3.3V) via 10k Interface mode select
' 9  RESET#    I - Output1 (uAlfat Reset)  B1 Leg 22
symbol uARes  = Output1
' 10 Black   GND  I - 0V       Common Ground
' 11 Red     V+   I - V+       3.3V
' 12 BL#    I - NC
' 13 VBATT    I - 3V or tie to V+ if not using Battery
'
symbol uATF  = %10100100  'GHI Electronics uAlfat-TF i2c address - Fixed
eeprom 186,(0,0)    'initialise counter for filename in 186 & 187
symbol RTC_0 = %11010000  'Dallas DS1307 RTC i2c address - Fixed
' open terminal after download
#terminal 19200     'Baud rate
'
General_Init:
'uALFAT
uAInit:
pause 3500      'wait for uAlfat to initialise fully
'sertxd ("<uALFAT initialise ",cr,lf) 
'low 3       'Jumper low  - set SPiClock low  for interface mode selection
'high uACS      'Jumper high - set SPiSSEL# high for interface mode selection
low  uARes      'reset chip to ensure uAlfat is set to i2c interface mode
high uARes      'Does not set up properly without the Pause & toggle of Reset#
'sertxd ("uAInit")    'Indicate what we are doing
hi2csetup i2cmaster,uATF,i2cfast_8,i2cbyte 'hi2csetup only required once per POR
gosub get_response    'Get initialisation header info 
'
RTCInit:
'RTC
'hi2csetup i2cmaster,RTC_0,i2cfast_8,i2cbyte 'hi2csetup only required once per POR
hi2cout [RTC_0],0,($00,$58,$23,$03,$25,$12,$07,%00010000) 'Remove once battery backup applied 
gosub RTC_Read
ptr = 192      'set pointer to beginning of clock data, write data to terminal
 sertxd (cr,lf,"YY_",@ptrinc,@ptrinc,","," MM_",@ptrinc,@ptrinc,","," DD_",@ptrinc,@ptrinc,","," HH_",@ptrinc,@ptrinc,","," MM_",@ptrinc,@ptrinc,","," SS_",@ptrinc,@ptrinc,CR,LF)
'
'set clock in uAlfat from DS1307 time
'sertxd ("<uAlfat SetClock>") 'Indicate what we are doing
GoSub uA_SetTime
if input1 = 1 then    'Selection switch for SD card inserted
 gosub uA_InitFilesys
endif
'
Main:
'
RTC:
gosub RTC_Read
'ptr = 192      'write data to terminal
'sertxd (cr,lf,"YY_",@ptrinc,@ptrinc,","," MM_",@ptrinc,@ptrinc,","," DD_",@ptrinc,@ptrinc,","," HH_",@ptrinc,@ptrinc,","," MM_",@ptrinc,@ptrinc,","," SS_",@ptrinc,@ptrinc,CR,LF)
'
if input1 = 1 then     'Selection switch for SD card inserted
 gosub uA_Send
endif
'
'
#rem
' Update uALFAT Firmware
sertxd ("<Load new FW")   'Indicate what we are doing
pause 500
 hi2cout ("X S",$0D)   'Load new Firmware
 gosub get_response
pause 60000 '15 secs @ 16MHz
sertxd (cr,lf,cr,lf,"remove SD card",cr,lf,cr,lf) 'Indicate finished write 9takes about 10 secs
end
#endrem
'
goto main
'
'####################################################
'#  SUBROUTINES         #
'####################################################
'
get_response:
'pause 50      'Pause required if UART_TX/DATARDY not direct connected!
'Sertxd ("-Response> ")   'Indicate what we are doing
Do While uADat =1    'DATARDY pin on uALFAT-TF goes high if there is data to be read.
 hi2cin (b0)      'read byte
' sertxd (b0)      'transmit it
 If b0="!" then              'test for response - "!00" is OK anything else is a problem
  hi2cin (b1)
  if b1 <> "0"then 
   gosub uA_MediaError
  else hi2cin (b2)
   if b2 <> "0"then gosub uA_MediaError
  endif
 EndIf
Loop       ' get everthing there is to get
Return
'
RTC_Read:
ptr = 192
for b27 = 6 to 0 step -1  'YMD   Read from registers 6,5,4
 if b27=3 then    'DoW   Read from register  3 - NOT USED so skip
  let b27=2    'HMS   Read from registers 2,1,0
 endif
 hi2cin [RTC_0],b27,(b0)  '[RTC_0],  Ensure yhe correct i2c device is addressed
 bcdtoascii b0,b1,b2   'convert BCD to ASCII
 @ptr=b1
 inc ptr
 @ptr=b2
 inc ptr
next
Return
'
uA_MediaError:
sertxd ("<Error>",b0,b1,b2,cr,lf) 'display contents of error 
Pause 5000
'turn on LED, set flag to stop running uAlfat routines
Return
uA_Send:
'sertxd ("<Write to Handle 0 hex13 bytes, SendData") 'Indicate what we are doing - 2 commands combined
 ptr = 192
 hi2cout [uATF],("W 0>13",$0D,@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,cr,lf)
 gosub get_response
 ' if <> !00 - card removed
'sertxd ("<FlushFile")    'Won't work if part of previous command
 hi2cout ("F 0",$0D)    'Flush data to, and update file details
 gosub get_response
'sertxd ("<Close file ")    'Indicate what we are doing
' hi2cout ("C 0",$0D)    'Close file
' gosub get_response
Return
uA_InitFilesys:
'create filename in the form YYMMDD_9999 where 9999 is sequentially created from 0001 each day
ptr = 188
for b27 = 6 to 4 step -1
 hi2cin [RTC_0],b27,(b26)  'YMD   Read from registers 6,5,4
 if @ptr <> b26 then    'compare to see if changed from last file system initialisation
  let @ptr = b26
  let w12 = 0
  write 186,WORD w12   'zero fileName index number
 endif
 inc ptr
next
'
Read 186,WORD w2       'read FileName index 0 to 9999 number from eeprom location 186
w2 = w2 + 1
if w2 > 9999 then let w2 = 1 :endif
Write 186,WORD w2     'store new index number
ptr =198       'replace DS1307 HH,MM with 0001 thru 9999
@ptr = w2 DIG 3 +"0"  '1000s
inc ptr
@ptr = w2 DIG 2 +"0"  '100s
inc ptr
@ptr = w2 DIG 1 +"0"  '10s
inc ptr
@ptr = w2 DIG 0 +"0"  '1s
'
'sertxd ("<Initialise FileSystem") 'Indicate what we are doing
hi2cout [uATF],("I ",$0D)   'Initialise file System
gosub get_response
'sertxd ("<Open/Append ")   'File name YYMMDD_0001.CSV Note:- 'Append' will Append or Create New if not existing
ptr = 192       'set memory location to beginning of clock data
hi2cout ("O 0A>",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,"_",@ptrinc,@ptrinc,@ptrinc,@ptrinc,".CSV",$0D)
gosub get_response
'sertxd ("<Write, FilenameData")  'Write File name as first entry in File (Hex12 = 18 bytes)
ptr = 192
hi2cout ("W 0>11",$0D,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,"_",@ptrinc,@ptrinc,@ptrinc,@ptrinc,".CSV",cr,lf)
gosub get_response
'sertxd ("<Write, HeaderData, Flush ") 'send header data for column headers (Hex13 = 19 bytes) 
hi2cout ("W 0>13",$0D,"YY,MM,DD,HH,MM,SS",cr,lf,"F 0",$0D) '3 separate commands combined into one
gosub get_response
'sertxd ("<SendData")    'Indicate what we are doing
'hi2cout ("YY,MM,DD,HH,MM,SS",cr,lf) 'send header data
'gosub get_response
'sertxd ("<FlushFile")    'Indicate what we are doing
'hi2cout ("F 0",$0D)    'Flush file
'gosub get_response
'sertxd ("<Close file ")   'Indicate what we are doing
'hi2cout ("C 0",$0D)    'Close file
'gosub get_response
Return
'
uA_SetTime:       'Runs one time per power up
 ptr = 192      'set scatchpad pointer to beginning of clock data
gosub uA_GetClk
 b0 =w11+2000-1980    'YY - convert to number of years since 1980
gosub uA_GetClk
 b1=w11
gosub uA_GetClk
 b2=w11
gosub uA_GetClk
 b3=w11
gosub uA_GetClk
 b4=w11
gosub uA_GetClk
 b5=w11
'         'Initial concept for this routine courtesy of ibenson
w5 = b0 << 9       '* 512 ' shift year to bits 9-15
w6 = b1 << 5       '* 32  ' shift month to bits 5-8
w5 = w5 + w6 + b2      'YMD
w6 = b3 << 11       '* 2048 ' shift hour to bits 11-15
w4 = b4 << 5       '* 128 ' shift minutes to bits 5-10
b5 = b5 / 2       'seconds divided by 2
w6 = w6 + w4 + b5     'HMS
'
'      'Initial concept for this routine courtesy of ibenson
' Create 8 nibbles from 2 words and convert to ascii representation of Hex Data
' to send to uAlfat in required ascii format ( a DWORD of int32 in 'C' )
b7 = b11 >> 4                        'shift high nibble to low nibble
      gosub uA_ChkAlpha
b0 = b7+"0"                          'temporary store
'
b7 = b11 & $0F
      gosub uA_ChkAlpha
b1 = b7+"0"
'
b7 = b10 >> 4
      gosub uA_ChkAlpha
b2 = b7+"0"
'
b7 = b10 & $0F
      gosub uA_ChkAlpha
b3 = b7+"0"
'
b7 = b13 >> 4
      gosub uA_ChkAlpha
b4 = b7+"0"
'
b7 = b13 & $0F
      gosub uA_ChkAlpha
b5 = b7+"0"
'
b7 = b12 >> 4
      gosub uA_ChkAlpha
b6 = b7+"0"
'
b7 = b12 & $0F
      gosub uA_ChkAlpha
b7 = b7+"0"
'
'set time
hi2cout [uATF],("T S",$0D)   'set uALFAT clock to run from main power
hi2cout ("S ",b0,b1,b2,b3,b4,b5,b6,b7,$0D) 'set time in clock
'hi2cout ("G X",$0D)    'get back hex value of time
'gosub Get_response
'hi2cout ("G F",$0D)    'get back US date formatted time
'gosub Get_response     '(PC file system displays as per region setting) 
'end
Return
'
uA_GetClk:  
[EMAIL="b20=@ptr"]b20=@ptr[/EMAIL]       'Get ascii clock data from scatchpad
inc ptr
[EMAIL="b21=@ptr"]b21=@ptr[/EMAIL]       'Get ascii clock data from scatchpad
w11 = b20 * 10 + b21 - $210   '$210 = $30 * 10 + $30  'courtesy of ibenson & Hippy
inc ptr        'shift high byte, add low byte, change ascii to hex
Return
'
uA_ChkAlpha:
if b7 > 9 then                       'test to see if hex over numerical value
      b7=b7+7                     'if so, convert to alpha value & convert to ascii
else
      b7=b7                        'else leave as numerical & convert to ascii
endif
Return
 
Last edited:

lbenson

Senior Member
Very nice project example for those wanting access to large amounts of memory. Very well-documented code which will repay a lot of study.

Have you looked at the ALFAT capabilities for implementing USB interfaces? That would provide amazing expansion capabilities to the picaxe. I have a GSM cell phone with USB interface I'd like to hook up to send text messages ...
 

BCJKiwi

Senior Member
The process is almost identical for USB memory stick.
The uALFAT chipset and firmware are identical for both USB and SD.
The USB OEM board (uALFAT-USB) has added components (a Max3421 USB host controller) which provides the necessary USB to uALFAT chip interfacing.
There is a different command to initialise the file system (U instead of I) and there is also a command for USB device detection which is not yet available for the SD versions.
So the code snippet should work unchanged for USB with the exception of the Detect 'U' then initialise 'J' routine in place of the blind initialise 'I' routine for the SD version. You still have to check for errors so the overall process is not much different.
The cost is higher (at US$45.95 for one) and the card is little larger (at 45mm x 36mm).

The uALFAT and (GHI3232) firmware are optimised for write/reading storage devices.
I'm doubt they would work right off if you plugged a cable straight into your phone.
However they also have a uALUSB firmware which is designed for interfacing to other devices like mouse, joysick, printer, etc as well as mass storage.
These different firmwares are freely available from their website and can be loaded into the chip to test and the other loaded again later if you need.

Have not studied the uALUSB in detail so you would need to check it out.

They also have other products including a USBWIZ and MP3 add-ons etc.

The application under development requires the data to be moved to a PC for analysis so removable media was the way to go. As for size - you buy the card size you need and SD sizes are getting up there (8Gb) but are a bit more pricey than USB memory sticks

I'm just happy that I now have something that actually works reliably!
 

BCJKiwi

Senior Member
Updated Post #1 details.

GHI Electronics have just released a new version of the firmware (3.06) which has improved support for i2c.
1. i2c speed is confirmed 400kHz and is claimed to be more robust.
2. Error monitoring can now be carried out over i2c eliminating the need for monitoring the DATARDY pin. However if there is a spare input available the DATARDY pin is probably simpler and quicker.
Software error checking requires testing for ! (! is error/info flag char) then accumulating the next 2 Chars and testing them to see what they are to determine if there is an error.
To use this routine to check to see if there is data to be read adds delay and complication.
Bear in mind that these products are usually run off compiled assembler routines in the PIC, not PICAXE BASIC!
 
Last edited:

yamato96

New Member
any possibility to use u-alfat with picaxe 18x trough simple i2c?
hacking 18x datalogger would be the anwser to my prayers!
 

BCJKiwi

Senior Member
Well I have not tried it as the 28x1 is the platform in use so just went directly to the hi2c modes.

Don't have an 18X to test but could try some basic non 'h' mode commands on the 28x1 over the next few days if you think that would help.

There have been a few other updates from uALFAT since the write up above.
 

BCJKiwi

Senior Member
There have been a number of firmware upgrades from GHI for the uAlfat - currently at Ver 3.08.
Note that LFN is not currently supported as there are licensing issues with Microsoft who now have a patent on LFN. GHI are negotiating a license on behalf of end users.

Feature set and comments generally as for POST #1 above. Some notes have been removed to fit inside 10000 character post size limit.

@ yamato96
Have rem'd out all the hi2c code and replaced it with the 18X compatible version for a quick test and it stores to the uAlfat without incident. Note that the i2cslave is required each time the device changes unlike the hi2c where the address can be part of the read / write.

Code:
'PICAXE 28X1  fw A.2,     RTC DS-1307,    uALFAT Ver 3.08
'
#picaxe 28x1
SetFreq em16
#terminal 19200
'
symbol RTC_0 = %11010000   'Dallas DS1307 RTC i2c address - Fixed
symbol uATF  = %10100100   'GHI Electronics uALFAT-TF i2c address - Fixed
symbol uADataReady = Input0   'uALFAT UART_TX/DATARDY
symbol uAStartLog  = Input1   'switch for Logging
symbol uARes = Output0    'uALFAT RESET
'
'Scratchpad
'93 thru 104      DS-1307 RTC Clock - YYMMDDHHMMSS
'93 thru 98       DS-1307 RTC Clock - YYMMDD - file initialisation
'99 thru 104      DS-1307 RTC Clock - HHMMSS - log data hhmmss
'101,102,103,104     Filename Index number - uAlfat initialisation
'105,106,107      D1,2,3
'108,109,110,111     D4,5,6,7
'112        D8
'113,114,115,116     D9,10,11,12
'117,118,119,120     D13,14,15,16
'121,122,123,124     D17,18,19,20
'
Init:
' hi2csetup i2cmaster,RTC_0,i2cslow_16,i2cbyte 'hi2c setup line only required once per POR
' hi2cout [RTC_0],0,($00,$59,$23,$01,$22,$03,$08,%00010000)
 i2cslave RTC_0,i2cslow_16,i2cbyte
 writei2c 0,($00,$59,$23,$01,$22,$03,$08,%00010000)
'
uAInit:        '!!!! DS1307 Clock must be set first 
 low  uARes      'reset chip to ensure uAlfat is set to i2c interface mode
 high uARes      'Does not set up properly without the Pause & toggle of Reset#
' hi2csetup i2cmaster,uATF,i2cSlow_16,i2cbyte 'hi2csetup only required once per POR
 gosub uA_Response    'Get initialisation header info 
 gosub RTC_Read
 GoSub uA_SetTime
'
Main: 
'
uALFAT:
 readoutputs b0     'see if Led turned On (output low as sinks from pwm)
 If uAStartLog = 1 Then   'Want to turn logging on / off
  If bit2 = 0 then   'On so turn off
   High 1     'record error Red   LED Off Supply from pwm - sink to port
   High 2     'recording    Green LED Off Supply from pwm - sink to port
  else      'Off so turn on
   High 1     'record error Red   LED Off Supply from pwm - sink to port
   Low  2     'recording    Green LED On Supply from pwm - sink to port
   pause 1000
   gosub uA_InitFilesys
  EndIf
 EndIf
 If bit2 = 0 then     'File Initialised, start logging
  gosub uA_StartLog
 Endif
'
Goto Main       'Loop for continuous display
End
'
' SUBROUTINES
'
uA_Response:
If uADataReady = 0 then    'Wait for DATARDY line to come high 
 goto uA_Response    ' - there is always data to read after every command
endif
i2cslave uATF,i2cslow_16,i2cbyte
uA_RespLoop:
Do While uADataReady = 1   'DATARDY pin on uALFAT-TF goes high if there is data to be read.
' hi2cin (b0)       'read byte
 readi2c (b0)
 If b0="!" then               'test for response - "!00" is OK anything else is a problem
'  hi2cin (b1)       'read byte
'  hi2cin (b2)       'read byte
  readi2c (b1)
  readi2c (b2)
  If b1 = "0" and b2 = "0" then
   goto uA_RespLoop
  Else
   goto uA_MediaError
  EndIf
 EndIf
Loop        'get everything there is to get
Return
'
'
uA_MediaError:
sertxd ("<Error> ",b0,b1,b2,cr,lf) 'display contents of error 
 Low  1       'Record error Red   LED ON  Supply from pwm - sink to port
 High 2       'Recording   Green LED Off  Supply from pwm - sink to port
 Pause 1000
 High 1       'Record error Red   LED Off  Supply from pwm - sink to port
' Port state read in uALFAT: so changing Record error output turns off logging
Goto Main
'
uA_StartLog:
'
RTC_Data:
 ptr = 99
 i2cslave RTC_0,i2cslow_16,i2cbyte
 for b25 = 2 to 0 step -1  'Get Time ~ HMS   Read from registers 2,1,0
'  hi2cin [RTC_0],b25,(b0)  '[RTC_0],  Ensure the correct i2c device is addressed
  readi2c (b1)
  bcdtoascii b0,b2,b3   'convert BCD to ASCII
  @ptrinc =b2     'FW A.2
  @ptrinc =b3
 next
 ptr = 99
' hi2cout [uATF],("W 0>13",$0D,@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,cr,lf)
 '37 bytes =      Hex 25   H  H   M  M   S  S   D1  D2  D3   D4  D5  D6  D7      D8      D9  D10  D11   D12   D13  D14  D15  D16   D17  D18  D19  D20
 i2cslave uATF,i2cslow_16,i2cbyte
 writei2c ("W 0>25",$0D,@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,@ptrinc,@ptrinc,",",@ptrinc,",",@ptrinc,@ptrinc,@ptrinc,".",@ptrinc,",",@ptrinc,@ptrinc,@ptrinc,@ptrinc,",",@ptrinc,@ptrinc,@ptrinc,@ptrinc,cr,lf)
 gosub uA_Response
 hi2cout ("F 0",$0D)    'Flush data to, and update file details
 gosub uA_Response
Return
uA_InitFilesys:
'8.3 File Name Support "YMMDD_99.csv" 'Currently GHI have licensing issues with Microsoft - LFN not supported.
 ptr = 97      '
 b20 = 167      'eeprom current YYMMDD
 i2cslave RTC_0,i2cslow_16,i2cbyte
 for b25 = 6 to 4 step -1  'YMD   Read from registers 6,5,4
'  hi2cin [RTC_0],b25,(b0)  '[RTC_0],  Ensure the correct i2c device is addressed
  readi2c b25,(b0)
  bcdtoascii b0,b2,b3   'convert BCD to ASCII
  @ptrinc =b2     'FW A.2
  @ptrinc =b3
  read b20, word w11
  if w1 <> w11 then
   write w11,w1   'Write changed data to eeprom - write only happens once per day!
   let w1 =0
  EndIf
  b20 = b20 +2    'inc eeprom pointer
 next
'
 Read 178,b1        'read FileName index 0 to 99 number from eeprom location 178
 b1 = b1 + 1      'increment by 1
 If b1 > 99 then
  let b1 = 1
 EndIf       'check to see if we have passed 99, if so, reset to 1
 Write 178,b1     'store new File Index number 01 thru 99
 bintoascii b1,b4,b5,b6
 ptr = 103      'store ascii data to scratchpad for datalogger
 @ptrinc =b5      '10s 'FW A.2
 @ptr    =b6      '1s
'
 i2cslave uATF,i2cslow_16,i2cbyte
' hi2cout [uATF],("C 0",$0D)  'Close File and File Handle left open by Flush
' hi2cout [uATF],("I",$0D)  'Initialise file System
 writei2c ("C 0",$0D)   'Close File and File Handle left open by Flush
 writei2c ("I",$0D)    'Initialise file System
 gosub uA_Response
 ptr = 98      'set memory location to beginning of clock data 1s of YY only
'     O Open 0 File Handle 0, A Append 
' hi2cout ("O 0A>",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,"_",@ptrinc,@ptrinc,".CSV",$0D)
 writei2c ("O 0A>",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,"_",@ptrinc,@ptrinc,".CSV",$0D)
 gosub uA_Response
 ptr = 97
' hi2cout ("W 0>11",$0D,"20",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,"_",@ptrinc,@ptrinc,".CSV",cr,lf)
 writei2c ("W 0>11",$0D,"20",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,"_",@ptrinc,@ptrinc,".CSV",cr,lf)
 gosub uA_Response
' hi2cout ("F 0",$0D)
 writei2c ("F 0",$0D)
 gosub uA_Response
Return
'
RTC_Read:
 ptr = 93
 i2cslave RTC_0,i2cslow_16,i2cbyte
 for b25 = 6 to 0 step -1  'YMD   Read from registers 6,5,4
  if b25=3 then    'DoW   Read from register  3 - NOT USED so skip
   let b25=2    'HMS   Read from registers 2,1,0
  endif
'  hi2cin [RTC_0],b25,(b0)  '[RTC_0],  Ensure the correct i2c device is addressed
  readi2c b25,(b0)  '[RTC_0],  Ensure the correct i2c device is addressed
  bcdtoascii b0,b1,b2   'convert BCD to ASCII
  @ptrinc =b1     'FW A.2
  @ptrinc =b2
 next
Return
'
uA_SetTime:       'Runs one time per power up
 ptr = 93      'set scatchpad pointer to beginning of clock data
  gosub uA_GetClk
 b0=w11+2000-1980    'YY - convert to number of years since 1980
  gosub uA_GetClk
 b1=w11       'MM
  gosub uA_GetClk
 b2=w11       'DD
  gosub uA_GetClk
 b3=w11       'HH
  gosub uA_GetClk
 b4=w11       'MM
  gosub uA_GetClk
 b5=w11 /2      'SS
'
' Pack 3 words Hex into 2 Words in uALFAT / DOS FAT file stamp date/time format
' Initial concept for this routine courtesy of ibenson
 w5 = b0 << 9      '* 512 ' shift year to bits 9-15
 w6 = b1 << 5      '* 32 ' shift month to bits 5-8
 w9 = w5 + w6 + b2     'YMD
 w6 = b3 << 11      '* 2048 ' shift hour to bits 11-15
 w4 = b4 << 5      '* 128 ' shift minutes to bits 5-10
' b5 = b5 / 2      'seconds divided by 2
 w10 = w6 + w4 + b5    'HMS
 
' sertxd (cr,lf,"<Packed hex> ",#w9," ",#w10,cr,lf)
'
'      'Initial concept for this routine courtesy of ibenson
' Create 8 nibbles from 2 words Hex & convert to ascii representation of Hex Data
' to send to uAlfat in required ascii format ( a DWORD of int32 in 'C' )
 b7 = b19 >> 4     'shift high nibble to low nibble
  gosub uA_ChkAlpha
 b10 = b7      'temporary store
'
 b7 = b19 & $0F
  gosub uA_ChkAlpha
 b11 = b7
'
 b7 = b18 >> 4
  gosub uA_ChkAlpha
 b12 = b7
'
 b7 = b18 & $0F
  gosub uA_ChkAlpha
 b13 = b7
'
 b7 = b21 >> 4
  gosub uA_ChkAlpha
 b14 = b7
'
 b7 = b21 & $0F
  gosub uA_ChkAlpha
 b15 = b7
'
 b7 = b20 >> 4
  gosub uA_ChkAlpha
 b16 = b7
'
 b7 = b20 & $0F
  gosub uA_ChkAlpha
 b17 = b7
'set time in uAlfat
' hi2cout [uATF],("T S",$0D)  'set uALFAT clock to run from main power
 i2cslave uATF,i2cslow_16,i2cbyte
 writei2c ("T S",$0D)   'set uALFAT clock to run from main power
 gosub uA_Response    '(PC file system displays as per region setting) 
' hi2cout
 writei2c ("S ",b10,b11,b12,b13,b14,b15,b16,b17,$0D) 'set time in clock
 gosub uA_Response    '(PC file system displays as per region setting) 
Return
'
uA_GetClk:       'courtesy of ibenson
 b20=@ptrinc      'Get ascii clock data from scatchpad
 b21=@ptrinc      'Get ascii clock data from scatchpad
 w11 = b20 * 10 + b21 - $210  'courtesy of Hippy,Convert 2 Bytes Ascii to 1 Word Dec, 
         'shift high byte, add low byte, change ascii to hex
Return
'
uA_ChkAlpha:
 if b7 > 9 then     'test to see if hex over numerical value
  b7=b7+7 + "0"    'if so, convert to alpha value & convert to ascii
 else
  b7=b7 + "0"     'else leave as numerical & convert to ascii
 endif
Return
 
Last edited:

yamato96

New Member
thank's for the great suport!!!
gonna order u-alfat right now! Got to check the best board 4 my needs/skills.
 

BCJKiwi

Senior Member
The -TF is the smallest and cheapest. Purchased 2 as it reduced the freight per unit to NZ. Purchased direct from GHI in the US as it was the lowest overall cost for me in NZ.

Don't know what part of the world you are in but there is a distributor in the UK.
 

yamato96

New Member
Im in portugal (EU).
maybe direct order from GHI in US is the best choise evaluating the exchange rate USD/EURO.
But would apreciate link to UK distributor to compare PricesperUnit/shipping costs
 
Last edited:

BCJKiwi

Senior Member
Peter, do you have specific questions?

There have been minor changes to my program that uses this technology. It is basically complete and has not had further development at this time but may well do in the future. however apart from 8.3 / LFN file names (see below), the posted code is not likely to change as it seems to work well.

This thread was set up as an example of how one could do data logging to the GHI product and how to manage the device.

It was not intended to be a complete stand alone project.

There have been further updates from GHI to firmware with some changes to function.

Biggest issues were around the long file naming (8.3 naming not affected) which apparently is proprietary to Microsoft and requires licensing. Initially Microsoft demanded a license from every end user and the LFN functionality was removed.

It is now included in the new devices and can be retrospectively licensed (without cost) on the earlier devices so LFN is again available.

To me, the two main advantages of this product are;
1. it works without hassles (unlike VDrive2 in my experience which does not support i2c and I could never get hSPI working and only the most basic bit banged SPI which was far too slow anyway - serial was not an option for this project)
2. It fully supports writing and reading files in DOS (and Windows) style file formats so the media can be plugged straight into any PC type computer and used directly without additional interpretation.
 

centrex

Senior Member
Hi BCJKiwi
Did you obtain the 3.3volt supply for the ualFAT from the same supply as the Picaxe, if so what did you use.
Many thanks
Centrex
 

BCJKiwi

Senior Member
Currently using a Max884 (free samples) to derive the 3.3V from the main 5V supply for the PICAXE etc.

Could also use the 3.3V available from the DE-ACCM3D accelerometer (included in the circuit) which has an on board 3.3V regulator, or, any other source.
 

MFB

Senior Member
SPI problems?

Many thanks BCJKiwi for a very useful contribution. It seems that the uALFAT with I2C is a better PICAXE match than the uDrive with UART that I have been evaluating.

For my low power/medium speed logging application I eventually gave up on the uDrive and now use 1Mbyte of EEPROM (with I2C bank select switching). In the future I plan to replace the eight EEPROM chips with a single 8-pin Atmel 4Mbytes DataFlash device, but have some concerns about the many negative comments on this forum regarding the 28-X1 implementation of SPI. Please could you elaborate on your experiences with trying to use SPI on the PICAXE?
 

BCJKiwi

Senior Member
Have not attempted to use SPI with the uAlfat as there are other i2c devices in the circuit and a) could not see the point of trying to mix spi andi2c on the same chip (possible but tricky) and b) was short on pins anyway.

Had previously tried to use SPI on a VDrive2 and completely failed. Don't how much of that was down to the PicAXE and how much was down to the VDrive2. Others seem to have good experience with SPI and it has higher speed potential than i2c.

Sorry but can't give you much more assitance than that but I do keep meaning to have another go at SPI - just don't have an application that has pushed me hard enough yet!
 

MFB

Senior Member
Know what you mean about needing an application to give that push. I have been delaying getting to grips with SPI and DataFlash. However, I have accumulated a nice pile of Atmel documentation and will have to make a start soon.
 

Gwillo

New Member
What else do i need in order for this to run.

Hi, iv been trying to set this up to work on a 40x1 which i believe should work on the same code. ( I have obviously used the appropriate pins based on your tags in the 2nd post as to what each pin on the uALFAT connects to)

Iv connected up all the pins on the uALFAT as stated in your 2nd post, and iv also connected all the pins required to run the PICAXE, (power download socket etc) I have also put in 4k7 pull up resistors on the i2c data and clock pins. I have also connected a DS1307+.

In order to get the device to start logging what else do i need installed, im not great with picaxe code but would i be correct in thinking that input 1 is the switch to start the logging, does this need to be tied low using a pull down when not tied high?

Also it looks like the values the program logs are H H M M S S D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 D17 D18 D19 D20,

what are the D values, and how do they relate to the input pins.

Sorry for probably sounding like a bit of newbie, i wouldnt usually ask, but iv already somehow fired one chip already (some how +v and -v fused together internally shorting my whole circuit and giving me a lovely burn off my voltage regulator ;). I have a 28x1 that im going to try working with until i can get a new 40x1 so any suggestions or help you could offer would be much apreiciated.

Just so you know i want to eventually use a 40x1 because i need more inputs and i know this means that ill need to change the code slightly.
 

BCJKiwi

Senior Member
Hi,
The 'D' values in the remmed out comment lines of Post #8 are just whatever additional data items you wish to log. These are derived from ram via @printC so the data must have been written to ram before this stage. Note that the number of data items has to be specified so if it changes, then the hex number in the uAlfat command needs to be changed to suit. (compare Post #2 with Post #8)

The program these snippets come from has a number of inputs (time, compass, accelerometer etc) and as the code reads each of thes devices, the output is stored in specific ram locations so it can all be read out in sequence via @printC and written to uAlfat.

So all this happens over i2c and no other pins are involved.
 
Last edited:

Gwillo

New Member
so all your inputs are via i2c?

If this is the case ist it also possible to get it to store adc values from pins by inserting them into the write part of the code along with the D values, or would this not work?

EDIT think i misunderstood your last post, are the "additional inputs" simply the d values that come up when in debug mode ( which i think are connected to certain pins)
 
Last edited:

BCJKiwi

Senior Member
There seems to be some confusion.

Post #8 shows at the beginning of the code, the scratchpad (ram) locations used to store the various data. D1 thru D20 are not detailed as they did not come from the clock but from other devices some of which are i2c but not all. So the pins and method of collection be it i2c or readadc or whatever is as required for each specific device.

The reference in my last post to i2c was that all these data items are written out via i2c to the uAlfat.

So as mentioned in the last post, the program flow is to read the data from each of the devices/inputs of interest in turn and store them in specific ram (scratchpad) locations as you go and once all have been assemled, then write them out to uAlfat in sequence from the scratchpad.

Hope this makes it a bit clearer.
 

Gwillo

New Member
I cant get it working

Hi, could you possibly post a circuit diagram for the 28x1 circuit with ualfat, im struggling to get the system working and i feel im probably missing something in my circuit.

Many Thanks

EDIT : or some photos of the device working or pin outs if that is easier

EDIT2 : I have used the picaxe debug function to see what the picaxe is doing, and it counts upto 8 on debug. (In the brackets in the bar at the top of the debug window), so it looks as though its waiting for something before it does anything? Any ideas?
 
Last edited:

BCJKiwi

Senior Member
This from Post #2 is the circuit diagram as far as the connections used betwen the uAlfat and the PICAXE 28X1 - uAlfat pin numbers on the left, PICAXE 28x1 pins/legs on the right.

There are only 4 connections between uAlFat and 28X1;
2 for i2c
1 to detect when data is available
1 to reset uAlfat

Code:
uAlfat                                                                PICAXE 28X1
' 1  UART_TX/DATARDY O              -                  Input0 (errors & responses)C0 Leg 11
' 2  UART_RX/BUSY  O                -   NC  (Device Busy)
' 3  i2c_SCL   I                         -                  i2c_SCL      C3 Leg 14
' 4  i2C_SDA          I/O              -                  i2c_SDA      C4 Leg 15
' 5  SPI_SCK   I                       -   NC @ uAlfat Tie low ( 0V ) via 10K Interface mode select
' 6  MISO/RTS    O                   -   NC
' 7  MOSI/CTS    I                     -   NC  
' 8  SPI_SSEL#    I                   -   NC @ uAlfat Tie High (3.3V) via 10k Interface mode select
' 9  RESET#    I                        -                         Output1 (uAlfat Reset)  B1 Leg 22
' 10 Black   GND  I                     -   0V                    Common Ground
' 11 Red     V+   I                      -   V+       3.3V
' 12 BL#    I                             -   NC
' 13 VBATT      I                        -   3V or tie to V+ if not using Battery
 
Last edited:

Gwillo

New Member
Thanks

Yeah thats what id done, i think my ds1307 may have blown, my 5 and 0v shorted internally on my 40x1 for some reason, and this may have messed up the timer, i just hope it hasnt blown my ualfat as it was connected to the same common and a 3v supply (from a voltage regulator) off of the same 12v supply that the picaxe was taken from (with a 5v regulator).

I'v got a replacement ds1307 comming, ill get back to you, looking through the code using the debug and looking for where it stops it seems to be at a line concerning the RTC so this seems to add up.(Or at least iv made it add up lol;))

Many Thanks for your help.
 

Gwillo

New Member
still cant get it working

Hi again, iv changed my ds1307 and i've still got the same problem, im now worried that i may have blown my uAlfat when i had the short out as the 3v regulator and 5v regulator i was using were sharing a common 12v supply and ground, so 5v would have been running through the ground rail. This would have put a potential difference of -2v effectily through the Ualfat.

I want to test if the uAlfat is working correctly, is there anyway of testing all its functions?

I have tried stripping down the code to find whats wrong with my circuit but the code is obviously on the complex side, i would like to just command the uAlfat to simply initialise the filesystem and write a file with no recorded data in it ie write a file called test and which only contains the word sample recorded in it, this would allow me to ensure the uAlfat is writing the file, but im struggling to separate whats needed to do this in the code from what isnt. I want to rule out the uAlfat as the source of the problem as it is obviously the thing thats hardest to test physically. So i want to write a file without any clock data involved, just a simple communication between the picaxe and the uAlfat module without any other comunication needed.

Would you possibly have something perhaps from when you were writing the code which would do this.

Sorry for being a pain, i understand the most part of the code however im stuggling especially with the code regarding the file writing.
 

BCJKiwi

Senior Member
The best way to check if it is working is to read up on the serial connection and firmware updating procedure.

Once you have it connected for serial to the PC, the initial part of the procedure described for firmware updating will return the existing version details for the downloader and for the installed firmware.

If you can get those displayed it would suggest the device is OK.
 

Gwillo

New Member
Serial Connection

Hi, how do i physically connect the uAlfat to the computer to use the 'C' code, would a pixaxe download cable suffice or are different resistor values required.
 

BCJKiwi

Senior Member
'C' code??

I used a MAX232 setup on the serial connection and used the following procedure to update the firmware but you only need to see the BL at step 9 to be sure the device is working and step 11 to get back the version info.

There have been updates to the uAlfat since the work I did so the procedure may be slightly different - check the manuals and documentation!!
Code:
1.  Place uALFAT firmware (uALFATFW.GHI) on the SD card
2.  Put SD Card into uALFAT
3.  Make sure VBAT is connected to VCC (3.3V)
4.  Make sure CTS is connected to ground, or, RTS // CTS connected to CTS // RTS on Level shifter if implemented
5.  UART_TX is output from uALFAT and should go to your MAX232 circuit Rx
6.  UART_RX is input  to   uALFAT and should go to your MAX232 circuit Tx
6.  Set the mode pins (SSEL and SCK) to force loader mode - see pinout below
7.  Run Hyperterminal at 9600
8.  Power up your circuit
9.  You should see "BL" on the terminal. If you do not see BL then the chip is not functional
10. Do not use firmwareloader.exe unless it is absolutely necessary.
11. Press "V" - use upper case letters and do not press enter - and you should see the loader version number (what is it?)
    To Upload the firmware from the SD card;
12. Press "LOK" - use upper case letters and do not press enter - and you should see sector numbers indicating writes.
    At the end you will see;    "!00"
                                "BL"
 
Max232 Level shifter cable connections
Pin #   Max232              uALFAT
        Pin #               Pin #
+5V     16          +3.3V   11, 13
0V      15          0V      10
Tx      12          Rx      2
Rx      11          Tx      1
CTS     10          RTS     6
RTS      9          CTS     7
                    High    5
                    Low     8
                    All other Pins disonnected
 

Gwillo

New Member
I think that my ds1307 is still not right, iv used the picaxe datalogger wizard menue in order to check that the clock is working and it isn't. in a 5v circuit the i2c sda & scl are tied high with 4k7 resistors, how did you tie yours with the uAlfat working on 3.3v?

As for updating the firmware on the uAlfat i dont have a max232 at the moment so im checking everything else in the meantime.
 

BCJKiwi

Senior Member
The 'uAlfat User Manual' documentation downloaded from GHI for (ver3.10) indicates in the section '1.3 Key Features' (page 4) that;
All I/O Pins are 5 volt tolerant
so i2c is just connected to the same i2c bus as all the other stuff running at 5V including the 28X1
 

Gwillo

New Member
Thanks, sorry i didnt see that.

Iv installed a new ds1307 and things are looking a little more promising, i still cant get it to create a file yet though, will it create the file even if there is no inputs for logging attached or not? Im using the second code from post 8, iv installed the two leds, the green led is flashing and the red one is constantly on. If i hold down uAStartLog (input1) then the green stops flashing and is just iluminated.

also the ualfat reset pin is active low, is this tied low simply through the picaxe or does it (as i thought) require a pull down resistor, sorry if this sounds a stupid question but my 3.3 voltage regulator got a little hot when i put in the resistor.

Many thanks, and sorry for your troubles.

EDIT: the flashing has now stopped, turned out i had a bad connection in the breadboard im using on the i2c scl pin, both led's are now fully on
 
Last edited:

Gwillo

New Member
Buying a new uAlfat

hi, i believe that my ualfat is fried as when i use a voltmeter accross the datardy pin to 3v i get a reading of around 0v, and again get a reading of 0v when i read from datardy to 0v. No need to be a genius to realise that this is a little odd and not what it was previously giving.

Before i go stuffing another one iv attached a link to a diagram iv made of what i think the circuit should be, could you say if this is different to your circuit or if there is anything obvoiusly wrong or missing.

http://i647.photobucket.com/albums/uu196/garethgwilliam/circuitdiagram.jpg.

Anyone viewing this post looking to produce this circuit from the link please dont copy my diagram as its quite probably wrong.

many thanks
 

hippy

Technical Support
Staff member
A few things on that circuit ...

You have your two regulators backwards, VI should be 12V, VO should be 5V, 3V3.

It would probably be best to power the 3V3 Reg from 5V rather than 12V.

You have no resistors in the lines driving the LED's. Add 330R minimum.

There are no decoupling capacitors.
 

Dippy

Moderator
Oh Dear. I think it would have been a good idea to have posted your circuit prior to connecting ANYTHING to it.
Hippy has highlighted the faults - quite a few. Phew!

I take it your electronics experience/skill is at the super-featherweight level?

ALWAYS read device Data Sheets before doing anything.
If you don't understand then someone here can probably help you.
Data Sheets will tell you about how to connect things and if you need capacitors.
The "IN" of a regulator is where you stick your power IN, and "OUT" is where the regulated oomph comes out :)

As you have no capacitors on your regulators I can only assume they are special ones , or, you haven't read the Data Sheet or looked in Manual 1 "Regulated Power Supply" which gives good hints on how to connect a regulator.

AND if you are a total novice then it is ALWAYS worth breadboarding the basics so you can check things like regulators BEFORE connecting expensive devices.
Anyone can make a mistake. And I'm sure everyone has made a mistake or two. But if you can discover a cockup before connecting ££s worth of stuff then it's good.
 

BeanieBots

Moderator
Agree with Hippy's comments. Quite likely to fry the PICAXE with that circuit never mind the ualfat.
Double check what your voltages (with PICAXE and ualfat removed) ACTUALY are and fit some LED resistors before you power up again.

Read the datasheets for the regulators you have used and fit the recommended decoupling caps. Also fit 100nF close to PICAXE power pins and about 10uF close to the ualfat power pins.
 

BCJKiwi

Senior Member
Also, some of the connections to the UAlfat are not as described in my original demonstration circuit notes.

R5 and R6 not required.
Should be no connection to pin12
 

Gwillo

New Member
Feeling a little stupid

HI, I previously had capacitors on the supplies after the regulators however i did take them out as they were for some reason stopping the picaxe from loading up, i found that when i removed them it worked, dont really know why, now i think about it it could be that to fully reset the picaxe i needed to disconect the supply and drain the capacitor.

The pin outs you highlighted on the voltage regulators are slightly different in vsm to what the data sheet says for the component that ive got so thats why the pins arent right, dont know why. It might be that iv labeled them up wrong in that picture, but yeah i do know which outputs on the voltage regulators should go where as iv check the data sheets, they may not be right on the picture but they are definantly right on the breadboard as i checked many times.

Also sorry about the resistors for the led's forgot to put them on the drawing, they are on the breadboard.

Just so as people know im using the second version of the code from post 8.

BCJKiwi, other than the removal of R5 and R6, are there any other connections which dont appear to be connected right, is the pull-up resisstor on pin 8 of the uAlfat connected to 5v or 3.3v, i assumed it was to 5v as all I/O pins are 5v tollerant?

Sorry for showing myself up a bit ;)
 
Top