IN the VGADEMO.fth, the last lines of the file are
\ CORRECT THE 5X7 FONT FOR USE WITH VGA
FONT $1D + C@ $0F = IF FONT $60 7 * ADO I C@ #27 REV I C! LOOP THEN
\ back it up into EEPROM - don't use paging NOTE: this becomes redundant once the font table is fixed
FONT DUP $60 7 * ESAVEB
END
what is "ESAVEB" ??? It gets a "???" and I have looked all over without finding a clue!
Hi Jeff, I'm shocked, absolutely shocked (Casa Blanca I think) that the extended features didn't backup to EEPROM. Normally after loading in a fresh kernel the idea is to download EXTEND.fth and if there were no errors in download (usually due to coming in too fast without handshaking) then it will do an automatic backup. So just make sure that you have enough line delay on your terminal settings (30 to 50ms) and that there were no errors. However the VGA DEMO does not do an automatic backup because it's a demo but you can tell it to at any time by typing BACKUP. The VGA demo is overlapping into ROM until I free up some more memory so you will see some garbage at the bottom of the screen when it's not blanked. Is that what you mean by "glitched".
I'm going to try the EEPROM thing again on the Quickstart, with and without my plug-in-board. I'm wondering if something there is getting in thew way. (Like USB power enable jumper maybe?) -I'll report back..
(Darn it! I took another chip!)
Edit, It seems the "ms delay" setting was key to getting this work. I switched to "TeraTerm" under Windows which has this delay setting, and it seems to be accepting the code now.
Jeff
Edit, It seems the "ms delay" setting was key to getting this work. I switched to "TeraTerm" under Windows which has this delay setting, and it seems to be accepting the code now.
I went through the same thing until I found the line delay setting in TeraTerm.
Been following the thread. Seems like I should be able to run this thing on a QuickStart, with or without my VGA+ board. That combo is such a nice little "mini"computer which just might be the thing for playing around with Forth.
In the past when I've looked into Forth and Forth-like languages I always found it interesting, but I always ran into a wall when I wanted to try Forth for the stuff I normally do in some high-level language on the computer.. writing emulators and data processors. Forths in general won't seem to let me work that way, with programs taking input from files, letting me edit source in my editor and so on. But with a QS I can as well do the interactive thing, as there's no operating system or filesystem there anyway.. so I'll have a go at it this weekend.
Tachyon does the interpreter's compilation in-line, it does not send it over to another cog so is susceptible to overrun on the input.
This makes it simpler, but needs the user to be aware how this works to avoid the issue. This one design decision that is different from other implementations.
Tachyon does the interpreter's compilation in-line, it does not send it over to another cog so is susceptible to overrun on the input.
This makes it simpler, but needs the user to be aware how this works to avoid the issue. This one design decision that is different from other implementations.
But Tachyon does not go through long long development cycles before release, it is a work in progress and the primary focus was to get it up and running as fast as possible and build up from there. So I use the expression "bear in mind" a bit but it's a reminder that any deficiencies Tachyon has now is simply because of it's being incomplete although it is "complete at any particular stage" in that it functions well and it's no slouch at 7 weeks. Compile speed is not really that important in the whole scheme of things so it has a lower priority at present as other things are far more important. IIRC PropForth had problems with line delays being required for a long time before that was finally fixed up and now it works really well. Being able to squeeze as much as I do out of one cog without having to resort to special PASM operations simply means that Tachyon will not fail to impress when it opens up to full throttle.
Also, the compilation in-line is very deliberate and can and will perform a lot faster than all that multiple buffering that goes on with serial buffers, terminal input buffers etc. The main offender at present is not having a dependable method of handshaking as some terminals support XON/XOFF and some don't. Putting in a longer line delay means it takes 5 seconds instead of 1 or 2 to compile a file, hardly anything to lose sleep over. In the end runtime speed is far more important which Tachyon cannot be faulted for, especially in the area of I/O and common operations which is where an MCU needs to perform. If that's a temporary tradeoff then I'm certainly happy with that
yes its perfectly fine and a valid choice, just noting that it is different in one of the many ways it can be different. Propforth tends to have many, very long scripts, and the delay was getting bothersome. We figured the chance to have an overrun meant we would get false bugs, so we made a different choice. Tachyon is attracting more of the advanced users and so this should not be an issue. Anything that works really well is fine in my book.
It is really cool how far you've come in such a short time. Clearly you don't waste as much time watching TV as some of us.
I started with Chris Savage and Jeff Martins spin code from 2006 in v 1.5 of the Ping manual.
Initially all I did was 'transcribe' the Spin code to Tachyon Forth and get it, first, to run ... and, second, to run right! It did, then I settled down to smooth it out and comment it.
One neat set of words that were very useful were NEWCNT and LAPCNT ... check them out, buried in the kernel.
I have started playing with SimpleIDE and have also been using this for editing Forth source code files (.fth) as well. It got me thinking that it would be nice if SimpleIDE had a terminal built-in especially if it supported common ANSI controls and allowed source code to be downloaded along with XON/XOFF handshaking. So I will try to find out about this but in the meantime some of you may have noticed that various snippets of code look a little Spin-like. You know, instead of the colon they start with pub or pri plus instead of a long line of code it is spread over multiple lines. Well, I'm trying to make this more readable for Spin users and it is just as readable to Forth users yet it does not compromise the simplicity of the Forth compilation process. There are probably other changes I will make as they seem practical and conducive to learning to program in Tachyon Forth (and have others understand it).
So where I can and as long as it doesn't compromise Tachyon itself I have been renaming or creating aliases of functions so that they are more familiar to Spin (and C) users but of course taking into account the RPN stack notation. Here's a snippet of LCD code that uses ++ and ~ and pub etc, even LOOKUP in a slightly different form:
pub LCDHOME
ypos C~ '' clear y line position
xpos C~ '' clear x character position
2 LCDCMD '' Raw home command for LCD
1 ms '' Just give the LCD time to execute it
;
pub LCDCLS '' Clear the LCD screen
1 LCDCMD '' Raw LCD command to clear it's screen
1 ms '' The only command that you really need to wait for
LCDHOME
;
pub LCDCR '' Carriage return
xpos C~ XYCUR '' Return to X position zero and update LCD's cursor
;
pub LCDLF '' Line feed
ypos C++
ypos C@ #lines => '' Wrap-around to the top of the display?
IF ypos C~ THEN
XYCUR '' Update the LCD's internal cursor
;
pub LCDCHAR ( char -- ) '' Treat character as data
LCDDAT
xpos C++ '' increment character position
xpos C@ chars => '' and wrap to next line if necessary
IF
xpos C~
LCDLF
THEN
;
pub LCDchar ( char -- )
0 REG C@ LCDCHAR '' Restore character and pass as a character to the LCD
;
pub LCDCtrls ( ctrl -- ) '' Look up and execute the code that corresponds to the ctrl character
$10 LOOKUP LCDchar { Default vector if above limit of $10 }
LCDchar LCDHOME LCDchar LCDchar
LCDchar LCDchar LCDchar BEEP
LCDchar LCDchar LCDLF LCDchar
LCDCLS LCDCR LCDchar LCDchar
;
pub LCDEMIT ( char -- ) '' Process the ASCII character either as a control or as a printable character
DUP BL < '' Less than a BLANK ($20) is a control character
IF DUP 0 REG C! LCDCtrls
ELSE LCDCHAR '' else it is display data
THEN
;
I have started playing with SimpleIDE and have also been using this for editing Forth source code files (.fth) as well. It got me thinking that it would be nice if SimpleIDE had a terminal built-in especially if it supported common ANSI controls and allowed source code to be downloaded along with XON/XOFF handshaking. So I will try to find out about this but in the meantime some of you may have noticed that various snippets of code look a little Spin-like. ....
Don't know if you're open to this, but it got me thinking....
I hear Go language compiler also compiles C code. The Go language terminal utility example Sal wrote uses the host PC's OS functions, so it gives tab completion, command history, command line editing, stuff like that for free. And it provides the channel interfaces, so the PC app can talk directly to the prop over a fast channel, if you chose to expand in this direction...
Also I have several Prop Platform USB boards with microSD slots on P0 to P3 with CS, DO, DI, and SCLK, but no Card Detect. How difficult to adapt the code? I was looking it over, searching against ".CARD" (that's how I found the dual definition) and a first glimpse it doesn't look too tricky to excise CD code ... am I missing anything critical?
I started with Chris Savage and Jeff Martins spin code from 2006 in v 1.5 of the Ping manual.
Initially all I did was 'transcribe' the Spin code to Tachyon Forth and get it, first, to run ... and, second, to run right! It did, then I settled down to smooth it out and comment it.
One neat set of words that were very useful were NEWCNT and LAPCNT ... check them out, buried in the kernel.
Brian,
I took the liberty of porting your wonderful PING.fth for Tachyon to PropForth and posted it to the PropForth 5.0 thread here. I don't want it to feel left out since everyone is playing with the new kid. (Sibling rivalries and all that! )
I'm going to do the PIR next, when I get more play time if there are no objections.
Since I don't use the card detect switch I never noticed it It just so happens that last night I came across this and renamed the card detect switch to .CD although I may improve my convention for naming pins as it can get confused with the standard Forth dot word for print.
My detect routines assume you have not used the seemingly obligatory pull-up resistor on the chip select line then you can use this routine to detect whether a card is present or not
: CD? ( -- flg ; Is SD card present? )
ON SDCS '' Force CS line low
.SDCS INPUTS '' Float CS
.SDCS IN '' Is it still low or has it been pulled up (by the card's pullup)
OFF SDCS
;
Also I have several Prop Platform USB boards with microSD slots on P0 to P3 with CS, DO, DI, and SCLK, but no Card Detect. How difficult to adapt the code? I was looking it over, searching against ".CARD" (that's how I found the dual definition) and a first glimpse it doesn't look too tricky to excise CD code ... am I missing anything critical?
So as you can see the card detect switch is not being used as I rely on the documented CS pull-up that is present on SD cards internally. If you have a pull-up to the CS line on your board then disconnect it.
After power up, this line is input with 50Kohm(+/-20Kohm) pull-up (can be used for card detection or SPI mode
selection). The pull-up may be disconnected by the user, during regular data transfer, with
SET_CLR_CARD_DETECT (ACMD42) command.
Here's a schematic of the SD hookup that is used in the code (although I have many others I test as well).
Seeing that a version of my L6470.fth has just been posted in the PropForth thread I thought I would post my Tachyon version of the original L6470.fth file. This is not totally optimized yet for Tachyon but the code takes 1.8K. These files are also available through the link section of the Tachyon Intro page. One of the aims with Tachyon was to avoid any cryptic PASM code when programming in Forth and so Tachyon had to be fast but it is also supported with a sensible set of instructions in it's VM.
L6470 Microstepper code for dual motors - L6470 1V1.txt
It's not quite two months since I started the Tachyon project and for the last couple of weeks I have been porting applications across to Tachyon and tweaking the kernel that little bit more etc. I have now released V1.1 which also introduces multi-tasking using cogs 4 to 7. There's also a KEYPOLL background function that can be used from the primary terminal task that's useful for checking for status updates such as SD card insertion/removals etc without resorting to using another cog.
The SD card "toolkit" has been up and running but I am still doing some more tests with various cards before I add on the full virtual memory and file system extensions. At the moment it's very useful for investigating SD cards and you can even backup the hub ram directly into the SD card as if it were just a very large SPI memory chip (and unless you want to use it in a PC, who cares). It's possible to do bitmap screen updates at around 20 fps with this method which just uses a PASM kernel routine for bit-bashing SPI. I might look at the counter approach later on once functionality is fully established (so 60fps would be possible!). BTW, I favor non-fragmentation of files as it simplfies file access and makes them far more efficient. Sometimes I even create one big non-fragmented file which may hold lots of smaller files. Certainly many of my logging files preallocate a large chunk as non-fragmented so that it becomes a simple virtual memory and avoids all those traditional and cumbersome file access methods. The virtual memory address is the handle and the virtual memory access words hide the caching and flushing etc.
Now there's also a lot of peripheral chip interfacing that I'm doing but let me know if there are any special requests as I will be testing and releasing this source daily.
It's not quite two months since I started the Tachyon project and for the last couple of weeks I have been porting applications across to Tachyon and tweaking the kernel that little bit more etc. I have now released V1.1 which also introduces multi-tasking using cogs 4 to 7. There's also a KEYPOLL background function that can be used from the primary terminal task that's useful for checking for status updates such as SD card insertion/removals etc without resorting to using another cog.
The kernel spin file starts things up and then terminates COG 0. Comments there led me to think that COG 0 would be available in addition to COGs 4..7 ... and then what about COG 3 if VGA is not compiled in, or you manually turn off VGA?
So is the RUN method hard coded only to accept 4..7 or are 0 and 3 also acceptable ?
... and the answer is 4..7 only, a request for 0 or 3 executes but nothing
Propeller .:.:--TACHYON--:.:. Forth V1.1 rev120827.0200
TACHYON
Propeller .:.:--TACHYON--:.:. Forth V1.1 rev120827.0200
ok
: TASK1 ( -- )
BEGIN
0 MASK OUTSET
#500 ms
0 MASK OUTCLR
#500 ms
AGAIN
; ok
: BLINKY 200d FOR 0 MASK OUTSET 100d ms 0 MASK OUTCLR 100d ms NEXT ; ok
END
End of source code, there were 0 errors found
CODE @$3E9D - bytes used in this load = 39
NAMES @$1DCB - bytes used in this load = 17
YCALLS @ 180 entries free
ok
NOVGA ok
ok
' BLINKY >PFA 3 RUN ok
.
' BLINKY >PFA 7 RUN ok
7 STOP ok
' BLINKY >PFA 0 RUN ok
There is a problem in the multi-tasking. Once you excercise a COG, say " ' BLINKY >PFA 5 RUN " and it runs for a while, and then you decide its usefulness is over and you issue a " 5 STOP" ...
THAT"s IT for COG 5 ... you can issue this, " ' BLINKY >PFA 5 RUN " until the cows come home and it isn't going to blink, because it never gets back to that SPIN initialization in COG 0 where the Tachyon VM idle loop is called for COG 5 "cognew(@RESET, @IDLE)"
Now maybe I have made the mistake of loading my expectations on to your project, but it seems to me that being able to start a cog with a task and then stop it and run yet another task and maybe go back to the first task or on to a third or fourth one is what we've come to expect from Prop based systems.
Another thing I dont get fix is to output a PWM signal on a specific pin.
Do you have an example in TACHYON
Thanks in advance,
Jan
Do you want PWM or duty mode DAC?
If it's a duty mode DAC then that's real easy, you can even do that in interactive mode as you have direct access to the counter registers. Just type this in:
#11 APIN
DUTY
To get a square wave (50%) type:
$8000.0000 FRQ
To get 25% type:
$4000.0000 FRQ
To make that into a convenient word say as an 8-bit DAC:
pub DAC! ( level -- )
#24 SHL FRQ DUTY
;
The pin can be specified once as shown above or changed on the fly. By default the A counter is accessed but you only have to type in "B" to change it like this:
B #12 APIN
$40 DAC!
Which will set pin 12 to use counter B with a 25% duty cycle.
Now if it's PWM (fixed frequency) you need then normally we dedicate a cog to looking after that (plus other things). That's not so hard either but this duty mode is simple and normally what you would use if you had an RC network to filter it to a voltage.
To answer this and your other question:
It's easy enough to use cog 0 but why bother as we already have 5 cogs running a Tachyon VM and I might want another one for an object from the OBEX (maybe). Each cog has an "run" vector but unless all cogs are runnning Tachyon (possible) they won't all be needed. At startup cogs 4 to 7 are loaded with the VM but told to execute an IDLE loop which just waits for it's run vector to come alive. Once it's off and running there is not much in the way of control that we have with these little cogs but that's the way the Prop is. You can stop them but you can't restart them unless you do another coginit which I can do but it's only necessary when you are mucking around testing and it's easier just to reset the Prop (^C or <break>).
The kernel spin file starts things up and then terminates COG 0. Comments there led me to think that COG 0 would be available in addition to COGs 4..7 ... and then what about COG 3 if VGA is not compiled in, or you manually turn off VGA?
So is the RUN method hard coded only to accept 4..7 or are 0 and 3 also acceptable ?
<snip>
[/code]
However, I could make the IDLE loop kill the vector before it runs the user code, then call the code so that if it returns it will be back to idle. I will check this method out.
EDIT: Just changed it so that it clears the vector when taken and if you exit your code it will wait back in the IDLE loop
Do you have experiance to communicate with a mcp3004/3008 or mcp3208
Thanks in advance.
Jan
I've started up an MCP3208 code document and I will hook-up a chip later as I have used these in old projects. You are welcome to follow my progress but be quick about it as it won't take long at all. Although this is the default ADC solution for many as it's easy I don't really use these chips anymore as I use cheaper solutions based on single-chip processors with embedded ADCs and I2C etc.
EDIT: The solution should have taken 5-10 minutes once I hooked up the pcb except I forgot that this board had a deliberate and hidden short between the Din and Dout of the chip and I was wondering why I kept reading back 0's until I decided to float the MOSI from the Prop after the first 8 bits. Anyway it's working now, there's both a fast and slow method. I checked it on my old pill counter sensor pcbs which use 1" photodiodes connected to opamps and into the MCP3208. It's all working well.
However, I could make the IDLE loop kill the vector before it runs the user code, then call the code so that if it returns it will be back to idle. I will check this method out.
EDIT: Just changed it so that it clears the vector when taken and if you exit your code it will wait back in the IDLE loop
Before I was running a "BEGIN..AGAIN" loop with no exit and stopping it was simple matter of "<cogid> STOP" With a foreground processes you test a "KEY?" to break a loop. Is there a way to send a cog a character? Or do we do it the old fashioned way cog abort flag in hub ram?
Since it's not possible to interrupt a cog then the only way to break into anything is if the user code polls for something. So I guess your code may have poll a variable then. I don't know if there's a better way. I will see if I can include something as a VM instruction that simplifies this. But remember this really only applies when you are testing out code and wish to stop it without resetting. Every other time we want to stop any kind of code we have to reset it anyway.
OK, when you put it that way. Most tasks will come in execute and exit back and the VM Idle Loop resumes. If you have and endless loop its still good to have control, so instead of "BEGIN.. AGAIN" You code "BEGIN.. ?hubflag UNTIL"so the loop can be forced out without a system reset.
Question: you said you made a change for multi-tasking several hours ago "Tachyon1v0-VGA.spin" was altered 4 hours ago and "Tachyon1v1-VGA.spin" 20+ hours ago. Did you mean to alter v1.0 or v1.1 ????
Whoooops, what's in a name??? Okay, I fixed the name of the files and removed 1V0 so there is no confusion. I will put that flag in shortly, maybe even use the vector location with a single-byte command rather than an address.
Okay so I have made an addition to allow other Tachyon cogs to receive a command, a bit like hitting a key. It's really very simple, we just insert ATN? which returns with a non-zero byte command which is inserted by another cog. You can interpret the command anyway you want, just like a key. The command is read from the cog's "tasks" vector which won't cause it to run wild as it will simply clear a byte command in the idle loop without trying to execute it.
Here's what my blinky looks like:
#13 MASK CONSTANT .RDY
: BLINKY BEGIN .RDY OUTSET 50d ms .RDY OUTCLR 50d ms ATN? UNTIL ;
' BLINKY >PFA 4 RUN
Now when I type:
1 4 RUN
where 1 is a "command" for cog 4 the loop will terminate and I can get control of it once again in the idle loop. This is also a neat way to pass commands to the cog if it is setup to process them like this:
#13 MASK CONSTANT .RDY
: BLINKY 50d BEGIN .RDY OUTSET DUP ms .RDY OUTCLR DUP ms ATN? DUP 1 > IF NIP DUP THEN 1 = UNTIL ;
' BLINKY >PFA 4 RUN
So blinky will start off with a fast blink, but now:
#200 4 RUN
will cause it to slow blink
Comments
Update: Up and running between work tasks.
what is "ESAVEB" ??? It gets a "???" and I have looked all over without finding a clue!
Wow. 195 posts. If there were one post detailing each word in the dictionary, the thread would be done already.
I'm going to try the EEPROM thing again on the Quickstart, with and without my plug-in-board. I'm wondering if something there is getting in thew way. (Like USB power enable jumper maybe?) -I'll report back..
(Darn it! I took another chip!)
Edit, It seems the "ms delay" setting was key to getting this work. I switched to "TeraTerm" under Windows which has this delay setting, and it seems to be accepting the code now.
Jeff
I went through the same thing until I found the line delay setting in TeraTerm.
In the past when I've looked into Forth and Forth-like languages I always found it interesting, but I always ran into a wall when I wanted to try Forth for the stuff I normally do in some high-level language on the computer.. writing emulators and data processors. Forths in general won't seem to let me work that way, with programs taking input from files, letting me edit source in my editor and so on. But with a QS I can as well do the interactive thing, as there's no operating system or filesystem there anyway.. so I'll have a go at it this weekend.
-Tor
This makes it simpler, but needs the user to be aware how this works to avoid the issue. This one design decision that is different from other implementations.
Also, the compilation in-line is very deliberate and can and will perform a lot faster than all that multiple buffering that goes on with serial buffers, terminal input buffers etc. The main offender at present is not having a dependable method of handshaking as some terminals support XON/XOFF and some don't. Putting in a longer line delay means it takes 5 seconds instead of 1 or 2 to compile a file, hardly anything to lose sleep over. In the end runtime speed is far more important which Tachyon cannot be faulted for, especially in the area of I/O and common operations which is where an MCU needs to perform. If that's a temporary tradeoff then I'm certainly happy with that
It is really cool how far you've come in such a short time. Clearly you don't waste as much time watching TV as some of us.
I started with Chris Savage and Jeff Martins spin code from 2006 in v 1.5 of the Ping manual.
Initially all I did was 'transcribe' the Spin code to Tachyon Forth and get it, first, to run ... and, second, to run right! It did, then I settled down to smooth it out and comment it.
One neat set of words that were very useful were NEWCNT and LAPCNT ... check them out, buried in the kernel.
So where I can and as long as it doesn't compromise Tachyon itself I have been renaming or creating aliases of functions so that they are more familiar to Spin (and C) users but of course taking into account the RPN stack notation. Here's a snippet of LCD code that uses ++ and ~ and pub etc, even LOOKUP in a slightly different form:
pub LCDHOME ypos C~ '' clear y line position xpos C~ '' clear x character position 2 LCDCMD '' Raw home command for LCD 1 ms '' Just give the LCD time to execute it ; pub LCDCLS '' Clear the LCD screen 1 LCDCMD '' Raw LCD command to clear it's screen 1 ms '' The only command that you really need to wait for LCDHOME ; pub LCDCR '' Carriage return xpos C~ XYCUR '' Return to X position zero and update LCD's cursor ; pub LCDLF '' Line feed ypos C++ ypos C@ #lines => '' Wrap-around to the top of the display? IF ypos C~ THEN XYCUR '' Update the LCD's internal cursor ; pub LCDCHAR ( char -- ) '' Treat character as data LCDDAT xpos C++ '' increment character position xpos C@ chars => '' and wrap to next line if necessary IF xpos C~ LCDLF THEN ; pub LCDchar ( char -- ) 0 REG C@ LCDCHAR '' Restore character and pass as a character to the LCD ; pub LCDCtrls ( ctrl -- ) '' Look up and execute the code that corresponds to the ctrl character $10 LOOKUP LCDchar { Default vector if above limit of $10 } LCDchar LCDHOME LCDchar LCDchar LCDchar LCDchar LCDchar BEEP LCDchar LCDchar LCDLF LCDchar LCDCLS LCDCR LCDchar LCDchar ; pub LCDEMIT ( char -- ) '' Process the ASCII character either as a control or as a printable character DUP BL < '' Less than a BLANK ($20) is a control character IF DUP 0 REG C! LCDCtrls ELSE LCDCHAR '' else it is display data THEN ;Don't know if you're open to this, but it got me thinking....
I hear Go language compiler also compiles C code. The Go language terminal utility example Sal wrote uses the host PC's OS functions, so it gives tab completion, command history, command line editing, stuff like that for free. And it provides the channel interfaces, so the PC app can talk directly to the prop over a fast channel, if you chose to expand in this direction...
Like my script for the Ping, my PIR code is a transcription of Josh Donelson's SPIN code to Tachyon Forth.
**** The code in PIR.ZIP is good under kernel 120815.0930 ****
**** The code in PIR2.ZIP is good under kernel 120820.1445 ****
Enjoy!!
I the new code for the SD card, in the top of the file you have a iomask constant for "Card Detect" called ".CARD"
Then down around line 179 you have a word defined ".CARD" ... Is this a problem?
Also I have several Prop Platform USB boards with microSD slots on P0 to P3 with CS, DO, DI, and SCLK, but no Card Detect. How difficult to adapt the code? I was looking it over, searching against ".CARD" (that's how I found the dual definition) and a first glimpse it doesn't look too tricky to excise CD code ... am I missing anything critical?
Brian,
I took the liberty of porting your wonderful PING.fth for Tachyon to PropForth and posted it to the PropForth 5.0 thread here. I don't want it to feel left out since everyone is playing with the new kid. (Sibling rivalries and all that!
I'm going to do the PIR next, when I get more play time if there are no objections.
Thanks for the words!
Since I don't use the card detect switch I never noticed it
My detect routines assume you have not used the seemingly obligatory pull-up resistor on the chip select line then you can use this routine to detect whether a card is present or not
: CD? ( -- flg ; Is SD card present? ) ON SDCS '' Force CS line low .SDCS INPUTS '' Float CS .SDCS IN '' Is it still low or has it been pulled up (by the card's pullup) OFF SDCS ;So as you can see the card detect switch is not being used as I rely on the documented CS pull-up that is present on SD cards internally. If you have a pull-up to the CS line on your board then disconnect it.
Here's a schematic of the SD hookup that is used in the code (although I have many others I test as well).
L6470 Microstepper code for dual motors - L6470 1V1.txt
The SD card "toolkit" has been up and running but I am still doing some more tests with various cards before I add on the full virtual memory and file system extensions. At the moment it's very useful for investigating SD cards and you can even backup the hub ram directly into the SD card as if it were just a very large SPI memory chip (and unless you want to use it in a PC, who cares). It's possible to do bitmap screen updates at around 20 fps with this method which just uses a PASM kernel routine for bit-bashing SPI. I might look at the counter approach later on once functionality is fully established (so 60fps would be possible!). BTW, I favor non-fragmentation of files as it simplfies file access and makes them far more efficient. Sometimes I even create one big non-fragmented file which may hold lots of smaller files. Certainly many of my logging files preallocate a large chunk as non-fragmented so that it becomes a simple virtual memory and avoids all those traditional and cumbersome file access methods. The virtual memory address is the handle and the virtual memory access words hide the caching and flushing etc.
Now there's also a lot of peripheral chip interfacing that I'm doing but let me know if there are any special requests as I will be testing and releasing this source daily.
Do you have experiance to communicate with a mcp3004/3008 or mcp3208
Thanks in advance.
Jan
Another thing I dont get fix is to output a PWM signal on a specific pin.
Do you have an example in TACHYON
Thanks in advance,
Jan
The kernel spin file starts things up and then terminates COG 0. Comments there led me to think that COG 0 would be available in addition to COGs 4..7 ... and then what about COG 3 if VGA is not compiled in, or you manually turn off VGA?
So is the RUN method hard coded only to accept 4..7 or are 0 and 3 also acceptable ?
... and the answer is 4..7 only, a request for 0 or 3 executes but nothing
Propeller .:.:--TACHYON--:.:. Forth V1.1 rev120827.0200 TACHYON Propeller .:.:--TACHYON--:.:. Forth V1.1 rev120827.0200 ok : TASK1 ( -- ) BEGIN 0 MASK OUTSET #500 ms 0 MASK OUTCLR #500 ms AGAIN ; ok : BLINKY 200d FOR 0 MASK OUTSET 100d ms 0 MASK OUTCLR 100d ms NEXT ; ok END End of source code, there were 0 errors found CODE @$3E9D - bytes used in this load = 39 NAMES @$1DCB - bytes used in this load = 17 YCALLS @ 180 entries free ok NOVGA ok ok ' BLINKY >PFA 3 RUN ok . ' BLINKY >PFA 7 RUN ok 7 STOP ok ' BLINKY >PFA 0 RUN okTHAT"s IT for COG 5 ... you can issue this, " ' BLINKY >PFA 5 RUN " until the cows come home and it isn't going to blink, because it never gets back to that SPIN initialization in COG 0 where the Tachyon VM idle loop is called for COG 5 "cognew(@RESET, @IDLE)"
Now maybe I have made the mistake of loading my expectations on to your project, but it seems to me that being able to start a cog with a task and then stop it and run yet another task and maybe go back to the first task or on to a third or fourth one is what we've come to expect from Prop based systems.
Do you want PWM or duty mode DAC?
If it's a duty mode DAC then that's real easy, you can even do that in interactive mode as you have direct access to the counter registers. Just type this in:
#11 APIN
DUTY
To get a square wave (50%) type:
$8000.0000 FRQ
To get 25% type:
$4000.0000 FRQ
To make that into a convenient word say as an 8-bit DAC:
pub DAC! ( level -- )
#24 SHL FRQ DUTY
;
The pin can be specified once as shown above or changed on the fly. By default the A counter is accessed but you only have to type in "B" to change it like this:
B #12 APIN
$40 DAC!
Which will set pin 12 to use counter B with a 25% duty cycle.
Now if it's PWM (fixed frequency) you need then normally we dedicate a cog to looking after that (plus other things). That's not so hard either but this duty mode is simple and normally what you would use if you had an RC network to filter it to a voltage.
It's easy enough to use cog 0 but why bother as we already have 5 cogs running a Tachyon VM and I might want another one for an object from the OBEX (maybe). Each cog has an "run" vector but unless all cogs are runnning Tachyon (possible) they won't all be needed. At startup cogs 4 to 7 are loaded with the VM but told to execute an IDLE loop which just waits for it's run vector to come alive. Once it's off and running there is not much in the way of control that we have with these little cogs but that's the way the Prop is. You can stop them but you can't restart them unless you do another coginit which I can do but it's only necessary when you are mucking around testing and it's easier just to reset the Prop (^C or <break>).
However, I could make the IDLE loop kill the vector before it runs the user code, then call the code so that if it returns it will be back to idle. I will check this method out.
EDIT: Just changed it so that it clears the vector when taken and if you exit your code it will wait back in the IDLE loop
EDIT: The solution should have taken 5-10 minutes once I hooked up the pcb except I forgot that this board had a deliberate and hidden short between the Din and Dout of the chip and I was wondering why I kept reading back 0's until I decided to float the MOSI from the Prop after the first 8 bits. Anyway it's working now, there's both a fast and slow method. I checked it on my old pill counter sensor pcbs which use 1" photodiodes connected to opamps and into the MCP3208. It's all working well.
Before I was running a "BEGIN..AGAIN" loop with no exit and stopping it was simple matter of "<cogid> STOP" With a foreground processes you test a "KEY?" to break a loop. Is there a way to send a cog a character? Or do we do it the old fashioned way cog abort flag in hub ram?
Question: you said you made a change for multi-tasking several hours ago "Tachyon1v0-VGA.spin" was altered 4 hours ago and "Tachyon1v1-VGA.spin" 20+ hours ago. Did you mean to alter v1.0 or v1.1 ????
Here's what my blinky looks like: Now when I type:
1 4 RUN
where 1 is a "command" for cog 4 the loop will terminate and I can get control of it once again in the idle loop. This is also a neat way to pass commands to the cog if it is setup to process them like this:
So blinky will start off with a fast blink, but now:
#200 4 RUN
will cause it to slow blink