Here's the highlights from the discussion with Sal on DOES>
The DOES> word is clever use of the code pointers in traditional forth dictionary structure.
The design decisions due to the prop architecture result in the propforth dictionary structure having significant differences from tradition forth dictionaries in in this respect.
Specifically, Propforth eliminates code pointers wherever possible to save space.
(The alternative would be to increase the every dictionary entry to include the code pointers, result would be the propforth kernel would not fit in the current prop's available memory space, or would not leave enough space to allow further application development).
So, the result is that the CREATE word does not function as expected in traditional forth; that is, it does not leave an address on the stack after it terminates. (Although there is a CREATE word in the kernel, and it does what it needs to in the context where its currently called, but it gets hard to use in other situations).
The alternative to CREATE...DOES> in propforth is to define words as IMMEDIATE and EXECUTABLE and use the structure
COMPILE? IF ...(compile time action)... ELSE ...(execution time action)... THEN
The resulting words are larger than in traditional forth, but the cost is more than offset by the savings from eliminating code pointers in the rest of all the dictionary entries.
The definition of the back-slash comment character ( \ ) is what Sal suggested we look at.
A different alternative (not yet implemented in the Propforth 4.0 kernel) could be to make a word that takes a dictionary entry and determines the actual address of the code portion of a dictionary entry (from the "virtual code pointer" for each dictionary entry and make the CREATE...DOES> words work from there.
So, there's what we've got to work with at this point.
If you can give a specific example of a CREATE...DOES> definition you are trying to use (or better yet a simplified example) we can make a stab at making something that works efficiently. This question was bound to come up sooner or later, so this is a good time to start looking at a general solution. You can PM me if you do not want to make the code public.
Earlier we had a discussion on arrays, since the
CREATE <arrayName> n ALLOT
construct does not work for the same reason; and we ended up suggesting
Hi.
I made Denpatokei(RadioControlledClock) using 4 cogs.
Loading below;
1_LCD_1.0.f
2_setup.f
3_monitor.f
4_diff.f
5_prop_clock.f
6_Denpatokei.f
Hardware:
LCD connection is same as LCD_1.0_20110116-0952.
RadioControlledCloack's signal(L-active) is connected to P4.
LED for signal is connected to P5.
P6 and P7 is used to measure error-time between RadioControlledCloack and prop_clock.
Hi.
I made Denpatokei(RadioControlledClock) using 4 cogs.
Loading below....
.....
6_Denpatokei.f cog6
decoding time-infornmation
This is for Japan. So this don't use in other country.
Executing WORD"denpatokei".
At first, prop_clock start on 2011 Jan01 (SAT) 00:00:00.
There is about -77msec for error-time between RadioControlledCloack and prop_clock.
I think this is strange. But not solved yet.
WOW! you have been busy! I'll show this to Sal next call.
These are great instructions, or at least a great start. Can you include them in the ZIP archive?
Do you want to post this on the google code site as an example?
1.
When synchronized to RadioControlledClock's signal, error-time is -77msec or -90msec,-82msec. (This value is not constant.)
Minus value means prop_clock is faster than RadioControlledClock's signal.
2.
After synchronized to RadioControlledClock's signal at Feb7 7:56, signal is off from propeller.
And then error-time is -95msec.
Next I connected RadioControlledClock's signal to propeller at 11:56.
error-time is 435msec.
Difference between 7:56 and 11:56 is 530msec.
This mean prop_clock delay 37usec per 1sec. (530msec/240min= 530msec/14400sec= 0.037msec/1sec)
I think code should be wrong.
But I can't solve it.
...fix Denpatokei's bug. Please teach me what is wrong.
Sal looked at the code this morning, he said it looked pretty cool, so he probably will make an effort to look at it.
I don't know what equipment he has available, but most likely some will be different from your set up.
He may substitute low res VGA for LCD if displaying on the pc over serial has issues.
Also, will have to compare the north american radio time synchronization to the japan radio time.
That should give at least a start on locating the bug.
About 1
Problem was code's time in front of begin-loop(LCD_init's time, and other) on prop_clock.f.
About 2
Propeller's frequency is a little little bigger than 80MHz.
So 1second for prop_clock is shorter than real 1second.
dT need to be added some value.
Now I'm adjusting time value.
mistake on #97
4_diff.f cog3
measure error-time between RadioControlledCloack and prop_clock
minus value mean prop_clock is fast. <-- wrong
minus value mean prop_clock delay.
mistake on #99
Difference between 7:56 and 11:56 is 530msec.
This mean prop_clock delay 37usec per 1sec. (530msec/240min= 530msec/14400sec= 0.037msec/1sec) <-- wrong
This mean prop_clock proceed 37usec per 1sec.
Error time become small. But about 10msec to -7msec.
This value is because using Forth?
In #101, "About 2", prop frequency was discovered to be higher that 80MHz. Can you do some tests? Check the frequency for 1 second, and do this several times to see what variation is present. Then check the frequency over ten minutes, and do this several times to see if your first test result is reliable.
In #101 97, your minus value means the prop is slow? This seems to contradict the "About 2" result.
If the error were due to using forth, it would be consistent to the accuracy of your equipment; my second guess would be non-deterministic algorithm (like an "if statement" in a loop). But I did not analyze the code (other stuff is going on).
So, I thought you were trying to set the clock time from a signal received on the radio? How accurate do you need/expect to be?
If the issue you are trying to address is that there is an error between your prop and the ultra high precision clock that is used to set the radio, you should maybe reconsider. The Cesium clock (over whatever they use) will ALWAYS be more accurate than anything we could ever afford (as far as I know). The only thing I know of that is affordable and very accurate is GPS equipment, and I don't think we can build those from scratch. If your clock source over the radio is NOT from an ultrahigh precision (government) source, than the error could be from the radio station, since they (generally) use internet or telephone company time synchronization. The further from the original standard the less strict and less accurate, etc.
What you CAN do, is measure the difference after a period of time, many times, and determine the average and then the deviation. Then add in a correction factor once a day or once a week or what ever you determine works. Or, re-check the time signal once in a given period (day week month etc) and reset the clock. I believe if it is withing two seconds it is good enough for internet timing (ntp) and if it is off by two minutes per minute than it is as good as windows.
Otherwise, subsequent words or loop structures change the return stack, and you get weird results.
>r and r> work on the return stack which is normally infrastructure and not directly manipulated by the user.
These provide a "sneaky way" to get an extra stack. I avoid playing with these if I can help it. I don't like "sneaky".
I avoid manipulating the return stack directly, and avoid >r and r> unless I'm starting with known working code for this reason.
But that's just me, I'm not advanced enough to use these effectively.
Folks more skilled then I use the return stack all the time, and successfully, I just prefer not to.
Hi.
I'm going to make case-statement.
But cannot load.
I have no idea where is wrong.
Please teach me how to fix.
wvariable case_ptr
wvariable case_work 12 allot
: case case_work case_ptr W! 4 ; immediate
: of
swap 4 = if over l>w 1550 =
if dup here W@ swap - swap W! nip
else drop
then
swap dup rot = $C_a_0branch w, here W@ 1550 w>l 0 w, 5
else ." 123" _mmcs
then
; immediate
: endof
5 = if $C_a_branch w, here W@ case_ptr W@ case_work 12 + >
if _mmcs else case_ptr W@ W! then
case_ptr dup W@ 2+ swap W! 4
else ." 456" _mmcs
then
; immediate
: other
swap 4 = if over l>w 1550 =
if dup here W@ swap - swap W! nip
else drop
then
4
else ." 789" _mmcs
then
; immediate
: endcase
4 = if here W@
begin dup case_ptr W@ 2- dup case_work W@ <
if 3drop 1
else W! case_ptr dup W@ 2- swap W! 0
then
until
else ." abc" _mmcs
then
; immediate
: test
case
1 of ." this is 1" endof
2 of ." this is 2" endof
3 of ." this is 3" endof
4 of ." this is 4" endof
5 of ." this is 5" endof
endcase
;
Loading error occured
: test
case
1 of ." this is 1" endof
123MISMATCHED CONTROL STRUCTURE(S)
Prop0 Cog6 ok
With reference to my previous post regarding create...does>, I have attached FACS.pdf which is a copy of my presentation at the 1986 Rochester Forth Conference. You will note that besides create .does>, I have used the defer..is words. I found a way to work around the absence of these words in PropForth. Attached find PropFacs.f, a working simulation of an analog computer. I have also attached a copy of a PropForth Quick Reference Guide (a first attempt) for which I would appreciate any comments.
WOW. Nice work! I'll discuss it with Sal next call. Thanks for the effort on this.
Most of the FACS material is way over my head, can the analog computer be used for processing audio, like the old EMS synthesizer?
The quick reference should be very handy, can I post it on the google code site?
You may post the Quick Reference on the google site. The analog computer was used to solve simulation models consisting of differential equations. It could also be used to simulate filters which might be used to processs audio data.
I took your file and converted it to Word 2008(Mac) in 'compatibility mode' which means it is a .doc file that can be read by most anything. I adjusted margins and inserted some forced page breaks so it didn't break in the middle of any definition, etc. Its zipped and attached here. If this a problem, I will pull it. Thanks for all the great work. I am sufficiently a novice at Forth that I have been praying someone would create this.
I made dynamic_drive_7seg.
Brightness is dark than static-driveLED. So low resistor is good for dynamic_drive_7seg.
Drive -frequency for dynamic_drive_7seg can change from Tera-Term.
When drive -frequency on 120Hz, display on 7segLED is clear.
Flicker is seen less than 100Hz.
Though I tested 3digits, I think 8digits need higher frequency.
Denpatokei's bug. error-time is -77msec or -90msec,-82msec. (This value is not constant.)
Did you ever get this fixed?
Talked to Sal about this again, he's doing internet time for the spineret. He said the technique he uses is to have a cog update the time once a second using waitcnt. He lets it run for a minute, and finds how much the clock is off, and adjusts for the difference. Then he does the same after an hour, then after a day. He said he none of the clocks (he's working with several different props) have drifted since before Christmas.
Do you have a cog whose only job is to update the clock every second?
Thanks for your advice.
WORD"prop_clock" update date/hour/minute/second. And when seccessfully receiving RadioControlledClock's signal, prop_clock sinchronize to its signal.
I will try to have a cog update the time once a second using waitcnt later.
Now I'm going to re-write dynamic_drive_7seg to add driver forMCP3204.
I updated dynamic_drive_7seg_LED. (also changed name)
It display up to 8-digits.
Please check line26,27 inside dynamic_drive_7seg_LED.f.
I made normal LED-character and reverse&mirror letters.
Loading dynamic_drive_7seg_LED.f, next MCP3204.f.
After run WORD"demo", it quit to change frequency 10 times.
I tested up to 3digits. More than 3digits is no test.
Attached find an updated version of PropFacs. I have added many new blocks including function generators and a delay line. The SIN, LOG & ANTILOG blocks access the corresponding propeller data tables. I also added a word that stores simulation results on the eeprom.
Analog computers were parallel computers which could solve problems faster than, slower than, or in real time irrespective of the model complexity. However, a digital emulation of the analog computer runs at a time dependent on the model complexity ( no. of blocks). I haved added two words to the utility section of the program, pretime and postime, which can be used to measure the running time of specific models. As one would expect, the output functions (e.g., display) have the greatest effect.
I would like to have the ANSI word dpl added to the forth core. If the parser would accept numbers with decimal points (e.g. 0.43), and store the decimal point position, I could automate the scaling of parameters. I am also considering how to add a graphics output function to the emulation, so that the tv screen can emulate a XY-recorder.
I have not included examples in the attached program, since I am preparing a document which will list and define the facs words, including a variety of examples to show how analog computers were used.
i did some PROPELLER things before in spin and assembler.
Now i like to start a new project where the Propeller should be an intelligent IO processor between an ARM (Linux) and a real world IO of A/D D/A , counters and dig I/O chips etc.
There should be a serial interface from the ARM to the Propeller.
On the Propeller i would like to realize a "dictionary" of I/O commands, which can be loaded and actualized by the ARM.
M y ideas:
- I need a comunication channel to the ARM , thats the normal Forth terminal interface, i guess.
- - i need further one I2C and 2..3 SPI interfaces for the comunication with the I/O hardware
Now I would like to get some suggestions how to start with this project:
- would you recommend to do this in FORTH (speed requirements are not so high)
- is FORTH reliable enough for application running several weeks?
- any hints where and how to start?
-- are there any dictionaries/libraries for an I2C or SPI master ?
The key is Clearly Defined Requirements:
High Level Requirements - What is the end function of the final device in high level terms
System level Requirements - what systems are need to fulfill the high level requirements
Implementations Requirements - What functions do you need to implement to achieve the system described
This applies to any project, but seems more obvious when using forth.
ALSO - defining requirements is in itself an iterative process, as you define the next level, you get more insight into the previous level, and should go back and make adjustments. Generally, one does not want to start coding until all requirements are defined to the extent that you know what you have to code. This is "the easy way". Of course few do it this way, which is ok, it just takes longer to do it the hard way.
That being said you have a good start on your requirements.
1. Exactly what sensors/inputs do you have in mind right now specifically? Do no include "possibly.." and "maybe someday..." items, you will have enough work with today's specifics, and you can add new stuff later.
2. "Intelligent I/O processor" does not sound specific, do you mean the prop is to be I/O interface and pre-processor to the ARM? If so, this should not be a problem.
3. Propforth can easily be extended to have drivers for reading and controlling each sensor, we just need the specific parts you are targeting.
4. There are many choices for serial interface. If there are less than 28 or so, it is easy to have one line for each part. If there are more than that, the parts that are accessed less often can be place on a SPI bus and accesses with a shift register. The method used on the C3 board may be useful. Again, the specific parts will dictate which need a dedicated I/O line, which can be multiplexed, and what baud rate for a given throughput is needed.
5. Usually you can leave the regular forth interface (Rx/TX on line 30&31) as the serial interface, and use the other pins for inter-device communication. Its easier and much more convenient, and its nice to leave something just in case you get to load up every last pin later on.
6. As of 4.x, Sal runs his DEVELOPMENT for days at a time. The 3.x stuff was less stable in development, needed to reboot once a day, but the final apps ran indefinitely. Final apps on 4.x are (so far) completely stable (Sal has not found any evidence of instability yet).
7. We expect Next week or so to have a public release of v4.5. This should be fast enough for any application you have in mind; if it isn't, the bottlenecks can be optimized in assembler.
8. If you have specifics on the I2C and SPI we can look are implementing the drivers. I haven't played with I2C and SPI myself, but Caskaz and Sal have SD support nearly complete.
So the first step in getting stated is to state very specifically what sensor you want to monitor and define the data you wish to collect. Everything else is built on that.
Also, if you are working on an ARM and are interested in FORTH, please check out Frank Sargents Pygmy Forth. http://pygmy.utoh.org/
If you have any requirements/specifications that you can't discuss on the thread, PM me and I will try to help properly define them. This step is critical for success. You should be able to finish defining requirements by the time V4.5 is released.
Comments
Here's the highlights from the discussion with Sal on DOES>
The DOES> word is clever use of the code pointers in traditional forth dictionary structure.
The design decisions due to the prop architecture result in the propforth dictionary structure having significant differences from tradition forth dictionaries in in this respect.
Specifically, Propforth eliminates code pointers wherever possible to save space.
(The alternative would be to increase the every dictionary entry to include the code pointers, result would be the propforth kernel would not fit in the current prop's available memory space, or would not leave enough space to allow further application development).
So, the result is that the CREATE word does not function as expected in traditional forth; that is, it does not leave an address on the stack after it terminates. (Although there is a CREATE word in the kernel, and it does what it needs to in the context where its currently called, but it gets hard to use in other situations).
The alternative to CREATE...DOES> in propforth is to define words as IMMEDIATE and EXECUTABLE and use the structure
The resulting words are larger than in traditional forth, but the cost is more than offset by the savings from eliminating code pointers in the rest of all the dictionary entries.
The definition of the back-slash comment character ( \ ) is what Sal suggested we look at.
A different alternative (not yet implemented in the Propforth 4.0 kernel) could be to make a word that takes a dictionary entry and determines the actual address of the code portion of a dictionary entry (from the "virtual code pointer" for each dictionary entry and make the CREATE...DOES> words work from there.
So, there's what we've got to work with at this point.
If you can give a specific example of a CREATE...DOES> definition you are trying to use (or better yet a simplified example) we can make a stab at making something that works efficiently. This question was bound to come up sooner or later, so this is a good time to start looking at a general solution. You can PM me if you do not want to make the code public.
Earlier we had a discussion on arrays, since the construct does not work for the same reason; and we ended up suggesting which works for many cases.
I upload Dump-tool(ramDump eeDump wordDump).
I found bug about WORD"c,".
I executed test1. This display datas defined by "c," on ram.
result is below; last loop[7 0 do .. loop]'s last is "62". Expected value is "7".
I checked [wvariable sample_2] by wordDump.
4062: sample_2 406C: 0024 1236 dovarw 406E: 0000 4070: 0201 01FF þu|\ 4072: 0403 0401 >èÞÅ\ \l| 4074: 0605 0603 4076: 4062 405F Hsample_There is no "7"."c," allocate 1byte. But if total number of "c," is odd, It seems last "c," is ignore.
And next word's "test1" start from odd address.
Sorry, I've been pre-occupied with Tunisia and Egypt.
Could you please open an issue with this information, I'll discuss it with Sal tomorrow
Thanks for your excellent work again.
EDIT: Sal says it sounds like a bug, "c," should allocate and initialize correctly in hub memory. He will look at it to fix in next release. Thanks!
I made Denpatokei(RadioControlledClock) using 4 cogs.
Loading below;
1_LCD_1.0.f
2_setup.f
3_monitor.f
4_diff.f
5_prop_clock.f
6_Denpatokei.f
Hardware:
LCD connection is same as LCD_1.0_20110116-0952.
RadioControlledCloack's signal(L-active) is connected to P4.
LED for signal is connected to P5.
P6 and P7 is used to measure error-time between RadioControlledCloack and prop_clock.
1_LCD_1.0.f cog5
LCD driver
2_setup.f
variables and constant
3_monitor.f cog4
monitoring signal's valid("0":800ms "1":500ms Marker:200ms L-active)
4_diff.f cog3
measure error-time between RadioControlledCloack and prop_clock
minus value mean prop_clock is fast.
5_prop_clock.f cog5
prop_clock and LCD's drive
6_Denpatokei.f cog6
decoding time-infornmation
This is for Japan. So this don't use in other country.
Executing WORD"denpatokei".
At first, prop_clock start on 2011 Jan01 (SAT) 00:00:00.
There is about -77msec for error-time between RadioControlledCloack and prop_clock.
I think this is strange. But not solved yet.
WOW! you have been busy! I'll show this to Sal next call.
These are great instructions, or at least a great start. Can you include them in the ZIP archive?
Do you want to post this on the google code site as an example?
I can't fix Denpatokei's bug.
1.
When synchronized to RadioControlledClock's signal, error-time is -77msec or -90msec,-82msec. (This value is not constant.)
Minus value means prop_clock is faster than RadioControlledClock's signal.
2.
After synchronized to RadioControlledClock's signal at Feb7 7:56, signal is off from propeller.
And then error-time is -95msec.
Next I connected RadioControlledClock's signal to propeller at 11:56.
error-time is 435msec.
Difference between 7:56 and 11:56 is 530msec.
This mean prop_clock delay 37usec per 1sec. (530msec/240min= 530msec/14400sec= 0.037msec/1sec)
I think code should be wrong.
But I can't solve it.
Please teach me what is wrong.
Sal looked at the code this morning, he said it looked pretty cool, so he probably will make an effort to look at it.
I don't know what equipment he has available, but most likely some will be different from your set up.
He may substitute low res VGA for LCD if displaying on the pc over serial has issues.
Also, will have to compare the north american radio time synchronization to the japan radio time.
That should give at least a start on locating the bug.
I think problem is solved.
About 1
Problem was code's time in front of begin-loop(LCD_init's time, and other) on prop_clock.f.
About 2
Propeller's frequency is a little little bigger than 80MHz.
So 1second for prop_clock is shorter than real 1second.
dT need to be added some value.
Now I'm adjusting time value.
mistake on #97
4_diff.f cog3
measure error-time between RadioControlledCloack and prop_clock
minus value mean prop_clock is fast. <-- wrong
minus value mean prop_clock delay.
mistake on #99
Difference between 7:56 and 11:56 is 530msec.
This mean prop_clock delay 37usec per 1sec. (530msec/240min= 530msec/14400sec= 0.037msec/1sec) <-- wrong
This mean prop_clock proceed 37usec per 1sec.
I use time-module for accesary item of ONKYO tuner.
Error time become small.
But about 10msec to -7msec.
This value is because using Forth?
I have no idea.
This cannot solve for me.
In #101, "About 2", prop frequency was discovered to be higher that 80MHz. Can you do some tests? Check the frequency for 1 second, and do this several times to see what variation is present. Then check the frequency over ten minutes, and do this several times to see if your first test result is reliable.
In #101 97, your minus value means the prop is slow? This seems to contradict the "About 2" result.
If the error were due to using forth, it would be consistent to the accuracy of your equipment; my second guess would be non-deterministic algorithm (like an "if statement" in a loop). But I did not analyze the code (other stuff is going on).
So, I thought you were trying to set the clock time from a signal received on the radio? How accurate do you need/expect to be?
If the issue you are trying to address is that there is an error between your prop and the ultra high precision clock that is used to set the radio, you should maybe reconsider. The Cesium clock (over whatever they use) will ALWAYS be more accurate than anything we could ever afford (as far as I know). The only thing I know of that is affordable and very accurate is GPS equipment, and I don't think we can build those from scratch. If your clock source over the radio is NOT from an ultrahigh precision (government) source, than the error could be from the radio station, since they (generally) use internet or telephone company time synchronization. The further from the original standard the less strict and less accurate, etc.
What you CAN do, is measure the difference after a period of time, many times, and determine the average and then the deviation. Then add in a correction factor once a day or once a week or what ever you determine works. Or, re-check the time signal once in a given period (day week month etc) and reset the clock. I believe if it is withing two seconds it is good enough for internet timing (ntp) and if it is off by two minutes per minute than it is as good as windows.
I have question.
It seems ">r" push 00000005 and 00001500 to RS although I thoght it shoud push only 00001500.
r> place 00002890 to stack.
Why "00002890"?
As far as I know, >r and r> should only be used in a definition, between ":" and ";" and cannot cross a definition or branching structure boundry.
: MyWord ... >r ... r> ... DO ... >r ... r> .... LOOP ... r> ...r> .... IF .... >r ... r> ... ELSE ....>r ... r> ...THEN .... ;Otherwise, subsequent words or loop structures change the return stack, and you get weird results.
>r and r> work on the return stack which is normally infrastructure and not directly manipulated by the user.
These provide a "sneaky way" to get an extra stack. I avoid playing with these if I can help it. I don't like "sneaky".
I avoid manipulating the return stack directly, and avoid >r and r> unless I'm starting with known working code for this reason.
But that's just me, I'm not advanced enough to use these effectively.
Folks more skilled then I use the return stack all the time, and successfully, I just prefer not to.
I'm going to make case-statement.
But cannot load.
I have no idea where is wrong.
Please teach me how to fix.
wvariable case_ptr wvariable case_work 12 allot : case case_work case_ptr W! 4 ; immediate : of swap 4 = if over l>w 1550 = if dup here W@ swap - swap W! nip else drop then swap dup rot = $C_a_0branch w, here W@ 1550 w>l 0 w, 5 else ." 123" _mmcs then ; immediate : endof 5 = if $C_a_branch w, here W@ case_ptr W@ case_work 12 + > if _mmcs else case_ptr W@ W! then case_ptr dup W@ 2+ swap W! 4 else ." 456" _mmcs then ; immediate : other swap 4 = if over l>w 1550 = if dup here W@ swap - swap W! nip else drop then 4 else ." 789" _mmcs then ; immediate : endcase 4 = if here W@ begin dup case_ptr W@ 2- dup case_work W@ < if 3drop 1 else W! case_ptr dup W@ 2- swap W! 0 then until else ." abc" _mmcs then ; immediate : test case 1 of ." this is 1" endof 2 of ." this is 2" endof 3 of ." this is 3" endof 4 of ." this is 4" endof 5 of ." this is 5" endof endcase ;Loading error occured
With reference to my previous post regarding create...does>, I have attached FACS.pdf which is a copy of my presentation at the 1986 Rochester Forth Conference. You will note that besides create .does>, I have used the defer..is words. I found a way to work around the absence of these words in PropForth. Attached find PropFacs.f, a working simulation of an analog computer. I have also attached a copy of a PropForth Quick Reference Guide (a first attempt) for which I would appreciate any comments.
NickL
WOW. Nice work! I'll discuss it with Sal next call. Thanks for the effort on this.
Most of the FACS material is way over my head, can the analog computer be used for processing audio, like the old EMS synthesizer?
The quick reference should be very handy, can I post it on the google code site?
Cool stuff!
You may post the Quick Reference on the google site. The analog computer was used to solve simulation models consisting of differential equations. It could also be used to simulate filters which might be used to processs audio data.
nickL
The quick reference is nice.
May I translate it to Japanese?
Yes you may.
NickL
I took your file and converted it to Word 2008(Mac) in 'compatibility mode' which means it is a .doc file that can be read by most anything. I adjusted margins and inserted some forced page breaks so it didn't break in the middle of any definition, etc. Its zipped and attached here. If this a problem, I will pull it. Thanks for all the great work. I am sufficiently a novice at Forth that I have been praying someone would create this.
I made dynamic_drive_7seg.
Brightness is dark than static-driveLED. So low resistor is good for dynamic_drive_7seg.
Drive -frequency for dynamic_drive_7seg can change from Tera-Term.
When drive -frequency on 120Hz, display on 7segLED is clear.
Flicker is seen less than 100Hz.
Though I tested 3digits, I think 8digits need higher frequency.
Display cannot do at 5872Hz.
Did you ever get this fixed?
Talked to Sal about this again, he's doing internet time for the spineret. He said the technique he uses is to have a cog update the time once a second using waitcnt. He lets it run for a minute, and finds how much the clock is off, and adjusts for the difference. Then he does the same after an hour, then after a day. He said he none of the clocks (he's working with several different props) have drifted since before Christmas.
Do you have a cog whose only job is to update the clock every second?
Thanks for your advice.
WORD"prop_clock" update date/hour/minute/second. And when seccessfully receiving RadioControlledClock's signal, prop_clock sinchronize to its signal.
I will try to have a cog update the time once a second using waitcnt later.
Now I'm going to re-write dynamic_drive_7seg to add driver forMCP3204.
I updated dynamic_drive_7seg_LED. (also changed name)
It display up to 8-digits.
Please check line26,27 inside dynamic_drive_7seg_LED.f.
I made normal LED-character and reverse&mirror letters.
Loading dynamic_drive_7seg_LED.f, next MCP3204.f.
After run WORD"demo", it quit to change frequency 10 times.
I tested up to 3digits. More than 3digits is no test.
WORD"disp_VR" display endlessly VR's value.
0-3.3V --> 000- 999
MCP3204's curcuit is #8 below:
http://forums.parallax.com/showthread.php?126285-Propforth-3.5-includes-Low-Res-VGA
I stop to post to PropForth-thread because of private matter.
Maby next is April.
Attached find an updated version of PropFacs. I have added many new blocks including function generators and a delay line. The SIN, LOG & ANTILOG blocks access the corresponding propeller data tables. I also added a word that stores simulation results on the eeprom.
Analog computers were parallel computers which could solve problems faster than, slower than, or in real time irrespective of the model complexity. However, a digital emulation of the analog computer runs at a time dependent on the model complexity ( no. of blocks). I haved added two words to the utility section of the program, pretime and postime, which can be used to measure the running time of specific models. As one would expect, the output functions (e.g., display) have the greatest effect.
I would like to have the ANSI word dpl added to the forth core. If the parser would accept numbers with decimal points (e.g. 0.43), and store the decimal point position, I could automate the scaling of parameters. I am also considering how to add a graphics output function to the emulation, so that the tv screen can emulate a XY-recorder.
I have not included examples in the attached program, since I am preparing a document which will list and define the facs words, including a variety of examples to show how analog computers were used.
NickL
Thanks, Professor Lordi. This is wonderful. I have posted it on the Google Code propforth downloads page.
i did some PROPELLER things before in spin and assembler.
Now i like to start a new project where the Propeller should be an intelligent IO processor between an ARM (Linux) and a real world IO of A/D D/A , counters and dig I/O chips etc.
There should be a serial interface from the ARM to the Propeller.
On the Propeller i would like to realize a "dictionary" of I/O commands, which can be loaded and actualized by the ARM.
M y ideas:
- I need a comunication channel to the ARM , thats the normal Forth terminal interface, i guess.
- - i need further one I2C and 2..3 SPI interfaces for the comunication with the I/O hardware
Now I would like to get some suggestions how to start with this project:
- would you recommend to do this in FORTH (speed requirements are not so high)
- is FORTH reliable enough for application running several weeks?
- any hints where and how to start?
-- are there any dictionaries/libraries for an I2C or SPI master ?
Any similar examples available?
I know a lot of newbie questions...
Regards
Markus
I am just setting up the prototype hardware
The key is Clearly Defined Requirements:
High Level Requirements - What is the end function of the final device in high level terms
System level Requirements - what systems are need to fulfill the high level requirements
Implementations Requirements - What functions do you need to implement to achieve the system described
This applies to any project, but seems more obvious when using forth.
ALSO - defining requirements is in itself an iterative process, as you define the next level, you get more insight into the previous level, and should go back and make adjustments. Generally, one does not want to start coding until all requirements are defined to the extent that you know what you have to code. This is "the easy way". Of course few do it this way, which is ok, it just takes longer to do it the hard way.
That being said you have a good start on your requirements.
1. Exactly what sensors/inputs do you have in mind right now specifically? Do no include "possibly.." and "maybe someday..." items, you will have enough work with today's specifics, and you can add new stuff later.
2. "Intelligent I/O processor" does not sound specific, do you mean the prop is to be I/O interface and pre-processor to the ARM? If so, this should not be a problem.
3. Propforth can easily be extended to have drivers for reading and controlling each sensor, we just need the specific parts you are targeting.
4. There are many choices for serial interface. If there are less than 28 or so, it is easy to have one line for each part. If there are more than that, the parts that are accessed less often can be place on a SPI bus and accesses with a shift register. The method used on the C3 board may be useful. Again, the specific parts will dictate which need a dedicated I/O line, which can be multiplexed, and what baud rate for a given throughput is needed.
5. Usually you can leave the regular forth interface (Rx/TX on line 30&31) as the serial interface, and use the other pins for inter-device communication. Its easier and much more convenient, and its nice to leave something just in case you get to load up every last pin later on.
6. As of 4.x, Sal runs his DEVELOPMENT for days at a time. The 3.x stuff was less stable in development, needed to reboot once a day, but the final apps ran indefinitely. Final apps on 4.x are (so far) completely stable (Sal has not found any evidence of instability yet).
7. We expect Next week or so to have a public release of v4.5. This should be fast enough for any application you have in mind; if it isn't, the bottlenecks can be optimized in assembler.
8. If you have specifics on the I2C and SPI we can look are implementing the drivers. I haven't played with I2C and SPI myself, but Caskaz and Sal have SD support nearly complete.
So the first step in getting stated is to state very specifically what sensor you want to monitor and define the data you wish to collect. Everything else is built on that.
Also, if you are working on an ARM and are interested in FORTH, please check out Frank Sargents Pygmy Forth. http://pygmy.utoh.org/
If you have any requirements/specifications that you can't discuss on the thread, PM me and I will try to help properly define them. This step is critical for success. You should be able to finish defining requirements by the time V4.5 is released.