Alfat Sd/mmc

[eoasap]

has anyone here had any experience using this chip? i would like to do standard USART communications with it, and would like to hear what anyone says about it. thanks!

[Ron Marcus]

has anyone here had any experience using this chip? i would like to do standard USART communications with it, and would like to hear what anyone says about it. thanks!

I am using the Alfat SD board. It works fine in text mode, and SPI mode. Framed mode is a bit tricky, but easier to work with for parsing the data. What is your app? I have logged about thirty hours working with the board and have encountered every stupid thing my feeble code writing brain could come up with.

Ron

[eoasap]

Ron,

i will be reading in GPS sentances (USART), either parsing or selecting sentances, and outputting this directly to the SD card (also USART) in text mode as i think that would be the easiest way. did you code yours with picbasic? on alfats site they only have proton basic and assembly code and ovbiously want to use picbasic.

Glenn

[Ron Marcus]

Ron,

i will be reading in GPS sentances (USART), either parsing or selecting sentances, and outputting this directly to the SD card (also USART) in text mode as i think that would be the easiest way. did you code yours with picbasic? on alfats site they only have proton basic and assembly code and ovbiously want to use picbasic.

Glenn

I wrote everything in PBP. Text mode is the easiest and speed should no be an issue. I would suggest a PIC with a large amount of memory, such as the 18F2620, or an external EEPROM as intermediate storage. THe Alfat is a gas hog, so if you are using batteries, you are not draining 80 mils on a constant basis. I write 3K of data to the PIC then dump it into the Alfat in short bursts.

Ron

[eoasap]

Ron, i'm using the 18LF8722 so memory shouldn't be much of a problem. do you think you could help me get started? as i'm a little overwhelmed by it all. I know i need to try simple stuff first, like creating a file, writing a bytes to it, and then verifying it on the computer, but i really am not sure how to get started with it.

Glenn

[Ron Marcus]

#1.Are you using the chip, or the SD board?
#2. Have you had experience with the hardware USART?
#3. Do you know what version of Alfat firmware is on the chip?
#4. What are you using for a display? LCD/Debug/ICSD?
For test purposes, I would suggest plain old Serin2/ serout2.The USART just adds one level of mystery. The device comes up at 9600 baud. No need for a 232 converter, if you are using a PIC, only with a PC in hyper term.
I've got some routines, just let me know the above answers. Also, check the user's forum at GHIELECTRONICS.com

[jimmyp]

All,

I'm new to this board, and am wanting to know if anyone has used PBP with an SD/MMC card to read/write data to from the SD/MMC card using FAT16 so that it is readable/writable between the PIC and a PC.

Please advise.

Thanks and Regards,

Jim

[PaulBarter]

Success of sorts.

I've been able to get the alfatSD to powerup and communicate in text mode but it was very intermittant.

During the powerup process I only occasionally got the reply from the board.

Following is the powerup part of the PBP program.

Powerup:
Pause 500
low ALFAT_CTS_PIN
pauseus 20
Input ALFAT_RTS_PIN
pauseus 20
low ALFAT_RESET_PIN
Pause 200
input ALFAT_RESET_PIN
pause 500

'Send reset string
gosub clear_LCD
lcdout "Sent- RS OK"
serout2 ALFAT_RX,ALFAT_BAUD,["RS OK",13]
serin2 ALFAT_TX,ALFAT_BAUD,2000,ALFAT_ERROR,[skip 2,str ALFAT_STRING\15] 'BRING IN UPTO 15 BYTES

'Output rcv characters to LCD
gosub Clear_LCD
lcdout "Sent- RS OK"
Lcdout $fe, $c0 ' move to second line
lcdout "Rcvd- ", str ALFAT_STRING\15

I have been able to get this to work every time, but it's a bit Rube Goldberg.
By putting a 1k resistor between the CTS and RTS on the AlfatSD the intermittant nature goes away and I get perfect powerup and comms.

I have no idea why, however, and was wondering if someone could help.
I've tried adding a 'LOW ALFAT_RTS_PIN' at the beginning of the powerup, but obviously this is overwritten when the pin is set as an input.

Once I get it sorted, I'll post the PBP program and some notes for the others out there that are obviously going through similar steep learning curves.

TIA

[Tom Estes]

Hi PaulBarter,

I've just completed a data logging project with the USB Wiz, a device that has both Alfat and USB on it. It appears from your description that the communications is about the same for both the USB Wiz and stand alone Alfat. Here are some things I discovered:

Your are correct in holding CTS low, it must be low or the alfat will not send data (I just tied mine to ground)

You can ignore RTS and leave it disconnected or as an input as you desire. If you intend to talk to Alfat at very high speeds with lots of data you may have to use both CTS and RTS to supervise data transfers. I run my interface at 9600 and neither are needed.

Alfat Reset should be HIGH at all times except when you are doing a reset. You make it an input so that means it floats and *may* be causing part of your communications problems. If you are going to reset the alfat with different devices and need to float your PIC input then a pull up resistor will be needed on the Reset line. Otherwise just place a HIGH alfat_Reset statement early on in your program. I do a reset on mine by Pulsout Alfat_Reset 1 after having pulled it high with a High Reset_alfat statement.

