With regard to the issue of a pull-up on the Chip Select for the SD card. For the SDPOLL word to work autonomously there must not be a pull-up.
"A Tale of Two Platform Modules"
The first, a Prop Platform USB board, pins 0 to 3 used, an SM 4 position 10K resistor pack pulling up all 4 lines, and worst of all the pull-up traces are mostly hidden by the socket! Maybe one of you guys with really young eyes and stead y hands could do it but the quarter inch of exposed traces (did I mention 'tiny') is nothing I want to tackle.
So, I left CS pulled up. the "SD" command showed me my card data, but when I pulled it out, nothing happened. I typed "SD" and, correctly, I got "Card Error." I put the card back in, again, nothing ... again, typed "SD"and it displayed my card info.
The second, Prop Plat Through Hole with a 'hacked'' microSD Platform Module (essentially cut the microSD out of a PP-USB), PP-TH has exact same Tachyon kernal and EXTEND and SDCARD. The board booted u p, typed SD and got card info. I then pulled the micro SD card got "Card Error", then re-inserted card and got card info.
The hack suffered from the same placement and tiny traces as the PP-USB, soooooo ... got out my hot air rework station and removed the SM resistor pack and then using 3 10K 1/8th watt resistors used a spare set of holes to put pull-ups back onto CLK, DO, and DI.
In the end with or without the pull-up on CS the Tachyon SD code works fine at its main job ... however, if you can have the CS pull-up removed you get some convenient benefits.
If you are stuck with a pullup on the CS line then just modify CARD? by specifying the input for the #CD. Here is the before and after:
[COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono]'' Detect SD card presence - the CS line must not have a pullup on it (redundant and undesirable).[/FONT]
[/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono]pub [/FONT][FONT=Ubuntu Mono][B]CARD?[/B][/FONT][FONT=Ubuntu Mono] ( -- flg ; Is SD card present? )[/FONT]
[/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] ON SDCS '' Force CS line low[/FONT]
[/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] .SDCS INPUTS '' Float CS[/FONT]
[/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] .SDCS IN '' Is it still low or has it been pulled up (by the card's pullup)[/FONT]
[/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] OFF SDCS[/FONT][/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono]
;
'' Secondary brute force method
[/FONT][/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono]'' Detect SD card presence - use card detect switch and dedicated I/O[/FONT]
[/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono]pub [/FONT][FONT=Ubuntu Mono][B]CARD?[/B][/FONT][FONT=Ubuntu Mono] ( -- flg ; Is SD card present? )[/FONT]
[/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] #CD IN 0=
;[/FONT]
[/FONT][/COLOR]
BTW, that SDCARD code is the "old stuff" before I added the redirection ability.
try to download the saa1064 source, get some problems with the words byte and long.
They are not seen by the compiler.
I load the latest version of the bin and extension file.
try to download the saa1064 source, get some problems with the words byte and long.
They are not seen by the compiler.
I load the latest version of the bin and extension file.
A tachyon is never still, you haven't been keeping up with the thread! I mentioned way back...... a day ago.... that I wanted to allow variables to be entered the same way we do in Spin using comma separated lists. So you will have to compile the new kernel as there are other changes too.
EDIT: I should mention too that you can just declare these in the normal way using VARIABLE & CVARIABLE but without a comma separated list
I've just tweaked the I2C routines to run at 400kHz with a cycle time of 36us for reading and writing. I know that there are PASM routines that run in their own cog or Spin routines that run very slow but this is just bytecode running from the main Tachyon cog.
Here's a shot of the timing when performing a write and a read ($55 I2C! I2C@):
What I'm wondering is does anyone have a need to run faster than this? Is anyone using 1MHz I2C?
There appears to be a bug in PINS? (current version of EXTEND) which is not present in earlier versions.
Results for pins 16-31 mirror those for pins 0-15.
There appears to be a bug in PINS? (current version of EXTEND) which is not present in earlier versions.
Results for pins 16-31 mirror those for pins 0-15.
NickL
Not sure what is happening there as I just did a quick check and got:
So that doesn't look mirrored at all. If you downloaded from the webpage version just make sure that you refresh it beforehand as you may have a stale copy. Just in case...
[COLOR=#000000][FONT=Ubuntu Mono]'' List out each of the Prop's I/O pins & their direction)[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono]pub [/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono][B]PINS?[/B][/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] CR ." i----------u----------i"[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] P@ DIRA COG@ ( port dir )[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] #16 0 [/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] DO[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] CR ." P" I $20A .NUM DUP I MASK AND [/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] IF ." -->" ELSE ." <--" THEN [/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] SPACE OVER I MASK AND 0<> 1 AND .[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] 5 SPACES OVER #31 I - MASK AND 0<> 1 AND . [/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] DUP #31 I - MASK AND[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] IF ." <-- P" ELSE ." --> P" THEN[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] #31 I - $20A .NUM[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] LOOP[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] CR ." i---------------------i"[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] 2DROP[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] ;
[/FONT][/COLOR]
I've just tweaked the I2C routines to run at 400kHz with a cycle time of 36us for reading and writing. <snip> What I'm wondering is does anyone have a need to run faster than this? Is anyone using 1MHz I2C?
400 kHz is a pretty decent speed even for a PASM implementation. For Forth, it's very impressive. Personally, if I needed anything faster, I'd use SPI. It seems a lot more robust for high speed use.
Wow, I go on vacation for a week and 4 new pages of Tachyon "news" are posted. You are right Peter Tachyons never stop moving. Look forward to catching up with everything.
Wow, I go on vacation for a week and 4 new pages of Tachyon "news" are posted. You are right Peter Tachyons never stop moving. Look forward to catching up with everything.
I do have some I2C RTC code as well with standardized interface so you can read and write stamps or strings without regard to the chip but I want to connect to a Spinneret I've got here and interface to that chip too. There's a 1-wire page and some other ones that are alluded to in the Intro page that will go up as soon as I finish scratching myself.
Thanks. The version I was using had the phrase ' #31 I - " missing in two critical places.
NickL
You know, it's quite possible that you had a snapshot of a page that I was editing because that only existed for the brief moment it took to check and fix. I try to avoid that however for this very reason and I either make small changes in a text editor before pasting or encapsulate my test code in curlys in the online document to avoid transients. So it you do get an error during loading then go back and just refresh your webpage copy.
I will try to fit it in today in my schedule of forum browsing, posting, and scratching myself (but mostly real work)
Do you need this multichannel as it would make sense and what frequency?
For many people familiar with Forth they know that things are done a certain way and Tachyon doesn't always do it the same. Even in little things such as DO.. LOOP it's conventional wisdom to push loop parameters onto the return stack (I cringe) and remove those after the loop exits. Also LOOP has a branch address compiled after it so that it can branch back to the start of the loop. The other problem is that the stack index is not easily accessible outside of the loop but has to be passed explicitly which is more junk on the data stack.
IDEA:
So in Tachyon we have a separate loop stack used for DO..LOOP and FOR..NEXT parameters which do not mess with the return stack and allow easy direct access to parameters. But there is still the branch address used by LOOP and NEXT which seems both inefficient and can slow down a fast loop. So I got to thinking what if we include the branch address as part of the loop parameters that get pushed onto the loop stack when we first enter the loop with DO, ADO, or FOR so that there are 3 not 2 parameters (as in DO)? This way when a branch has to be taken it can read it directly from the loop stack in cog RAM and snap back to the start of the loop in an instant without the slow hub access required to read the branch normally. The same would go for repeating structures such as BEGIN UNTIL as well.
Just thought I'd share this one with you as I'm always looking at ways of making Tachyon and Forth better, both from a programming perspective and from a run-time efficiency perspective.
Actually that would make it a fourth Forth stack I already have the DATA, RETURN, and LOOP stacks. Already I'm looking at putting the loop branch address onto a BRANCH stack so that then would make it five stacks! Well, whatever works as long as it doesn't make it complicated from the coding perspective, just simpler. I've started coding a new version of Tachyon that has almost zero overhead when looping in DO..LOOPs etc. I also want to extend that to repeat branches as well but I will test out the looping shortly.
BTW, Tachyon also uses 4 or 5 cog registers (COGREG) for parameters in certain functions such as SPI, SD etc where there is a lot of repetition and this helps keep the data stack small and tidy.
Tachyon V2 stacks:
DATA for pertinent data parameters (not using it for junk)
RETURN only for return addresses (and the occasional fudge)
LOOP where index and limits for looping are placed
+
BRANCH for branch addresses for looping and repeat structures
LOCAL for local variables
EDIT: I think Tachyon is now 2 months old a couple of days ago, time for it to evolve!
I will try to fit it in today in my schedule of forum browsing, posting, and scratching myself (but mostly real work)
Do you need this multichannel as it would make sense and what frequency?
Two channels will be fine, because the most motor controller shields for the arduino (I use the ASC board) can handle 2 motors.
I think a frequency of about 500 HZ will be fine (adjustable?), and the range of manupulation the pwm may be 0..255
Well I have been playing with Tachyon V2 and looping is like it's slid on rails, I'm getting figures of 400ns loop overhead compared to 800ns (average due to hub access jitter) in V1. As a side bonus I no longer need special words to compile loops, you know DO compiles a (DO) bytecode normally and leaves stuff on the stack for LOOP to work with and compile a (LOOP),<branch>. Yep, no longer need those special word and the loop code is more compact, cleaner, and twice as fast. The same will go for BEGIN..WHILE..REPEAT structures etc.
@Jan: Wait your turn! I'm busy with V2!
I will try to get around to it soon.
I've made a decision to hold Tachyon V2 until I have done a bit more testing and tweaking so as to avoid all the "this doesn't work" when I am still testing and deciding what to do. The kernel is running very well and I made some decisions in optimizing it. For starters besides the new stacked looping used in DO...LOOP +LOOP FOR..NEXT I have also implemented stacked conditional looping with <BEGIN...AGAIN> or UNTIL> and added a POPMARK word so that a forced exit can adjust the MARKER (branch marker) stack. The reason I did not replace the conventional conditional looping was that it does have uses and there may be some user code that may not take into account the MARKER stack and break it.
So I've had to squeeze a bit more into the cog kernel where there was absolutely no room before so now the bits are more compressed I managed to find some operations or parts thereof that could be moved to the hub kernel (bytecode) and removed some redundant registers etc. The 16-bit calls (vs 8-bit indexed) have not been used yet as everything so far including my applications have not exhausted the call vector table but I will be pushing it so that these limits are tested. This also means the expansion of the dictionary and word help functions into EEPROM or other non-volatile storage such as SPI FLASH or SD.
I'm also thinking of implementing a fast serial download feature a bit like PropForth in that a Tachyon cog just processes the input stream and strips out all the redundant spaces and comments etc (about 50%) and buffers this in available RAM which the main Tachyon cog can then process at it's speed which most of the time is fast. This would remove any need for line delays as there is no handshaking although I wish that all terminal emulators supported XON/XOFF properly. So the TACHYON word that I use at the start of a source code file will trigger the fast load automatically. BTW, the TACHYON word is just there to make sure that you don't try to load it on another Forth system and also to reset error counters etc.
There's also context switching support for changing the REG base for any Tachyon cog so that it can have it's own local variables etc. If anyone wants a copy to play with V2 in the meantime and perhaps report bugs (without expecting anything) then please PM me for a link.
What's the story on "=IF" and/or "EQIF" ... it looks like its there but it isn't. The other day you mentioned LOOKUP and LOOKDOWN as CASE substitutes . Do they exist?
I would like to take a whack at V2. Please send the link to my regular email address ... TNX
What's the story on "=IF" and/or "EQIF" ... it looks like its there but it isn't. The other day you mentioned LOOKUP and LOOKDOWN as CASE substitutes . Do they exist?
I would like to take a whack at V2. Please send the link to my regular email address ... TNX
Since we have to work with the Spin tool we also need to avoid reserved names such as LOOKUP so internally it's known as VECTORS. However I don't have a LOOKDOWN yet although it's probably no problem and still checking out a few different scenarios to see how I can make a really useful (and efficient) CASE structure. Will send you the link shortly. The EQIF was removed as there are only so many bits in a long and so many longs in a cog and we are always a "bit" short.
JonnyMac has contributed an enormous amount of code to the Parallax community. One of my favorites is "jm_servo8-ez.spin" ... it is what its name implies ... simple and easy background servo pulse driver all in spin. The counters/timers of the prop are hidden behind the WAITCNT commands. Its a quick, easy and CLEAN way to get servos up and running on a prop.
I started my usual way by transcribing from spin to TF ... I got a clean load in two tries under kernal rev120905.0000.. I sat back and looked at what I had and GAWD! ... it sure was ugly and I couldn't get the background task to kickoff. After some patient help from Peter I have it going and documented and available for public consumption.
I compiled the code under kernel 120905.0000 with and EXTEND.fth newer than 120904. I ran it on a PropBOE with a couple of GWS servos I had hanging around. Any problems let me know.
My pleasure -- and thanks for the kind words. I am still in the struggling stages with Forth, and as this is the Halloween season and I'm very busy writing code for my customers, not sure how I'll fair. The key for me -- as I often tell my customers -- is to create a real project. It's neat to see a translation of the code, though I dare say I don't know how you got from point a to point b....
JonnyMac has contributed an enormous amount of code to the Parallax community. One of my favorites is "jm_servo8-ez.spin" ... it is what its name implies ... simple and easy background servo pulse driver all in spin. The counters/timers of the prop are hidden behind the WAITCNT commands. Its a quick, easy and CLEAN way to get servos up and running on a prop.
I started my usual way by transcribing from spin to TF ... I got a clean load in two tries under kernal rev120905.0000.. I sat back and looked at what I had and GAWD! ... it sure was ugly and I couldn't get the background task to kickoff. After some patient help from Peter I have it going and documented and available for public consumption.
I compiled the code under kernel 120905.0000 with and EXTEND.fth newer than 120904. I ran it on a PropBOE with a couple of GWS servos I had hanging around. Any problems let me know.
Brian do you have SDCard.fth running with the PBOE? If so please share if possible.
EDIT: Now that I found version : SDCARD.fth ." SD CARD Toolkit - 120908.0400 is does have the PBOE word and I got the bitmask correct but I still get a "SD Card Error" when attempting to use the SD word?
Brian do you have SDCard.fth running with the PBOE? If so please share if possible.
EDIT: Now that I found version : SDCARD.fth ." SD CARD Toolkit - 120908.0400 is does have the PBOE word and I got the bitmask correct but I still get a "SD Card Error" when attempting to use the SD word?
NOPE! It won't work on any of my uSD cards. I also checked Mike Green's PropBOE Basic source code for pin numbers as well as loaded the code and verified the card worked.
NOPE! It won't work on any of my uSD cards. I also checked Mike Green's PropBOE Basic source code for pin numbers as well as loaded the code and verified the card worked.
Okay, thanks for the effort. I'll just be patient and wait until the SD tool kit is further along in Tachyon.
Okay, thanks for the effort. I'll just be patient and wait until the SD tool kit is further along in Tachyon.
I just added the BOE parameters that were handed to me but I double checked the schematic and entered the pin numbers individually using the SDCS SDK MOSI MISO words and had a look at the long it generated and it was different from what was supplied. So the definition has been corrected.
Before it was: $19171816 SDPINS but after entering:
#25 SDCS
#23 SCK
#24 MOSI
#22 MISO
ok
I read the result as
sdpins @ .LONG 17181619 ok
Comments
NEW - Project page links
"A Tale of Two Platform Modules"
The first, a Prop Platform USB board, pins 0 to 3 used, an SM 4 position 10K resistor pack pulling up all 4 lines, and worst of all the pull-up traces are mostly hidden by the socket! Maybe one of you guys with really young eyes and stead y hands could do it but the quarter inch of exposed traces (did I mention 'tiny') is nothing I want to tackle.
So, I left CS pulled up. the "SD" command showed me my card data, but when I pulled it out, nothing happened. I typed "SD" and, correctly, I got "Card Error." I put the card back in, again, nothing ... again, typed "SD"and it displayed my card info.
The second, Prop Plat Through Hole with a 'hacked'' microSD Platform Module (essentially cut the microSD out of a PP-USB), PP-TH has exact same Tachyon kernal and EXTEND and SDCARD. The board booted u p, typed SD and got card info. I then pulled the micro SD card got "Card Error", then re-inserted card and got card info.
The hack suffered from the same placement and tiny traces as the PP-USB, soooooo ... got out my hot air rework station and removed the SM resistor pack and then using 3 10K 1/8th watt resistors used a spare set of holes to put pull-ups back onto CLK, DO, and DI.
In the end with or without the pull-up on CS the Tachyon SD code works fine at its main job ... however, if you can have the CS pull-up removed you get some convenient benefits.
[COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono]'' Detect SD card presence - the CS line must not have a pullup on it (redundant and undesirable).[/FONT] [/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono]pub [/FONT][FONT=Ubuntu Mono][B]CARD?[/B][/FONT][FONT=Ubuntu Mono] ( -- flg ; Is SD card present? )[/FONT] [/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] ON SDCS '' Force CS line low[/FONT] [/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] .SDCS INPUTS '' Float CS[/FONT] [/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] .SDCS IN '' Is it still low or has it been pulled up (by the card's pullup)[/FONT] [/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] OFF SDCS[/FONT][/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] ; '' Secondary brute force method [/FONT][/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono]'' Detect SD card presence - use card detect switch and dedicated I/O[/FONT] [/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono]pub [/FONT][FONT=Ubuntu Mono][B]CARD?[/B][/FONT][FONT=Ubuntu Mono] ( -- flg ; Is SD card present? )[/FONT] [/FONT][/COLOR][COLOR=#000000][FONT=Arial][FONT=Ubuntu Mono] #CD IN 0= ;[/FONT] [/FONT][/COLOR]BTW, that SDCARD code is the "old stuff" before I added the redirection ability.
try to download the saa1064 source, get some problems with the words byte and long.
They are not seen by the compiler.
I load the latest version of the bin and extension file.
EDIT: I should mention too that you can just declare these in the normal way using VARIABLE & CVARIABLE but without a comma separated list
Here's a shot of the timing when performing a write and a read ($55 I2C! I2C@):
What I'm wondering is does anyone have a need to run faster than this? Is anyone using 1MHz I2C?
There appears to be a bug in PINS? (current version of EXTEND) which is not present in earlier versions.
Results for pins 16-31 mirror those for pins 0-15.
NickL
400 kHz is a pretty decent speed even for a PASM implementation. For Forth, it's very impressive. Personally, if I needed anything faster, I'd use SPI. It seems a lot more robust for high speed use.
Peterbdo you have a pwm example in tachyon?
NickL
Do you need this multichannel as it would make sense and what frequency?
IDEA:
So in Tachyon we have a separate loop stack used for DO..LOOP and FOR..NEXT parameters which do not mess with the return stack and allow easy direct access to parameters. But there is still the branch address used by LOOP and NEXT which seems both inefficient and can slow down a fast loop. So I got to thinking what if we include the branch address as part of the loop parameters that get pushed onto the loop stack when we first enter the loop with DO, ADO, or FOR so that there are 3 not 2 parameters (as in DO)? This way when a branch has to be taken it can read it directly from the loop stack in cog RAM and snap back to the start of the loop in an instant without the slow hub access required to read the branch normally. The same would go for repeating structures such as BEGIN UNTIL as well.
Just thought I'd share this one with you as I'm always looking at ways of making Tachyon and Forth better, both from a programming perspective and from a run-time efficiency perspective.
http://www.ece.cmu.edu/~koopman/forth/rochester_90b.pdf
BTW, Tachyon also uses 4 or 5 cog registers (COGREG) for parameters in certain functions such as SPI, SD etc where there is a lot of repetition and this helps keep the data stack small and tidy.
Tachyon V2 stacks:
DATA for pertinent data parameters (not using it for junk)
RETURN only for return addresses (and the occasional fudge)
LOOP where index and limits for looping are placed
+
BRANCH for branch addresses for looping and repeat structures
LOCAL for local variables
EDIT: I think Tachyon is now 2 months old a couple of days ago, time for it to evolve!
Two channels will be fine, because the most motor controller shields for the arduino (I use the ASC board) can handle 2 motors.
I think a frequency of about 500 HZ will be fine (adjustable?), and the range of manupulation the pwm may be 0..255
Cheers,
Jan Kromhout
Hellevoetsluis-NL
@Jan: Wait your turn! I'm busy with V2!
I will try to get around to it soon.
So I've had to squeeze a bit more into the cog kernel where there was absolutely no room before so now the bits are more compressed
I'm also thinking of implementing a fast serial download feature a bit like PropForth in that a Tachyon cog just processes the input stream and strips out all the redundant spaces and comments etc (about 50%) and buffers this in available RAM which the main Tachyon cog can then process at it's speed which most of the time is fast. This would remove any need for line delays as there is no handshaking although I wish that all terminal emulators supported XON/XOFF properly. So the TACHYON word that I use at the start of a source code file will trigger the fast load automatically. BTW, the TACHYON word is just there to make sure that you don't try to load it on another Forth system and also to reset error counters etc.
There's also context switching support for changing the REG base for any Tachyon cog so that it can have it's own local variables etc. If anyone wants a copy to play with V2 in the meantime and perhaps report bugs (without expecting anything) then please PM me for a link.
What's the story on "=IF" and/or "EQIF" ... it looks like its there but it isn't. The other day you mentioned LOOKUP and LOOKDOWN as CASE substitutes . Do they exist?
I would like to take a whack at V2. Please send the link to my regular email address ... TNX
Since we have to work with the Spin tool we also need to avoid reserved names such as LOOKUP so internally it's known as VECTORS. However I don't have a LOOKDOWN yet although it's probably no problem and still checking out a few different scenarios to see how I can make a really useful (and efficient) CASE structure. Will send you the link shortly. The EQIF was removed as there are only so many bits in a long and so many longs in a cog and we are always a "bit" short.
: PBOE '' Prop BOE
$19171816 SDPINS
{
#25 SDCS '' SD Card chip select
#23 SCK '' SD Card clock
#24 MOSI '' SD data in from Prop
#22 MISO '' SD data out to Prop
)
Based on this from the Prop BOE docs
P22 MicroSD card DO (data out)
P23 MicroSD card CLK (clock)
P24 MicroSD card DI (data in)
P25 MicroSD card /CS (active-low chip select)
Just not sure if this is correct.
I started my usual way by transcribing from spin to TF ... I got a clean load in two tries under kernal rev120905.0000.. I sat back and looked at what I had and GAWD! ... it sure was ugly and I couldn't get the background task to kickoff. After some patient help from Peter I have it going and documented and available for public consumption.
I compiled the code under kernel 120905.0000 with and EXTEND.fth newer than 120904. I ran it on a PropBOE with a couple of GWS servos I had hanging around. Any problems let me know.
Thanks, Jon!
Attachment not found.
My pleasure -- and thanks for the kind words. I am still in the struggling stages with Forth, and as this is the Halloween season and I'm very busy writing code for my customers, not sure how I'll fair. The key for me -- as I often tell my customers -- is to create a real project. It's neat to see a translation of the code, though I dare say I don't know how you got from point a to point b....
Brian do you have SDCard.fth running with the PBOE? If so please share if possible.
EDIT: Now that I found version : SDCARD.fth ." SD CARD Toolkit - 120908.0400 is does have the PBOE word and I got the bitmask correct but I still get a "SD Card Error" when attempting to use the SD word?
NOPE! It won't work on any of my uSD cards. I also checked Mike Green's PropBOE Basic source code for pin numbers as well as loaded the code and verified the card worked.
Okay, thanks for the effort. I'll just be patient and wait until the SD tool kit is further along in Tachyon.
Before it was: $19171816 SDPINS
but after entering:
#25 SDCS
#23 SCK
#24 MOSI
#22 MISO
ok
I read the result as
sdpins @ .LONG 17181619 ok
So the correct long is: $17181619 SDPINS