Hi.
It seems to operate finely.
Curcuit is #61.
Bad reason was diode.
I used schotkey diode.
I changed normal diode(1S1588).
But this code is not perfect.
There are delay(1 delms) inside WORD"lcd_demo1" and WORD"lcd_demo2".
If these are erased, character display after "lcd_clear, lcd_pos" are skipped.
Maybe I think "reset_sr" need delay-time.
There could be lots of interactions due to hardware tolerance, circuit constructions, code errors, etc. Assuming those are NOT the cause, I would guess:
The overhead associated with un-optimized forth takes a long time compared to the assembler version. So the part has more time to swing before the program gets a chance to check the reading. Depending on when it hits the opportunity to check the part, it may or may not be at the same point it was last time. So, for the high level forth word, the region we would consider "stable" is that range of tick you observed. A range of 1000 ticks might not be close enough for measuring light of sound, but could be fine for measuring temperature change, etc.
In addition to the touch buttons, the demo has an interactive session on the virtual COM port. The interactive command line can be accessed using the Propeller Serial Terminal program, but TeraTerm or Minicom work better.
Documentation of SD card issue I'm seeing. I've attached the transcript but it's kind of long.
This is currently being done with V5.2 and fast serial but I saw same problem with V5.0 and standard serial.
Basically, thing work fine until I do a saveforth, I can reboot and hardware reset without problems. After the saveforth (I don't even add anything to the dictionary), any hardware reset or reboot causes COG5 to be left unavailable. You can try to switch the console to it but it acts like its interpreter is dead or it had something other than the interpreter started on it during the reset. All the other COGs work fine. The only way to recover COG5 is by reloading the kernel with the Propeller Tool.
Reset/Reboot sequence BEFORE saveforth:
CON:Prop0 Cog5 RESET - last status: 0 ok
Prop0 Cog5 ok
sdboot.f - initializing
sdboot.f - Loading boot.f
boot.f - initializing
SDCard size: 1,982,465 Kbytes
File System: sys
Start Block: 1
End Block: 65,538
File System Size (blocks): 65,537
File System Size (bytes): 32,765 Kbytes
File System: usr
Start Block: 65,538
End Block: 3,964,928
File System Size (blocks): 3,899,390
File System Size (bytes): 1,949,695 Kbytes
boot.f - DONE
Prop0 Cog4 ok
Prop0 Cog4 ok
sdboot.f - DONE - PropForth Loaded
Prop0 Cog5 ok
Prop0 Cog5 ok
CON:Prop0 Cog6 RESET - last status: 0 ok
Reset/Reboot sequence AFTER saveforth:
CON:Prop0 Cog5 RESET - last status: 0 ok
Prop0 Cog5 RESET - last status: 0 ok
Prop0 Cog5 ok
Prop0 Cog5 ok
sdboot.f - initializing
.
.
.
.
.
.
.
.
.
.
.
.
CON:Prop0 Cog6 RESET - last status: 0 ok
Prop0 Cog6 RESET - last status: 0 ok
I didn't insert the dots in the above to indicate omitted text - those dots actually print out on the console.
This was the same thing I was seeing with V5.0 following the same steps.
I didn't examine the details yet, but remember, the SD support is a different kernel. We aren't supposed to use saveforth with the EEPROM or SD support (It though saveforth was removed from those kernels). The use-model is to always have the same (storage equipeped) kernel, and load your extensions and applications from the EEPROM or SD. If you futz with the kernel, you can change the behavior of words needed at boot time.
After we the test automation nailed down, it will be easier to document the steps for customizing the kernels with built in support. In the mean time, we should avoid kernel changes on the storage equipped kernels and just load up from source scripts.
Ahhhh, interesting. I didn't realize that saveforth's role had changed.
Thanks for making me an issue!!! (let the grammar Nazis have fun with that one!)
So saveforth is only valid if building and saving a basic kernel and for EEPROM and SD kernels, you load your custom words at boot time through the boot.f and snoot.f files? I'm not sure I like that totally, it takes the elegant incremental development model away and makes it kind of clunky to keep adding words to the vocabulary and getting them to the EEPROM or SD and updating the boot files - lots of steps, lots of touch points, lots of places to introduce error, lots of thing to slow your development down.
No you're right. Only "PropForthDevKernel.spin" work "right";
both "PropForthEEpromKernel.spin" and "PropForthSDKernel.spin" work different in that they broke saveforth.
So we either have to fix saveforth or change the definition of "works right".
This is a temporary situation until we get the automated testing running, then we can return to the regular development process. At that point, we will be able to make changes very quickly with a very high confidence that nothing got broke.
In the mean time, we will about updating the documentation to express the situation better.
ALSO consider using the slightly more complex "execute from SD scripts" model;
where you run source from SD as scripts, and load, run and forget chunks of application via script to allow very large applications.
EDIT - think of PropForthSDKernel.spin as the "bios", the boot.f as the main application (possible a loop), and have the main application load other files from SD, that contain definition and scripts that run those definitions, then forget them after they complete.
Issue 148 update - Sal confirmed that saveforth is still supposed to work the same on v5.x. Please use the work around (execute from scripts rather than modifying the kernel with saveforth) till we get automation working. At that point it will be faster and easier to test modifications to the kernel and create new releases.
Issue 148: Thank you, PB. I'll try to wrap my tiny brain around this scripting thing. So much to learn for us old folks!! I'll look at it as an opportunity to ....well, to do something!
The Multichannel support is very stable, a test has been running continuously for a month with no failure; (a couple servos are aiming a laser pointer at various points on the ceiling); telnet in every day to check the cogs shows its very stable. There's a few more details ion the CSP-GO thread, all that information will be gathered up and included in the next propforth release.
There could be a new MyGo BETA next week or so. There should also be a 5.21 (beta) with an enhanced fl (fast load). TeraTerm would not overrun FL, but the Go from the PC would overrun. The release will require a special Go Program on the PC for the automation. So propforth will auto detect Go Channels on the PC, or drop back to (an extremely fast) regular serial.
It now should be a matter of weeks until regression test automation is ready. The automation should make it much easier to add tests and produce new kernels. This is important now. 4.0 took significant time to release; 5.0 test was longer than development.
5.3 is the next targeted public release and will include an optimized FAST LOAD. The support for GO channels got too fast, it was able to overrun the previous buffering scheme. 5.3 should be out in about in 90 days, as it takes that long to use the final code and collect bugs.
The remaining question is bout how to package channel stuff. We'll have auto regression, so it will be easier to generate and test releases, but we have to figure out how it will impact day to day use. Sal guestimates it will take about six months to bring it all together.
Please check this out, it is instructions to set up the FAST SERIAL using 8 to 32 channels to do some THROUGHPUT and SPEED tests. We would like your data and observations if you could give this a try.
We think the number of CPU's on the work station will affect the speed. We want to check if doubling the number of CPU's (using a different PC's) will increase the speed by 5%. (This means that a slow PC is still almost as fast as a fast PC). We don't have many PC's we can run the test on, if you would run this on yours it would give us perspective.
We think that doubling the number of channels (8, 16, 32 channels are valid) will decrease throughput by 30%. COG6 allocates 1K of cog RAM for the buffer, this is divided among the channels. So 1 channel gets 1K bytes buffer, 32 channels each get 32 bytes buffer. Once you get your PC set up, run the tests a couple times with different number of channels and let us know if your results agree with our guestimations.
In any case the FAST serial is buffered and optimized, and seems to be faster with 32 channels than it used to be with only 1 channel. This is still synchronous over asynchronous, so each channel is about the same as 56700 baud async. When this gets moved to the Ethernet hardware, it might be faster, as in "holy-moley!" faster.
We might be getting a new in-line assembly method. instead of forth words that are a string of jumps to other forth words as in
: word-name forth-word forth-word .... ;
it would be
:X word-name assembler-word assembler-word .... ;
It turns out that the bits of assembler can be grouped into "chunks" that are frequently used sequences. so each "assembler-word" will directly compile that series of opcodes into memory. There are lots of combination of opcode that don't make any sense, and only a few (? compared to what?) that come up often. In this method, calling the word :X starts the process, and assembler-word will lay down the sequence of opcodes. The semicolon (maybe ;X) will end the process and continue in normal forth.
This might make writing (and learning) assembly easy enough even for me.
More as this develops, Sal might have something in 5.3
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
Hey Rick
I'm stuck with linux, can you give me some pointers?
Code is at /home/oplc/Code/Gocode (per your example, which makes more sense than the instruction I posted)
This has the bin, pkg, and src from the mygo download.
The instructions indicate that only the PATH needs to be set so in .bashrc I have:
PB, I'm doing domestic chores today but when/if I get a chance to sit down, I'll sit down with my Linux laptop and see what I did. It neds some care and feeding and updating anyway.
Since i rmember it going smoothly, I have a hunch I added something someplace but didn't write it down.
Thanks Rick. Looking forward to your clues. If we can get it running I can write up the steps and make and instructions page.
Today's meeting notes:
V5.0 continues to be extremely stable, Sal's test beds have been running continuously since the release and we've seen no problems. He's been logging in and checking the cogs, MCS and everything else is solid.
The automated build is running. Its not finished, but Sal knows what its going to look like. The kernels generated as output must necessarily be identical between runs, so logs and timestamps will be saved to a separate file. The first run (and any radical change) will need to be manually examined and verified for correctness, much as we did on last public release. Once this baseline is established, subsequent runs can be analyzed for differences, and either corrected or accepted as a new baseline. This will allow LOTS of fast incremental test runs, small and easy to understand. So we have the possibility of starting with the current release (which was tested and approved) as the baseline, and just change the version string. Then incrementally apply each additional change until we get to a v5.3 for public release. It will be a couple weeks till the automated build support is complete, then we have to test and make the v5.3 release. So best case is maybe July.
Sal is trying for two more data sets for MSC / Go-channel throughput, using 4 CPU and 8 CPU. I'll try to post the results, there's a couple folks who are interested.
Sal also has done experiments with a $6.44 bluetooth module as a cable replacement suitable for MCS/Go-channels; mentioned on the wireless thread. If this works out, it would be suitable for any place a cable is used. It may be that a volume purchase could make bluetooth roughly the same cost as a cable, with comparable throughput, for any PC with a serial port.
When I do 'which gcc' and 'which gccgo' it happily informs me that there is no gcc and no gccgo installed. So I'm going to make a guess: this has something to do with the problem.
I just installed the go package per instructions, but I manually extracted the archive. Is there some automated package manager that determines the dependencies and all? I could not get 'yum' to find go, how did you do the install?
What are gcc and gccgo contributing, if the go compile is already present? I'm not so good at linux. I'm worried that too many extra packages will crush my poor little XO.
Ahh, forth on the propeller. Great stuff. I ported cforth to osx a year or two ago, and you can find it at http://sourceforge.net/projects/cforth/
It mostly works, though it still has issues I've not tried to fix yet, though I suppose I really should attempt to do so, since it would provide some helpful info for forth on the prop.
Need to get me one of those propeller boards with the web server built-in, but until I do, my quickstart board will have to do.
I'll download this one, and take a look (if I can) and give feedback where appropriate.
If I remember correctly, I just unpacked (untarred?), the release package into /opt/go and set the paths. Nothing beyond that other than setting up the env variables.
I'm not sure if gcc and gccgo play a part. From what I was reading, they shouldn't but your error message might indicate otherwise. I was looking through golang-nut mailing list for any clues last night and didn't see anything.
Can you go to the directory where the source file is: /home/rapost/code/go/src/goterm in my case and then try
go run goterm.go
I think this will run the program directly without tryning to do all the package stuff. If you still get an error, then we probably need to look at your install or see if you need gcc. A simple go program that used a go routine might be interesting to try. It appears that while go doesn't have a byte code interpreter or virtual machine to contend with, there is a runtime wrapper of sorts that goes around the program (you're not directly executing your code on the hardware). I'm wondering if the simple hello.go program doesn't cause the runtime to try something that the more complicated (go routines) goterm program causes to happen. Whenever you do that thing - BOOM!
The $3.03 Kindle book on Go programming was pretty helpful reading last night until my iPad hit me in the face when I finally dozed off. It has some language issues (grammar and such) but the content seems to be spot on.
Please be aware that propforth is not intended to be 100% adherent to any standards, as it is tailored to the prop's unique architecture. Mostly everything does what you'd expect, except CREATE is a little weird.
Since you also use C, would you be interested in looking at porting the synchronous serial drivers for MCS/Go-Channels from propforth to C on the prop? I'm sure many C folks would be interested in this. On the PC side, we already have Go-channel support in Go; there exists Python-CSP which should adapted without too much trouble, and Erlang which shows promise. The goal is to set up the common lowest level interface, so we can connect any implementation to any other implementation.
Prof B. I think we cross posted - back up a couple and this one make more sense.
Simple program using go routines. I put this into a file name goroutines.go in /code/go/src/goroutines
package main
import (
"fmt"
"time"
)
func simulateEvent(name string, timeInSecs time.Duration) {
// sleep for a while to simulate time consumed by event
fmt.Println("Started ", name, ": Should take", timeInSecs, "seconds.")
time.Sleep(time.Duration(timeInSecs * 1e9))
fmt.Println("Finished ", name)
}
func main() {
go simulateEvent("100m sprint", 10) //start 100m sprint, it should take 10 seconds
go simulateEvent("Long jump", 6) //start long jump, it should take 6 seconds
go simulateEvent("High jump", 3) //start high jump, it should take 3 seconds
//so that the program doesn't exit here, we make the program wait here for a while
time.Sleep(time.Duration(12 * 1e9))
}
from inside that directory, you can do "go run goroutines.go"
from outside that directory, you can do "go install goroutines"
[rapost@C3PO code]$ goroutines
Started 100m sprint : Should take 10ns seconds.
Started Long jump : Should take 6ns seconds.
Started High jump : Should take 3ns seconds.
Finished High jump
Finished Long jump
Finished 100m sprint
You should see output like the above.
(ignore the 'ns seconds' - something funky in the example.)
If this works, we'll need to dig into goterm.go and see what it does that's different.
I hope we can get this working for you....go is starting to grow on me!
Softcon, check also the roving networks serial wi-fi modules.
I got a RN-XV (I already had x-bee adapters), and after having configured the module I was able to run propforth from a terminal with no effort. Only changed serial pin definition in the propforth spin, because I used another pair of pins for serial communication.
Massimo
Comments
It seems to operate finely.
Curcuit is #61.
Bad reason was diode.
I used schotkey diode.
I changed normal diode(1S1588).
But this code is not perfect.
There are delay(1 delms) inside WORD"lcd_demo1" and WORD"lcd_demo2".
If these are erased, character display after "lcd_clear, lcd_pos" are skipped.
Maybe I think "reset_sr" need delay-time.
I will adjust on 2_wire_LCD_sr(8bit-mode).
I write mcp3204 code.
Forth word
disp_VR
Assembler word -- disp_VR_asm
Converted voltage(0 - 3.3V) to 0 - 999
Forth word
disp_VR (using CH0 and single mode)
Assembler word -- disp_VR_asm (using CH0 and single mode)
I tried to measure time(Hi/Lo) by forth word
Displayed Hi/Lo-time(ticks) for CS
When cs is Lo, A/D serial is sent to Prop.
Forth word
time_check
time_check <---- start forth word "Free_Run_f" Hi Lo | | 7024 168048 7024 167376 7024 167376 7024 167152 7024 167824 7024 167376 7024 167152 7024 168048 7024 167376 <---- Hit any key start assenbler word "Free_Run_a" CON:Prop0 Cog5 RESET - last status: 0 ok Hi Lo | | 1893 1038 1843 1067 1299 1067 1893 1067 1893 1067 1893 846 1893 878 1893 910 <---- Hit any key Prop0 Cog6 ok CON:Prop0 Cog5 RESET - last status: 0 okExecuted forth word "Free_Run_f"Hi-time 87.8usec(7024ticks)
Lo-time 2089 - 2100usec(167152 - 168048ticks)
Executed assembler word "Free_Run_a"
Hi-time 23 - 23.6usec(1843 - 1893ticks)
Lo-time 10.6 - 13.3usec(846 - 1067ticks)
Why Lo-time of "Free_Run_f" isn't stable?
There could be lots of interactions due to hardware tolerance, circuit constructions, code errors, etc. Assuming those are NOT the cause, I would guess:
The overhead associated with un-optimized forth takes a long time compared to the assembler version. So the part has more time to swing before the program gets a chance to check the reading. Depending on when it hits the opportunity to check the part, it may or may not be at the same point it was last time. So, for the high level forth word, the region we would consider "stable" is that range of tick you observed. A range of 1000 ticks might not be close enough for measuring light of sound, but could be fine for measuring temperature change, etc.
I wrote 1_wire_LCD(8bit-mode).
Please refering below;
http://www.romanblack.com/shift1.htm
http://code.google.com/p/propforth/downloads/detail?name=QuickstartTouchSenseBoot-PF5.0-20120506.txt&can=2&q=
In addition to the touch buttons, the demo has an interactive session on the virtual COM port. The interactive command line can be accessed using the Propeller Serial Terminal program, but TeraTerm or Minicom work better.
http://propforth.googlecode.com/files/Propforth-V5.03-20120505.zip
Examples from Propforth.htm can now be pasted into the terminal session and executed.
There are no changes aside from the update to propforth.htm
Youtube movie is demo3.
http://www.youtube.com/watch?v=F1PZPnyb1Jo
This is currently being done with V5.2 and fast serial but I saw same problem with V5.0 and standard serial.
Basically, thing work fine until I do a saveforth, I can reboot and hardware reset without problems. After the saveforth (I don't even add anything to the dictionary), any hardware reset or reboot causes COG5 to be left unavailable. You can try to switch the console to it but it acts like its interpreter is dead or it had something other than the interpreter started on it during the reset. All the other COGs work fine. The only way to recover COG5 is by reloading the kernel with the Propeller Tool.
Reset/Reboot sequence BEFORE saveforth:
CON:Prop0 Cog5 RESET - last status: 0 ok Prop0 Cog5 ok sdboot.f - initializing sdboot.f - Loading boot.f boot.f - initializing SDCard size: 1,982,465 Kbytes File System: sys Start Block: 1 End Block: 65,538 File System Size (blocks): 65,537 File System Size (bytes): 32,765 Kbytes File System: usr Start Block: 65,538 End Block: 3,964,928 File System Size (blocks): 3,899,390 File System Size (bytes): 1,949,695 Kbytes boot.f - DONE Prop0 Cog4 ok Prop0 Cog4 ok sdboot.f - DONE - PropForth Loaded Prop0 Cog5 ok Prop0 Cog5 ok CON:Prop0 Cog6 RESET - last status: 0 okReset/Reboot sequence AFTER saveforth:
I didn't insert the dots in the above to indicate omitted text - those dots actually print out on the console.
This was the same thing I was seeing with V5.0 following the same steps.
Thoughts? Ideas?
http://code.google.com/p/propforth/issues/detail?id=148
I didn't examine the details yet, but remember, the SD support is a different kernel. We aren't supposed to use saveforth with the EEPROM or SD support (It though saveforth was removed from those kernels). The use-model is to always have the same (storage equipeped) kernel, and load your extensions and applications from the EEPROM or SD. If you futz with the kernel, you can change the behavior of words needed at boot time.
After we the test automation nailed down, it will be easier to document the steps for customizing the kernels with built in support. In the mean time, we should avoid kernel changes on the storage equipped kernels and just load up from source scripts.
I'll go over this with Sal in tomorrow's meeting.
Thanks for making me an issue!!! (let the grammar Nazis have fun with that one!)
So saveforth is only valid if building and saving a basic kernel and for EEPROM and SD kernels, you load your custom words at boot time through the boot.f and snoot.f files? I'm not sure I like that totally, it takes the elegant incremental development model away and makes it kind of clunky to keep adding words to the vocabulary and getting them to the EEPROM or SD and updating the boot files - lots of steps, lots of touch points, lots of places to introduce error, lots of thing to slow your development down.
Unless I'm missing a step or tool someplace.
both "PropForthEEpromKernel.spin" and "PropForthSDKernel.spin" work different in that they broke saveforth.
So we either have to fix saveforth or change the definition of "works right".
This is a temporary situation until we get the automated testing running, then we can return to the regular development process. At that point, we will be able to make changes very quickly with a very high confidence that nothing got broke.
In the mean time, we will about updating the documentation to express the situation better.
ALSO consider using the slightly more complex "execute from SD scripts" model;
where you run source from SD as scripts, and load, run and forget chunks of application via script to allow very large applications.
EDIT - think of PropForthSDKernel.spin as the "bios", the boot.f as the main application (possible a loop), and have the main application load other files from SD, that contain definition and scripts that run those definitions, then forget them after they complete.
The Multichannel support is very stable, a test has been running continuously for a month with no failure; (a couple servos are aiming a laser pointer at various points on the ceiling); telnet in every day to check the cogs shows its very stable. There's a few more details ion the CSP-GO thread, all that information will be gathered up and included in the next propforth release.
There could be a new MyGo BETA next week or so. There should also be a 5.21 (beta) with an enhanced fl (fast load). TeraTerm would not overrun FL, but the Go from the PC would overrun. The release will require a special Go Program on the PC for the automation. So propforth will auto detect Go Channels on the PC, or drop back to (an extremely fast) regular serial.
It now should be a matter of weeks until regression test automation is ready. The automation should make it much easier to add tests and produce new kernels. This is important now. 4.0 took significant time to release; 5.0 test was longer than development.
5.3 is the next targeted public release and will include an optimized FAST LOAD. The support for GO channels got too fast, it was able to overrun the previous buffering scheme. 5.3 should be out in about in 90 days, as it takes that long to use the final code and collect bugs.
The remaining question is bout how to package channel stuff. We'll have auto regression, so it will be easier to generate and test releases, but we have to figure out how it will impact day to day use. Sal guestimates it will take about six months to bring it all together.
http://code.google.com/p/propforth/wiki/PF521BETAgomutermTEST
is for the BETA testers.
Please check this out, it is instructions to set up the FAST SERIAL using 8 to 32 channels to do some THROUGHPUT and SPEED tests. We would like your data and observations if you could give this a try.
We think the number of CPU's on the work station will affect the speed. We want to check if doubling the number of CPU's (using a different PC's) will increase the speed by 5%. (This means that a slow PC is still almost as fast as a fast PC). We don't have many PC's we can run the test on, if you would run this on yours it would give us perspective.
We think that doubling the number of channels (8, 16, 32 channels are valid) will decrease throughput by 30%. COG6 allocates 1K of cog RAM for the buffer, this is divided among the channels. So 1 channel gets 1K bytes buffer, 32 channels each get 32 bytes buffer. Once you get your PC set up, run the tests a couple times with different number of channels and let us know if your results agree with our guestimations.
In any case the FAST serial is buffered and optimized, and seems to be faster with 32 channels than it used to be with only 1 channel. This is still synchronous over asynchronous, so each channel is about the same as 56700 baud async. When this gets moved to the Ethernet hardware, it might be faster, as in "holy-moley!" faster.
THANKS!
We might be getting a new in-line assembly method. instead of forth words that are a string of jumps to other forth words as in
it would be
It turns out that the bits of assembler can be grouped into "chunks" that are frequently used sequences. so each "assembler-word" will directly compile that series of opcodes into memory. There are lots of combination of opcode that don't make any sense, and only a few (? compared to what?) that come up often. In this method, calling the word :X starts the process, and assembler-word will lay down the sequence of opcodes. The semicolon (maybe ;X) will end the process and continue in normal forth.
This might make writing (and learning) assembly easy enough even for me.
More as this develops, Sal might have something in 5.3
Hey Rick
I'm stuck with linux, can you give me some pointers?
I'm using OLPC XO, which linux 386 fedora.
Install is to /usr/local/go per the instructions at http://golang.org/doc/install
Code is at /home/oplc/Code/Gocode (per your example, which makes more sense than the instruction I posted)
This has the bin, pkg, and src from the mygo download.
The instructions indicate that only the PATH needs to be set so in .bashrc I have:
export PATH=$PATH:/usr/local/go/bin
export GOPATH=/usr/local/go/:/home/oplc/Code/Gocode
the environment variable from "go env"
GOROOT="/usr/local/go"
Hello.go will compile and run, but
"go install goterm"
gives the message
# runtime/cgo
exec gcc: exeec: "gcc": executable file not found in $PATH
I tried including various paths in HOME, PATH, GOROOT, and GOPATH, but no luck, and I'm just hacking now.
Any idea how to fix this?
Since i rmember it going smoothly, I have a hunch I added something someplace but didn't write it down.
Today's meeting notes:
V5.0 continues to be extremely stable, Sal's test beds have been running continuously since the release and we've seen no problems. He's been logging in and checking the cogs, MCS and everything else is solid.
The automated build is running. Its not finished, but Sal knows what its going to look like. The kernels generated as output must necessarily be identical between runs, so logs and timestamps will be saved to a separate file. The first run (and any radical change) will need to be manually examined and verified for correctness, much as we did on last public release. Once this baseline is established, subsequent runs can be analyzed for differences, and either corrected or accepted as a new baseline. This will allow LOTS of fast incremental test runs, small and easy to understand. So we have the possibility of starting with the current release (which was tested and approved) as the baseline, and just change the version string. Then incrementally apply each additional change until we get to a v5.3 for public release. It will be a couple weeks till the automated build support is complete, then we have to test and make the v5.3 release. So best case is maybe July.
Sal is trying for two more data sets for MSC / Go-channel throughput, using 4 CPU and 8 CPU. I'll try to post the results, there's a couple folks who are interested.
Sal also has done experiments with a $6.44 bluetooth module as a cable replacement suitable for MCS/Go-channels; mentioned on the wireless thread. If this works out, it would be suitable for any place a cable is used. It may be that a volume purchase could make bluetooth roughly the same cost as a cable, with comparable throughput, for any PC with a serial port.
My go env gives this:
If I do "which gcc", I get this:
If I do "which gccgo", I get this:
I'm trying to find out if there's a way to get a verbose listing of the install to see what's actually happening.
It's strange that the simple program works but something in the more complex fails.
When I do 'which gcc' and 'which gccgo' it happily informs me that there is no gcc and no gccgo installed. So I'm going to make a guess: this has something to do with the problem.
I just installed the go package per instructions, but I manually extracted the archive. Is there some automated package manager that determines the dependencies and all? I could not get 'yum' to find go, how did you do the install?
What are gcc and gccgo contributing, if the go compile is already present? I'm not so good at linux. I'm worried that too many extra packages will crush my poor little XO.
It mostly works, though it still has issues I've not tried to fix yet, though I suppose I really should attempt to do so, since it would provide some helpful info for forth on the prop.
Need to get me one of those propeller boards with the web server built-in, but until I do, my quickstart board will have to do.
I'll download this one, and take a look (if I can) and give feedback where appropriate.
I'll have to try your cforth for OS X. The more Forths, the merrier!
If I remember correctly, I just unpacked (untarred?), the release package into /opt/go and set the paths. Nothing beyond that other than setting up the env variables.
I'm not sure if gcc and gccgo play a part. From what I was reading, they shouldn't but your error message might indicate otherwise. I was looking through golang-nut mailing list for any clues last night and didn't see anything.
Can you go to the directory where the source file is: /home/rapost/code/go/src/goterm in my case and then try
go run goterm.go
I think this will run the program directly without tryning to do all the package stuff. If you still get an error, then we probably need to look at your install or see if you need gcc. A simple go program that used a go routine might be interesting to try. It appears that while go doesn't have a byte code interpreter or virtual machine to contend with, there is a runtime wrapper of sorts that goes around the program (you're not directly executing your code on the hardware). I'm wondering if the simple hello.go program doesn't cause the runtime to try something that the more complicated (go routines) goterm program causes to happen. Whenever you do that thing - BOOM!
The $3.03 Kindle book on Go programming was pretty helpful reading last night until my iPad hit me in the face when I finally dozed off. It has some language issues (grammar and such) but the content seems to be spot on.
The Way to Go: A Thorough Introduction to the Go Programming Language
Still working the issue as time permits. What a great way to learn!!
Please be aware that propforth is not intended to be 100% adherent to any standards, as it is tailored to the prop's unique architecture. Mostly everything does what you'd expect, except CREATE is a little weird.
Since you also use C, would you be interested in looking at porting the synchronous serial drivers for MCS/Go-Channels from propforth to C on the prop? I'm sure many C folks would be interested in this. On the PC side, we already have Go-channel support in Go; there exists Python-CSP which should adapted without too much trouble, and Erlang which shows promise. The goal is to set up the common lowest level interface, so we can connect any implementation to any other implementation.
Just a little project for your spare time
Simple program using go routines. I put this into a file name goroutines.go in /code/go/src/goroutines
package main import ( "fmt" "time" ) func simulateEvent(name string, timeInSecs time.Duration) { // sleep for a while to simulate time consumed by event fmt.Println("Started ", name, ": Should take", timeInSecs, "seconds.") time.Sleep(time.Duration(timeInSecs * 1e9)) fmt.Println("Finished ", name) } func main() { go simulateEvent("100m sprint", 10) //start 100m sprint, it should take 10 seconds go simulateEvent("Long jump", 6) //start long jump, it should take 6 seconds go simulateEvent("High jump", 3) //start high jump, it should take 3 seconds //so that the program doesn't exit here, we make the program wait here for a while time.Sleep(time.Duration(12 * 1e9)) }from inside that directory, you can do "go run goroutines.go"
from outside that directory, you can do "go install goroutines"
You should see output like the above.
(ignore the 'ns seconds' - something funky in the example.)
If this works, we'll need to dig into goterm.go and see what it does that's different.
I hope we can get this working for you....go is starting to grow on me!
I got a RN-XV (I already had x-bee adapters), and after having configured the module I was able to run propforth from a terminal with no effort. Only changed serial pin definition in the propforth spin, because I used another pair of pins for serial communication.
Massimo
I got
So I guess that it cannot find the the packages fmt and time? Do I need to install differently?