| |
In using legOS, I've found that many of the design decisions seem
somewhat backwards, and I think that this is due to a desire to keep the
interface as similar as possible to NQC. I was wondering what people
would think about changing the core API to be more along the lines of
what someone familiar with UNIX would be expecting. (Maintaining
backwards compatability via helper functions which could be selectively
compiled.) Specifically, some of the things that I have in mind are:
* Calling threads "threads" rather than "processes", and starting them
via pthread_create() or some such, rather than execi().
* Thread synchronization in the style of pthreads. (eg. mutexes,
condition variables, etc)
* Having the motor and sensor access functions take a parameter
specifying which motor/sensor to access, rather than having the
selection be in the function name. (ie. motor_speed_set(MOTOR_A, 100)
rather than motor_a_speed(100)).
* Functions (or perhaps function-type macros) instead of volatile
global variables. eg. time() rather than sys_time.
* Networking API which works similarly to sockets, with read() and
write() calls, rather than a callback for recieving data.
Let me know what you think about this.
--matt
|
|
Message has 2 Replies:
 | | Re: API changes
|
| My only concern with these proposed changes is possible increased memory usage. Encapsulation, error reporting, thread synchronisation etc are nice; but with just 32k of RAM I would question whether these are appropriate for some applications. For (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.legos)
|
6 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
