The British empire managed to export the English language by colonizing and having all the local law provided only in English. Yes, there is a certain tyranny of which language people learn. After all, language is an important tool for survival vial access to knowledge and even legal recourse.
But it is TV, radio, the telephone, and the internet that are eroding many languages. Taiwanese has no written text, so Chinese usurps it. Movies may have translation in text at the bottom, but often English or some other dominant language is provided in the sound track. Media is reducing native languages.
With computers, language is as much a misnomer as saying economics is a science. But both are subject to another form of tyranny - professional jargon. If you don't use the lexicon we use, you are not one of us. And in a publish or perish environment that can be very serious business. So there is a peer pressure and tribal association factor that come into play when people want to share or hold back knowledge. After all, for many knowledge is power.
It is 6:32am and I still having figured out how to code this darn serial port.
With computers, language is as much a misnomer as saying economics is a science
You might have to elaborate on that. Given that programming languages are very rigorously defined they are more like maths than economics as far as I can see. I think Chomsky had a lot to say about that.
On the other hand programming languages are "natural languages" in the sense that we don't just use them to get a machine to do what we want we also use them to communicate human to human. They are used to express ideas about data structures, algorithms, object hierarchies and endless other things.
As for the "tyranny - professional jargon", well perhaps, as in all professions. However you may have noticed the huge impact of the open source movement here in recent times. Today huge junks of that "professional jargon" are laid open for public inspection and collaboration. Think, Java, Linux, web servers like Apache or browsers like Firefox and Chrome, or data bases or a million other things. When Google put together their new Go language it was all put out in the open, if you want to join in you can and hundreds have. Has any other profession voluntarily exposed itself like that? The fact that we are here discussing this on the Parallax forums is a fine example of what I mean.
8:01am 12 hours to go. Still trying to sort out the serial port problem.
@Heater,
Just the fact that computer languages are rigorously defined is enough to say it is not a true language. Creation of language is about the most free, almost anarchistic process there is. Anybody can coin a new word. Grammars are forgotten when immediate communication is required. People just scream "Run". Natural languages are messy, ever changing and have huge expanding vocabularies. Forth does this to some extent, but it still is more concerned with encoding and manipulating lifeless data, while natural language is really communicating. A computer language is quite limited.
Besides, language requires communication as its primary function. You mention this. Computer languages primarily communicate with a machine that might serve humans in communication. We really do not use computer languages to communicate with other people, we just use devices programmed by computers to do so. I certainly don't try to buy a latte at Starbucks by speaking C++ or Python. I use those 'languages' to control devices that manipulate and transmit data and can serve many functions aside from communication.
Natural language does have two mode of transmission, written and aural; and the computer does both well as the transmitting media -- nothing to do with the actual message. It has no business participating in altering the message.
My personal experience is that I truly appreciate 'open source' as I have a lot of limitations placed on me by being a native English speaker in Taiwan.
The simple fact is I think mainly in English and I have the most knowledge to recall in English. Without the Internet, I'd have a lot less to read and enjoy. But do you know anyone that thinks solely in a computer language? If you did, they might be considered autistic and unable to socialize.
From infancy, we learn language primarily in a social context as our family takes care of us and our needs. It is only much later that we get into abstractions of logic, set theory, numbers, and so on. This all usually occurs after puberty and the brain actually changes into a more defined and limited structure from there on. So the primary and first experiences of acquiring language are rather emotional and sensual, not logical or empirical. Systems of abstraction do creep in as education and we begin learning codes by counting numbers and saying the alphabet, but it is many years before we really begin to use these rather force fed codes in an intelligent manner. In fact, I have a lot of difficulty believing that one can effectively teach computer languages to a 9 year old child. The multiple levels of abstraction are rather absurd to a child in that stage of brain development.
Computer languages are a powerful and rigorous subset of natural languages, much as mathematics is. These aspects are quite wonderful in that they free humans from rather tedious tasks that were once done by armies of bookkeepers, and statisticians.
And yet, they can never be all the things that a natural language is. Just the fact that computers can create messages doesn't mean much. They can't listen and de-cypher meaning anywhere near as well as a human. The computer mimics speach as a parrot does. There may be a little bit of contextualization at the beginning, but it doesn't take long for the computer to become rather lost as communications explore more ideas and aspects of an exchange of ideas. The computer language focuses on data, not on meaning.
@Heater,
BTW, regarding Chomsky and his universal grammar. It has been disproven, and by computers no less.
It seems that extensive computer analysis of the structure of grammars in language samplings from all over the world demonstrated that the structure was statistically random. There is no underlying 'universal grammar' to be found.
Sorry, I don't have a reference on this one and I am citing it from memory, but I think I got the jist of it right.
Wulfden is a log cabin built at 1540 feet on the Western slope of Mount Mansfield. The house is totally off grid. My well, a shallow well (5 tiles deep) is about 400 feet away and 40 feet below the house. The well is a pretty strong reliable source, but it has its limits. The pump is a 3/4 horse Flotec shallow well jet fed by several hundred feet of #6/2. This pump fills a 600 gallon plastic cistern buried against the rear wall of the foundation. A second Flotec shallow well pump (1/2 horse) draws from the cistern and pressurizes the system.
I had been using a 15 Amp rated mechanical timer switch until it recently failed and ran all night, pumping the well almost dry and wrecking the impeller. I have wanted an electronic solution; so the timing was right.
CONSIDERATIONS
(1) recognize and act upon tank full and low battery voltage in power system.
(2) allow for well and battery recovery, That is too say let me dial in total pumping duration, but also an off and on times. Say that the pump will run for no longer than 5--15 minutes at a time and will stay off for 5-15 minutes between pumping sessions .
(3) If it proves reliable add 'tank low' detection and have it start to pump water on its own.
Hardware
(1) Wulfden Propeller Platform Through Hole CPU board
(2) Wulfden K107 LCD Serial BackPack and 4x20 display
(3) Crydom D1225, 25 Amp Solid State Relay
Software
(1) Tachyon Forth, ,compiled under SimpleIDE on an iMac. Details below ...
Propeller .:.:--TACHYON--:.:. Forth V21121114.1330
NAMES: $616C...7499 for 4909 (20713 bytes added) with 22528 bytes free
CODE: $0000...2A86 for 5977 (0883 bytes added) with 21882 bytes free
CALLS: 0608 vectors free
MODULES LOADED:
2713: pumptimer.fth Smart Shallow Well Pump Timer - 121124.1800
1840: EXTEND.fth Primary extensions to TACHYON kernel - 121113.1200
----------------------------------------------------------------
To Be Done
(1) Code is essentially complete. Some code is pretty darn good even if I say it myself. To balance that out, I will be the first to say some of it is pretty ragged.
(2) push button code needs debouncing. In a tight Tachyon loop at 80 MHz you just don't stand a chance!!! (Edit) push buttons are debounced. THEY need more work, BUT WORK a lot better than yesterday morning
I almost got my forth project done. An analog solar tracker using LED sensors with Dual all N-Chanel MOSFET H-Bridges.
This is using a QuickStart board. I usually build from scratch but I wanted to try a "Store Bought One".
The QuickStart and Plugboard are mounted to a piece of PC Board.
The H-Bridges use all N-Ch MOSFETS.
The Low side is IRF3708 and the High side is a conventional MOSFET in this case IRFZ48V.
The High Side driver uses a Depletion Mode MOSFET, DN2530, Level shifter similar to an I2C circuit. This is pulsed through a capacitor and rectifier to drive the gate on. A 2N7000 MOSFET turns the gate off.
And the schematic:
I'm using PropForth 5.0 "PropForthEEpromKernel".
I have a bunch of words I dump on top of the dictionary for testing and editing.
The actual tracker code is fairly short.
This is clearly not finished although the stuff does work.
1. I don't know how to get it to "Auto Start" after a power up or reset.
2. Timing must be experimented with.
And my forthware:
\ Forget back to fence, redoo fence, and list the words
forget fence : fence ; h1B emit c" [2J" .cstr words
\ Forget back to fence, and list the words
forget fence h1B emit c" [2J" .cstr words
\ Forget back to fence, redoo fence, and list the words
forget fence : fence ; cb words
\ Forget back to fence, and list the words
forget fence cb words
fl
\ --------------- words added to PropForth -----------------
decimal
: fence ;
0 wvariable baseold
\ .hex ( n -- ) emit a single hex digit
: .hex hF and d48 + dup d57 > if d7 + then emit ;
\ .x ( n -- ) emit a single digit in the current base
: .x base W@ u/mod drop d48 + dup d57 > if d7 + then dup d93 > if d3 + then emit ;
\ .xn ( n1 n2 -- ) emit n1 as an n2 place number in the current base
: .xn dup >r 0 do base W@ u/mod loop drop r> 0 do .x loop ;
\ Display functions
\ .bn ( n1 n2 -- ) emit n1 as an n2 (1 to 32) place binary number
: .bn dup 0 do 2dup d32 swap - rev 1 i lshift and if ." 1" else ." 0" then loop 2drop ;
\ .dn ( n1 n2 -- ) emit n1 as an n2 place decimal number
: .dn dup >r 0 do d10 u/mod loop drop r> 0 do .hex loop ;
\ .hn ( n1 n2 -- ) emit n1 as an n2 place hex number
: .hn dup >r 0 do d16 u/mod loop drop r> 0 do .hex loop ;
\ .xn ( n1 n2 -- ) emit n1 as an n2 place number in the current base
: .xn dup >r 0 do base W@ u/mod loop drop r> 0 do .x loop ;
\ ------------------- ascii escape sequences ------------------
\ ascii escape sequences start with ESC
\ Clearly Plagerized from "prof_braino"
: esc d27 emit ; \ ESCAPE
: csi esc d91 emit ; \ [
: capK ." K" ; \ capital K
: smallm ." m" ; \ small m
\ .digits ( n - ." emit as decimal characters" ) for AT convert 0-99 for emit
: .digits dup d9 > if d2 else 1 then .dn ;
\ at ( x y - ) put cursor at x ; y line / column from upper left corner
: at csi .digits ." ;" .digits ." f" ;
: home csi ." 1;1f" ;
: clear csi ." 2J" ;
: preclear csi ." 1J" ;
: postclear csi ." 0J" ;
: cls home clear ;
: clear-eol csi d0 .digits capK ;
: clear-bol csi d1 .digits capK ;
: clear-line csi d2 .digits capK ;
\ attributes esc[d#;d#m = csi d#;d#m
: atoff csi d48 emit smallm ; \ 0 off
: bold csi d49 emit smallm ; \ 1 bold
\ : faint csi d50 emit smallm ; \ 2 faint ?
\ : italic csi d51 emit smallm ; \ 3 italic ?
: underscore csi d52 emit smallm ; \ 4 underscore (mono) ?
\ : sblink csi d53 emit smallm ; \ 5 slow blink PINK
\ : fblink csi d54 emit smallm ; \ 6 fast blink
: reverse csi d55 emit smallm ; \ 7 reverse
\ : conceal csi d56 emit smallm ; \ 8 conceal
\ : crossout csi d57 emit smallm ; \ 9 crossed out ?
\ there are more...
\ ( n -- ) Curser movements
: cup csi .digits ." A" ; \ up
: cdown csi .digits ." B" ; \ down
: cforward csi .digits ." C" ; \ forward
: cback csi .digits ." D" ; \ backward
: csave csi ." s" ; \ save position
: crestore csi ." u" ; \ restore position
\ ( -- ) graphics mode Color attributes Forground/Background
: black csi d30 .digits smallm ;
: onblack csi d40 .digits smallm ;
: red csi d31 .digits smallm ;
: onred csi d41 .digits smallm ;
: green csi d32 .digits smallm ;
: ongreen csi d42 .digits smallm ;
: yellow csi d33 .digits smallm ;
: onyellow csi d43 .digits smallm ;
: blue csi d34 .digits smallm ;
: onblue csi d44 .digits smallm ;
: magenta csi d35 .digits smallm ;
: onmagenta csi d45 .digits smallm ;
: cyan csi d36 .digits smallm ;
: oncyan csi d46 .digits smallm ;
: white csi d37 .digits smallm ;
: onwhite csi d47 .digits smallm ;
\ ----------------- end ascii escape sequences ----------------
\ .sx ( -- ) prints out the stack with a letter tag on the end Non-Destructivly
: .sx ." ST: " $C_stPtr COG@ 2+ dup $C_stTop < if $C_stTop swap - 0 do $C_stTop 2- i - COG@
.long space loop else drop then ; \ removed cr from end of the word st?
: .s0 .sx ." <0" cr ; : .s1 .sx ." <1" cr ; : .s2 .sx ." <2" cr ; : .s3 .sx ." <3" cr ;
: .s4 .sx ." <4" cr ; : .s5 .sx ." <5" cr ; : .s6 .sx ." <6" cr ; : .s7 .sx ." <7" cr ;
: .s8 .sx ." <8" cr ; : .s9 .sx ." <9" cr ; : .sA .sx ." <A" cr ; : .sB .sx ." <B" cr ;
: .sC .sx ." <C" cr ; : .sD .sx ." <D" cr ; : .sE .sx ." <E" cr ; : .sF .sx ." <F" cr ;
: .sG .sx ." <G" cr ; : .sH .sx ." <H" cr ; : .sI .sx ." <I" cr ; : .sJ .sx ." <J" cr ;
: .sK .sx ." <K" cr ; : .sL .sx ." <L" cr ; : .sM .sx ." <M" cr ; : .sN .sx ." <N" cr ;
: .sO .sx ." <O" cr ; : .sP .sx ." <P" cr ; : .sQ .sx ." <Q" cr ; : .sR .sx ." <R" cr ;
: .sS .sx ." <S" cr ; : .sT .sx ." <T" cr ; : .sU .sx ." <U" cr ; : .sV .sx ." <V" cr ;
: .sW .sx ." <W" cr ; : .sX .sx ." <X" cr ; : .sY .sx ." <Y" cr ; : .sZ .sx ." <Z" cr ;
\ -------------------------------------------------------------
\ .sd ( -- ) prints out the stack as 10 place decimal numbers Non-Destructivly
: .sd ." STD:" $C_stPtr COG@ 2+ dup $C_stTop < if $C_stTop
swap - 0 do $C_stTop 2- i - COG@ d10 .dn space loop else drop then cr ;
\ .sh ( -- ) prints out the stack in hex Non-Destructivly
: .sh ." STH:" base W@ baseold W! hex .sx cr baseold W@ base W! ;
\ cb ( -- ) clear TeraTerm scroll buffer assuming TeraTerm is set to 512 lines
: cb d509 0 do cr loop bold blue 0 0 at clear ;
\ pins? ( -- ) samples the current status of all the io pins and prints them to the terminal
: pins?
d32 0 do ." " i d2 .dn loop cr
d32 0 do i px? if ." HI" else ." LO" then loop cr
d32 0 do dira COG@ i rshift 1 and if ." OT" else ." IN" then loop cr ;
\ Alternate method
\ pins? ( -- ) samples the current status of all the io pins and prints them to the terminal
\: pins?
\ d32 0 do ." " i d2 .dn loop cr
\ d32 0 do i px? if ." ^" else ." v" then loop cr
\ d32 0 do dira COG@ i rshift 1 and if ." <" else ." >" then loop cr ;
\ enablesteppers ( -- ) enable the stepper outputs and set to 0
: enablesteppers dira COG@ h000FF000 or dira COG!
ina COG@ hFFF00FFF and h00000000 or outa COG! ;
\ stepaz ( n -- ) n lowest 2 bits converted to 5 wire step code
: stepaz b11 and 1 swap lshift h0001000 * ina COG@ hFFFF0FFF and or outa COG! ;
\ stepalt ( n -- ) n lowest 2 bits converted to 5 wire step code
: stepalt b11 and 1 swap lshift h0010000 * ina COG@ hFFF0FFFF and or outa COG! ;
\ fence
: fence ;
\ -------------- end words added to PropForth -----------------
decimal
fl
\ Number of charging cycles for the High Side MOSFET
wvariable hbcharge
\ Cycle time in ms for eack half cycle
wvariable hbtime
\ Reset sensor capacitor time
wvariable hbresettime
\ Initialize the I/O pins
: hbinit 23 pinhi 22 pinlo 21 pinlo 20 pinhi 19 pinhi 18 pinlo 17 pinlo 16 pinhi
24 16 do i pinout loop
8 pinin 8 pinlo 9 pinin 9 pinlo ;
: aleft 21 pinhi
hbcharge W@ 0 do
23 pinlo hbtime W@ delms
23 pinhi hbtime W@ delms
loop
21 pinlo ;
: aright 22 pinhi
hbcharge W@ 0 do
20 pinlo hbtime W@ delms
20 pinhi hbtime W@ delms
loop
22 pinlo ;
: bleft 17 pinhi
hbcharge W@ 0 do
19 pinlo hbtime W@ delms
19 pinhi hbtime W@ delms
loop
17 pinlo ;
: bright 18 pinhi
hbcharge W@ 0 do
16 pinlo hbtime W@ delms
16 pinhi hbtime W@ delms
loop
18 pinlo ;
\ Reset the LED Capacitors
: hbreset 8 pinout 9 pinout hbresettime W@ delms 8 pinin 9 pinin ;
\ read the sensors
: hbled 9 px? 1 and 2 * 8 px? 1 and + ;
: fence ;
1 hbcharge W!
1 hbtime W!
100 hbresettime W!
hbinit
: LED hbreset
1000 0 do hbled
dup 0 = if then
dup 1 = if aleft then
dup 2 = if aright then
dup 3 = if then
drop
loop ;
: MainLoop 1000000 0 do LED loop ;
Do you want a complete image of the code as it exists in the QuickStart?
(Heck I don't know how to do it anyway.)
OK, it's 1:45 AM central time so it would be 11:45 PM Pacific time.
Hey it's still the weekend. Am I still within the allotted time period? Ha Ha!
@Brian
Very nice real world usefulness -- it could be a real winner. From what I understand is Forth code gets better with age. In other words, once one has a working prototype - the code can be refined and improved at one's leisure. Off-the-grid is definitely a situation that needs good low-power solutions.
It is 3:47pm here in old Taiwan. Technically the competition has about 4 hours to go, but it would take quite a bit for me to resolve what I want to do.
Tachyon rocks. It seems easily accessible to the user. And that is just as important as lightning fast speed.
While I have made more sense out of what PropForth offers up as a RS232 serial interface, the tutorial doesn't actually demonstrate a hard-wire loop back that reaches to the world outside the Propeller. It has the console communicate with a far destination cog via a rather lengthy chain. The features that allow communication to flow are not clearly mentioned. A hard-wire loop back that produces an echo would be much more educational as I could connect and disconnect the wire to confirm the i/o pins are interrupted.
I'd have to say that PropForth plays very nicely with itself. But I have to really wonder what that is about. It seems to be code only for code's sake. I just can't see much 'user-friendly' real world connectivity for all the claims of speed and elegance. While I can easily roll my own SPI, I2C, and maybe even 1-wire; the asynchronous side of support is not very clear.
At some point, for RS232 links and for RS422 or RS485 that provide long wire transmits and receive it has to be simpler than that, and use less cogs or not much is left over to process other items; such as control of your pumps, a real-time clock, and so on. You may want to use RS485 with your pump control as the wire can communicate for kilo-meters.
At this point, I have pretty much given up on getting my half-duplex bi-directional link configured and am attempting to just have a hard-wire serial loop-back that might take only 3 cogs. But two would really be ideal.
I guess the next phase is to try to use Tachyon for the chopstick printer and the Dec 4th contest deadline.
I wonder what Prof Braino has to show us. After all, it is really his opportunity to demonstrate the usefulness of PropForth. He likely knows it better than any of us. And I see we have another PropForth entry - a solar tracker.
Brain Reily for Tachyon - pump and battery monitoring and control
Duane C Johnson for PropForth - Solar tracker with a very nice working fully mos-fet h-bridge
Loopy Byteloose for PropForth - Stepper motor examples for 5 wire unipolar 5v 200ma steppers.
Have I missed anybody? I guess Mindrobots will decide later today.
Do you want a complete image of the code as it exists in the QuickStart? (Heck I don't know how to do it anyway.)
If you want to present the code so sometone else can reproduce it, I would suggest:
1) post your code above as a file (Duane_solar_tracker.f or similar)
2) reference the exact version of forth you used ( Propforth-V5.03-20120505.zip ?) and maybe include a link to it
3) name the spin file from the kernel (..V5.03\CurrentRelease\PropForthEEprom PropForthEEpromFastSerialKernel.spin )
4) incldue any other extensions needed to run the final application
This way, anybody could reproduce at least the software part of it.
Cool stuff!
If you want to share this as an example project it could be posted on the propforth wiki and as a download.
Well, a day late and a dollar short... as they say.
It seems I finally got a hard-wire loopback to confirm active RS232 communications. And this process only uses 3 cogs to observe. When actually in operation the i/o may only use 2 cogs.
In general, every asynchronous serial port removes the cog from being a Forth stack machine and it becomes a serial i/o state machine (each Forth cog is configured with a dormant asynch serial i/o as well as active Forth stack machine - the function can be toggled from one to the other).
So one creates a serial cog and attaches it to another cog to have it tied to an active Forth stack machine. While in theory, I can have all 8 cogs configured as serial devices, there would be no Forth stack machines to do anything useful.
And while one can link two serial cogs i/o pins to i/o pins (lets call that face to face), that is rather useless as I suspect a synchonous link would be much faster and more stable.
So it seems that the best one can do is to get 3 serial ports used by 3 Forth stack machines on the 8 cogs. One cog remains the serial link to the dumb terminal and the remaining cog would be available for whatever comes to mind (maybe a real time clock?)
Somehow I just knew this was going to be late.
And now I need to do some more testing to see if I can actually get a bi-directional asynchronous serial over one wire. If that does work, I still have enough other cogs to drive the steppers and print a chopstick.
Maybe I should change my blood pressure medication ;-0
What an odyssey.
It should be fairly easy to write a bit-bang serial port driver in Forth. I don't know if PropForth is fast enough to do this, but it might work at half-duplex 9600 baud. This way you could implement it in a single cog. It should work as long as you can save the received byte in a buffer and wait for the next byte in less than one-half bit time. If the sender uses more than one stop bit you would have more time in between bytes.
Hi Dave,
Well I have already gotten 2 requests for printed chopsticks. So I am trying to go forward with this.
I really have only studied asynchronous serial on the SX chips, but having 32 bits may actually make the whole process easier that with 8 bit registers. Mostly it is as you mentioned, about timing. One has to set up a sampling cycle 4 to 16 times faster than the baud rate and then poll a pin for incoming activity. Output is simpler as one has complete control of the timing.
I am just try to work with the system in place for now. There are two configuration words serial and _serial which can set the baud rate and the RX and TX pins. That's the easy part. Then there is a word sersetflags that activates serial communications. And then there is the attaching to another cog with an active Forth stack machine via yet another word ioconn. One verifies the setup with cog? queries and serflags? queries.
Once all that is established, it is a matter of not disturbing the setup and communicating with the Forth cog tied to the serial cog via the console with something like the phrase c" anyword " 0 cogx for the 0 cog.
I don't know if this makes any sense to you at all, but that's what I've discovered so far. The trick is to reach the TX buffer with output from the console, have it loop-back through a physically hardwired loop, and to verify the data has arrived via the hardwire loop-back and not via some other means.
Propforth has eight locations of 228 bytes in Hub Ram allocated to serial communications and these appear to be intended to support the asynchronous serial driver that is already loaded within the cog, but dormant when the cog is initially loaded with Forth machine. There is a flag that toggles between the two service functions.
The serial hub ram includes a circular rx and a circular tx buffer. All I get about the serial services is the words that initialize them, the actual driver is in machine code and not easy to de-cypher. And again in hub is a location that is used to pass single bytes at a time from one cog to another when an adjacent address asserts a 'ready to receive' code. Received bytes after clearing the buffer go to the Forth cog and seem to enter the same input stream that arrives at the interpreter.
So I keep playing with this and am trying to figure out what Sal Sanci had in mind. The documentation does not provide a formal focused discussion of reaching the outside world with an asyn serial port and locating all the words that apply are awkward as they are not presented applied to their use - just alphabetical listings. So I seem to be collecting information from 4 or 5 different places and guess a lot .
Since the buffers are circular, I am not quite sure of how to clear them. I suppose I could just write to the whole contiguous block of bytes and not concern myself with what the pointer is or where it might be located. I may need to clear the RX and I presume writing h00 throughout will be enough.
I am sure that might be more than you wanted to know.
It is it's <Read pointer that say to You if it is empty.
If both Read pointer and Write pointer have same Value = Buffer is empty
If Read pointer < Write pointer buffer have bytes to read.
But Read pointer will never be bigger that Write pointer ---> That indicate You have error
Hi Dave,
Well I have already gotten 2 requests for printed chopsticks. So I am trying to go forward with this.
Propforth has 228 bytes in Hub Ram allocated to serial commuications and it appears to be intended to support the asychronous serial driver that is already loaded, but dormant when the cog is loaded with Forth machine. This includes a circular rx and a circular tx buffer. All I get about the serial services is the words that initialize them, the actual driver is in machine code and not easy to de-cypher.
So I keep playing with this and am trying to figure out what Sal Sanci had in mind. The documentations does provide a formal discussion of reaching the outside world with a asyn serial port and locating all the words that apply are awkward as they are not presented applied to their use - just alphabetical listings. So I seem to be collecting information from 4 or 5 different places and guess a lot .
Since the buffers are circular, I am not quite sure of how to clear them. I may need to clear the RX and I presume writting h00 throughout will be effective as they store ASCII code.
@Saphia,
Thanks, I haven't been able to verify where those pointers are. But while the hub ram has 228 or maybe 224 bytes set aside for communications, I have info about only 200 to 204 of the locations. I suspect my pointers are amongst those extra locations.... unless they are sitting in the cog ram.
It should be fairly easy to write a bit-bang serial port driver in Forth. I don't know if PropForth is fast enough to do this, but it might work at half-duplex 9600 baud. This way you could implement it in a single cog. It should work as long as you can save the received byte in a buffer and wait for the next byte in less than one-half bit time. If the sender uses more than one stop bit you would have more time in between bytes.
bit bang is very easy in forth, notice propforth at 230500 baud and Tachyeon at 3 million over bluetooth.
loopy is having trouble separating the individual transmit and recieve functions out of the entire integrated and opimized development environment.
cog7 runs the prop serial for the development environment
coig6 run the forth kernel for th developer
cog5 runs one party for the loopback test
cog4 runs the other party for the loopback test
i don't recall another cog. being involved, unless it the one buffering and interpreting the soucre code
,
but, only one. cog is needed for the serial itself, and can easily run up to 3 million baud async
there are two entries, one using Tachyon, one using propforth. both authors are quite capable.
Could we get some feedback as to how much trouble it would be to port the application to another flavor of forth on the prop?
i would expect that the main task would be converting the format for the number literals. there also should be a couple thngs that are "done different" on a given flavor, but for the most part they should be straight forward.
i'm interest to hear this would be easy, doable, or not possible; and what the biggest issue would be.
thanks in advance if duane or brian want to give this a look.
Wait a minute, 1M Baud is 1 micro second per bit.
At a Prop clock speed of 80MHz we get 20 million PASM instructions per second.
That's 20 instructions per bit, at 1M Baud.
Crank that up to 3M Baud and we only have a tad over 6 instructions per bit.
I conclude that 3MB is possible in PASM, or even in some compiled code, but for sure not possible with an interpreted language like Forth.
If you want that COG to also handle full duplex we are looking at a lot slower.
Wait a minute, 1M Baud is 1 micro second per bit.
At a Prop clock speed of 80MHz we get 20 million PASM instructions per second.
That's 20 instructions per bit, at 1M Baud.
Crank that up to 3M Baud and we only have a tad over 6 instructions per bit.
I conclude that 3MB is possible in PASM, or even in some compiled code, but for sure not possible with an interpreted language like Forth.
If you want that COG to also handle full duplex we are looking at a lot slower.
Forth in general, and propforth in particular, are only interpreted WHEN THE SOURCE IS COMPILED on input. Unlike basic, which always interprets, propforth executes. Mostly jmp instructions, that's why its so darned fast. Basically, forth is a way to run assembler without having to do all the work in assembler. Only the interesting parts need be examined and implemented in assembler, the boring parts are done in simple forth (and executed at nearly assembler speed).
Propforth has been de-rated to 230400 baud as Sal saw an error once at higher speeds, but he said he might have tripped over the wire or something. But we know Tachyon runs at 3M from Peter. We should hear from him, maybe I'm crazy again, its happened before.
EDIT - Here we go , the link that states Tachyon throughput.
prof_braino, could you run the code shown below on PropForth? It tops out at about 12,500 baud on pfth. I'm curious what kind of speed you would get on PropForth. It seems like to be able to get 230,400 baud you would have to implement some of the code in assembly. Does PropForth compile source directly into assembly?
: waitcnt begin dup cnt@ - 0< until ;
: putch 256 or dup + clkfreq@ 9600 /
11 >r
cnt@
begin
r> 1- dup >r
while
rot dup
30 lshift
outa!
1 rshift
swap rot dup rot +
waitcnt
repeat
r> 2drop 2drop
;
: test cnt@ 65 putch cnt@ swap - 80 / . ;
... the interesting parts need be examined and implemented in assembler,
Exactly, why advertise Forth as running at assembler speed if you are actually using assembler to get the job done?
..the boring parts are done in simple forth (and executed at nearly assembler speed).
No idea what that means "and executed at nearly assembler speed". Even if it only took two asm instructions to implement every Forth word that would be half as fast. I'm sure it must be an order of magnitude worse that that even for simple operations.
Both Tachyon and PropForth have serial routines coded in assembly. Propforth runs full duplex serial in its own COG. This assembler word can (and is) started up in other COGs for Prop to Prop communication. Tachyon runs a high speed optimized serial receiver in its own COG and then has bit banging transmit embedded in the kernel code;
[CENTER][COLOR=#999999][FONT=Ubuntu Mono]{[/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono] [/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono][B]****** CONSOLE SERIAL OUTPUT ******[/B][/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono] [/FONT][/COLOR][COLOR=#999999][FONT=Ubuntu Mono]}[/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono][/FONT][/COLOR][/CENTER][COLOR=#000000][FONT=Ubuntu Mono]' Transmit the character that is in the tos register[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono]' [/FONT][/COLOR]
[COLOR=#ffff00][FONT=Ubuntu Mono][B]transmit[/B][/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono] or outa,txmask ' ensure output is high[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] or dira,txmask ' make it an output[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] or tos,stopmask ' fill up with stop bits[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] shl tos,#1 ' add in start bit as first bit[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] mov txcnt,#10 ' 8 data bits + 1 start + stop bits[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono]txdat mov R0,cnt[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] add R0,bit_ticks[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono]txbit shr tos,#1 wc ' lsb first[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] muxc outa,txmask ' output bit[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] waitcnt R0,bit_ticks[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] djnz txcnt,#txbit 'another bit to transmit?[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] jmp #DROP[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono][/FONT][/COLOR]
...back to picking a winner.....I bet the suspense is killing at least 2 people!!
to get 230,400 baud you would have to implement some of the code in assembly. Does PropForth compile source directly into assembly?
Yes, well no, not directly. It compiles forth into the dictionary, and it yeilds executable instructions with extra overhead that makes it work in the dictionary. On the other hand, the (manual) optimizations generally end up in straight assembly. Instead of jumping to each each assembly implementation for each lowest level word and back to the highest level word, optimizing generally remove all the extra jumps. And it turns into straight assemble for the most part, with a "forth interface" wrapper around it instead of around each individual word. Removing the redundant jumps has a big effect on often executed code.
The pre-optimized propforth up to version 4 ran at 19.2 very happily with no reported problems, so we think it was bullet proof with lots of overhead. I never traced through the code, so I don't know if Sal did any "tricks", but i don't think he did.
prof_braino, could you run the code shown below on PropForth?
Somebody could, but I'm not the best candidate. I'm not set up very well for test here. We should get somebody smart to analyze it properly.
...what does cnt@ do? Is that cnt C@ to me? is clkfreq@ just clkfreq C@? I bet those should be COG@
I don't have while...repeat; I have begin...until so I have to switch this around...
OK i guess i'm testing after all. Give me a couple minutes here......
EDIT - OK, I give up. I can't figure out what its intended to do, and I don't know what my code is trying to achieve. I would need to load pfth first, and figure out the stack notes, and break up putch into three easier small words, and recode the loop. I would also need check that all the little words work the way I imagine they might.
It really needs somebody familiar with both pfth and propforth, or we have to go through the learning curve for what we don't know. Sorry that's the best I got right now. Maybe when I get back to the lab I can try it out.
OK, This is really hard judging and it makes me really, really appreciate the torture and anguish we put MattG through when he has a contest and we flood him with entries. (Unless he really does just count the sprinkles on a donut and divide by the number of letters in that day's Garanimal's name)
First off, Loopy gets a more than honorable mention for his determination in attempting this while also learning Forth. Plus his dogged tenacity to dig through code and words looking for that elusive half-duplex serial connection!! Let's cheer him on for the Forth of December contest because when you search your heart, you really know you too want a set of printed chopsticks and want to see the video!!
I can't find the actual source code for PropForth's serial routine but it is assembler, I'm sure. Here's the word that creates the dictionary entry (and the code itself) I believe this is the base-64 assembler encoding that has been mentioned elsewhere.
As you stated previously, it needs to be down to pure assembler in order to obtain the speeds it delivers on eother implementation. The Forth inner interpreter alone, if it were invovled, would inject the usual 4-5 time overhead of any bytecode (or thread chasing) interpreter. You can't reach "near assembler speeds" unless you are writing and running assembler.
oh, yeah, the contest winner.....looks like I got distracted......sorry......happens to me a LOT!!
@prof_braino, I modified my code so it would run under PropForth, and it ran at an equivalent baud rate of about 6,500. That's about half the speed of PASM pfth. The 230,400 baud that you quoted must be from the assembly routine that mindrobots described, and not from a bit-banging Forth routine. I was rather surprised to see that PropForth doesn't support WHILE. That's a very basic and commonly used word.
OK, the WINNER IS....wow, this was really difficult!
I can see using either of these projects in some of my projects (should I ever really complete a project)
Brian's Pump timer had practical application in a time of needs and when you read through his code, you can really see the elegance of Forth and how the application was built. This is ready to go for any similar application you may have around the house with very little modification.
Duane's project on the other hand was a tour de force in hardware and software that shows the benefits of building and testing in a Forth environment. While not a stand alone project per se (unless I'm missing something, which if I am please correct me) it is a key foundation piece for any project needing the capability to do solar tracking.
While the turnout was less than expected, the final results were excellent!!
...and the WINNER is just by the slightest edge...BRIAN and his Smart Shallow Well Pump Timer
YAY!! HUZZAH! HUZZAH!!! The first Forth Contest has a WINNER!!!!
Congratulations, Brian!!!
We'll need to get your mailing information to Ken for the prize distribution!
I wish I had something to offer the other contestants other than a hearty "Well Done!!" and a reminder to keep plugging away on your projects because you are all eligible to compete in Peter's Forth of December contest!!!!
Thank you all for competing, commenting or just watching the thread go by!
Cool. How about if we sweeten the deal with a brand new, FREE Human Interface Board for the QuickStart? These aren't even released yet but I can grab one from the production line before I leave for Thanksgiving.
Forth and Tachyon fans, rise up! There's new hardware ready to be sent to whoever Rick chooses after Thanksgiving!
What is this Human Interface Board? Do you have a description of it?
Comments
But it is TV, radio, the telephone, and the internet that are eroding many languages. Taiwanese has no written text, so Chinese usurps it. Movies may have translation in text at the bottom, but often English or some other dominant language is provided in the sound track. Media is reducing native languages.
With computers, language is as much a misnomer as saying economics is a science. But both are subject to another form of tyranny - professional jargon. If you don't use the lexicon we use, you are not one of us. And in a publish or perish environment that can be very serious business. So there is a peer pressure and tribal association factor that come into play when people want to share or hold back knowledge. After all, for many knowledge is power.
It is 6:32am and I still having figured out how to code this darn serial port.
You might have to elaborate on that. Given that programming languages are very rigorously defined they are more like maths than economics as far as I can see. I think Chomsky had a lot to say about that.
On the other hand programming languages are "natural languages" in the sense that we don't just use them to get a machine to do what we want we also use them to communicate human to human. They are used to express ideas about data structures, algorithms, object hierarchies and endless other things.
As for the "tyranny - professional jargon", well perhaps, as in all professions. However you may have noticed the huge impact of the open source movement here in recent times. Today huge junks of that "professional jargon" are laid open for public inspection and collaboration. Think, Java, Linux, web servers like Apache or browsers like Firefox and Chrome, or data bases or a million other things. When Google put together their new Go language it was all put out in the open, if you want to join in you can and hundreds have. Has any other profession voluntarily exposed itself like that? The fact that we are here discussing this on the Parallax forums is a fine example of what I mean.
@Heater,
Just the fact that computer languages are rigorously defined is enough to say it is not a true language. Creation of language is about the most free, almost anarchistic process there is. Anybody can coin a new word. Grammars are forgotten when immediate communication is required. People just scream "Run". Natural languages are messy, ever changing and have huge expanding vocabularies. Forth does this to some extent, but it still is more concerned with encoding and manipulating lifeless data, while natural language is really communicating. A computer language is quite limited.
Besides, language requires communication as its primary function. You mention this. Computer languages primarily communicate with a machine that might serve humans in communication. We really do not use computer languages to communicate with other people, we just use devices programmed by computers to do so. I certainly don't try to buy a latte at Starbucks by speaking C++ or Python. I use those 'languages' to control devices that manipulate and transmit data and can serve many functions aside from communication.
Natural language does have two mode of transmission, written and aural; and the computer does both well as the transmitting media -- nothing to do with the actual message. It has no business participating in altering the message.
My personal experience is that I truly appreciate 'open source' as I have a lot of limitations placed on me by being a native English speaker in Taiwan.
The simple fact is I think mainly in English and I have the most knowledge to recall in English. Without the Internet, I'd have a lot less to read and enjoy. But do you know anyone that thinks solely in a computer language? If you did, they might be considered autistic and unable to socialize.
From infancy, we learn language primarily in a social context as our family takes care of us and our needs. It is only much later that we get into abstractions of logic, set theory, numbers, and so on. This all usually occurs after puberty and the brain actually changes into a more defined and limited structure from there on. So the primary and first experiences of acquiring language are rather emotional and sensual, not logical or empirical. Systems of abstraction do creep in as education and we begin learning codes by counting numbers and saying the alphabet, but it is many years before we really begin to use these rather force fed codes in an intelligent manner. In fact, I have a lot of difficulty believing that one can effectively teach computer languages to a 9 year old child. The multiple levels of abstraction are rather absurd to a child in that stage of brain development.
Computer languages are a powerful and rigorous subset of natural languages, much as mathematics is. These aspects are quite wonderful in that they free humans from rather tedious tasks that were once done by armies of bookkeepers, and statisticians.
And yet, they can never be all the things that a natural language is. Just the fact that computers can create messages doesn't mean much. They can't listen and de-cypher meaning anywhere near as well as a human. The computer mimics speach as a parrot does. There may be a little bit of contextualization at the beginning, but it doesn't take long for the computer to become rather lost as communications explore more ideas and aspects of an exchange of ideas. The computer language focuses on data, not on meaning.
BTW, regarding Chomsky and his universal grammar. It has been disproven, and by computers no less.
It seems that extensive computer analysis of the structure of grammars in language samplings from all over the world demonstrated that the structure was statistically random. There is no underlying 'universal grammar' to be found.
Sorry, I don't have a reference on this one and I am citing it from memory, but I think I got the jist of it right.
Wulfden is a log cabin built at 1540 feet on the Western slope of Mount Mansfield. The house is totally off grid. My well, a shallow well (5 tiles deep) is about 400 feet away and 40 feet below the house. The well is a pretty strong reliable source, but it has its limits. The pump is a 3/4 horse Flotec shallow well jet fed by several hundred feet of #6/2. This pump fills a 600 gallon plastic cistern buried against the rear wall of the foundation. A second Flotec shallow well pump (1/2 horse) draws from the cistern and pressurizes the system.
I had been using a 15 Amp rated mechanical timer switch until it recently failed and ran all night, pumping the well almost dry and wrecking the impeller. I have wanted an electronic solution; so the timing was right.
CONSIDERATIONS
(1) recognize and act upon tank full and low battery voltage in power system.
(2) allow for well and battery recovery, That is too say let me dial in total pumping duration, but also an off and on times. Say that the pump will run for no longer than 5--15 minutes at a time and will stay off for 5-15 minutes between pumping sessions .
(3) If it proves reliable add 'tank low' detection and have it start to pump water on its own.
Hardware
(1) Wulfden Propeller Platform Through Hole CPU board
(2) Wulfden K107 LCD Serial BackPack and 4x20 display
(3) Crydom D1225, 25 Amp Solid State Relay
Software
(1) Tachyon Forth, ,compiled under SimpleIDE on an iMac. Details below ...
To Be Done
(1) Code is essentially complete. Some code is pretty darn good even if I say it myself. To balance that out, I will be the first to say some of it is pretty ragged.
(2) push button code needs debouncing. In a tight Tachyon loop at 80 MHz you just don't stand a chance!!! (Edit) push buttons are debounced. THEY need more work, BUT WORK a lot better than yesterday morning
(3) find a case and package it up
(4) wire it into the pump circuit.
(5) I will update the code periodically
I almost got my forth project done. An analog solar tracker using LED sensors with Dual all N-Chanel MOSFET H-Bridges.
This is using a QuickStart board. I usually build from scratch but I wanted to try a "Store Bought One".
The QuickStart and Plugboard are mounted to a piece of PC Board.
The H-Bridges use all N-Ch MOSFETS.
The Low side is IRF3708 and the High side is a conventional MOSFET in this case IRFZ48V.
The High Side driver uses a Depletion Mode MOSFET, DN2530, Level shifter similar to an I2C circuit. This is pulsed through a capacitor and rectifier to drive the gate on. A 2N7000 MOSFET turns the gate off.
And the schematic:
I'm using PropForth 5.0 "PropForthEEpromKernel".
I have a bunch of words I dump on top of the dictionary for testing and editing.
The actual tracker code is fairly short.
This is clearly not finished although the stuff does work.
1. I don't know how to get it to "Auto Start" after a power up or reset.
2. Timing must be experimented with.
And my forthware:
\ Forget back to fence, redoo fence, and list the words forget fence : fence ; h1B emit c" [2J" .cstr words \ Forget back to fence, and list the words forget fence h1B emit c" [2J" .cstr words \ Forget back to fence, redoo fence, and list the words forget fence : fence ; cb words \ Forget back to fence, and list the words forget fence cb words fl \ --------------- words added to PropForth ----------------- decimal : fence ; 0 wvariable baseold \ .hex ( n -- ) emit a single hex digit : .hex hF and d48 + dup d57 > if d7 + then emit ; \ .x ( n -- ) emit a single digit in the current base : .x base W@ u/mod drop d48 + dup d57 > if d7 + then dup d93 > if d3 + then emit ; \ .xn ( n1 n2 -- ) emit n1 as an n2 place number in the current base : .xn dup >r 0 do base W@ u/mod loop drop r> 0 do .x loop ; \ Display functions \ .bn ( n1 n2 -- ) emit n1 as an n2 (1 to 32) place binary number : .bn dup 0 do 2dup d32 swap - rev 1 i lshift and if ." 1" else ." 0" then loop 2drop ; \ .dn ( n1 n2 -- ) emit n1 as an n2 place decimal number : .dn dup >r 0 do d10 u/mod loop drop r> 0 do .hex loop ; \ .hn ( n1 n2 -- ) emit n1 as an n2 place hex number : .hn dup >r 0 do d16 u/mod loop drop r> 0 do .hex loop ; \ .xn ( n1 n2 -- ) emit n1 as an n2 place number in the current base : .xn dup >r 0 do base W@ u/mod loop drop r> 0 do .x loop ; \ ------------------- ascii escape sequences ------------------ \ ascii escape sequences start with ESC \ Clearly Plagerized from "prof_braino" : esc d27 emit ; \ ESCAPE : csi esc d91 emit ; \ [ : capK ." K" ; \ capital K : smallm ." m" ; \ small m \ .digits ( n - ." emit as decimal characters" ) for AT convert 0-99 for emit : .digits dup d9 > if d2 else 1 then .dn ; \ at ( x y - ) put cursor at x ; y line / column from upper left corner : at csi .digits ." ;" .digits ." f" ; : home csi ." 1;1f" ; : clear csi ." 2J" ; : preclear csi ." 1J" ; : postclear csi ." 0J" ; : cls home clear ; : clear-eol csi d0 .digits capK ; : clear-bol csi d1 .digits capK ; : clear-line csi d2 .digits capK ; \ attributes esc[d#;d#m = csi d#;d#m : atoff csi d48 emit smallm ; \ 0 off : bold csi d49 emit smallm ; \ 1 bold \ : faint csi d50 emit smallm ; \ 2 faint ? \ : italic csi d51 emit smallm ; \ 3 italic ? : underscore csi d52 emit smallm ; \ 4 underscore (mono) ? \ : sblink csi d53 emit smallm ; \ 5 slow blink PINK \ : fblink csi d54 emit smallm ; \ 6 fast blink : reverse csi d55 emit smallm ; \ 7 reverse \ : conceal csi d56 emit smallm ; \ 8 conceal \ : crossout csi d57 emit smallm ; \ 9 crossed out ? \ there are more... \ ( n -- ) Curser movements : cup csi .digits ." A" ; \ up : cdown csi .digits ." B" ; \ down : cforward csi .digits ." C" ; \ forward : cback csi .digits ." D" ; \ backward : csave csi ." s" ; \ save position : crestore csi ." u" ; \ restore position \ ( -- ) graphics mode Color attributes Forground/Background : black csi d30 .digits smallm ; : onblack csi d40 .digits smallm ; : red csi d31 .digits smallm ; : onred csi d41 .digits smallm ; : green csi d32 .digits smallm ; : ongreen csi d42 .digits smallm ; : yellow csi d33 .digits smallm ; : onyellow csi d43 .digits smallm ; : blue csi d34 .digits smallm ; : onblue csi d44 .digits smallm ; : magenta csi d35 .digits smallm ; : onmagenta csi d45 .digits smallm ; : cyan csi d36 .digits smallm ; : oncyan csi d46 .digits smallm ; : white csi d37 .digits smallm ; : onwhite csi d47 .digits smallm ; \ ----------------- end ascii escape sequences ---------------- \ .sx ( -- ) prints out the stack with a letter tag on the end Non-Destructivly : .sx ." ST: " $C_stPtr COG@ 2+ dup $C_stTop < if $C_stTop swap - 0 do $C_stTop 2- i - COG@ .long space loop else drop then ; \ removed cr from end of the word st? : .s0 .sx ." <0" cr ; : .s1 .sx ." <1" cr ; : .s2 .sx ." <2" cr ; : .s3 .sx ." <3" cr ; : .s4 .sx ." <4" cr ; : .s5 .sx ." <5" cr ; : .s6 .sx ." <6" cr ; : .s7 .sx ." <7" cr ; : .s8 .sx ." <8" cr ; : .s9 .sx ." <9" cr ; : .sA .sx ." <A" cr ; : .sB .sx ." <B" cr ; : .sC .sx ." <C" cr ; : .sD .sx ." <D" cr ; : .sE .sx ." <E" cr ; : .sF .sx ." <F" cr ; : .sG .sx ." <G" cr ; : .sH .sx ." <H" cr ; : .sI .sx ." <I" cr ; : .sJ .sx ." <J" cr ; : .sK .sx ." <K" cr ; : .sL .sx ." <L" cr ; : .sM .sx ." <M" cr ; : .sN .sx ." <N" cr ; : .sO .sx ." <O" cr ; : .sP .sx ." <P" cr ; : .sQ .sx ." <Q" cr ; : .sR .sx ." <R" cr ; : .sS .sx ." <S" cr ; : .sT .sx ." <T" cr ; : .sU .sx ." <U" cr ; : .sV .sx ." <V" cr ; : .sW .sx ." <W" cr ; : .sX .sx ." <X" cr ; : .sY .sx ." <Y" cr ; : .sZ .sx ." <Z" cr ; \ ------------------------------------------------------------- \ .sd ( -- ) prints out the stack as 10 place decimal numbers Non-Destructivly : .sd ." STD:" $C_stPtr COG@ 2+ dup $C_stTop < if $C_stTop swap - 0 do $C_stTop 2- i - COG@ d10 .dn space loop else drop then cr ; \ .sh ( -- ) prints out the stack in hex Non-Destructivly : .sh ." STH:" base W@ baseold W! hex .sx cr baseold W@ base W! ; \ cb ( -- ) clear TeraTerm scroll buffer assuming TeraTerm is set to 512 lines : cb d509 0 do cr loop bold blue 0 0 at clear ; \ pins? ( -- ) samples the current status of all the io pins and prints them to the terminal : pins? d32 0 do ." " i d2 .dn loop cr d32 0 do i px? if ." HI" else ." LO" then loop cr d32 0 do dira COG@ i rshift 1 and if ." OT" else ." IN" then loop cr ; \ Alternate method \ pins? ( -- ) samples the current status of all the io pins and prints them to the terminal \: pins? \ d32 0 do ." " i d2 .dn loop cr \ d32 0 do i px? if ." ^" else ." v" then loop cr \ d32 0 do dira COG@ i rshift 1 and if ." <" else ." >" then loop cr ; \ enablesteppers ( -- ) enable the stepper outputs and set to 0 : enablesteppers dira COG@ h000FF000 or dira COG! ina COG@ hFFF00FFF and h00000000 or outa COG! ; \ stepaz ( n -- ) n lowest 2 bits converted to 5 wire step code : stepaz b11 and 1 swap lshift h0001000 * ina COG@ hFFFF0FFF and or outa COG! ; \ stepalt ( n -- ) n lowest 2 bits converted to 5 wire step code : stepalt b11 and 1 swap lshift h0010000 * ina COG@ hFFF0FFFF and or outa COG! ; \ fence : fence ; \ -------------- end words added to PropForth ----------------- decimal fl \ Number of charging cycles for the High Side MOSFET wvariable hbcharge \ Cycle time in ms for eack half cycle wvariable hbtime \ Reset sensor capacitor time wvariable hbresettime \ Initialize the I/O pins : hbinit 23 pinhi 22 pinlo 21 pinlo 20 pinhi 19 pinhi 18 pinlo 17 pinlo 16 pinhi 24 16 do i pinout loop 8 pinin 8 pinlo 9 pinin 9 pinlo ; : aleft 21 pinhi hbcharge W@ 0 do 23 pinlo hbtime W@ delms 23 pinhi hbtime W@ delms loop 21 pinlo ; : aright 22 pinhi hbcharge W@ 0 do 20 pinlo hbtime W@ delms 20 pinhi hbtime W@ delms loop 22 pinlo ; : bleft 17 pinhi hbcharge W@ 0 do 19 pinlo hbtime W@ delms 19 pinhi hbtime W@ delms loop 17 pinlo ; : bright 18 pinhi hbcharge W@ 0 do 16 pinlo hbtime W@ delms 16 pinhi hbtime W@ delms loop 18 pinlo ; \ Reset the LED Capacitors : hbreset 8 pinout 9 pinout hbresettime W@ delms 8 pinin 9 pinin ; \ read the sensors : hbled 9 px? 1 and 2 * 8 px? 1 and + ; : fence ; 1 hbcharge W! 1 hbtime W! 100 hbresettime W! hbinit : LED hbreset 1000 0 do hbled dup 0 = if then dup 1 = if aleft then dup 2 = if aright then dup 3 = if then drop loop ; : MainLoop 1000000 0 do LED loop ;Do you want a complete image of the code as it exists in the QuickStart?(Heck I don't know how to do it anyway.)
OK, it's 1:45 AM central time so it would be 11:45 PM Pacific time.
Hey it's still the weekend. Am I still within the allotted time period? Ha Ha!
I will edit and up date this later.
Duane J
Very nice real world usefulness -- it could be a real winner. From what I understand is Forth code gets better with age. In other words, once one has a working prototype - the code can be refined and improved at one's leisure. Off-the-grid is definitely a situation that needs good low-power solutions.
It is 3:47pm here in old Taiwan. Technically the competition has about 4 hours to go, but it would take quite a bit for me to resolve what I want to do.
Tachyon rocks. It seems easily accessible to the user. And that is just as important as lightning fast speed.
While I have made more sense out of what PropForth offers up as a RS232 serial interface, the tutorial doesn't actually demonstrate a hard-wire loop back that reaches to the world outside the Propeller. It has the console communicate with a far destination cog via a rather lengthy chain. The features that allow communication to flow are not clearly mentioned. A hard-wire loop back that produces an echo would be much more educational as I could connect and disconnect the wire to confirm the i/o pins are interrupted.
I'd have to say that PropForth plays very nicely with itself. But I have to really wonder what that is about. It seems to be code only for code's sake. I just can't see much 'user-friendly' real world connectivity for all the claims of speed and elegance. While I can easily roll my own SPI, I2C, and maybe even 1-wire; the asynchronous side of support is not very clear.
At some point, for RS232 links and for RS422 or RS485 that provide long wire transmits and receive it has to be simpler than that, and use less cogs or not much is left over to process other items; such as control of your pumps, a real-time clock, and so on. You may want to use RS485 with your pump control as the wire can communicate for kilo-meters.
At this point, I have pretty much given up on getting my half-duplex bi-directional link configured and am attempting to just have a hard-wire serial loop-back that might take only 3 cogs. But two would really be ideal.
I guess the next phase is to try to use Tachyon for the chopstick printer and the Dec 4th contest deadline.
I wonder what Prof Braino has to show us. After all, it is really his opportunity to demonstrate the usefulness of PropForth. He likely knows it better than any of us. And I see we have another PropForth entry - a solar tracker.
So these are all the entires we have.
Brain Reily for Tachyon - pump and battery monitoring and control
Duane C Johnson for PropForth - Solar tracker with a very nice working fully mos-fet h-bridge
Loopy Byteloose for PropForth - Stepper motor examples for 5 wire unipolar 5v 200ma steppers.
Have I missed anybody? I guess Mindrobots will decide later today.
If you want to present the code so sometone else can reproduce it, I would suggest:
1) post your code above as a file (Duane_solar_tracker.f or similar)
2) reference the exact version of forth you used ( Propforth-V5.03-20120505.zip ?) and maybe include a link to it
3) name the spin file from the kernel (..V5.03\CurrentRelease\PropForthEEprom PropForthEEpromFastSerialKernel.spin )
4) incldue any other extensions needed to run the final application
This way, anybody could reproduce at least the software part of it.
Cool stuff!
If you want to share this as an example project it could be posted on the propforth wiki and as a download.
Thank you all for contributing, commenting or just watching!!!
The winner will be announced later today!!
It seems I finally got a hard-wire loopback to confirm active RS232 communications. And this process only uses 3 cogs to observe. When actually in operation the i/o may only use 2 cogs.
In general, every asynchronous serial port removes the cog from being a Forth stack machine and it becomes a serial i/o state machine (each Forth cog is configured with a dormant asynch serial i/o as well as active Forth stack machine - the function can be toggled from one to the other).
So one creates a serial cog and attaches it to another cog to have it tied to an active Forth stack machine. While in theory, I can have all 8 cogs configured as serial devices, there would be no Forth stack machines to do anything useful.
And while one can link two serial cogs i/o pins to i/o pins (lets call that face to face), that is rather useless as I suspect a synchonous link would be much faster and more stable.
So it seems that the best one can do is to get 3 serial ports used by 3 Forth stack machines on the 8 cogs. One cog remains the serial link to the dumb terminal and the remaining cog would be available for whatever comes to mind (maybe a real time clock?)
Somehow I just knew this was going to be late.
And now I need to do some more testing to see if I can actually get a bi-directional asynchronous serial over one wire. If that does work, I still have enough other cogs to drive the steppers and print a chopstick.
Maybe I should change my blood pressure medication ;-0
What an odyssey.
Well I have already gotten 2 requests for printed chopsticks. So I am trying to go forward with this.
I really have only studied asynchronous serial on the SX chips, but having 32 bits may actually make the whole process easier that with 8 bit registers. Mostly it is as you mentioned, about timing. One has to set up a sampling cycle 4 to 16 times faster than the baud rate and then poll a pin for incoming activity. Output is simpler as one has complete control of the timing.
I am just try to work with the system in place for now. There are two configuration words serial and _serial which can set the baud rate and the RX and TX pins. That's the easy part. Then there is a word sersetflags that activates serial communications. And then there is the attaching to another cog with an active Forth stack machine via yet another word ioconn. One verifies the setup with cog? queries and serflags? queries.
Once all that is established, it is a matter of not disturbing the setup and communicating with the Forth cog tied to the serial cog via the console with something like the phrase c" anyword " 0 cogx for the 0 cog.
I don't know if this makes any sense to you at all, but that's what I've discovered so far. The trick is to reach the TX buffer with output from the console, have it loop-back through a physically hardwired loop, and to verify the data has arrived via the hardwire loop-back and not via some other means.
Propforth has eight locations of 228 bytes in Hub Ram allocated to serial communications and these appear to be intended to support the asynchronous serial driver that is already loaded within the cog, but dormant when the cog is initially loaded with Forth machine. There is a flag that toggles between the two service functions.
The serial hub ram includes a circular rx and a circular tx buffer. All I get about the serial services is the words that initialize them, the actual driver is in machine code and not easy to de-cypher. And again in hub is a location that is used to pass single bytes at a time from one cog to another when an adjacent address asserts a 'ready to receive' code. Received bytes after clearing the buffer go to the Forth cog and seem to enter the same input stream that arrives at the interpreter.
So I keep playing with this and am trying to figure out what Sal Sanci had in mind. The documentation does not provide a formal focused discussion of reaching the outside world with an asyn serial port and locating all the words that apply are awkward as they are not presented applied to their use - just alphabetical listings. So I seem to be collecting information from 4 or 5 different places and guess a lot .
Since the buffers are circular, I am not quite sure of how to clear them. I suppose I could just write to the whole contiguous block of bytes and not concern myself with what the pointer is or where it might be located. I may need to clear the RX and I presume writing h00 throughout will be enough.
I am sure that might be more than you wanted to know.
Circular buffers not need clearing.
It is it's <Read pointer that say to You if it is empty.
If both Read pointer and Write pointer have same Value = Buffer is empty
If Read pointer < Write pointer buffer have bytes to read.
But Read pointer will never be bigger that Write pointer ---> That indicate You have error
Thanks, I haven't been able to verify where those pointers are. But while the hub ram has 228 or maybe 224 bytes set aside for communications, I have info about only 200 to 204 of the locations. I suspect my pointers are amongst those extra locations.... unless they are sitting in the cog ram.
bit bang is very easy in forth, notice propforth at 230500 baud and Tachyeon at 3 million over bluetooth.
loopy is having trouble separating the individual transmit and recieve functions out of the entire integrated and opimized development environment.
cog7 runs the prop serial for the development environment
coig6 run the forth kernel for th developer
cog5 runs one party for the loopback test
cog4 runs the other party for the loopback test
i don't recall another cog. being involved, unless it the one buffering and interpreting the soucre code
,
but, only one. cog is needed for the serial itself, and can easily run up to 3 million baud async
there are two entries, one using Tachyon, one using propforth. both authors are quite capable.
Could we get some feedback as to how much trouble it would be to port the application to another flavor of forth on the prop?
i would expect that the main task would be converting the format for the number literals. there also should be a couple thngs that are "done different" on a given flavor, but for the most part they should be straight forward.
i'm interest to hear this would be easy, doable, or not possible; and what the biggest issue would be.
thanks in advance if duane or brian want to give this a look.
Wait a minute, 1M Baud is 1 micro second per bit.
At a Prop clock speed of 80MHz we get 20 million PASM instructions per second.
That's 20 instructions per bit, at 1M Baud.
Crank that up to 3M Baud and we only have a tad over 6 instructions per bit.
I conclude that 3MB is possible in PASM, or even in some compiled code, but for sure not possible with an interpreted language like Forth.
If you want that COG to also handle full duplex we are looking at a lot slower.
Forth in general, and propforth in particular, are only interpreted WHEN THE SOURCE IS COMPILED on input. Unlike basic, which always interprets, propforth executes. Mostly jmp instructions, that's why its so darned fast. Basically, forth is a way to run assembler without having to do all the work in assembler. Only the interesting parts need be examined and implemented in assembler, the boring parts are done in simple forth (and executed at nearly assembler speed).
Propforth has been de-rated to 230400 baud as Sal saw an error once at higher speeds, but he said he might have tripped over the wire or something. But we know Tachyon runs at 3M from Peter. We should hear from him, maybe I'm crazy again, its happened before.
EDIT - Here we go , the link that states Tachyon throughput.
http://forums.parallax.com/showthread.php?141061-TACHYON-A-Fast-and-small-Forth-byte-code-VM-(source-code-available)-Web-pages&p=1111702&viewfull=1#post1111702
: waitcnt begin dup cnt@ - 0< until ; : putch 256 or dup + clkfreq@ 9600 / 11 >r cnt@ begin r> 1- dup >r while rot dup 30 lshift outa! 1 rshift swap rot dup rot + waitcnt repeat r> 2drop 2drop ; : test cnt@ 65 putch cnt@ swap - 80 / . ;Exactly, why advertise Forth as running at assembler speed if you are actually using assembler to get the job done?
No idea what that means "and executed at nearly assembler speed". Even if it only took two asm instructions to implement every Forth word that would be half as fast. I'm sure it must be an order of magnitude worse that that even for simple operations.
[CENTER][COLOR=#999999][FONT=Ubuntu Mono]{[/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono] [/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono][B]****** CONSOLE SERIAL OUTPUT ******[/B][/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono] [/FONT][/COLOR][COLOR=#999999][FONT=Ubuntu Mono]}[/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono][/FONT][/COLOR][/CENTER][COLOR=#000000][FONT=Ubuntu Mono]' Transmit the character that is in the tos register[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono]' [/FONT][/COLOR] [COLOR=#ffff00][FONT=Ubuntu Mono][B]transmit[/B][/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono] or outa,txmask ' ensure output is high[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] or dira,txmask ' make it an output[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] or tos,stopmask ' fill up with stop bits[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] shl tos,#1 ' add in start bit as first bit[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] mov txcnt,#10 ' 8 data bits + 1 start + stop bits[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono]txdat mov R0,cnt[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] add R0,bit_ticks[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono]txbit shr tos,#1 wc ' lsb first[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] muxc outa,txmask ' output bit[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] waitcnt R0,bit_ticks[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] djnz txcnt,#txbit 'another bit to transmit?[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] jmp #DROP[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono][/FONT][/COLOR]...back to picking a winner.....I bet the suspense is killing at least 2 people!!
Yes, well no, not directly. It compiles forth into the dictionary, and it yeilds executable instructions with extra overhead that makes it work in the dictionary. On the other hand, the (manual) optimizations generally end up in straight assembly. Instead of jumping to each each assembly implementation for each lowest level word and back to the highest level word, optimizing generally remove all the extra jumps. And it turns into straight assemble for the most part, with a "forth interface" wrapper around it instead of around each individual word. Removing the redundant jumps has a big effect on often executed code.
The pre-optimized propforth up to version 4 ran at 19.2 very happily with no reported problems, so we think it was bullet proof with lots of overhead. I never traced through the code, so I don't know if Sal did any "tricks", but i don't think he did.
Somebody could, but I'm not the best candidate. I'm not set up very well for test here. We should get somebody smart to analyze it properly.
...what does cnt@ do? Is that cnt C@ to me? is clkfreq@ just clkfreq C@? I bet those should be COG@
I don't have while...repeat; I have begin...until so I have to switch this around...
OK i guess i'm testing after all. Give me a couple minutes here......
EDIT - OK, I give up. I can't figure out what its intended to do, and I don't know what my code is trying to achieve. I would need to load pfth first, and figure out the stack notes, and break up putch into three easier small words, and recode the loop. I would also need check that all the little words work the way I imagine they might.
It really needs somebody familiar with both pfth and propforth, or we have to go through the learning curve for what we don't know. Sorry that's the best I got right now. Maybe when I get back to the lab I can try it out.
First off, Loopy gets a more than honorable mention for his determination in attempting this while also learning Forth. Plus his dogged tenacity to dig through code and words looking for that elusive half-duplex serial connection!! Let's cheer him on for the Forth of December contest because when you search your heart, you really know you too want a set of printed chopsticks and want to see the video!!
Now, for the WINNER!!!!!!
I can't find the actual source code for PropForth's serial routine but it is assembler, I'm sure. Here's the word that creates the dictionary entry (and the code itself) I believe this is the base-64 assembler encoding that has been mentioned elsewhere.
As you stated previously, it needs to be down to pure assembler in order to obtain the speeds it delivers on eother implementation. The Forth inner interpreter alone, if it were invovled, would inject the usual 4-5 time overhead of any bytecode (or thread chasing) interpreter. You can't reach "near assembler speeds" unless you are writing and running assembler.
oh, yeah, the contest winner.....looks like I got distracted......sorry......happens to me a LOT!!
@mindrobots, who won the contest?
OK, the WINNER IS....wow, this was really difficult!
I can see using either of these projects in some of my projects (should I ever really complete a project)
Brian's Pump timer had practical application in a time of needs and when you read through his code, you can really see the elegance of Forth and how the application was built. This is ready to go for any similar application you may have around the house with very little modification.
Duane's project on the other hand was a tour de force in hardware and software that shows the benefits of building and testing in a Forth environment. While not a stand alone project per se (unless I'm missing something, which if I am please correct me) it is a key foundation piece for any project needing the capability to do solar tracking.
While the turnout was less than expected, the final results were excellent!!
...and the WINNER is just by the slightest edge...BRIAN and his Smart Shallow Well Pump Timer
YAY!! HUZZAH! HUZZAH!!! The first Forth Contest has a WINNER!!!!
Congratulations, Brian!!!
We'll need to get your mailing information to Ken for the prize distribution!
I wish I had something to offer the other contestants other than a hearty "Well Done!!" and a reminder to keep plugging away on your projects because you are all eligible to compete in Peter's Forth of December contest!!!!
Thank you all for competing, commenting or just watching the thread go by!
Jeff