| |
If I wasn't in a hurry with so many things to do in the next two days, I
would figure this out for myself. My apologies for such a simple question.
We're wrapping a lot sensor input stuff at a higher level of abstraction
than the raw pbForth words. This makes sense; a Forther would probably do
the same. For example, we're providing
(get-light-value 'PORT2)
expands to
3 1 SENSOR_TYPE
128 1 SENSOR_MODE
1 SENSOR_CLEAR
1 SENSOR_READ DUMP
1 SENSOR_VALUE
effectively. Perhaps this is a bit much every time the programmer checks the
light sensor, but that's what our initial compilation process converts the
abstraction into.
What I'm not having much luck with (quickly) is how to handle the touch
sensors similarly. That is, I need to logically or some values, and the
correct combination is... _either_ EDGE and BOOLEAN _or_ PULSE and BOOLEAN?
That is, could I provide an abstraction like
(pressed-or-released? 'PORT1)
and expand that into
1 0 SENSOR_TYPE
32 64 AND 0 SENSOR_MODE
0 SENSOR_CLEAR
0 SENSOR_READ DROP
0 SENSOR_BOOL
?
Currently, I'm not having much luck with this, and wonder if any of the
people who have been programming the Mindstorm (natively) in Forth for a
while might have some insight on how best to map some high-level touch
sensor abstractions to the underlying Forth?
CC:s on replies are appreciated.
Thanks much as always,
Matt
|
|
Message has 1 Reply:
 | | RE: Lazy newbieish question
|
| (...) Matt, I see this all the time when I teach embedded C programming to desktop guys - it's an objectification of things at the wrong level. Maybe you could consider this: (setup-light-sensor 'PORT2) which expands to 3 1 SENSOR_TYPE 128 1 (...) (22 years ago, 17-Jul-02, to lugnet.robotics.rcx.pbforth)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
