Propeller to Propeller Intercommunications standards?
Oldbitcollector (Jeff)
Posts: 8,091
Question:
How tough would it be to create an object which used the FullDuplexSerial code to
create a Propeller intercommunications object which was plug-in compatible with
existing objects?
Something along the lines of calling on "Combokeyboard.spin" via this object
so that all would need to be changed is the item in the OBJ section of the
code which required it and a couple I/O settings.
Does this sound remotely possible?
Establishing some "standards" around multi-propeller code would be a positive
step forward with so many projects being worked on.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
How tough would it be to create an object which used the FullDuplexSerial code to
create a Propeller intercommunications object which was plug-in compatible with
existing objects?
Something along the lines of calling on "Combokeyboard.spin" via this object
so that all would need to be changed is the item in the OBJ section of the
code which required it and a couple I/O settings.
Does this sound remotely possible?
Establishing some "standards" around multi-propeller code would be a positive
step forward with so many projects being worked on.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
What I'm looking for is an object which is plug-in-compatible with existing objects.
Your response sounds like you have a trick up your sleeve?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
to me it is not clear in all details how much compatibility you would like to have
just replace a keyboard through a second prop where the second prop creates original keyboard signals ?
or replace the keyboard-object through another object "Universal-Intercom" that uses FullDuplexSerial in the background and has methods with the same names
as the methods in the object "Combokeyboard.spin"
AND also methods to be compatible with the mousedriver
AND beeing compatibe with a 4x4 keyboard
AND beeing compatibe with tv_text,
AND beeing compatibe with VGA_Text,
AND beeing compatibe with IR-remote controls
AND beeing compatibe with N64-controller
AND beeing compatibe with Atari-Joystick ???
What do you have in mind ? Emulating different kinds of hardware ?
best regards
Stefan
You got the idea.. I like the term "Universal-Intercom." [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
OK - one goal is beeing compatible with a lot of different hardware.
I'm still curious for what reason do you want to have a SUPER-compatibilty ?
To me there are several device-classes which should be compatible
Displays: TV, VGA, serial (LCD), PropTerminal
Input: PC-Keyboard, small 3x4 and 4x4 keyboards, IR-remote-controls
Can you describe two or three concrete examples of what you would like to do ?
The TV-, and VGA-objects are more or less compatible to FullDuplexSerial
but there are some differencies like setcursor, clear screen etc.
As a first step I would appreciate if the methodnames for these things would be following a
standard that you REALLY just change the object-filename and everything is running again.
What is not clear to me can this be done by simply changing the methodnames or is there a must
for wrapper-methods ?
Will the wrapper-object beeing used in that way that the original-object-filename
will be replaced by the wrapper-object-filename ?
What would be the best way to cope with the fact that each start-method has a different
number of parameters with different meanings ?
Is it possible to reduce the changings to just change the parameterlist of the start-method
to the new device ?
I would like to keep everything compatible with the propellertool. That would mean no conditional
compiling and similar features other compilers have but not the propellertool
Would it make sense to code a new variant of all these objects (TV, VGA, etc.) that have the
same number of parameters in the start-method with one additional parameter DEVICETYPE
and depending on DEVICETYPE the use of the parameters is adjusted to the refering object ?
best regards
Stefan
What I've got in mind is a simple three-propeller system of my own, configured as follows...
Propeller 1: (Master)
Keyboard/Mouse/SD/NES
Propeller 2: (Audio)
Either Andy's Synth object or HSS
Propeller 3: (Video)
Doug's new 8x8 driver (hopefully it'll support graphics as well soon.)
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
to me this sounds like interprop-to-prop-communication.
But in this case in my opinion it wouldn't be nescessary to have the keyboard-object, the VGA-text-object, the NES-object
etc. to be compatible with each other.
Your propeller 1 uses the standard-keyboard-driver to catch the input of the user and will send data to the second and the 3rd prop
f.e. via FullDuplexSerial. The 2nd and 3rd prop are programmed to await commands from prop 1 executing these commands
and then simply wait for the next commands.
Do have a complete different software-architecture in mind ?
best regards
Stefan