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!
Printable View
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.Quote:
Originally Posted by eoasap
Ron
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.Quote:
Originally Posted by eoasap
Ron
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
#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
#1.Are you using the chip, or the SD board?
The chip
#2. Have you had experience with the hardware USART?
no experience
#3. Do you know what version of Alfat firmware is on the chip?
no, but i think its 3.06
#4. What are you using for a display? LCD/Debug/ICSD?
LCD
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
ok, i'll work on trying to learn the serin2/serout2. so i'll need to setup the code @9600 baud. is serin/serout hard to implement?
My first suggestion is to buy the Alfat SD board with SD socket. It will be easier to work out the necessary code and limit the possible problems. Soldering that chip will be a major pain in the neck. I have ruined more than one until I discovered solder paste and toaster ovens.
Either way, if you limit your possible sources of trouble, you will be able to concentrate on the interface. The absolute best purchase would be the Alfat development board. I was too cheap to buy one, and paid for it in the form of an extended learning curve.
Rpn
i already soldered it onto the board. i used to have to solder parts like these on all the time, so thats not a problem. when i got the chip, there was no documentation with it, is there extra documentation with the dev board ?
Have you been on the user's forum website? Also, the Proton Basic is not too different from PBP. You can learn alot about timing and protocol.
yes, have been on the user website for a while, but i didn't see anyone else there that used PBP. did you manually go through the proton code and change it to picbasic ? i'm sure i'd screw that up! :)
i really am just interested in doing some simple stuff with it for now.
If you have the manual, turn it to "getting started with text mode". Basically you apply power with the UART/SPI pin high.
Pause 500
low ALFAT_CTS
pauseus 20
input ALFAT_RTS
pauseus 20
low ALFAT_RESET
pause 200
input ALFAT_RESET
pause 500
main1:
serout2 ALFAT_RX,84,["RS OK",13] ; Send reset string
read:
serin2 ALFAT_TX,84,bufchar]
lcdout bufchar
if DATARDY = 1 then main2
This little code snippet resets the Alfat and reads back the startup message and version number. After that, you can send out the commands you need in a similar style to the main1: line. Wait for the responses, and use wait in your serin2 string to parse out the info you need.
Alfat is very finicky about correct syntax, so be very careful.
I would immedietly disable the echo, then change over to drive A (SD card)
Ron
serin2 ALFAT_TX,84,bufchar]
there should be a '[' before bufchar, right?
do i need to declare bufchar as a byte ?
Is there a loop for the serin2 alfat_tx,84, [bufchar] ?
How do i use datardy?
I was getting errors using 'read:' also, so changed it to read1:
Sorry, I was doing it from memory. "READ" is a reserved word. My bad. DATARDY is a pin on Alfat. If it is high, then Alfat has data to send. It takes about ten microseconds to change states if it is empty, or transitions high. It is a flag and should be aliased as a bit variable, just as ALFAT_BUSY should.Quote:
Originally Posted by eoasap
Ron
is the rest of it right? because i still can't quite get it.
It works for me. Any output from Alfat at all?
what i'm doing is declaring bufchar as a byte, and then loop at the end of
read:
serin2 ALFAT_TX,84,[bufchar]
lcdout bufchar
goto read
like that, i get a bunch of gibberish. yesterday i was getting numbers like 292 (clears screen) 302 (clears screen) 306 (clears screen) .... etc
When I get to my lab, I will send you a snippet of code. bufchar is a byte variable. It can't go over 255, so there must be a couple of variables in there.Quote:
Originally Posted by eoasap
Thanks Ron, i'm sure there's just something minor i'm leaving out (hopefully!) you've already been such a big help! thanks :)
Did you ever get this sorted? I'm about to embark on a very similar exercise with a 16F877 and alfatSD board using PBP. Any snippets of code or other advice would be greatly appreciated. TIA
Sorry, I've been out of the country till last night. If at all possible, work with the SD or development board for these units to start with.I am a huge proponent of development kits, they are more money, but cheap in time.Quote:
Originally Posted by PaulBarter
Alfat is extremely finicky in regards to syntax and timing, and I have spent many hours over "spelling errors" and formatting issues.
Next, if possible, use text mode with the UART. This is the easiest, and most forgiving.Also, the learning curve is more gentle. I was one of the unlucky few that had to use SPI in framed mode. Now, there are plenty of programming examples in "C", and also Proton basic. The latter was invaluable, but required some translation.
SPI gives you the ability to free up your hardware UART and run at some impressive speeds, especially with a MSSP module as on the 18 series chips. You have to account for every single bit going into and out of the Alfat, but it works reliably. I went with framed mode, because it was easier to parse data and error responses(i've had more than my share!). The Alfat user's forum is quite helpful too.
Thanks for that,
I have ordered the ALFATSD board but it'll be a couple of weeks to get to New Zealand. I am planning on using UART in text mode since my application is a simple serial logger.
I've also looked at the proton basic stuff and it looks helpful but I won't know how helpful until I dive into the actual project.
I was hoping you or eoasap had a bare bones PBP program to get me started since I'm not using the proton development board.
Perhaps when I get my chip I'll cobble one together and may re-post if I hit a brick wall. I'm still a bit of a newbie but have had pretty good sucess with serial comms on these chips already. the only unkown is writing this serial data to a text file. Thanks again for the timely reply.
As far as getting text from Alfat, if you know the length of the text string, you can assign a variable array to Alfat's response. Call it Alfat_response.
Let's say you block out 60 bytes to the array. When you use serin2, you can declare,in statement, (Alfat_response\4) the \4 means serin2 will get four consecutive bytes from the input pin. I don't have the book, so syntax is up to you. The display sequence would be to create a loop and LCDout the characters using the loop counter to increment the array
For loop = 0 to 3 ; One less since we start from zero
LCDOUT (Alfat_response[loop])
Next loop
Now, if you don't know how many characters are coming out of Alfat, do the loop, and time it out after 10 milliseconds. Keep in mind that some characters will not print to the LCD. You may have to use 'DEC' or 'HEX' to make any sense of them.
That's all for now,
Ron
Hello again:
I got my Alfat SD board and have made an attempt at getting it to go but with limited success.
Attached is a PBP program that should reset the ALFATSD and then list the files/folders on the card using text mode.
When I run it, all I get as replies from the ALfat are null characters (Dec 0). It doesn't go to the error routine (except once), so I'm pretty sure the connections are good. Note that I'm using B5-7 rather than B0-2.
I'm still a bit of a newbie when it comes to this stuff so any suggestions on how to get this to go would be gratefully accepted. Also, feel free to tell me how crap I am at programming, I've got a pretty thick skin.
I thought the file list would be the simplest way to ensure I was communicating properly but if there's a simpler way to show on the LCD that things are working then let me know.
TIA
-Paul
Hey Paul. You should look at the Proton+ routines on the GHI website. They gave me some excellent insight into timing that the GHI docs were sadly lacking in. After powering up the board, do a hard reset by bringing the reset pin to gnd, then let it float by making the associated pin an input. Do not use weak pullups on portB at this point. The reset routine for proton is what I followed. Next, if all is well, you should see a "BL". This will tell you the bootloader is ready to either load the Alfat firmware, or update it. At this point send "R" or "RS" ? Check the Alfat docs on this. You should get the Alfat startup message complete with version number. If you get this far, you're 3/4 of the way there....
Ron
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
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
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
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"Quote:
Originally Posted by PaulBarter
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!
did you guys get it working ?
Would this code work for reading and writing to an SD card that is not alfat?
No, since the Alfat is the device that's handling all the FAT manipulation on the SD card. The code is merely a DOS like language used to send instructions to the alfat.
-pb