Have run into a curious problem with a strange work-around.
This line of code works and creates a filename in uAlfat storage;
hi2cout ("O 0A>",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,".CSV",$0D)
(YYMMDDHH.csv)
The uAlfat states that all the data in any commands must be ascii (with the CR/LF sent as $OD) but already found that in some cases this is the Hex value sent as ascii - i.e. hex BF60 had to be sent as Ascii BF60 !!
The data in the scratchpad (@printc) is from a DS1307 Clock and converted to ascii using BCDTOASCII and stored to the scratchpad thus;
hi2cin [RTC_0],6,(b0) ' Year Read from register 6
bcdtoascii b0,b1,b2
@ptr=b1
inc ptr
@ptr=b2
inc ptr
However I wanted to change the last two bytes of the filename from the HH to a sequential number 01 thru 99.
Wrote the code for that and stored it to b4 and b5 (tens and ones) and used the following line;
hi2cout ("O 0A>",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,b4,b5,".CSV",$0D)
There were no complaints from the uAlfat but no characters in the file name for b4 and b5.
I tried every form of hex,decimal etc conversion including bintoascii but nothing worked including storing actual ascii in b4 and b5 ( i.e. b4 = "1" without success.
So on a long shot I tried;
bintoascii b4,b2,b1,b0
bintoascii b5,b3,b2,b1
ptr=198
@ptr=b0
inc ptr
@ptr=b1
and the original line;
hi2cout ("O 0A>",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,".CSV",$0D)
and it works??!!
Now this suggests there is some fundamental difference in the way data is stored/returned from the scratch pad
from
the way is is stored/returned from a variable.
I don't believe it is the use of the variable b4 etc as I have used this form elsewhere when sending commands to the uAlfat
Any thoughts anyone?
This line of code works and creates a filename in uAlfat storage;
hi2cout ("O 0A>",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,".CSV",$0D)
(YYMMDDHH.csv)
The uAlfat states that all the data in any commands must be ascii (with the CR/LF sent as $OD) but already found that in some cases this is the Hex value sent as ascii - i.e. hex BF60 had to be sent as Ascii BF60 !!
The data in the scratchpad (@printc) is from a DS1307 Clock and converted to ascii using BCDTOASCII and stored to the scratchpad thus;
hi2cin [RTC_0],6,(b0) ' Year Read from register 6
bcdtoascii b0,b1,b2
@ptr=b1
inc ptr
@ptr=b2
inc ptr
However I wanted to change the last two bytes of the filename from the HH to a sequential number 01 thru 99.
Wrote the code for that and stored it to b4 and b5 (tens and ones) and used the following line;
hi2cout ("O 0A>",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,b4,b5,".CSV",$0D)
There were no complaints from the uAlfat but no characters in the file name for b4 and b5.
I tried every form of hex,decimal etc conversion including bintoascii but nothing worked including storing actual ascii in b4 and b5 ( i.e. b4 = "1" without success.
So on a long shot I tried;
bintoascii b4,b2,b1,b0
bintoascii b5,b3,b2,b1
ptr=198
@ptr=b0
inc ptr
@ptr=b1
and the original line;
hi2cout ("O 0A>",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,".CSV",$0D)
and it works??!!
Now this suggests there is some fundamental difference in the way data is stored/returned from the scratch pad
from
the way is is stored/returned from a variable.
I don't believe it is the use of the variable b4 etc as I have used this form elsewhere when sending commands to the uAlfat
Any thoughts anyone?
Last edited: