Bit of a delay on Sundays notes. I seem to be coming down with another job, and its interfering with projects.
Notes from Sunday's call
Latest Release still seems stable. The build system is "mostly bullet proof". The test automation has occasional variances dues to time stamps, undefined I/O pins etc; but should be livable. Sal is including a "Misc" directory, with support for stepper, bmpo85, double float, unix time. One more step before public release is for braino to run through the package one more time, to confirm everything is as planned. After that, Sal will cut over to the new code, and cut out the old code. We might be able to make a public release for 5.3 at that time. A task still remaining is to revise the existing tests. It looks like this will most be ADDING new tests for everything in the code base, but it might trigger changes to existing tests. Sal might let us revise the tests AFTER the public release, in the interest of getting the 5.3 out sooner. Normally I would say this is risky, but Sal has demonstrated repeatedly that when he thinks the code is stable, it really is pretty stable. In any case more regression tests will be added, it might be a flood. This is good, as these are the examples for how to use the propforth tools.
With Sal's focus on kernel development winding down, he has some time to look at Tachyon. Peter has made different design decisions in Tachyon from Sal's for PropForth, so the compare and contrast is interesting. Basically, Tachyon is newer, and is designed to be small and vey fast. PropForth is (several years) older, and designed for flexibility, data streams, logging, per-filtering for sensors, and pre-control of actuators (I don't know if this is the right term, think of reflexes as opposed to conscious control of your knee etc). PropForth also has an education focus built in, but I don't know if we got that bit right yet. So, both PropForth and Tachyon could turn out the same, or very different. They probably each will be best suited for different specific uses, but able to preform the others functions to at least some degree. In any case, Sal is going to offer comments to Peter. This is pretty important, as we tried doing code review for propforth, the previous attempts didn't have much result. The "do-different" this time is to have motivated, qualified experts as the core team driving the discussion; this is in contrast to "just inviting reviewers" as done last attempt. This may have an impact on "other projects", more on this in another thread.
Sal started a Raspberry Pi plugin board. RPi is to be the baseline configuration for propforth with Linux. Sal's using the propforth software Logic Analyzer to watch the RPi GPio in real-time while he does the circuit. Very Cool! We're discussing stackable headers, and just put props on top of the RPi. We think we could have up to 14 master props, and N sub props, so we might have enough pins and cogs to something interesting.
Circuit is "brain dead simple". Just a 10k resistor pack as pullups on the RPi GPio, and connect these 14 (16?) pins to the prop. It might be better to run power to the RPi from the prop, as we're having shortages of micro USB cables. We might put a blue tooth master on the RPi, as we plan on using netbook or smartphone to shell in to RPi & prop in the field.
Sal seems to have found a bug in RPi, setting RPi to 230400 baud (a "sweet spot" for speed and stability) results in 9600 baud. Which is weird, as RPi should be able to go much faster.
RPi is FAST single threaded. Folks are using RPi for "realtime" apps, but RPi not so good at multi-threaded, or realtime processing multiple activities. So we're thinking RPi+Prop has much potential. Compare this to RPi+Arduino, which is FAST single threaded+slow single threaded, we think prop will offer significant advantages, at least for some projects.
RPi configuration: The RPi will be used as a Linux box offering OS services. For embedded apps, we don't think we will have much cause to use the HDMI out and Xwindows desktop on the RPi, as these are fairly slow. BUT it seems that using ssh to shell in to a command line is very nice and fast. VNC is kind of nice as we can use the desktop PC to get at the RPi desktop, but this is also slow. Samba gets to the RPi's files, but is also a little clunky. Next experiment is XMing to window in from the PC, this could be a little better. Sal has selected DokuWiki running on the RPi, as he prefers to document on the device he's documenting. All this is working towards setting up interfaces to the GO applications, to enable RPi+Prop (GO+Propforth) applications.
The first demo for v5.3 is to be the football bot. This looks like it should be the next BIG project. We may rename this "Little Robot" if the football shape doesn't work out. A daydream about a later phase of this project is the Football Bot + RPi + prop. We think this might be happening when the RPi camera comes out, we're thinking a football bot would be nice with a vision system. I'm getting excited, I keep seeing ADVANCED ROBOT WITH IMAGE PROCESSING, but I haven't figured out how to keep it under twenty dollars. We might have to relax the cost constraint. First things first, for now I'm still waiting on my steppers. Final testing should keep me busy until the arrive.
Is it possible to run in Cog0 and Cog1 Propforth.
I will run in Cog1 an infinite loop thats increase every second a variable (global) with one (written in forth) ,
and test the value of this variable with the running Propforth in Cog0?
Is it possible to run in Cog0 and Cog1 Propforth.
I will run in Cog1 an infinite loop thats increase every second a variable (global) with one (written in forth) ,
and test the value of this variable with the running Propforth in Cog0?
By default, COG7 is the terminal serial driver, and COG6 is the user's forth interpreter. You can switch these, there is a configuration script in v5.3
The remaining cogs are available for any use. Just be aware load a source file definitions is sent to the next available cog (which is COG5 by default in most cases), so don't use up the last cog until all the source is loaded.
You should be fine, use
cog?
to see which cogs are assigned, and where their I/O is connected;
and use
." myforthwords " <cog#> cogx
where "myforthwords" are any valid labels
To launch execution in the other cogs
." myloop " 1 cogx
." mytest " 0 cogx
where "myloop" is your infinite loop, and "mytest" is your test the value routine
Braino started doing the "user testing" of the automation; that is, plugging it in and running it without reading the instructions; when something doesn't work, just read the instructions up to that point. Everything runs fine on a Quickstart until the standard test bed items were needed, (SD, spinneret, RTC, etc). We need better instructions on how to recognize the meaning of an error, but we're getting there.
Propforth v5.3 Data streams demo:
The demo looks like its will be built and released on stages as the Little Robot project. We tried different names but Little Robot is how we refer to it when we talk about it, and the kids like it, so we'll try that for a while. Details are growing on the wiki pages. The stepper driver will run on the last release(s) of propforth, so you can try it if you have erco's $2.29 uln2003 steppers.
A local school has requested to be the pilot users, we might outfit a class with the basic bot, and see how far we get. Folks may opt for the prop (quickstart) or arduino or TMS430. I'll be using Propforth. They are interested in expanding the bot as the kids learn, its anyone's guess how it will turn out.
Raspberry Pi investigation:
Sal is finding that Prop + RPi make a good combo.
watched changing pins states with proforth software logic analyser,
Rpi can change pins states at 25 - 30 ns unoptimized;
Prop 40 ns, 50 if 100mz
So RPi is plenty fast for bit banging.
The comunincations channels should go well past the limits of serial.
It will be handy for going from the realtime domain of the prop to the OS domain of linux on RPi.
Since RPi is single thread, it will experience issues with latency for time crititcal events as the time sindow gets smaller. Dealing with Linux interupt based programmin is fun and all, but it seems it will be more convenitnt to let the prop do the realtime stuff and the RPi do the OS stuff, as hypothesized.
Sal is documenting instructions for setting up the RPi
Documentation is being done using doku wiki on the raspberry pi itself. Ffor now its only a draft and prone to change, but I'll be emailling the URL to team members if they want to mess with the bleeding edge.
We're trying picocom, there appearrrs to be a bug in minicom.
Sal using Samba to get at the file from the PC.
We've decided against VNC, its just too slow. Instead Sal recommends Xming, its aPC only install.
Using RPi as a workstaion desktop is a little slow, but Pi as headless linux is great. Its as good as anything we'd want. While it can be handy to diectly connect a monitor for certain applications, it looks like our primary config will be RPi as headless linux.
Also, spineret (for $60) has 4 connections, RPi ($35) provides as many as we want.
We will b using RRpi for our ethernet services.
BEAM bots and nBot:
We discussed BEAM robotics. If you haven't looked at this, please do. This has a LOT of similarities with the basic concepts and design of propforth. That is, make a bunch of individual functions that "just do thiere job". When they all start working at the same time, we get an impression of something much more complex. While BEAM makes robots the use the environment and special sensors instead of a processor, we plan to "do the specialized bits in software" rather than custom sensors, if possible. The concept of "subsumption architecture" and "fusion of sensor data at the actuator instead of the processor" sound like fun things to play with. If we can do this in software, rather than build custom hardware, we might have some fun.
It doesn't look like the steppers will be sufficient to to the nbot balance thing on the first model Little Robot. But we will plan on doing this on one of the upgrades.
High level optimization versus Low level Optimization:
The startegy has been to limit low level optimization in favor of high level optimization where ever possible. High level is much more difficult but much more productive. We may get to determine if this pays off in the next series of experiments.
I had some free time today and ported Brian Riley's great PING.fth for Tachyon to PropForth (Thanks, Brian!!!).
I thought it was a good chance to brush up my rusty Forth (plus I don't want PropForth to feel neglected with the new kid on the block getting all the attention).
It's basically the same 4 words as Brian's Tachyon version. I did need to add a delus (delay micro-second) word since PropForth doesn't have one of those. It took about an hour to port and test (I'm rusty in PropForth and don't code quickly in any language).
I also figured this could be modified to work with the Chinese ultrasonic sensors for LittleRobot. The cost of a PING)) pretty much by itself destroys LittleRobot's budget.
Test it if you're willing and able!
I'll do the PIR words next since I'm 80% there, now.
: test
cnt COG@ cnt COG@ swap - . cr
cnt COG@ 1 delus cnt COG@ swap - . cr
;
Prop0 Cog6 ok
test
272
23584
Prop0 Cog6 ok
"1 delus" take 0.0125usec * (23584 - 272).
It's 291.4usec.
Microsend-order delay by using forthword is imposiible on PropForth.
It should use assembler-word.
Interesting that the PING distances still worked out. The PING))) initial pulse time must not be that important, just the time between WAITPEQ/WAITPNE that actually measures the distance.
Interesting that the PING distances still worked out. The PING))) initial pulse time must not be that important, just the time between WAITPEQ/WAITPNE that actually measures the distance.
I think the minimum distance has something to do with the send pulse getting past the receiver before the receiver is checked, or you get a false reading from you send pulse.
Or are you trying to detect multiple return signals from a single send pulse? Is that how Matt Murdock did it?
Interesting that the ping distances still worked out. The ping))) initial pulse time must not be that important, just the time between waitpeq/waitpne that actually measures the distance.
The best approach to coding the ping is to use the counters. The code shown below allows three pings to be continuously monitored using only counter A in one cog. No pasm required.
Delay don't use assembler word same as "1-wire Routines in Spin".
But it seems to work finely.
I have only one DS18B20.
So, no check multidevice.
Only"device" should work on multidevices.
Prop0 Cog6 ok
device
ROM Code
Device No. 1 : 850000037A65FC28
Prop0 Cog6 ok
temp
37 .2500 degree
37 .2500 degree
37 .2500 degree
Prop0 Cog6 ok
rd_scratch
Temperature LSB: 54
Temperature MSB: 2
TH register : 4B
TL register : 46
Configuration : 7F
Reserved(FFH) : FF
Reserved : C
Reserved(10H) : 10
CRC : BA
Prop0 Cog6 ok
wr_scratch
Temperature LSB: 54
Temperature MSB: 2
TH register : 4B
TL register : 46
Configuration : 5F
Reserved(FFH) : FF
Reserved : C
Reserved(10H) : 10
CRC : CA
Prop0 Cog6 ok
I found temperature-display isn't updated.
I will fix later.
I got a question about the i and j loop counters, here's the answer in case anybody has the same question
: test 7 0 do cr ." out " 5 0 do ." in i=" i . ." j=" j . loop cr loop ;
Prop0 Cog0 ok
test
out in i=0 j=0 in i=1 j=0 in i=2 j=0 in i=3 j=0 in i=4 j=0
out in i=0 j=1 in i=1 j=1 in i=2 j=1 in i=3 j=1 in i=4 j=1
out in i=0 j=2 in i=1 j=2 in i=2 j=2 in i=3 j=2 in i=4 j=2
out in i=0 j=3 in i=1 j=3 in i=2 j=3 in i=3 j=3 in i=4 j=3
out in i=0 j=4 in i=1 j=4 in i=2 j=4 in i=3 j=4 in i=4 j=4
out in i=0 j=5 in i=1 j=5 in i=2 j=5 in i=3 j=5 in i=4 j=5
out in i=0 j=6 in i=1 j=6 in i=2 j=6 in i=3 j=6 in i=4 j=6
Prop0 Cog0 ok
I is the inner loop (this loop) counter,
j is the outer loop counter (j is count from the loop calling this loop)
J is there so you can get at the value of the outer loop counter from inside a nested loop.
The Little Robot project has gotten another green light. Advisers suggest its best to treat it as an real project with real emergency deadlines. Just like work, only with fun robots! Now the critical path is the mechanical design. I reprapped the prototype football wheel, its beautiful but with comical errors. Good thing its easy to mod and reprint! The padwan will issue another iteration between classes, maybe this week.
RPi continues to look better and better as a compliment to propforth. Many folks are doing divers for the RPi, it looks like propforth will do one RPi driver, to allow two dedicated serial lines for GO channels. One line will be to talk to the prop, the other will be to talk to the RPi. Then we can do all the rest of the drivers for sensors and actuators on the prop, where drivers are easy.
Using propforth's software Logic Analyzer extension, one can see the state of the RPi pins changing AS THE CODING is happening. It kind of "Better than JTAG", as you can play interactively and watch in realtime. Logic Analyzer can detect at one clock cycle (you also have to know a little about whats going on) but so far its working better than other methods.
Sal has most of the documentation on how to configure the RPi with proper packages for go and propforth. The team members can check the IP address sent out in last weeks email and check the doku pages for updates. The last part is recompiling GO for the ARM, it takes about an hour. WAIT FOR THIS TO FINISH! Starting the next package download and configuration before the compile ends causes nasty bad things to happen, and I might have to start over again. But, what could be more fun?
So far we're using Xming, Samba, mercurial, go, minicom and picocom.
I discovered that printrun and pronterface run just fine, it looks like we may be getting more RPi's to go with the repraps as a headless workstation right there on the printer! Can't beat it with a stick!
Using propforth as a way in to the Linux box has had several advantages. One is we get to use those cheap Bluetooth modules, now we get wireless connection to the test rig from anywhere in the house. You can work interactively on the test rig in the lab from out in the kitchen, just using terminal windows.
If you've neve bothered with embedded Linux, RPi makes it cheap enough where you don't really have to worry about it. The previous offerings were a bit pricey, and have lots of extras (also pricey) that made one hesitate. RPi, just jump on in!
We're still wading through on the last bits of the v5.3 release, the documentation on how to do the last manual step of the automation process. Its really just a win-diff of two directories, but there a couple details that are not so straight forward, and need proper instructions before we turn it loose on the community. Perhaps another month or so till release.
I used FET as strong-pullup when DS18B20PAR is converting.
But firstly I thought P0(1-Wire bus) use as strong-pullup.
DS18B20 need 1.5mA from 1-Wire bus during conversion.
Because Propeller's output pin's source current(outa=1) is 10mA.
Refered WORD"parasite" inside 1-Wire_devices_1.0
outa COG@ ow_mask or outa COG! \ Set _OW-pin to Hi(output register)
CONVERT_T writeByte
dira COG@ ow_mask or dira COG! \ Set _OW-pin to Output(dira register)
300 delms
dira COG@ ow_mask andn dira COG!
outa COG@ ow_mask andn outa COG!
But this didn't operate.
My idea is wrong?
I found out crc8-calculation was wrong.
I fix on 1-Wire_1.1.
Just a simple question, I have a DNA-RTC board, can PropForth use the extra RAM that is available, and the RTC? Are there drivers available for this? In other setups, things like LMM, and XMM come up, can this be applicable or usable in PropForth? Or is programming in PropForth so tight and small, you really do not need any extra RAM? When I had PropForth loaded in to the Propeller Tool, and did the Object Info, it shows that PropForth uses all of the available RAM, so what are the limits on program size?
Ray, there are RTC words in one of the extension directories and they work great with the DNA RTC. They were written for the Spinneret and it uses the same RTC chip. I used those words on the DNA when I was helping with beta testing.
As for the memory, I need something more than my phone browser to answer that....more when I get to a real PC. Maybe the Professor can address the memory it would be nice to be able to use flash and SRAM space.
Ray, there are RTC words in one of the extension directories and they work great with the DNA RTC.
I looked in the PropForth Downloads section, and I did not see any extension that would contain RTC words. But, you did mention that you used PropForth to debug the DNA-RTC board, so it must be somewhere. Now that I think about it, I did not see any words that would access the uSD card, although it might be that I am not recognizing the words for the intended purpose. I do have the PropForth Quick Reference for the listing of core words, it would be nice if it had a real example as to how that word was used. I guess with the free and open stuff their is always the problem of examples that even idiots like myself could interpret.
RTC? ... In other setups, things like LMM, and XMM come up, can this be applicable or usable in PropForth? Or is programming in PropForth so tight and small, you really do not need any extra RAM? When I had PropForth loaded in to the Propeller Tool, and did the Object Info, it shows that PropForth uses all of the available RAM, so what are the limits on program size?
Ray
What Rick said for RTC.
RE RAM:
Propforth allocates the entire 32K. If you type "free" it tells you how much is left for application development. There's tons of RAM available, you can party down; its just internal to propforth. However, propforth is not designed to work with SPIN, or rather, SPIN is not designed to work with anything other than SPIN. So we don't know know a nice way to set up an interface, so we didn't bother. Peter might be working some SPIN interface with Tachyon, he's going for very small and very fast, while propforth is going for very large and still pretty darn fast.
To have extra memory, we just use the SD card. Since we can only get at 32k at once maximum, and usually only want 1 block of 512 bytes at a time anyway, SD works great. SD is fast enough to not be the bottle neck. The key is what to do with all the 512 byte blocks shooting to and fro. We concentrate on processing data streams as high speed, the prop and SD are a wonderful team. Because propforth source can be executed as a script from SD, the source code of any size can reside on the SD and not increase the dictionary in RAM (or be loaded to execute, and forgotten when done). There's really no limit on program size in propforth, you just have to take care that any single chunk is smaller than 32k (actually its something like 22k due to dictionary size, but I never get near that much in one go anyway).
It is a simple matter to to use extra RAM, you just have to write a driver. Any driver would be custom for what you have in mind. The issue to consider is the cost in overhead. In general, we have noticed that the cost in overhead negates the advantages of extra RAM on micro controllers in general, particularly concerning a generic RAM driver. That is, if you really need more than 32K at once, consider using a part that is built for that purpose. This is why we are looking at the RPi as a "Linux OS add-on" to the prop. We plan to use the RPi for image processing (computer vision) and the prop for data stream pre processing for senors and actuators. The right tool for the right job. And it looks like the combo totally kicks @$$!
That being said, that are many possible situation where an extra chunk of ram tied to 8 or 16 pins is the ideal solution. Just because I didn't think of it doesn't mean its not a great idea. It all comes back to designing within the prop architecture. If it can be done, it can usually be done elegantly with propforth. If you sketch out what you have in mind, maybe we can suggest a nice way to do it?
I looked in the PropForth Downloads section, and I did not see any extension that would contain RTC words.
words that would access the uSD card,
a real example as to how that word was used.
examples that even idiots like myself could interpret.
Got you covered... I'm all about idiots like myself!
So, for PropForth, at this point, it is best when you have an SD card available. Has their been any tests using flash ram, and how that compares to the SD card? I am not sure that anybody, especially me, has any idea as to how to write a driver for flash ram.
Since I was looking at Tachyon, and his version of multitasking, does PropForth have such a feature, or something like it?
The questions that I am asking do not pertain to any specific project or interest, just want to know more about what PropForth can do for me.
As for the Raspberry PI, I have mine set up, in a headless format, and I am trying to figure out which language I want to use, on the Propeller, to communicate with the Raspberry PI. I also have a robot project put on hold till I find a device that would provide more brain power for the robot.
On release 5.0, the RTC.f file is kind of buried -> /PropFORTH/V5.0/kernels/BootKernel/BootOptimizeKernel/BootOptimizeFsrdKernel/sd/ip/RTC.f
I usually round up all my .f files via a search of a new release and put a copy of everything in one place so I can find it and work with it without remembering where it is or was or should be.....
As for the memory, Prof B stated it clearly. WHat SPIN shows/tells about memory usage doesn't mean anything to Forth. What's important is what free shows you about the dictionary for your kernel. Each one (dev/eeprom/sd) starts out with so much available dictionary space and that is used as you add words. The EEPROM and SD can be used as file systems for either data files or for .f files to make your system add and delete words as needed. You could come up with a pretty complex application by properly chaining together definitions and .f files to add the words you need for various functions of your application.
As for SRAM and flash, there aren't any drivers or interfaces for them yet (as far as I know). I do have a DNA with both types of memory plus some Quickstart expansion boards that support both, so it is a possible fun project in my future.
PropForth comes out of the box ready to multi-task. You have complete access to all the COGs and in DEV or EEPROM kernel for example, the only dedicated COG is really #7 as it runs the serial I/O to the console. 0-6 are free for your use. COG 6 is where the PF interpreter that the console initially talks to is running. If you load any .f files that have 'fl' as the first word, then you will use an additional COG for the load (it goes faster that way).
With a little work, PropForth is easily set up to have master/slave propellers, so you can multi-task with multiple COGs across multiple propellers (it's way cool!).
I'm falling behind the cool kids as far as my RPi goes - mine hasn't talked to a Propeller yet.
PropForth... is best when you have an SD card available.
.. flash ram, ... compares to the SD card? I am not sure that anybody, especially me, has any idea as to how to write a driver for flash ram.
... multitasking, does PropForth ?
... not ... any specific project... what PropForth can do for me.
Raspberry PI, .. set up... headless... which language .. on the Propeller, to communicate with the Raspberry PI.
1) If you need prop to do something small, you can go without SD; this is the way propforth was originally designed, and works great. If you need some application bigger than 32k, SD is the best bang per buck, simple, and fast, you just have to know how to orchestrate processing and SD transfer effectively. It easy, you just have to get used to it.
2) flash ram - analysis and applications say we don't need, so we didn't implement the driver, too much higher priority work comes first. If you really feel you need have flash ram, its a simple matter of reading the data sheet, and trying out sending the commands from the command line to the pins to which its connected. In about an hour you will have the beginnings of your driver. Try it, you'll say, " I had no idea drivers were so easy!"
3) Multitasking - forth is famous for software multitasking. Cliffe Biffle had 140 tasks running at once on his propellerforth in 2008. The real question is how do you intend to use it? Each task consumers memory, a cog running 2 tasks only has 1K per task, running 32 tasks has 32 bytes per task. As some point you don' have enough room for a stack and dictionary works to execute. Also, the prop has HARDWARE multitasking, and we can string together more bare prop chips ad infiinitum, so why bother with slow software multitasking? The code exists, you can do it for fun, Sal did it and threw it away due to no benefit. Multiprop (MCS + norom) is the way to go, its totally awesome, shine the 80's software multitasking garbage.
4) Ask not what propforth can do for you, ask what you can do with propforth. Write you flash driver, until you start playing with the code and making it dance, you'll find you are breaking new ground and contributing in no time. You just have to get used to it, your skill level is directly proportional to the "hours of flight time logged" using it.
5) RPI - Go Language on the RPi is a direct interface to MCS and multiprop. That is, the RPi and the prop become more or less a single distributed process (sort of, the communications channels are limited to the prop clock speed, so the RPi might have to wait sometimes). If you can design the prop module and the RPi Go modles in terms of there interfaces, they can work seemlessly. This is the whole deal of the kernel build automation and the regression test automation. The automation technology is the direction we will be going. This opens a whole new world of possiblities to explore.
For example: The prop will run the sensors and actuators, and perform prefiltering and local realtime processing of the data streams. The ata streams will be sent to the RPi for number crunching and further OS services, like sending the processed data over the internet to a heavy duty workstation(s) for image generation, environmental modelling etc.
[Prop + propforth] + [RPi + Go] = something pretty cool for under $100. Seriously, take a look at this, you're going to love it.
Nick, thanks for pointing that out. I'll have to cruise over to the Wiki and check them out. Too much to read on too many things in too many places.....we live in fun times!!
Thanks for all the info. The one thing that I do notice is, it is a challenge to find the pertinent programs that I would be using with PropForth. As an example, RTC.f, if it wasn't for mindrobots, I would have never found the necessary information. In some ways it is starting to feel like an OBEX experince, when you are trying to find the correct stuff. As PropForth gets more popular, the experience for finding the correct programs will probably get worse.
The other observation is that, I think, you need a lot more examples that show how all of this stuff works. I have not looked at the RTC.f file, but I am making a guess that it does not have any working examples as to how you would use the program in a workable situation. I have not looked at the SD program, which would be on my list of necessary things, but I am guessing the same situation exists.
I have not given up on PropForth just yet, but the experience so far, has been very frustrating. For the Forth guys, they are probably thinking, what is this guy talking about, probably not trying hard enough, that's all. I am not sure that I have answer to that question.
Thanks for all the info. The one thing that I do notice is, it is a challenge to find the pertinent programs that I would be using with PropForth. As an example, RTC.f, if it wasn't for mindrobots, I would have never found the necessary information. In some ways it is starting to feel like an OBEX experince, when you are trying to find the correct stuff. As PropForth gets more popular, the experience for finding the correct programs will probably get worse.
The other observation is that, I think, you need a lot more examples that show how all of this stuff works. I have not looked at the RTC.f file, but I am making a guess that it does not have any working examples as to how you would use the program in a workable situation. I have not looked at the SD program, which would be on my list of necessary things, but I am guessing the same situation exists.
I have not given up on PropForth just yet, but the experience so far, has been very frustrating. For the Forth guys, they are probably thinking, what is this guy talking about, probably not trying hard enough, that's all. I am not sure that I have answer to that question.
Ray
We tried a bunch of stuff (documentation methods), it only worked to a certain extent.
The propfoth.htm file is the instructions, with examples, for all the kernel functions, per Sal. That part is fairly solid.
The tutorials, included with the build automation and regression test automation, are included in the download, but are not so well documented.
Most of the wiki is my inconsistent attempts to write stuff down. We rely heavily on the community to help keep it all together.
After the 5.3 kernel comes out, we will devote more attention to proper documentation, tutorials, and examples. Its the best we can do at this price point.
Comments
Bit of a delay on Sundays notes. I seem to be coming down with another job, and its interfering with projects.
Notes from Sunday's call
Latest Release still seems stable. The build system is "mostly bullet proof". The test automation has occasional variances dues to time stamps, undefined I/O pins etc; but should be livable. Sal is including a "Misc" directory, with support for stepper, bmpo85, double float, unix time. One more step before public release is for braino to run through the package one more time, to confirm everything is as planned. After that, Sal will cut over to the new code, and cut out the old code. We might be able to make a public release for 5.3 at that time. A task still remaining is to revise the existing tests. It looks like this will most be ADDING new tests for everything in the code base, but it might trigger changes to existing tests. Sal might let us revise the tests AFTER the public release, in the interest of getting the 5.3 out sooner. Normally I would say this is risky, but Sal has demonstrated repeatedly that when he thinks the code is stable, it really is pretty stable. In any case more regression tests will be added, it might be a flood. This is good, as these are the examples for how to use the propforth tools.
With Sal's focus on kernel development winding down, he has some time to look at Tachyon. Peter has made different design decisions in Tachyon from Sal's for PropForth, so the compare and contrast is interesting. Basically, Tachyon is newer, and is designed to be small and vey fast. PropForth is (several years) older, and designed for flexibility, data streams, logging, per-filtering for sensors, and pre-control of actuators (I don't know if this is the right term, think of reflexes as opposed to conscious control of your knee etc). PropForth also has an education focus built in, but I don't know if we got that bit right yet. So, both PropForth and Tachyon could turn out the same, or very different. They probably each will be best suited for different specific uses, but able to preform the others functions to at least some degree. In any case, Sal is going to offer comments to Peter. This is pretty important, as we tried doing code review for propforth, the previous attempts didn't have much result. The "do-different" this time is to have motivated, qualified experts as the core team driving the discussion; this is in contrast to "just inviting reviewers" as done last attempt. This may have an impact on "other projects", more on this in another thread.
Sal started a Raspberry Pi plugin board. RPi is to be the baseline configuration for propforth with Linux. Sal's using the propforth software Logic Analyzer to watch the RPi GPio in real-time while he does the circuit. Very Cool! We're discussing stackable headers, and just put props on top of the RPi. We think we could have up to 14 master props, and N sub props, so we might have enough pins and cogs to something interesting.
Circuit is "brain dead simple". Just a 10k resistor pack as pullups on the RPi GPio, and connect these 14 (16?) pins to the prop. It might be better to run power to the RPi from the prop, as we're having shortages of micro USB cables. We might put a blue tooth master on the RPi, as we plan on using netbook or smartphone to shell in to RPi & prop in the field.
Sal seems to have found a bug in RPi, setting RPi to 230400 baud (a "sweet spot" for speed and stability) results in 9600 baud. Which is weird, as RPi should be able to go much faster.
RPi is FAST single threaded. Folks are using RPi for "realtime" apps, but RPi not so good at multi-threaded, or realtime processing multiple activities. So we're thinking RPi+Prop has much potential. Compare this to RPi+Arduino, which is FAST single threaded+slow single threaded, we think prop will offer significant advantages, at least for some projects.
RPi configuration: The RPi will be used as a Linux box offering OS services. For embedded apps, we don't think we will have much cause to use the HDMI out and Xwindows desktop on the RPi, as these are fairly slow. BUT it seems that using ssh to shell in to a command line is very nice and fast. VNC is kind of nice as we can use the desktop PC to get at the RPi desktop, but this is also slow. Samba gets to the RPi's files, but is also a little clunky. Next experiment is XMing to window in from the PC, this could be a little better. Sal has selected DokuWiki running on the RPi, as he prefers to document on the device he's documenting. All this is working towards setting up interfaces to the GO applications, to enable RPi+Prop (GO+Propforth) applications.
The first demo for v5.3 is to be the football bot. This looks like it should be the next BIG project. We may rename this "Little Robot" if the football shape doesn't work out. A daydream about a later phase of this project is the Football Bot + RPi + prop. We think this might be happening when the RPi camera comes out, we're thinking a football bot would be nice with a vision system. I'm getting excited, I keep seeing ADVANCED ROBOT WITH IMAGE PROCESSING, but I haven't figured out how to keep it under twenty dollars. We might have to relax the cost constraint. First things first, for now I'm still waiting on my steppers. Final testing should keep me busy until the arrive.
Is it possible to run in Cog0 and Cog1 Propforth.
I will run in Cog1 an infinite loop thats increase every second a variable (global) with one (written in forth) ,
and test the value of this variable with the running Propforth in Cog0?
Thanks for any help
By default, COG7 is the terminal serial driver, and COG6 is the user's forth interpreter. You can switch these, there is a configuration script in v5.3
The remaining cogs are available for any use. Just be aware load a source file definitions is sent to the next available cog (which is COG5 by default in most cases), so don't use up the last cog until all the source is loaded.
You should be fine, use to see which cogs are assigned, and where their I/O is connected;
and use
where "myforthwords" are any valid labels
To launch execution in the other cogs
where "myloop" is your infinite loop, and "mytest" is your test the value routine
Braino started doing the "user testing" of the automation; that is, plugging it in and running it without reading the instructions; when something doesn't work, just read the instructions up to that point. Everything runs fine on a Quickstart until the standard test bed items were needed, (SD, spinneret, RTC, etc). We need better instructions on how to recognize the meaning of an error, but we're getting there.
Propforth v5.3 Data streams demo:
The demo looks like its will be built and released on stages as the Little Robot project. We tried different names but Little Robot is how we refer to it when we talk about it, and the kids like it, so we'll try that for a while. Details are growing on the wiki pages. The stepper driver will run on the last release(s) of propforth, so you can try it if you have erco's $2.29 uln2003 steppers.
A local school has requested to be the pilot users, we might outfit a class with the basic bot, and see how far we get. Folks may opt for the prop (quickstart) or arduino or TMS430. I'll be using Propforth. They are interested in expanding the bot as the kids learn, its anyone's guess how it will turn out.
Raspberry Pi investigation:
Sal is finding that Prop + RPi make a good combo.
watched changing pins states with proforth software logic analyser,
Rpi can change pins states at 25 - 30 ns unoptimized;
Prop 40 ns, 50 if 100mz
So RPi is plenty fast for bit banging.
The comunincations channels should go well past the limits of serial.
It will be handy for going from the realtime domain of the prop to the OS domain of linux on RPi.
Since RPi is single thread, it will experience issues with latency for time crititcal events as the time sindow gets smaller. Dealing with Linux interupt based programmin is fun and all, but it seems it will be more convenitnt to let the prop do the realtime stuff and the RPi do the OS stuff, as hypothesized.
Sal is documenting instructions for setting up the RPi
Documentation is being done using doku wiki on the raspberry pi itself. Ffor now its only a draft and prone to change, but I'll be emailling the URL to team members if they want to mess with the bleeding edge.
We're trying picocom, there appearrrs to be a bug in minicom.
Sal using Samba to get at the file from the PC.
We've decided against VNC, its just too slow. Instead Sal recommends Xming, its aPC only install.
Using RPi as a workstaion desktop is a little slow, but Pi as headless linux is great. Its as good as anything we'd want. While it can be handy to diectly connect a monitor for certain applications, it looks like our primary config will be RPi as headless linux.
Also, spineret (for $60) has 4 connections, RPi ($35) provides as many as we want.
We will b using RRpi for our ethernet services.
BEAM bots and nBot:
We discussed BEAM robotics. If you haven't looked at this, please do. This has a LOT of similarities with the basic concepts and design of propforth. That is, make a bunch of individual functions that "just do thiere job". When they all start working at the same time, we get an impression of something much more complex. While BEAM makes robots the use the environment and special sensors instead of a processor, we plan to "do the specialized bits in software" rather than custom sensors, if possible. The concept of "subsumption architecture" and "fusion of sensor data at the actuator instead of the processor" sound like fun things to play with. If we can do this in software, rather than build custom hardware, we might have some fun.
It doesn't look like the steppers will be sufficient to to the nbot balance thing on the first model Little Robot. But we will plan on doing this on one of the upgrades.
High level optimization versus Low level Optimization:
The startegy has been to limit low level optimization in favor of high level optimization where ever possible. High level is much more difficult but much more productive. We may get to determine if this pays off in the next series of experiments.
I thought it was a good chance to brush up my rusty Forth (plus I don't want PropForth to feel neglected with the new kid on the block getting all the attention).
It's basically the same 4 words as Brian's Tachyon version. I did need to add a delus (delay micro-second) word since PropForth doesn't have one of those. It took about an hour to port and test (I'm rusty in PropForth and don't code quickly in any language).
I also figured this could be modified to work with the Chinese ultrasonic sensors for LittleRobot. The cost of a PING)) pretty much by itself destroys LittleRobot's budget.
Test it if you're willing and able!
I'll do the PIR words next since I'm 80% there, now.
Enjoy!
About "delus" in ping.txt.
"1 delus" take 0.0125usec * (23584 - 272).
It's 291.4usec.
Microsend-order delay by using forthword is imposiible on PropForth.
It should use assembler-word.
Interesting that the PING distances still worked out. The PING))) initial pulse time must not be that important, just the time between WAITPEQ/WAITPNE that actually measures the distance.
Time to learn how to do PASM in Forth!
I think the minimum distance has something to do with the send pulse getting past the receiver before the receiver is checked, or you get a false reading from you send pulse.
Or are you trying to detect multiple return signals from a single send pulse? Is that how Matt Murdock did it?
this should clear it up ....
The best approach to coding the ping is to use the counters. The code shown below allows three pings to be continuously monitored using only counter A in one cog. No pasm required.
13 wconstant RPG \ right ping 14 wconstant CPG \ center ping 15 wconstant LPG \ left ping \ program constants (counter modes) h_1000_0000 RPG + constant RPG1mode h_2000_0000 RPG + constant RPG2mode h_1000_0000 CPG + constant CPG1mode h_2000_0000 CPG + constant CPG2mode h_1000_0000 LPG + constant LPG1mode h_2000_0000 LPG + constant LPG2mode variable rdist \ measured distances in inches variable cdist variable ldist : rc_ping 1 frqa COG! begin RPG pinout RPG1mode ctra COG! -400 phsa COG! RPG pinin RPG2mode ctra COG! 0 phsa COG! 25 delms phsa COG@ 11800 / rdist L! CPG pinout CPG1mode ctra COG! -400 phsa COG! CPG pinin CPG2mode ctra COG! 0 phsa COG! 25 delms phsa COG@ 11800 / cdist L! LPG pinout LPG1mode ctra COG! -400 phsa COG! LPG pinin LPG2mode ctra COG! 0 phsa COG! 25 delms phsa COG@ 11800 / ldist L! 0 until ;NickL
I'll have to play with this.
Thanks!
I translated "1-wire Routines in Spin" to PropForth.
http://obex.parallax.com/objects/342/
Delay don't use assembler word same as "1-wire Routines in Spin".
But it seems to work finely.
I have only one DS18B20.
So, no check multidevice.
Only"device" should work on multidevices.
Prop0 Cog6 ok device ROM Code Device No. 1 : 850000037A65FC28 Prop0 Cog6 ok temp 37 .2500 degree 37 .2500 degree 37 .2500 degree Prop0 Cog6 ok rd_scratch Temperature LSB: 54 Temperature MSB: 2 TH register : 4B TL register : 46 Configuration : 7F Reserved(FFH) : FF Reserved : C Reserved(10H) : 10 CRC : BA Prop0 Cog6 ok wr_scratch Temperature LSB: 54 Temperature MSB: 2 TH register : 4B TL register : 46 Configuration : 5F Reserved(FFH) : FF Reserved : C Reserved(10H) : 10 CRC : CA Prop0 Cog6 okI found temperature-display isn't updated.
I will fix later.
I is the inner loop (this loop) counter,
j is the outer loop counter (j is count from the loop calling this loop)
J is there so you can get at the value of the outer loop counter from inside a nested loop.
The Little Robot project has gotten another green light. Advisers suggest its best to treat it as an real project with real emergency deadlines. Just like work, only with fun robots! Now the critical path is the mechanical design. I reprapped the prototype football wheel, its beautiful but with comical errors. Good thing its easy to mod and reprint! The padwan will issue another iteration between classes, maybe this week.
RPi continues to look better and better as a compliment to propforth. Many folks are doing divers for the RPi, it looks like propforth will do one RPi driver, to allow two dedicated serial lines for GO channels. One line will be to talk to the prop, the other will be to talk to the RPi. Then we can do all the rest of the drivers for sensors and actuators on the prop, where drivers are easy.
Using propforth's software Logic Analyzer extension, one can see the state of the RPi pins changing AS THE CODING is happening. It kind of "Better than JTAG", as you can play interactively and watch in realtime. Logic Analyzer can detect at one clock cycle (you also have to know a little about whats going on) but so far its working better than other methods.
Sal has most of the documentation on how to configure the RPi with proper packages for go and propforth. The team members can check the IP address sent out in last weeks email and check the doku pages for updates. The last part is recompiling GO for the ARM, it takes about an hour. WAIT FOR THIS TO FINISH! Starting the next package download and configuration before the compile ends causes nasty bad things to happen, and I might have to start over again. But, what could be more fun?
So far we're using Xming, Samba, mercurial, go, minicom and picocom.
I discovered that printrun and pronterface run just fine, it looks like we may be getting more RPi's to go with the repraps as a headless workstation right there on the printer! Can't beat it with a stick!
Using propforth as a way in to the Linux box has had several advantages. One is we get to use those cheap Bluetooth modules, now we get wireless connection to the test rig from anywhere in the house. You can work interactively on the test rig in the lab from out in the kitchen, just using terminal windows.
If you've neve bothered with embedded Linux, RPi makes it cheap enough where you don't really have to worry about it. The previous offerings were a bit pricey, and have lots of extras (also pricey) that made one hesitate. RPi, just jump on in!
We're still wading through on the last bits of the v5.3 release, the documentation on how to do the last manual step of the automation process. Its really just a win-diff of two directories, but there a couple details that are not so straight forward, and need proper instructions before we turn it loose on the community. Perhaps another month or so till release.
DS18B20 1pc Digital Thermometer
DS18B20PAR 2pcs Same as DS18B20 Only parasite-power
DS2802 2pcs Kb Add-Only Memory Only parasite-power
Prop0 Cog6 ok devices? ROM Code Device No. 1 : 060000043C610028 DS18B20 Digital Termometer Device No. 2 : 850000037A65FC28 DS18B20 Digital Termometer Device No. 3 : 140000043C63B928 DS18B20 Digital Termometer Device No. 4 : 1300000767418C09 DS2802 1Kb Add-Only Memory Device No. 5 : 3800000767440209 DS2802 1Kb Add-Only Memory Prop0 Cog6 ok DS2802 flag W! Prop0 Cog6 ok devices? ROM Code Device No. 1 : 1300000767418C09 DS2802 1Kb Add-Only Memory Device No. 2 : 3800000767440209 DS2802 1Kb Add-Only Memory Prop0 Cog6 ok DS18B20 flag W! Prop0 Cog6 ok devices? ROM Code Device No. 1 : 060000043C610028 DS18B20 Digital Termometer Device No. 2 : 850000037A65FC28 DS18B20 Digital Termometer Device No. 3 : 140000043C63B928 DS18B20 Digital Termometer Prop0 Cog6 ok allTemp device1 : 28 .9375 degree device2 : 29 .1875 degree device3 : 29 .0 degree device1 : 28 .9375 degree device2 : 29 .1875 degree device3 : 29 .0 degree device1 : 29 .0 degree device2 : 29 .1875 degree device3 : 29 .0 degree device1 : 29 .0 degree device2 : 29 .2500 degree device3 : 29 .625 degree device1 : 29 .0 degree device2 : 29 .2500 degree device3 : 29 .6250 degree device1 : 29 .0 degree device2 : 29 .2500 degree device3 : 30 .6250 degree <--- hit any key Prop0 Cog6 okI used FET as strong-pullup when DS18B20PAR is converting.
But firstly I thought P0(1-Wire bus) use as strong-pullup.
DS18B20 need 1.5mA from 1-Wire bus during conversion.
Because Propeller's output pin's source current(outa=1) is 10mA.
Refered WORD"parasite" inside 1-Wire_devices_1.0
outa COG@ ow_mask or outa COG! \ Set _OW-pin to Hi(output register) CONVERT_T writeByte dira COG@ ow_mask or dira COG! \ Set _OW-pin to Output(dira register) 300 delms dira COG@ ow_mask andn dira COG! outa COG@ ow_mask andn outa COG!But this didn't operate.My idea is wrong?
I found out crc8-calculation was wrong.
I fix on 1-Wire_1.1.
Ray
As for the memory, I need something more than my phone browser to answer that....more when I get to a real PC. Maybe the Professor can address the memory it would be nice to be able to use flash and SRAM space.
Ray
What Rick said for RTC.
RE RAM:
Propforth allocates the entire 32K. If you type "free" it tells you how much is left for application development. There's tons of RAM available, you can party down; its just internal to propforth. However, propforth is not designed to work with SPIN, or rather, SPIN is not designed to work with anything other than SPIN. So we don't know know a nice way to set up an interface, so we didn't bother. Peter might be working some SPIN interface with Tachyon, he's going for very small and very fast, while propforth is going for very large and still pretty darn fast.
To have extra memory, we just use the SD card. Since we can only get at 32k at once maximum, and usually only want 1 block of 512 bytes at a time anyway, SD works great. SD is fast enough to not be the bottle neck. The key is what to do with all the 512 byte blocks shooting to and fro. We concentrate on processing data streams as high speed, the prop and SD are a wonderful team. Because propforth source can be executed as a script from SD, the source code of any size can reside on the SD and not increase the dictionary in RAM (or be loaded to execute, and forgotten when done). There's really no limit on program size in propforth, you just have to take care that any single chunk is smaller than 32k (actually its something like 22k due to dictionary size, but I never get near that much in one go anyway).
It is a simple matter to to use extra RAM, you just have to write a driver. Any driver would be custom for what you have in mind. The issue to consider is the cost in overhead. In general, we have noticed that the cost in overhead negates the advantages of extra RAM on micro controllers in general, particularly concerning a generic RAM driver. That is, if you really need more than 32K at once, consider using a part that is built for that purpose. This is why we are looking at the RPi as a "Linux OS add-on" to the prop. We plan to use the RPi for image processing (computer vision) and the prop for data stream pre processing for senors and actuators. The right tool for the right job. And it looks like the combo totally kicks @$$!
That being said, that are many possible situation where an extra chunk of ram tied to 8 or 16 pins is the ideal solution. Just because I didn't think of it doesn't mean its not a great idea. It all comes back to designing within the prop architecture. If it can be done, it can usually be done elegantly with propforth. If you sketch out what you have in mind, maybe we can suggest a nice way to do it?
Got you covered... I'm all about idiots like myself!
Looking the download archive propforth.zip
..\V5.x\kernels\doc\tutorials\
tutorial-4.1 SD.txt
tutorial-6.1 RTC.txt
Since I was looking at Tachyon, and his version of multitasking, does PropForth have such a feature, or something like it?
The questions that I am asking do not pertain to any specific project or interest, just want to know more about what PropForth can do for me.
As for the Raspberry PI, I have mine set up, in a headless format, and I am trying to figure out which language I want to use, on the Propeller, to communicate with the Raspberry PI. I also have a robot project put on hold till I find a device that would provide more brain power for the robot.
Ray
DS2502 need 12V when writing datas.
But I don't make curcuit.
So I don't try writing-datas to DS2502.
Maybe , I think Reading is ok.
Prop0 Cog6 ok devices? ROM Code Device No. 1 : 060000043C610028 DS18B20 Digital Thermometer Device No. 2 : 850000037A65FC28 DS18B20 Digital Thermometer Device No. 3 : 140000043C63B928 DS18B20 Digital Thermometer Device No. 4 : 1300000767418C09 DS2802 1Kb Add-Only Memory Device No. 5 : 3800000767440209 DS2802 1Kb Add-Only Memory Prop0 Cog6 ok DS18B20 set_family Prop0 Cog6 ok devices? ROM Code Device No. 1 : 060000043C610028 DS18B20 Digital Thermometer Device No. 2 : 850000037A65FC28 DS18B20 Digital Thermometer Device No. 3 : 140000043C63B928 DS18B20 Digital Thermometer Prop0 Cog6 ok DS2502 set_family Prop0 Cog6 ok devices? ROM Code Device No. 1 : 1300000767418C09 DS2802 1Kb Add-Only Memory Device No. 2 : 3800000767440209 DS2802 1Kb Add-Only Memory Prop0 Cog6 ok all_devices Prop0 Cog6 ok devices? ROM Code Device No. 1 : 060000043C610028 DS18B20 Digital Thermometer Device No. 2 : 850000037A65FC28 DS18B20 Digital Thermometer Device No. 3 : 140000043C63B928 DS18B20 Digital Thermometer Device No. 4 : 1300000767418C09 DS2802 1Kb Add-Only Memory Device No. 5 : 3800000767440209 DS2802 1Kb Add-Only Memory ====== DS18B20 DS18B20PAR ==================== Prop0 Cog6 ok 1 DS18B20_rd_scratch Temperature LSB: 50 Temperature MSB: 5 TH register : 40 TL register : 30 Configuration : 7F Reserved(FFH) : FF Reserved : C Reserved(10H) : 10 CRC : 15 Prop0 Cog6 ok 5F 20 50 1 DS18B20_wr_scratch Temperature LSB: 50 Temperature MSB: 5 TH register : 50 TL register : 20 Configuration : 5F Reserved(FFH) : FF Reserved : C Reserved(10H) : 10 CRC : 42 Prop0 Cog6 ok allTemp device1 : 25 .8750 degree device2 : 26 .625 degree device3 : 25 .9375 degree device1 : 25 .8750 degree device2 : 26 .1250 degree device3 : 26 .0 degree device1 : 25 .9375 degree device2 : 26 .625 degree device3 : 26 .0 degree device1 : 27 .7500 degree device2 : 26 .1250 degree device3 : 26 .1250 degree device1 : 29 .5000 degree device2 : 26 .1250 degree device3 : 26 .1250 degree device1 : 29 .5625 degree device2 : 28 .5000 degree device3 : 26 .1250 degree device1 : 29 .1250 degree device2 : 30 .1250 degree device3 : 26 .1250 degree device1 : 28 .7500 degree device2 : 30 .3125 degree device3 : 26 .3125 degree device1 : 28 .4375 degree device2 : 29 .6875 degree device3 : 28 .3750 degree device1 : 28 .1875 degree device2 : 29 .1875 degree device3 : 29 .5625 degree device1 : 27 .9375 degree device2 : 28 .8125 degree device3 : 30 .1875 degree device1 : 27 .7500 degree device2 : 28 .4375 degree device3 : 29 .7500 degree Prop0 Cog6 ok ====== DS2502 =================== devices? ROM Code Device No. 1 : 060000043C610028 DS18B20 Digital Thermometer Device No. 2 : 850000037A65FC28 DS18B20 Digital Thermometer Device No. 3 : 140000043C63B928 DS18B20 Digital Thermometer Device No. 4 : 1300000767418C09 DS2802 1Kb Add-Only Memory Device No. 5 : 3800000767440209 DS2802 1Kb Add-Only Memory Prop0 Cog6 ok 4 epromStatus WRITE PROTECT PAGE1 :1 PAGE2 :1 PAGE3 :1 PAGE4 :1 PAGE ADDRESS REDIRECTION BYTE PAGE1 :255 PAGE2 :255 PAGE3 :255 PAGE4 :255 Prop0 Cog6 ok 0 4 readPage PAGE0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 Prop0 Cog6 okOn release 5.0, the RTC.f file is kind of buried -> /PropFORTH/V5.0/kernels/BootKernel/BootOptimizeKernel/BootOptimizeFsrdKernel/sd/ip/RTC.f
I usually round up all my .f files via a search of a new release and put a copy of everything in one place so I can find it and work with it without remembering where it is or was or should be.....
As for the memory, Prof B stated it clearly. WHat SPIN shows/tells about memory usage doesn't mean anything to Forth. What's important is what free shows you about the dictionary for your kernel. Each one (dev/eeprom/sd) starts out with so much available dictionary space and that is used as you add words. The EEPROM and SD can be used as file systems for either data files or for .f files to make your system add and delete words as needed. You could come up with a pretty complex application by properly chaining together definitions and .f files to add the words you need for various functions of your application.
As for SRAM and flash, there aren't any drivers or interfaces for them yet (as far as I know). I do have a DNA with both types of memory plus some Quickstart expansion boards that support both, so it is a possible fun project in my future.
PropForth comes out of the box ready to multi-task. You have complete access to all the COGs and in DEV or EEPROM kernel for example, the only dedicated COG is really #7 as it runs the serial I/O to the console. 0-6 are free for your use. COG 6 is where the PF interpreter that the console initially talks to is running. If you load any .f files that have 'fl' as the first word, then you will use an additional COG for the load (it goes faster that way).
With a little work, PropForth is easily set up to have master/slave propellers, so you can multi-task with multiple COGs across multiple propellers (it's way cool!).
I'm falling behind the cool kids as far as my RPi goes - mine hasn't talked to a Propeller yet.
1) If you need prop to do something small, you can go without SD; this is the way propforth was originally designed, and works great. If you need some application bigger than 32k, SD is the best bang per buck, simple, and fast, you just have to know how to orchestrate processing and SD transfer effectively. It easy, you just have to get used to it.
2) flash ram - analysis and applications say we don't need, so we didn't implement the driver, too much higher priority work comes first. If you really feel you need have flash ram, its a simple matter of reading the data sheet, and trying out sending the commands from the command line to the pins to which its connected. In about an hour you will have the beginnings of your driver. Try it, you'll say, " I had no idea drivers were so easy!"
3) Multitasking - forth is famous for software multitasking. Cliffe Biffle had 140 tasks running at once on his propellerforth in 2008. The real question is how do you intend to use it? Each task consumers memory, a cog running 2 tasks only has 1K per task, running 32 tasks has 32 bytes per task. As some point you don' have enough room for a stack and dictionary works to execute. Also, the prop has HARDWARE multitasking, and we can string together more bare prop chips ad infiinitum, so why bother with slow software multitasking? The code exists, you can do it for fun, Sal did it and threw it away due to no benefit. Multiprop (MCS + norom) is the way to go, its totally awesome, shine the 80's software multitasking garbage.
4) Ask not what propforth can do for you, ask what you can do with propforth. Write you flash driver, until you start playing with the code and making it dance, you'll find you are breaking new ground and contributing in no time. You just have to get used to it, your skill level is directly proportional to the "hours of flight time logged" using it.
5) RPI - Go Language on the RPi is a direct interface to MCS and multiprop. That is, the RPi and the prop become more or less a single distributed process (sort of, the communications channels are limited to the prop clock speed, so the RPi might have to wait sometimes). If you can design the prop module and the RPi Go modles in terms of there interfaces, they can work seemlessly. This is the whole deal of the kernel build automation and the regression test automation. The automation technology is the direction we will be going. This opens a whole new world of possiblities to explore.
For example: The prop will run the sensors and actuators, and perform prefiltering and local realtime processing of the data streams. The ata streams will be sent to the RPi for number crunching and further OS services, like sending the processed data over the internet to a heavy duty workstation(s) for image generation, environmental modelling etc.
[Prop + propforth] + [RPi + Go] = something pretty cool for under $100. Seriously, take a look at this, you're going to love it.
NickL
The other observation is that, I think, you need a lot more examples that show how all of this stuff works. I have not looked at the RTC.f file, but I am making a guess that it does not have any working examples as to how you would use the program in a workable situation. I have not looked at the SD program, which would be on my list of necessary things, but I am guessing the same situation exists.
I have not given up on PropForth just yet, but the experience so far, has been very frustrating. For the Forth guys, they are probably thinking, what is this guy talking about, probably not trying hard enough, that's all. I am not sure that I have answer to that question.
Ray
We tried a bunch of stuff (documentation methods), it only worked to a certain extent.
The propfoth.htm file is the instructions, with examples, for all the kernel functions, per Sal. That part is fairly solid.
The tutorials, included with the build automation and regression test automation, are included in the download, but are not so well documented.
Most of the wiki is my inconsistent attempts to write stuff down. We rely heavily on the community to help keep it all together.
After the 5.3 kernel comes out, we will devote more attention to proper documentation, tutorials, and examples. Its the best we can do at this price point.