However, I suspect your major communication problem is this: Alfat_RX needs to be held HIGH. You can do this with a pull up resistor or as I did by putting a High Alfat_RX statement in my program BEFORE doing an Alfat reset. This line is very sensitive to noise and *will* cause error after error if not strongly held either by the PIC driving it high or a pullup resistor.

On the USB Wiz there is an additional signal to contend with. It is one called Mode 0. It must be grounded to hold the USB Wiz in RS232 mode. I don't know if Alfat has the same issue.

I'm not associated with the Alfat people and probably can't suggest much more than this but thought I could give you the benefit of my findings.

TomE

[eoasap]

Powerup:
Pause 500
low ALFAT_CTS_PIN
pauseus 20
Input ALFAT_RTS_PIN
pauseus 20
low ALFAT_RESET_PIN
Pause 200
input ALFAT_RESET_PIN
pause 500

'Send reset string
gosub clear_LCD
lcdout "Sent- RS OK"
serout2 ALFAT_RX,ALFAT_BAUD,["RS OK",13]
serin2 ALFAT_TX,ALFAT_BAUD,2000,ALFAT_ERROR,[skip 2,str ALFAT_STRING\15] 'BRING IN UPTO 15 BYTES

TIA

My project is fully functioning now also (I use the Alfat chip and not the usb wiz, but should be similar). don't send the "RS OK" function first. you need to send "R" to run the firmware. Without running the firmware, you can't do anything and you're still in the bootloader. your code is right up until sending "RS OK". You only need to reset by dropping the reset pin low, not by sending out "RS OK". I can't imagine a scenario where you'd need to send "RS OK"

this is what i have:

LOW ALFAT_CTS : PAUSEUS 20 'MAKE CTS INPUT
INPUT ALFAT_RTS : PAUSEUS 20 'MAKE RTS PIN OUTPUT LOW
LOW ALFAT_RS : PAUSE 300 'PULL THE RESET PIN LOW
INPUT ALFAT_RS 'BRING THE ALFAT OUT OF RESET
INPUT ALFAT_TX 'RECEIVE ALFAT DATA

SERIN2 ALFAT_TX , ABAUD , [str ALFATIN\2] 'should be "BL"

LCDOUT CMD, LINE1, "ALFAT BOOT"
LCDOUT CMD, LINE2, str ALFATIN\2
' pause 1000

BL_Version_Read:
LCDOUT CMD, CLR
LCDOUT CMD, LINE1, "Bootloader Vers."
SEROUT2 ALFAT_RX, ABAUD , ["V"] 'receive 3.0
SERIN2 ALFAT_TX , ABAUD , [str ALFATIN\3] 'wait for CR
LCDOUT CMD, LINE2, str ALFATIN\3
' pause 1000


Firmware_Run:
LCDOUT CMD, CLR
SEROUT2 ALFAT_RX, ABAUD , ["R"]
SERIN2 ALFAT_TX , ABAUD , [wait("A"), str ALFATIN\16]

lcdout cmd, line1, "Firmware Active"
lcdout cmd, line2, "A"
lcdout cmd, lcdb2, str ALFATIN\16
'will receive "Alfat Version 3.12 Z:" (or similar)
'if you get "BL" in return, you need to update firmware
pause 1000

Disable_Echo:
LCDOUT CMD, CLR
SEROUT2 ALFAT_RX, ABAUD, ["EE 0", 13]
SERIN2 ALFAT_TX, ABAUD, [str ALFATIN\2]
lcdout cmd, line1, "ALFAT"
lcdout cmd, line2, "INITIATED"
' pause 2000
alfat_exit:
RETURN



'then after what i call 'initializing the alfat' , you need to change to drive A 'like this to access the SD card

ALFAT_DRIVEA:
LCDOUT CMD, CLR
LCDOUT CMD, LCDA4, "CHANGING"
LCDOUT CMD, LCDB4, "TO DRIVE A"
' PAUSE 500

SEROUT2 ALFAT_RX, ABAUD,["A:", 13]
SERIN2 ALFAT_TX, ABAUD ,[wait(13),str ALFATIN\3]
LCDOUT CMD, CLR
LCDOUT CMD, LINE1, "Command Prompt"
LCDOUT CMD, LINE2, STR ALFATIN\3
' pause 500
RETURN


' after this, you can create files and write to them like this
'A = append existing file
'R = open to read only
'W = Create new file to write to
SEROUT2 ALFAT_RX, ABAUD, ["OF W#1 GPRMC.TXT", 13]
'open NEW file, called GPRMC.TXT
LCDOUT CMD, CLR
LCDOUT CMD, LINE1, "Open GPRMC.TXT"
LCDOUT CMD, LINE2, "Success"
pause 1000


'tell alfat how many bytes (in hex) to write
SEROUT2 ALFAT_RX, ABAUD, ["WF #1 6", 13]
'send out the actual bytes to be writting
SEROUT2 ALFAT_RX, ABAUD, ["$GPRMC" , 13] 'write the bytes


'same thing but with a variable
'Store Current GPS Data
SEROUT2 ALFAT_RX, ABAUD, ["WF #1 36", 13] '
SEROUT2 ALFAT_RX, ABAUD, [str GPRMC_IN\54, 13]


I can write at least several hundred kb doing this without any problems (haven't tried logging longer yet) so it works fine
let me know if you get stuck!

[eoasap]

did you guys get it working ?

[Christopher4187]

Would this code work for reading and writing to an SD card that is not alfat?