VIPER1's Garage Parking Lights - A TAQOZ version
Peter Jakacki
Posts: 10,193
Viper1 made a cool garage parking light based on a Stamp and a ping sensor and using actual traffic signals for his garage, just so he could park his van without running into his workspace. I decided that this would be a good learning app for TAQOZ and I would try to recode it so that the TAQOZ code and the PBASIC could be followed line by line. Alas, it didn't make sense and was looking a jumble. Time to think Forth, so I looked at the video and came up with this version instead. See if you can follow it. Better still, make it up with a ping sensor and LEDs and try it out. Maybe it works, maybe it doesn't. It looks like it should, but would probably need some adjustment.
This version will work with TAQOZ in ROM and compiles in 524 bytes of code so use BACKUP to back it up to Flash. Later on (sidetracked) I will come up with a simple Flash loader that will automatically boot your backup.
Do you see any bugs? Can you see any way to improve it? I will try it myself when I have time too but it does compile and run if I dummy out the PING.
Have fun!
This version will work with TAQOZ in ROM and compiles in 524 bytes of code so use BACKUP to back it up to Flash. Later on (sidetracked) I will come up with a simple Flash loader that will automatically boot your backup.
Do you see any bugs? Can you see any way to improve it? I will try it myself when I have time too but it does compile and run if I dummy out the PING.
Have fun!
TAQOZ
{ Adapted from PBASIC code posted by VIPER1
Traffic light for garage parking in conjunction with a ping sensor
The light timer is triggered by movement
If the car is too far away the lights will stay off (optional)
}
--- Distance constants ( need to be adjusted for TAQOZ )
11000 := GREEN_DISTANCE
7500 := YELLOW_DISTANCE
4600 := RED_DISTANCE
--- Time constants
1000 := LIGHT_ON_TIME
--- Light States
1 := RED
2 := YELLOW
3 := GREEN
--- IO PINS
13 := *GREEN
14 := *YELLOW
15 := *RED
12 := SENSOR1
--- Variables
long timer
long pingTime
4 longs distance --- current distance plus previous readings
{
The ROM doesn't have a WAITLO but does have WAITPIN = WAITHI
Add these if necessary
}
pub WAITHI WAITPIN ;
pub WAITLO BEGIN WAITPIN 0= UNTIL ;
--- Simple PING routine to measure and store us and mm
pub PING ( trig/echo -- )
--- set and pulse then float
PIN H 5 us L F
--- detect & cacl high period
WAITHI CNT@ WAITLO CNT@ - ABS
--- convert cycles to us and store
CLKHZ 1,000,000 U/ U/ DUP pingTime !
--- convert to mm and store
170145 1,000,000 */ distance !
--- update movement history
distance distance 4+ 12 <CMOVE
;
--- Allow only one light on or none --- RED LIGHT or OFF LIGHT etc
pub LIGHT ( state -- )
SWITCH
--- Retrigger the light timer on an active state
?DUP IF LIGHT_ON_TIME timer ! THEN
--- all off microseconds before turning one on
*GREEN LOW *YELLOW LOW *RED LOW
RED CASE *RED HIGH BREAK
YELLOW CASE *YELLOW HIGH BREAK
GREEN CASE *GREEN HIGH BREAK
;
--- return with the car's distance in mm (or whatever)
pub CAR ( -- distance )
distance @
;
--- check history for changes and deglitch and report movement above a threshold
pub MOVEMENT? ( -- flg )
distance @ distance 4 + @ - ABS 100 >
distance 4 + @ distance 8 + @ - ABS 100 >
distance 8 + @ distance 12 + @ - ABS 100 >
AND
;
--- check distance and activate lights - priority to RED
pub LIGHTS
RED_DISTANCE CAR > IF RED LIGHT BREAK
YELLOW_DISTANCE CAR > IF YELLOW LIGHT BREAK
GREEN_DISTANCE CAR < IF GREEN LIGHT BREAK
--- Car is too far away - just turn off the lights (optional)
OFF LIGHT
;
pub MAIN
CRLF ." TAQOZ GARAGE PARKING AID "
timer ~
distance 16 ERASE --- wipe distance rray
OFF LIGHT
--- Loop forever
BEGIN
--- Get the distance from sensor #1
SENSOR1 PING
pingTime @ .AS" Ping time = #####us" ." ; distance = " CAR .AS" #####mm ; timer = " timer @ .AS" ####" CRLF
MOVEMENT?
IF --- activate lights according to distance when there is movement
LIGHTS LIGHT_ON_TIME timer !
ELSE
--- check light timer countdown and turn off when 0
timer @ IF timer -- ELSE OFF LIGHT THEN
THEN
100 ms
AGAIN
;
END
Comments
Peter, I believe that having P2D2 available at need will give Tachyon a huge push as we can easily spread an application and application specific base boards are fast to produce. So please focus on completing the hardware including lap, but start with one first, don't let us wait until everything is completed. In terms of time lost 100 boards used to start and then replaced to unify should not be an issue. I didn't ask how many board will be ordered in Europe (before Brexit), as that makes sense only if the design is ready...-
everyone, who deals with forth will vary the language. Of course everyone is allowed and encouraged to do this.
But: If you try to share code and reuse your code or teach forth, it is beneficial to stick to standards.
Even if they are less smart!
So instead of
":=" it would be good to use the word "constant" and
"variable" for "long" as this is the standard cell size.
":" instead of "pub".
"\" instead of "---".
....
A very helpful advantage is, that new users can read/use documentation of other systems. For example in
http://forth.sourceforge.net/standard/fst83/fst83-12.htm
there is a most perfect description of every basic word.
And there are several very good basic tutorials, like:
http://www.murphywong.net/hello/simple.htm
Forth was invented well over 50 years ago and what was good then on a minicomputer was good then, but may not be good now. You mentioned the "instead of" and that's a little funny because I wrote Tachyon for myself and for Prop users who were used to Spin syntax as there were a few things from there that I could borrow that seemed advantageous. For instance, seeing I had a separate dictionary where I would want to cull and reclaim memory from names that did not have to remain public, I needed a way of specifying at the time the word was created whether it could be reclaimed automatically if need be. The Spin words pub and pri seemed a perfect fit for the job and so while I could still use : it seems much better to be able to specify public or private words, and also preemptive or immediate words neatly and cleanly. So pub, pri, and pre are there for a good reason. The Prop is not a minicomputer or a PC, and it has it's own advantages and it's own limitations.
Here's some of my rationale behind the differences, not from a committee member nutting out a standard, but from an MCU user.
CONSTANT is a big word that obscures the very constants and names it seeks to define, especially long lists. Example:
3 CONSTANT m
3 := m
Nobody is ever really sure what a variable is. It might be 16-bits, or 32-bits, or it might be initialized or not, or it might be in code memory, or not. Variable is its name and variable is its implementation. I'm coding for an MCU unlike a PC where variables will be lumped in between code and headers etc and writing 32-bits to a 16-bit variable can trash and crash the PC, So? The PC reboots. No big deal, but an MCU running industrial controls 24/7 can cause not just a real crunching crash, but also result in danger to life and limb. So I need to control where those variables are. In Spin you could define byte/word/long for data and this fits in perfectly with Tachyon since I want to allocate data for "a variable" of variable size, in an area that does not have any code that can get clobbered due to an oversight or a bug. Complementing those words with the plural allows me to allocate and control. Example: This structure continues and I know that I can erase the entire structure in one go as well, and the address of each variable is contiguous and predictable so that cid is 4 bytes after ocr etc.
\ is a lovely short word but gets bunched up against code and looks too much like all the other symbols including /. Much better to enforce spacing even if it is bunched up. However I find it better to comment above the line for so that it is lined up with the code. Example: In this case the --- doesn't obscure the pub definition either.
Anyway, Tachyon is not ANSI Forth and doesn't try to be either, it's better than that. Trying to make it so would be just forcing Just Another Feeble Forth onto another CPU rather than a serious tool customized for that unique MCU, and the Propeller is certainly a unique MCU.
Thanks!! Peter. This looks very interesting .
Thanks for the explanations of your smarter special forth. (I am still not convinced, that long is better than variable because you use ! And @. I suppose these will only work with standard cell size. A variable will be signed.)
I think P2 has got about the power and memory size, minicomputers had, when forth was most used, so using forth on P2 (or some other micros like esp32) makes a lot of sense.
But this is not the point.
If you create a new "better" syntax and want it to be useful for others, then you have to supply complete and good documentation and new learning material. If you use standard Syntax then all of this is already there!
Well, I try not to take it too seriously with long and @ etc. What works? What's practical? What things have I always wanted to change? What's the downside etc. I'd be perpetually bogged down in indecision if I wasn't so busy making decisions and getting it done.
Is Tachyon a "better" Forth? Well, it certainly is a better Forth for the Prop then I've ever seen and certainly it ticks the boxes in terms of a on-chip interactive Propeller environment.