many thanks a lot for all the hints. I will make first tests from April 3, have to do some other jobs before :-(
I will also try to contribute something to the documentation...
We checked out the smart quotes fix, made the changes, and started generating a new release archive.
Since this is just a corrected Propforth.htm file, the release will still be v 5.0, but with a new date.
This should be available around Tuesday this week.
Thanks to Duane C. Johnson for reporting the issue, and to mindrobots (Rick) for figuring out the solution!
The documentation and everything associated with PF5.0 look great! Can't wait to get started. Can't believe how well this has been adapted to the Prop! I seem to recall that initially there was some question about whether the Prop was suitable for Forth at all. Things certainly have moved on from THAT!
The current instructions steer beginners away from using the EEPROM and SD versions of the code. So, within the beginner's implementation, is there any way to save user-defined words except ephemerally?
The saveforth word will write an image of your current forth (including any words you created) from RAM back to EEPROM. Once you do this, all your new words become permanent until you F11 a new kernel into the chip.
Hi.
I re-write 2_wire_LCD(8bit control) to 2_wire_LCD(4bit control).
lcd_demo2 take 8seconds on 2_wire_LCD(8bit control).
lcd_demo2 take 14seconds on 2_wire_LCD(4bit control).
... PF5.0 look great! I seem to recall that initially there was some question about whether the Prop was suitable for Forth at all.
Phrases similar to "forth is not viable on the prop", "never do anything useful", and such were common, just as "man is will never fly" used to be common. So it was inevitable.
Sal's pretty sharp, and knows the inner working of most major languages and many processors, and selected the "proper tool" for the particular platform, for his needs.
EEPROM and SD versions of the code.
beginner's implementation, is there any way to save user-defined words except ephemerally?
The saveforth word will write an image of your current forth (including any words you created) from RAM back to EEPROM. Once you do this, all your new words become permanent until you F11 a new kernel into the chip.
As mindrobots said, in the non-SD non-EEPROM developers kernel propforthDevBootKernel.spin, the SAVEFORTH word reads the current dictionary from RAM and writes it into EEPROM.
NOTE that this only takes the CURRENT definition of each word, if you redefined FOO is only takes the most recent definition, so the kernel is minimal after SAVEFORTH. Be sure all your words are debugged before doing saveforth (or learn the hard way that one isn't like I do)
SAVEFORTH is purposely REMOVED from SD and EEPROM versions, it would whack the kernel (in most cases, I don't know all the details); this is why the BOOT.F is called on reboot in SD and EEPROM versions, to auto load your bazillion scripts and get you application(s) going.
The REALLY interesting stuff is scheduled to come up Sunday, if Sal was not too sick this week. The next bit should bring together and begin completion of all the previous work to this point.
So even the beginner's version presumes/requires a 64KB EEPROM? Or is it the 32KB boot block which is rewritten with SAVEFORTH?
The basic developer kernel will run on ANY propchip regarless of EEPROM size including 0K EEPROM (see ROMLESS tutorial);
SAVEFORTH will work with ANY stock EEPROM, 32K to 64K, and will work with correct larger EEPROM configurations. Yes, it writes (only) the 32k boot block.
EPPROM, SD, and SAVEFORTH versions can be combined every which way by the user, (they were in previous versions) but that starts getting a little advanced so we dumbed it down since I had so many problems keeping it all straight. I didn't earn this BRAIN?-NO! name for nuthin'!
I think the cat already has his head sticking out. I think you should elaborate!
Intriguing, too, is what Sal might reveal Sunday. Prof_B, do you want to come clean? Are you in a position where you can divulge more?
Sorry, did not mean to be cryptic. This is the GO language support for integrating prop as sensor actuator level to PC as number cruncher/communications/display/storage services. per http://forums.parallax.com/showthread.php?138412-GO-language-amp-Hoare-CSP-Channels/ (not to cross post or anything, this is in response to a direct question)
The first use of which will be automated testing, to speed up bring the existing forth extensions to version 5.0
The GO stuff is in a separate thread because we anticipate the majority of future CSP work will be done by the REALLY smart folks, independent of language or processor.
Hmmm... Since I wanted this to be all Prop-based, I have been creating something similar to Jeff Martin's Serial Terminal to run on one Prop, and installing Propforth on a second Prop. Is this not going to work?
Looks like I'll need to dig into JupiterACE. It is brand-new to me.
EDIT: CSP Channels... Dang! I'm a total bunny. Will go to your other thread and figure out what is going on!
If it this one http://obex.parallax.com/objects/457/ it needs a PC to talk to, I think. But you can do it all on one prop chip with propforth. Including running off a single prop chip with no PC, or running multiple propchips as a single big prop chip, with or without a PC (just needs a little more effort to set up).
What equipment have you got, and what specifically do you want to do? Netbook or Monitor? Quickstart or protoboard? Run propforth (+ PASM) or integrate with SPIN objects?
It all starts and ends with requirements.
PS -JupiterACE (Demoboard) + monitor + keyboard versus netbook + quickstart are the two simple options
What equipment have you got, and what specifically do you want to do?
Well, I've got everything. But this particular project was inspired by a discussion that g3cwi began, where he wanted an inexpensive and minimal platform to take on holiday. His question, and your response, got me thinking that I'd like to make a Forth system that uses just a PS/2 keyboard, a VGA monitor, and however many propellers are necessary. (In other words I'm specifically abandoning the laptop, the netbook, the notebook, and the tablet.)
But I think you've answered the question pretty well - that I ought to start with JupiterACE rather than my own homebrewed prop-based terminal object.
Forth? Does this have some advantages over the native Spin?
Not unless you are interested in the stuff that forth provides. The propforth kernel is just a spin program that sets up the (assembler program that is the) forth kernel. SPIN interprets every step that's executing, FORTH is interpreted only once when the definition is added to the dictionary, and executes as assembly. Its a bit faster than spin in some cases.
Once installed, one no longer needs to deal with spin or the proptool (until one wished to change and reload the initial kernel). Forth tend to be seen as a "universal, interactive assembler" interface, except easier. This is not for someone that prefers to program in spin and/or doesn't care about speed, efficiency, minimalism, flexibility, and small memory footprint.
Propforth and forth in general allow interactive development on the processor itself, bypassing the traditional code-compile-download-burntoprom-execute-test cycle with forth's code-execute-test cycle. the idea is we get 1-10x more experiment iterations in the same wall clock time. Also, we don't need a JTAG interface or separate compiler or emulator etc, which means we don't need a fancy expensive workstation and other additional hardware for development we get the same (very fast) performance with the smallest dumb terminal. This is of no concern to the typical C coder, which has already spend the money for the best workstation, and has less limited resources; a similar model applies to SPIN. Also, folks that already know SPIN (or C or anything else) typically have already invested in learning that language/environment, and wish to leverage that.
On the other hand, folks that have limited budgets and time can learn the much simpler forth and become expert in about the same time (five to ten years) with much lower cash expense.
The biggest advantage is forth lends itself well towards "minimum necessary and sufficient to accomplish the task" and is fun (If you like that kind of thing).
many thanks a lot for all the hints. I will make first tests from April 3, have to do some other jobs before :-(
I will also try to contribute something to the documentation...
Markus
So ok now its April 15..
Short question, i am just modifiing the
PropForthBootOptimzeAsmSrc.f
for expanding the serial comunication.
I must add about 10..20 lines of assembler.
Is it necessary to allocate some additional memory for this code?
Or does this PropFprth for me?
I must add about 10..20 lines of assembler.
Is it necessary to allocate some additional memory for this code?
Or does this PropFprth for me?
This is eventually going to be in the propforth.htm doc. The intention is that the users will drive the documentation by these questions and the ensuing conversation. That it, please write it down when you get it to work, and we will add it to the docs.
So anyway, I haven't mastered this myself, caskaz and Nick Lordi are the experts, up there with Sal, but with different method and intent.
But here's what I got:
* Follow the tutorials in tutorial-8.x (you must determine which tutorial is closest to your target).
* Notice the bits about
"8. Compare the output of spinmaker to PropForthOptimizeBootKernel.spin (kernels) (where the dictionary starts, (I use windiff) this verifies the code base is reproducable, (may be some differences in some variable values, such as fl_in, or the first long in any assembler definitions, this is OK) If you are recompiling recompile, trim add 0's at end of file as required, goal is to get maximum number of longs. Spin require 16 free longs, so pad/trim to that goal."
You have to edit the source and add or trim the 0's at the end of the file. "Till it comes out right" is a crappy explanation, but that's all I got right now.
If you can recompile, and your result can be used to recompile AGAIN and get an identical result, its right.
Sorry this explanation is weak, others please jump in and fill in the details.
Please take a look, and send any comments or feedback. We would like to include a selection of user's favorite extensions in the download archive, this is the first pass. If there is anything you would like to add, please post!
This is relevant to the general propforth thread. The GO CSP channels will soon be a main feature of propforth.
This was the remaining function to be implemented in order to provide automated regression testing. Y'all will want to check this out. This ROCKS
Moving forward, the intent is to automate the regression suite so that anyone and everyone can run the full regression suite in the background in a couple of minutes, after any change.
The first benefit is that the regression test will take minutes instead of weeks. The second benefit is that we will be able to tell immediately if any given change breaks anything in the entire propforth domain, from kernel to final application. This is important as this tech is usually insanely expensive and cumbersome. And now we will have it!
Dang you, Professor Braino and your evil companion Sal!!!!
As predicted, my first order of business today when I got to work (in the early quiet of a Monday morning) was to try this.
Your instructions worked on my Win7 system as I hit all the highlighted steps (skipped all the EMACS gobledygook). The only small change I found was in the section for setting up the CSP channels between GO and PropForth, when it comes to compiling muxterm, you have "go install muxterm" and it had to be "go install gomuxterm" on my system. The source directory is 'gomuxterm'
Everything else worked like a champ!!
Once I was presented with the IP addresses, a flicker went off in my brain and I turned to my trusty Linux laptop sitting, waiting its turn at GO/Forth fame and did a telnet to my windows system to port 4000 on the indicated IP and lo and behold, I was talking to my Propeller's Propforth session.
I didn't know I was getting a way to expose my serially connected Prop to the Internets with this little exercise! VERY COOL!!!!
No I have Go code to look at, PropForth to play with and a whole new world of CSP out there to explore!! I'm still having trouble wrapping my little head around all thsi means but it is an excellent addition to the Prop toolbox!!!
Now, I need to reshuffle my week's priorities because SOMEONE has placed the new, shiny thing in front of me and it's called GO FORTH CSP!!
Thank you for contributing once more to my time management issues!!!!
(SERIOUSLY, go try this, it is UBER COOL!!!)
I forgot to add it is VERY slow and brings back nostalgic memories of TTY and 300baud modem connections as you watch the letters from a response PAINFULLY form on your screen. But then it's better to be slow than IMPOSSIBLE!!
P.S. Hopefully, I have some time for LINUX testing before anybody realizes I'm not really working!!
when it comes to compiling muxterm, you have "go install muxterm" and it had to be "go install gomuxterm" on my system.
The source directory is 'gomuxterm'
Would you do me a big favor and see if you can make that correction on the instruction page? I tried to give all the guys permissions, but I don't see much editing going on, and I think it might be broken (I play with it while I was sick and well never mind).
I didn't know I was getting a way to expose my serially connected Prop to the Internets with this little exercise! VERY COOL!!!!
Ermm about that, please make sure your behind a firewall or something, does anybody know if this is a security issue and how to fix it? The braino lab has three firewalls, they are mostly to keep stuff from escaping; I just physically pull the wire out when things get out of hand.
I forgot to add it is VERY slow and brings back nostalgic memories of TTY and 300baud modem connections as you watch the letters from a response PAINFULLY form on your screen. But then it's better to be slow than IMPOSSIBLE!!
The SLOW is by design, on the prototype its BYE transfer with ACK for every byte over serial, so this is that absolute worst case . Sal will implement streaming so its one ack per line, then over ethernet so that stuff is done by the hardware (spinerette/WIZ8500). Step by step, as they say, until we can connect all 32 channels to 32 cogs on 5-32 props, and/or various workstations etc.
Ideally, somebody will eventually step up with a big stack of props so we can experiment on s'load all connected into one massive app, but I don't know what such an app would do. But it should allow us to connect physically remote workstations into the app, as if it were in the same box.
Ermm about that, please make sure your behind a firewall or something, does anybody know if this is a security issue and how to fix it? The braino lab has three firewalls, they are mostly to keep stuff from escaping; I just physically pull the wire out when things get out of hand.
YES! It is a security issue at least on your LAN segment. If you are behind a router to the Internet and don't have your router doing any port forwarding, you should be OK if you trust those that share your local segment. When I had the Prop and gomuxterm running on my Win7 system, I had no problem doing telnet from Linux to it. When I had it running on the Linux box, I couldn't telnet from Win7 to Linux. I believe Linux out of the box is a little less tolerant on who it lets in to chat it up. I need to do more playing here. In this case, your hosting workstation should grant/deny local access to the Prop(s). It's a local resource that it should control.
The SLOW is by design, on the prototype its BYE transfer with ACK for every byte over serial, so this is that absolute worst case . Sal will implement streaming so its one ack per line, then over ethernet so that stuff is done by the hardware (spinerette/WIZ8500). Step by step, as they say, until we can connect all 32 channels to 32 cogs on 5-32 props, and/or various workstations etc.
It seems faster on Linux.....but I'm sure that's just an illusion due to soem psychological bias in my brain.....
Ideally, somebody will eventually step up with a big stack of props so we can experiment on s'load all connected into one massive app, but I don't know what such an app would do. But it should allow us to connect physically remote workstations into the app, as if it were in the same box.
I'm working on my "Stack O' Props" but somebody distracted me with a bright shiny toy named CSP/GO/FORTH!!
Speaking of Linux, I go things running there without major effort or problems.
0) I skipped over all the emacs stuff. I use GEDIT with a termial tab at the bottom.
1) Install the new Go package as instructed by the folks at golang.org
(I ended up putting my Go in /opt/go)
2) I downloaded the mygo.zip from the PropForth downloads and unzipped it into my code directory (/home/rapost/code/go)
3) I updated my .bashrc as follows:
export GOROOT=/opt/go
export GOPATH=/home/rapost/code/go:/home/rapost/code/go/mygo
- at this point, I bounced out of and back into terminal to get all my settings how I wanted them
4) cd to my code directory /code/go/mygo and was able to run goterm and gomuxterm without problems.
5) I know, please write it up for the wiki
Guess I need to go learn me some GO...and all those other languages that like to talk CSP, now!
Thanks, PB & Sal! This is quite a nifty breakthrough for integrating the Prop and a workstation. My head is starting to spin with new project ideas!!
Hi.
I tried to make 2_wire_LCD(4bit mode) by using shift register.
But initialize is incomplete.
For example 41(hex) lcd_char(display "A" char), LCD display "$!".
Shift-register's data and LCD's Enable are common line.
So, I made assembler WORD"shift_out". This WORD output pulse(150nsec) on Shift-register's data(A .
LCD's Enable-pulse width is minimum230nsec.
I thought it is ok. But no good.
It seems WORD"shift_out" output $(0x24) and !(0x21), when 41(hex) lcd_char execute.
Hi.
I think I found out fault reason.
Shift-register's Qf is High at sixth clock(rise-up edge).
And then LCD's Enable is High with diode-off.
I shorted latch-pulse to 100nsec.
assembler WORD "a_shift_data"
__1
shl $C_stTOS , # 1 wc
\ set latch to Hi/Lo
if_c or outa , $C_treg2
\ clock pulse 150nsec
or outa , $C_treg1
nop
\ set _latch to Lo
andn outa , $C_treg2
andn outa , $C_treg1
modified below;
__1
shl $C_stTOS , # 1 wc
\ set latch to Hi/Lo
if_c or outa , $C_treg2
\ clock pulse 150nsec--> 100nsec
or outa , $C_treg1
\ nop
\ set _latch to Lo
andn outa , $C_treg2
andn outa , $C_treg1
But LCD accepted Enable-pulse.
I have 2 LCD. Both have same fault.
Enable_pulse_width's time seems shorter than manual value.
The biggest problem is neither Sal nor I have the same hardware, so was can't reproduce your error condition, so any feedback we can give is just speculation.
I have an LCD module, but I never got it running, too many other fish to fry. I'm not EE, so I'm worried I might hurt it, and move too slow.
Has any other forth user done any HD44780 driver? We need a common circuit so we can reproduce each others results.
Hi.
I modified curcuit and codes. Pulse-width is 500nsec.
It need 7 pulses. Not using Shiftregister's Qa.
Serial-parallel conversion is ok.
I captutered photo by executing code below;
: test1 begin 2B shift_out lcd_enable reset_sr 1 delms 0 until ;
cimg0600:
Range 2V 500nsec
upper wave is point-A("latch" data input of shiftregister)
Range 2V 500usec
lower wave is point-B("clk" clock input of shiftregister)
cimj0602:
Range 2V 500nsec
upper wave is point-A("latch" data input of shiftregister)
Range 1V 500usec
lower wave is point-C(diode P-side) on curcuit diagram.
7th pulse(lower of of cimg0600) shift out Hi to Qg-out for shiftregister.
Signal to LCD's Enable is cramped by diode during 1st to 6th pulse.
But there is pulse(point C) at 7th.
Voltage on diode-N-side leak at diode-P-side?
This don't operate.
Initialization is incomplete.
Curcuit is bad or codes is bad or both are bad?
I have no idea.
Comments
many thanks a lot for all the hints. I will make first tests from April 3, have to do some other jobs before :-(
I will also try to contribute something to the documentation...
Markus
We checked out the smart quotes fix, made the changes, and started generating a new release archive.
Since this is just a corrected Propforth.htm file, the release will still be v 5.0, but with a new date.
This should be available around Tuesday this week.
Thanks to Duane C. Johnson for reporting the issue, and to mindrobots (Rick) for figuring out the solution!
The documentation and everything associated with PF5.0 look great! Can't wait to get started. Can't believe how well this has been adapted to the Prop! I seem to recall that initially there was some question about whether the Prop was suitable for Forth at all. Things certainly have moved on from THAT!
The current instructions steer beginners away from using the EEPROM and SD versions of the code. So, within the beginner's implementation, is there any way to save user-defined words except ephemerally?
I re-write 2_wire_LCD(8bit control) to 2_wire_LCD(4bit control).
lcd_demo2 take 8seconds on 2_wire_LCD(8bit control).
lcd_demo2 take 14seconds on 2_wire_LCD(4bit control).
Phrases similar to "forth is not viable on the prop", "never do anything useful", and such were common, just as "man is will never fly" used to be common. So it was inevitable.
Sal's pretty sharp, and knows the inner working of most major languages and many processors, and selected the "proper tool" for the particular platform, for his needs.
As mindrobots said, in the non-SD non-EEPROM developers kernel propforthDevBootKernel.spin, the SAVEFORTH word reads the current dictionary from RAM and writes it into EEPROM.
NOTE that this only takes the CURRENT definition of each word, if you redefined FOO is only takes the most recent definition, so the kernel is minimal after SAVEFORTH. Be sure all your words are debugged before doing saveforth (or learn the hard way that one isn't
SAVEFORTH is purposely REMOVED from SD and EEPROM versions, it would whack the kernel (in most cases, I don't know all the details); this is why the BOOT.F is called on reboot in SD and EEPROM versions, to auto load your bazillion scripts and get you application(s) going.
The REALLY interesting stuff is scheduled to come up Sunday, if Sal was not too sick this week. The next bit should bring together and begin completion of all the previous work to this point.
Welcome, you're starting at the perfect time!
So even the beginner's version presumes/requires a 64KB EEPROM? Or is it the 32KB boot block which is rewritten with SAVEFORTH?
LOL
The basic developer kernel will run on ANY propchip regarless of EEPROM size including 0K EEPROM (see ROMLESS tutorial);
SAVEFORTH will work with ANY stock EEPROM, 32K to 64K, and will work with correct larger EEPROM configurations. Yes, it writes (only) the 32k boot block.
EPPROM, SD, and SAVEFORTH versions can be combined every which way by the user, (they were in previous versions) but that starts getting a little advanced so we dumbed it down since I had so many problems keeping it all straight. I didn't earn this BRAIN?-NO! name for nuthin'!
I think the cat already has his head sticking out. I think you should elaborate!
Intriguing, too, is what Sal might reveal Sunday. Prof_B, do you want to come clean? Are you in a position where you can divulge more?
Sorry, did not mean to be cryptic. This is the GO language support for integrating prop as sensor actuator level to PC as number cruncher/communications/display/storage services. per http://forums.parallax.com/showthread.php?138412-GO-language-amp-Hoare-CSP-Channels/ (not to cross post or anything, this is in response to a direct question)
The first use of which will be automated testing, to speed up bring the existing forth extensions to version 5.0
The GO stuff is in a separate thread because we anticipate the majority of future CSP work will be done by the REALLY smart folks, independent of language or processor.
Looks like I'll need to dig into JupiterACE. It is brand-new to me.
EDIT: CSP Channels... Dang! I'm a total bunny. Will go to your other thread and figure out what is going on!
What equipment have you got, and what specifically do you want to do? Netbook or Monitor? Quickstart or protoboard? Run propforth (+ PASM) or integrate with SPIN objects?
It all starts and ends with requirements.
PS -JupiterACE (Demoboard) + monitor + keyboard versus netbook + quickstart are the two simple options
Cheers
Richard
Well, I've got everything. But this particular project was inspired by a discussion that g3cwi began, where he wanted an inexpensive and minimal platform to take on holiday. His question, and your response, got me thinking that I'd like to make a Forth system that uses just a PS/2 keyboard, a VGA monitor, and however many propellers are necessary. (In other words I'm specifically abandoning the laptop, the netbook, the notebook, and the tablet.)
But I think you've answered the question pretty well - that I ought to start with JupiterACE rather than my own homebrewed prop-based terminal object.
Not unless you are interested in the stuff that forth provides. The propforth kernel is just a spin program that sets up the (assembler program that is the) forth kernel. SPIN interprets every step that's executing, FORTH is interpreted only once when the definition is added to the dictionary, and executes as assembly. Its a bit faster than spin in some cases.
Once installed, one no longer needs to deal with spin or the proptool (until one wished to change and reload the initial kernel). Forth tend to be seen as a "universal, interactive assembler" interface, except easier. This is not for someone that prefers to program in spin and/or doesn't care about speed, efficiency, minimalism, flexibility, and small memory footprint.
Propforth and forth in general allow interactive development on the processor itself, bypassing the traditional code-compile-download-burntoprom-execute-test cycle with forth's code-execute-test cycle. the idea is we get 1-10x more experiment iterations in the same wall clock time. Also, we don't need a JTAG interface or separate compiler or emulator etc, which means we don't need a fancy expensive workstation and other additional hardware for development we get the same (very fast) performance with the smallest dumb terminal. This is of no concern to the typical C coder, which has already spend the money for the best workstation, and has less limited resources; a similar model applies to SPIN. Also, folks that already know SPIN (or C or anything else) typically have already invested in learning that language/environment, and wish to leverage that.
On the other hand, folks that have limited budgets and time can learn the much simpler forth and become expert in about the same time (five to ten years) with much lower cash expense.
The biggest advantage is forth lends itself well towards "minimum necessary and sufficient to accomplish the task" and is fun (If you like that kind of thing).
So ok now its April 15..
Short question, i am just modifiing the
PropForthBootOptimzeAsmSrc.f
for expanding the serial comunication.
I must add about 10..20 lines of assembler.
Is it necessary to allocate some additional memory for this code?
Or does this PropFprth for me?
Regards
Markus
I have just seen
sersendbreak (n2, n1, --)
is sending a break of n clocks on the given serial interface..
so its not necessary for me to re-invent this ?
So the only thing i have to add is an:
ODD, EVEN, NO
parity switch. Thats fine.
Markus
Regards
Markus
This is eventually going to be in the propforth.htm doc. The intention is that the users will drive the documentation by these questions and the ensuing conversation. That it, please write it down when you get it to work, and we will add it to the docs.
So anyway, I haven't mastered this myself, caskaz and Nick Lordi are the experts, up there with Sal, but with different method and intent.
But here's what I got:
* Follow the tutorials in tutorial-8.x (you must determine which tutorial is closest to your target).
* Notice the bits about
"8. Compare the output of spinmaker to PropForthOptimizeBootKernel.spin (kernels) (where the dictionary starts, (I use windiff) this verifies the code base is reproducable, (may be some differences in some variable values, such as fl_in, or the first long in any assembler definitions, this is OK) If you are recompiling recompile, trim add 0's at end of file as required, goal is to get maximum number of longs. Spin require 16 free longs, so pad/trim to that goal."
You have to edit the source and add or trim the 0's at the end of the file. "Till it comes out right" is a crappy explanation, but that's all I got right now.
If you can recompile, and your result can be used to recompile AGAIN and get an identical result, its right.
Sorry this explanation is weak, others please jump in and fill in the details.
http://code.google.com/p/propforth/downloads/detail?name=DuaneJohnsonExtensions20120414.txt
Please take a look, and send any comments or feedback. We would like to include a selection of user's favorite extensions in the download archive, this is the first pass. If there is anything you would like to add, please post!
http://forums.parallax.com/showthread.php?138412-GO-language-amp-Hoare-CSP-Channels&p=1092814&viewfull=1#post1092814
This is relevant to the general propforth thread. The GO CSP channels will soon be a main feature of propforth.
This was the remaining function to be implemented in order to provide automated regression testing. Y'all will want to check this out. This ROCKS
Moving forward, the intent is to automate the regression suite so that anyone and everyone can run the full regression suite in the background in a couple of minutes, after any change.
The first benefit is that the regression test will take minutes instead of weeks. The second benefit is that we will be able to tell immediately if any given change breaks anything in the entire propforth domain, from kernel to final application. This is important as this tech is usually insanely expensive and cumbersome. And now we will have it!
This makes me smile.
As predicted, my first order of business today when I got to work (in the early quiet of a Monday morning) was to try this.
Your instructions worked on my Win7 system as I hit all the highlighted steps (skipped all the EMACS gobledygook). The only small change I found was in the section for setting up the CSP channels between GO and PropForth, when it comes to compiling muxterm, you have "go install muxterm" and it had to be "go install gomuxterm" on my system. The source directory is 'gomuxterm'
Everything else worked like a champ!!
Once I was presented with the IP addresses, a flicker went off in my brain and I turned to my trusty Linux laptop sitting, waiting its turn at GO/Forth fame and did a telnet to my windows system to port 4000 on the indicated IP and lo and behold, I was talking to my Propeller's Propforth session.
I didn't know I was getting a way to expose my serially connected Prop to the Internets with this little exercise! VERY COOL!!!!
No I have Go code to look at, PropForth to play with and a whole new world of CSP out there to explore!! I'm still having trouble wrapping my little head around all thsi means but it is an excellent addition to the Prop toolbox!!!
Now, I need to reshuffle my week's priorities because SOMEONE has placed the new, shiny thing in front of me and it's called GO FORTH CSP!!
Thank you for contributing once more to my time management issues!!!!
(SERIOUSLY, go try this, it is UBER COOL!!!)
I forgot to add it is VERY slow and brings back nostalgic memories of TTY and 300baud modem connections as you watch the letters from a response PAINFULLY form on your screen. But then it's better to be slow than IMPOSSIBLE!!
P.S. Hopefully, I have some time for LINUX testing before anybody realizes I'm not really working!!
Would you do me a big favor and see if you can make that correction on the instruction page? I tried to give all the guys permissions, but I don't see much editing going on, and I think it might be broken (I play with it while I was sick and well never mind).
Ermm about that, please make sure your behind a firewall or something, does anybody know if this is a security issue and how to fix it? The braino lab has three firewalls, they are mostly to keep stuff from escaping; I just physically pull the wire out when things get out of hand.
The SLOW is by design, on the prototype its BYE transfer with ACK for every byte over serial, so this is that absolute worst case . Sal will implement streaming so its one ack per line, then over ethernet so that stuff is done by the hardware (spinerette/WIZ8500). Step by step, as they say, until we can connect all 32 channels to 32 cogs on 5-32 props, and/or various workstations etc.
Ideally, somebody will eventually step up with a big stack of props so we can experiment on s'load all connected into one massive app, but I don't know what such an app would do. But it should allow us to connect physically remote workstations into the app, as if it were in the same box.
YES! It is a security issue at least on your LAN segment. If you are behind a router to the Internet and don't have your router doing any port forwarding, you should be OK if you trust those that share your local segment. When I had the Prop and gomuxterm running on my Win7 system, I had no problem doing telnet from Linux to it. When I had it running on the Linux box, I couldn't telnet from Win7 to Linux. I believe Linux out of the box is a little less tolerant on who it lets in to chat it up. I need to do more playing here. In this case, your hosting workstation should grant/deny local access to the Prop(s). It's a local resource that it should control.
It seems faster on Linux.....but I'm sure that's just an illusion due to soem psychological bias in my brain.....
I'm working on my "Stack O' Props" but somebody distracted me with a bright shiny toy named CSP/GO/FORTH!!
Speaking of Linux, I go things running there without major effort or problems.
0) I skipped over all the emacs stuff. I use GEDIT with a termial tab at the bottom.
1) Install the new Go package as instructed by the folks at golang.org
(I ended up putting my Go in /opt/go)
2) I downloaded the mygo.zip from the PropForth downloads and unzipped it into my code directory (/home/rapost/code/go)
3) I updated my .bashrc as follows:
export GOROOT=/opt/go
export GOPATH=/home/rapost/code/go:/home/rapost/code/go/mygo
- at this point, I bounced out of and back into terminal to get all my settings how I wanted them
4) cd to my code directory /code/go/mygo and was able to run goterm and gomuxterm without problems.
5) I know, please write it up for the wiki
Guess I need to go learn me some GO...and all those other languages that like to talk CSP, now!
Thanks, PB & Sal! This is quite a nifty breakthrough for integrating the Prop and a workstation. My head is starting to spin with new project ideas!!
I tried to make 2_wire_LCD(4bit mode) by using shift register.
But initialize is incomplete.
For example 41(hex) lcd_char(display "A" char), LCD display "$!".
Shift-register's data and LCD's Enable are common line.
So, I made assembler WORD"shift_out". This WORD output pulse(150nsec) on Shift-register's data(A
LCD's Enable-pulse width is minimum230nsec.
I thought it is ok. But no good.
It seems WORD"shift_out" output $(0x24) and !(0x21), when 41(hex) lcd_char execute.
What is wrong?
I think I found out fault reason.
Shift-register's Qf is High at sixth clock(rise-up edge).
And then LCD's Enable is High with diode-off.
I shorted latch-pulse to 100nsec.
assembler WORD "a_shift_data" __1 shl $C_stTOS , # 1 wc \ set latch to Hi/Lo if_c or outa , $C_treg2 \ clock pulse 150nsec or outa , $C_treg1 nop \ set _latch to Lo andn outa , $C_treg2 andn outa , $C_treg1 modified below; __1 shl $C_stTOS , # 1 wc \ set latch to Hi/Lo if_c or outa , $C_treg2 \ clock pulse 150nsec--> 100nsec or outa , $C_treg1 \ nop \ set _latch to Lo andn outa , $C_treg2 andn outa , $C_treg1But LCD accepted Enable-pulse.
I have 2 LCD. Both have same fault.
Enable_pulse_width's time seems shorter than manual value.
The biggest problem is neither Sal nor I have the same hardware, so was can't reproduce your error condition, so any feedback we can give is just speculation.
I have an LCD module, but I never got it running, too many other fish to fry. I'm not EE, so I'm worried I might hurt it, and move too slow.
Has any other forth user done any HD44780 driver? We need a common circuit so we can reproduce each others results.
I modified curcuit and codes. Pulse-width is 500nsec.
It need 7 pulses. Not using Shiftregister's Qa.
Serial-parallel conversion is ok.
I captutered photo by executing code below;
: test1 begin 2B shift_out lcd_enable reset_sr 1 delms 0 until ;
cimg0600:
Range 2V 500nsec
upper wave is point-A("latch" data input of shiftregister)
Range 2V 500usec
lower wave is point-B("clk" clock input of shiftregister)
cimj0602:
Range 2V 500nsec
upper wave is point-A("latch" data input of shiftregister)
Range 1V 500usec
lower wave is point-C(diode P-side) on curcuit diagram.
7th pulse(lower of of cimg0600) shift out Hi to Qg-out for shiftregister.
Signal to LCD's Enable is cramped by diode during 1st to 6th pulse.
But there is pulse(point C) at 7th.
Voltage on diode-N-side leak at diode-P-side?
This don't operate.
Initialization is incomplete.
Curcuit is bad or codes is bad or both are bad?
I have no idea.
Someone have solution?
Sorry,I upload curcuit diagram now.