I wouldn't go as far as "bible", but it is a fun read.
All this talk of Forth has made me nostalgic. Back in the second half of the 80s I wrote the first commercial MIDI voice librarian program for DOS. It was all in Forth. I haven't had time to explore Propforth yet, but this has got me to install gforth on my Mac and play around with it a little.
So that was you! When you get warmed up, come out and play. Your skills should not lay idle! The prop and forth were made for each other. (Or at least propforth is being made for the prop )
I didn't check, but I think that
" 7 emit 0 emit 4F emit 4B emit "
gets put into cog 2's input buffer, andit executes just as if you typed it from the command line.
Unfortunately this didn't work
To make a BREAK signal (longer the one byte ) i mo dified the PropForth.spin a little bit.
In the
Asemby language serial driver
label serentryPFA i made a small cahange in the Transmit routine
' Transmit
'
transmit jmpret task1Ptr, task2Ptr
rdword txdata, v_in
cmp txdata, #$000 wz 'oo generates a break
if_z jmp #:sbreak
test txdata, #$100 wz ' wz is 1 if all bit after AND are 0 -> sending data if bit 8 is not set
if_nz jmp #transmit
mov t1 , #$100
wrword t1 , v_in ' write $100 back to addres V_in
or txdata,#$100 ' add start and stopbit
shl txdata,#2
or txdata,#1
mov txbits,#11
mov txcnt,cnt ' cnt = system counter
jmp #:bit
:sbreak mov t1 , #$100
wrword t1 , v_in ' write $100 back to addres V_in
mov txdata, #$1 ' write 1 to Txdata
shl txdata, #32 ' shift left 1 to %10000000000000000000000000000000
sar txdata, #32 ' shift arithmetic right to get $FFFFFFFF, is there any better way to get this result?
mov txbits, #32 ' reduce this number to get a shorter break now its 32 marks/spaces
mov txcnt, cnt
Modifiing strings works as followes:
: zeile c" xxx" ;
0 zeile 1+ C!
To suppress the Crlf at the output
c" test" 2 cogx
So that was you! When you get warmed up, come out and play. Your skills should not lay idle! The prop and forth were made for each other. (Or at least propforth is being made for the prop )
I had at least two dreams last night in which I was using Propforth. That's weird. I guess it means I'd better get it installed and working. :-) It's going to be a couple weeks, though. I have three choir concerts this weekend and UPEW next weekend.
I try to use serial-communication between proto(forth_master_work_02.f) and Demo(slave_work_o2.spin).
Sending from proto to demo is OK.
But receiving from demo to proto cannot receive.
Sending data(1 2 3 4 5 6 7 8 9 0) from demo to proto. (Not forth_master_work_02.f and slave_work_o2.spin)
Checking cog5's io and it is always 0x100(no data).
And I checked (0x9dc - 0xa5b) inside cog5's cogdataarea(from 0x9d8 224byte). There are datas.
How do datas get?
Do you have any ideas?
:sbreak mov t1 , #$100
wrword t1 , v_in ' write $100 back to addres V_in
mov txdata, #$1 ' write 1 to Txdata
shl txdata, [COLOR="red"]#32[/COLOR] ' shift left 1 to %10000000000000000000000000000000
sar txdata, [COLOR="red"]#32[/COLOR] ' shift arithmetic right to get $FFFFFFFF
' is there any better way to get this result?
Did you actually test this? The way it is now you'll end up with txdata == 1. If you want $FFFFFFFF then use neg txdata, #1 (or shift by #31).
I can not speak for any one else. Though for me Forth is a good language, though I prefer BASIC, Assembly, and Pascal. I thank Prof_Braino for getting me to try Forth, it has helped expand my knowledge. I have enjoyed my short lived excursion into Forth, it is back to the traditional infix languages for me now.
I often forget that not every one has the eyes to work with LQFPs with the naked eye.
LOL! I can still do that, but LQFPs don't annoy me. Teensy paragraph text does; so thanks! BTW, in cases where I've wanted to signal a whisper in the forum, I've kept the font size the same but changed the color to gray. I suppose that may have annoyed some people, too, though.
BTW, in cases where I've wanted to signal a whisper in the forum, I've kept the font size the same but changed the color to gray. I suppose that may have annoyed some people, too, though.
Even your whispers are quite loud and I've hung on to most of your words except in a few cases.
Yes, I've been annoyed, but it has been mostly a good time. You need to work on your Rhett Butler accent though.
Another question:
I have to extend the serial transmsion code at serentyPFA for a break and a parity bit transmission.
It works so far, but the SPIN compiler is compalining now, thats it is missing some long words.
I have stolen 4 longs from the wfreespacestart at the end of PropForth.spin.
Is this dangerous, or only cutting my free space for my own FORTH words?
... extend the serial transmsion code at serentyPFA for a break and a parity bit transmission.
SPIN compiler is ... missing some long words.
4 longs from the wfreespacestart at the end of PropForth.spin. Is this dangerous, or only cutting my free space for my own FORTH words?
You can take from free space as needed. BUT the kernel wants to know what it starts and stops.
When you change material in the kernel, its a good idead to re-generate the kernel using the spinmaker process as described in the documation pages. If spinmaker process can be completed successfully, you can be confident that the new kernel is correct. If spinmaker does not complete successfully, you have found your first error.
Running spinmaker is the regression test for kernel changes, as it uses most functions when recreating the kernel code.
Any idea how to send a break (2ms) ?
2 cogstop
4 5 9600 2 startserialcog
c" teststring sending " 2 cogx
\this works fine
\now i will try to send a break on TxD
4 pinlo
2 delms
4 pinhi
seems not to work, because the serilacog seems to stuck port 4
Sal's reply:
"Break functionality was not implemented in the serial driver. If it needs to be done only once,
stop the serial driver,
tx pin to out,
tx pin lo for 2 ms,
tx pin to hi,
tx pin to input,
restart the serial driver. "
So all you need to add is stop and restart serial driver;
and be sure that the pin has changed to "out" and back to "in" (<= was ommitting this step the cause for getting stuck?)
I like to extend the startserialcog word with one or two more options.
This would give me and us a very powerful tool to handle several serial devices with different protocols on different ports.
For my opinion the Propeller is a great part for all this I/O stuff, really fantastic in combination with FORTH.
Unfortunately i fear that Parallax is going now this mainstream way with Eclipse + C . This MEETO strategy i guess is not helpful, also not for entering the industrial market.
The Propeller (II) as scalable (1..n COGs) IP for FPGAs would be fantastic for this, but this is off topic here..
Hi.
I uploaded.
Serial-communication between proto(propforth) and demo(spin) looks like ok.
Hi Caskaz,
Due to my (still) poor FORTH knowledge, i can only estimate what you have done,
but as far as i can see it would be very helpful for me and others to handle incoming and outgoing serial data in
FORTH.
May ad some small more small comments to give us the chance to learn a little more about your
demo ?
All this talk of Forth has made me nostalgic. Back in the second half of the 80s I wrote the first commercial MIDI voice librarian program for DOS. It was all in Forth. I haven't had time to explore Propforth yet, but this has got me to install gforth on my Mac and play around with it a little.
Four months ago, I was able to get a used, in great condition, paperback copy of "Starting Forth" for about $22 through Amazon, you should give it a try.
I just now went to www.amazon.com and searched "starting forth leo brody" and it showed 17 used paperback copies available from various dealers, with stated condition ranging from 'used-good' to 'used-very good' and ranging in price from $3.43 to $64.00 (average about $25 plus $3.99 shipping).
thanks a lot for the comments and hints, i will study it today. The Hive project is really astonishing, a kind of "grassroot computing" or real personal computer, where you can understand every bit if you like, fantastic.
How many Prop Users are in Germany is hard to say. Would be a good question to the Parallax stuff how many percent of the Propellers are delivered to Europe.
I guess its more exotic here, then in the US where Parallax is a well introduced brand at least in the semi-professional area. Here, all the
PICs and Atmels are dominating. But i love the Propeller because i already spent to much time of my life, finding deadlocks and similar bugs with interrupts.
After ten years its time to visit Germany again, isn't it?..;-)
Hi.
I did experiments about slave-prop.
I rewrite 2_wire_LCD.
2_wire_LCD_1.3 control LCD's backlight-brightness by NCO.
Contrast is adjusted by pot.
fsload norom.f
Prop0 Cog6 ok
: bootslave 8 9 A B rambootnx ;
Prop0 Cog6 ok
: demo bootslave 1 0 e100 4 startserialcog 10 delms 4 0 term ;
Prop0 Cog6 ok
demo
Hit CTL-F to exit term
SLAVEProp8 Cog6 ok
þ
UNDEFINED WORD þ <---- Only first time Maybe this is caused by startserialcog's bug.
SLAVEProp8 Cog6 ok
Copy/paste 2_wire_LCD_1.3.f to TeraTerm
lcd_demo <---- Demo running on connected LCD to slave-prop
SLAVEProp8 Cog6 ok
<--- Enter CTL-F
Prop0 Cog6 ok
4 0 term
Hit CTL-F to exit term
lcd_clear <---- Clear on connected LCD to slave-prop
SLAVEProp8 Cog6 ok
200 lcd_dec <---- Displaying "512" at pos(0,0) on connected LCD to slave-prop
SLAVEProp8 Cog6 ok
<--- Enter CTL-F
Prop0 Cog6 ok
I think reason is startserialcog's bug(#175) maybe.
That could be the case. I't unusual that you would see it consistently, Sal said it should only happen in a very rare circumstance. The bug from #175 is fixed in 4.5
... slave-prop's clock is 98MHz. Do you think slave is operating?
I haven't messed with modifying the synchronous serial yet, I'm still figuring out the multi-channel part of it.
They say the prop should be fine up to 120MHz and higher, so that shouldn't be a problem.
As long as the master and slave can sync you should get a response. If they cannot, the slave won't load, and will stop.
So it depends on whether the slave come back with a prompt.
Comments
I wouldn't go as far as "bible", but it is a fun read.
So that was you! When you get warmed up, come out and play. Your skills should not lay idle! The prop and forth were made for each other. (Or at least propforth is being made for the prop
Unfortunately this didn't work
To make a BREAK signal (longer the one byte ) i mo dified the PropForth.spin a little bit.
In the
Asemby language serial driver
label serentryPFA i made a small cahange in the Transmit routine
' Transmit ' transmit jmpret task1Ptr, task2Ptr rdword txdata, v_in cmp txdata, #$000 wz 'oo generates a break if_z jmp #:sbreak test txdata, #$100 wz ' wz is 1 if all bit after AND are 0 -> sending data if bit 8 is not set if_nz jmp #transmit mov t1 , #$100 wrword t1 , v_in ' write $100 back to addres V_in or txdata,#$100 ' add start and stopbit shl txdata,#2 or txdata,#1 mov txbits,#11 mov txcnt,cnt ' cnt = system counter jmp #:bit :sbreak mov t1 , #$100 wrword t1 , v_in ' write $100 back to addres V_in mov txdata, #$1 ' write 1 to Txdata shl txdata, #32 ' shift left 1 to %10000000000000000000000000000000 sar txdata, #32 ' shift arithmetic right to get $FFFFFFFF, is there any better way to get this result? mov txbits, #32 ' reduce this number to get a shorter break now its 32 marks/spaces mov txcnt, cntModifiing strings works as followes:
To suppress the Crlf at the output
c" test" 2 cogx
i modified cogx a little bit:
thanks all the help, i will now progress with handling the incoming bytes.
I had at least two dreams last night in which I was using Propforth. That's weird. I guess it means I'd better get it installed and working. :-) It's going to be a couple weeks, though. I have three choir concerts this weekend and UPEW next weekend.
I try to use serial-communication between proto(forth_master_work_02.f) and Demo(slave_work_o2.spin).
Sending from proto to demo is OK.
But receiving from demo to proto cannot receive.
Sending data(1 2 3 4 5 6 7 8 9 0) from demo to proto. (Not forth_master_work_02.f and slave_work_o2.spin)
Checking cog5's io and it is always 0x100(no data).
And I checked (0x9dc - 0xa5b) inside cog5's cogdataarea(from 0x9d8 224byte). There are datas.
How do datas get?
Do you have any ideas?
Paul
Thanks, i am stupid...neg is so easy,
Kind Regards
Markus
Your small "whispering" font is hard to read. Please stop using it.
-Phil
-Phil
Even your whispers are quite loud and I've hung on to most of your words except in a few cases.
Yes, I've been annoyed, but it has been mostly a good time. You need to work on your Rhett Butler accent though.
-Phil
I have to extend the serial transmsion code at serentyPFA for a break and a parity bit transmission.
It works so far, but the SPIN compiler is compalining now, thats it is missing some long words.
I have stolen 4 longs from the wfreespacestart at the end of PropForth.spin.
Is this dangerous, or only cutting my free space for my own FORTH words?
Regards
Markus
You can take from free space as needed. BUT the kernel wants to know what it starts and stops.
When you change material in the kernel, its a good idead to re-generate the kernel using the spinmaker process as described in the documation pages. If spinmaker process can be completed successfully, you can be confident that the new kernel is correct. If spinmaker does not complete successfully, you have found your first error.
Running spinmaker is the regression test for kernel changes, as it uses most functions when recreating the kernel code.
Sal's reply:
"Break functionality was not implemented in the serial driver. If it needs to be done only once,
stop the serial driver,
tx pin to out,
tx pin lo for 2 ms,
tx pin to hi,
tx pin to input,
restart the serial driver. "
So all you need to add is stop and restart serial driver;
and be sure that the pin has changed to "out" and back to "in" (<= was ommitting this step the cause for getting stuck?)
I have to handle i quite curious protocol (its British ;-) ) where the maximum time between the break and the next sign is restricted.
The other things is, that i have to handle ODD parity in this protocol. So i am just extending the serial driver with some small add. features (as it was already done by
Ken Peterson http://forums.parallax.com/showthread.php?106657-Odd-Parity-Device-and-Hex-Strings&p=752143&viewfull=1#post752143 3 years ago).
I like to extend the startserialcog word with one or two more options.
This would give me and us a very powerful tool to handle several serial devices with different protocols on different ports.
For my opinion the Propeller is a great part for all this I/O stuff, really fantastic in combination with FORTH.
Unfortunately i fear that Parallax is going now this mainstream way with Eclipse + C . This MEETO strategy i guess is not helpful, also not for entering the industrial market.
The Propeller (II) as scalable (1..n COGs) IP for FPGAs would be fantastic for this, but this is off topic here..
Regards
Markus
I uploaded.
Serial-communication between proto(propforth) and demo(spin) looks like ok.
Hi Caskaz,
Due to my (still) poor FORTH knowledge, i can only estimate what you have done,
but as far as i can see it would be very helpful for me and others to handle incoming and outgoing serial data in
FORTH.
May ad some small more small comments to give us the chance to learn a little more about your
demo ?
Greetings from Germany
Markus
I upload textfiles.
I think sals_sample.txt is useful for you.
HIVE group is nice, there are many prop-user in Germany?
I had been for 2weeks in G
Four months ago, I was able to get a used, in great condition, paperback copy of "Starting Forth" for about $22 through Amazon, you should give it a try.
I just now went to www.amazon.com and searched "starting forth leo brody" and it showed 17 used paperback copies available from various dealers, with stated condition ranging from 'used-good' to 'used-very good' and ranging in price from $3.43 to $64.00 (average about $25 plus $3.99 shipping).
I hope this helps.
Maybe not "bible," but as a widely recognized starting point for the Forth language it is as close to what "K & R" is to the C language as we have.
thanks a lot for the comments and hints, i will study it today. The Hive project is really astonishing, a kind of "grassroot computing" or real personal computer, where you can understand every bit if you like, fantastic.
How many Prop Users are in Germany is hard to say. Would be a good question to the Parallax stuff how many percent of the Propellers are delivered to Europe.
I guess its more exotic here, then in the US where Parallax is a well introduced brand at least in the semi-professional area. Here, all the
PICs and Atmels are dominating. But i love the Propeller because i already spent to much time of my life, finding deadlocks and similar bugs with interrupts.
After ten years its time to visit Germany again, isn't it?..;-)
Regards
Markus
I did experiments about slave-prop.
I rewrite 2_wire_LCD.
2_wire_LCD_1.3 control LCD's backlight-brightness by NCO.
Contrast is adjusted by pot.
fsload norom.f Prop0 Cog6 ok : bootslave 8 9 A B rambootnx ; Prop0 Cog6 ok : demo bootslave 1 0 e100 4 startserialcog 10 delms 4 0 term ; Prop0 Cog6 ok demo Hit CTL-F to exit term SLAVEProp8 Cog6 ok þ UNDEFINED WORD þ <---- Only first time Maybe this is caused by startserialcog's bug. SLAVEProp8 Cog6 ok Copy/paste 2_wire_LCD_1.3.f to TeraTerm lcd_demo <---- Demo running on connected LCD to slave-prop SLAVEProp8 Cog6 ok <--- Enter CTL-F Prop0 Cog6 ok 4 0 term Hit CTL-F to exit term lcd_clear <---- Clear on connected LCD to slave-prop SLAVEProp8 Cog6 ok 200 lcd_dec <---- Displaying "512" at pos(0,0) on connected LCD to slave-prop SLAVEProp8 Cog6 ok <--- Enter CTL-F Prop0 Cog6 okIs there more info in this? We are testing v4.5 for public release, I want to make sure all the old stuff is fixed and in there.
This error always occure on my protoboard.
Using propforth4.0a.
I think reason is startserialcog's bug(#175) maybe.
Changing line 209 On norom.f :
0 L@ 4 rshift setHzb ---> 0 L@ d u/ setHzb
I think slave-prop's clock is 98MHz.
Do you think slave is operating?
That could be the case. I't unusual that you would see it consistently, Sal said it should only happen in a very rare circumstance. The bug from #175 is fixed in 4.5
I haven't messed with modifying the synchronous serial yet, I'm still figuring out the multi-channel part of it.
They say the prop should be fine up to 120MHz and higher, so that shouldn't be a problem.
As long as the master and slave can sync you should get a response. If they cannot, the slave won't load, and will stop.
So it depends on whether the slave come back with a prompt.
I translated dwd_jm_quickstart_demo110610i.spin to forth-code.
And I add 24C512 to QuickStart board.
HEY! I was going to do that! You beat me to it!
Thanks for post, I'm still busy with the v4.5 regression test for release later this week(?).
Don't forget to call and ask for a 64k version!
http://forums.parallax.com/showthread.php?132191-WARNING-Quickstart-board-has-a-32K-EEPROM-not-a-64K&p=1009316&viewfull=1#post1009316