Should we have files that spec' only a single device's pins/ board's config'? e.g.:
pd_keyboard.spin,
pd_mouse.spin,
pd_nes.spin,
pd_tv.spin,
xtal.spin,
colors.spin
(Inside each standard file would be the standard constants).
One other problem: how would we catch any pin conflict - or does that even matter?
Oh, and thanks hippy - your post shows me how I'd use this stuff:
Example 1:
OBJ
pd : "pindefs"
PUB
tvPin := pd.PinLookup(String("TV_ADC1")) ' Requires PinLookup in pd
Example 2:
OBJ
pd_tv : "pd_tv"
PUB
tvPin := pd_tv#TV_ADC1
I think that's right - anyone want to check me?
@Baggers: If we do it with object files, even Hydra users get in on the action - as the objects get included when they compile. I guess that works (?) and if they're running an OS I suspect they'll have some equivalent to the SD (an expansion card?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
hippy said...
What of the existing Parallax Objects, like TV_text, should they be changed to use pindefs?
No, it's not necessary. Only the top-level object in any app needs to refer to the pindefs object. This is because the start methods in other objects normally accept the requisite pin definition as a parameter, as is the case with TV_Text.
Hippy, for runtime pin assignment lookup:
1. Using a straight pinmap[noparse][[/noparse]devindex] is troublesome as the number of devices continue to grow.
2. An array of 32 or 64 byte pairs (depending on PropI or II version) for pin numbers could be used.
3. Mike Green's spin method per pin binary lookup merits more study. Mike, how would that work?
I like that idea simonl, especially because of lower memory useage. If this happens and someone is using just one object (like just SD), your method would allow them not to load a bunch of extra junk into ROM and/or RAM.
One issue I see with this all is what about:
1. Multiple pieces of hardware of the same type (2 mice, 2 SD cards, 4 joysticks, or the like)
2. Changing hardware while a program/OS is running... (Unplug the keyboard and switch it for a mouse (after telling the program that's what your doing))
3. Ever increasing amount of hardware is being used, list will grow large quickly and any project will only use a small subset of all possibilt hardware.
VGA,
Composite video,
mouse,
keyboard,
hosts of LCDs,
controllers from a bunch of counsels,
GPS,
Compas,
Motors,
Accelerometers,
SD cards,
MP3 encloder/decoder chips,
OGG encoder/decoder chips,
Audio Jacks,
MIDI Jacks,
1. Ah, yes, forgot about multiples. OK, we could do the same as OBC suggested: e.g. pd_mouse1.spin would have constants with '1' suffix (so MOUSE1 = 24), and pd_mouse2.spin constants would have a '2' suffix.
2. If any app' was hot-swap tolerant, I guess it will still be expected to handle that as it does now?
3. Hmm; I guess every original app' creator will need to 'claim' a standard filename for their app's required hardware that's not already got a standard filename. So if my app' requires a keyboard, mouse, and six LEDs, I'd just need to claim a new filename for the LEDs (say pd_SRL_APP01_LEDS1.spin); create the pindefs within that file; then distribute the file with my app'. If the end user wanted the LEDs on different pins, all they need do is redefine the constants in 'pd_SRL_APP01_LEDS1.spin'
[noparse][[/noparse]NOTE: pd_keyboard1.spin, pd_mouse1.spin would reference the user's existing files (although I'd still include mine in the archive, in case they didn't already have them]
{Edited to add the '1' suffix to the standard pindef filenames!}
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Here is a demo that uses both spin defines and a binary array for configuration. The array is 2 dimensional and contains a compatability header. You can edit prophw.bin with·DOS·debug from a CMD window;·a GUI would of course be required for ease of use.·My PinDefs.spin may be a bit out of date.
Take it or leave it; just demoing a possible solution.
all:
what about passing the pin information from the OS to the APP in the ram , using Ariba's method? this wouldn't require an SD card.
jazzed :
trying your demo in a second. thanks for the post, i really like to see things like this and coleys post of working code. gives us a chance to see a theory in practice
Hippy:
I really like how you've broken this down in to digestible logic chunks. Perhaps our pindef should only be considered for compliant operating systems? About the second step, Anything we include on the target hardware, or in the OS should probably be as compact as possible. unless we do indeed require an SD card, which might be a little elitist.
Perhaps we should create a few different 'classifications' of applications and have a different method of passing information to each?
I'm not sure i fully understand your suggestion, all i know is that when i hear "windows registry" my stomach turns
Giemme:
A bios would be awesome. the problem i think would be convincing everyone to purchase an extra eeprom, and hook it up.
Baggers said...
Quick question!, What about people who don't use SD, like current Hydra users, how will they get their pindefs? or are you just leaving them out of the situation?
I wouldn't be happy leaving anyone out. It is possible to run an OS without an SD card though , and if we put the pin definitions in the OS (and therefor in the eeprom) that would negate the problem i think.
Coley said...
I don't quite understand the rest of this thread though, what exactly are you aiming for???
Complete world domination. Oh wait, you mean with this thread?
my ultimate goal is two fold. first to create an OS standard so people can switch between OS's without problems. second, to make it so that people can write applications that dont have to be re-compiled. download and run, no questions asked. (this seems to be the one people have picked up on recently)
Coley said...
Defintions stored in EEPROM would be great but what about the demoboard it's only got 32K, what happens if your code uses all of it already?
thats a good question, but it only applies to the operating system stored in the eeprom. The operating system will have to squeeze the pin data into a few bytes at the end of the EEPROM
applications that 'require' the eeprom are rare enough that they can be hand edited before compliing i think
perhaps we are thinking too big in trying to include everything. why not just make it a standard , for now, to include info in the rom about some subset of 'standard' hardware? This would cover the majority of apps intended to be run on an operating system.
I think an OS definitly needs precompiled Applications which can configure itself according a configuration file/array.
Now most Applications are programmed in Spin, and you can say: change the pindef object and recompile the source. But this will change in future. For an Application programmed in C, you must say: buy the C compiler, make a project, change the Defines in the Header XY, and recompile the source. And perhaps other languages and compiler follows.
The Configuration array has only to define the lowest level, absolutly necessary Pins. Application which uses special hardware should have a CON block or include the pindef-object that defines the special Pins. Then the User can simply use the Application binary unchanged and has to connect the hardware at the predefined Pins, or he must recompile the source if he want to use other Pins.
The most necessary Pins are:
- SD card
- Display basepin (to show an Error message)
- Clock settings (not a Pin but a long and a byte)
Second prority:
- Keyboard basepin
- Mouse basepin
- Audio In/Out Pins
- Ethernet, Software USB (for alternativ Bootloaders)
- RTC, GPS
Serial RX/TX are fixed on 31,30 and EEPROM/I2C ar fixed on 28,29.
This minimal configuration and the commandline has to be passed in the MainRAM, this exists always in any Hardware, because it is part of the Propeller. And an Application can't read it from SD card without to know the SD card pins.
To clarify: An OS can also start binaries which not follows such a standard, you simply not have the benefit of auto configuration and command line passing.
I will assemble a list and some examples of a concrete implementation and post it later...
OK here is my proposal of a config byte array. It can be passed in MainRAM
or as SD card file (but then from where come the SDcard Basepin?).
Index:
0..3 clkfreq (little endian long)
4 clkreg
5 sd card basepin (other pins +1,+2,+3)
6 keyboard basepin (odd=Hydra, even=Normal PS2)
7 mouse basepin (odd=Hydra, even=Normal PS2)
8 display basepin (TV,VGA,LCD)
9 debug/serial2 tx pin
10 debug/serial2 rx pin
11 audio in pin
12 audio out Left
13 audio out Right (-1=mono)
14 Soft-USB basepin
15 Ethernet basepin (also XBEE..)
16 RTC basepin (if not I2C on 28/29)
17 GPS basepin
18 ADC basepin
19..24 future standards
25..30 user defined
31 display mode (NTSC/PAL/VGA/Terminal)
Filename: "pconfig.sys" ?
Address for passing in MainRAM: $7FE0..$7FFF
Command Line:
0..30 max 31 byte string
31 terminating zero
32..35 MagicNumber (ie: "CMDL")
36..47 Return Application Filename
Filename: "cmd.sys"
Address for passing in MainRam: $7FB0..$7FDF
- with the magic number we can detect if a cmdline is passed in RAM or not.
- the Return Application is the binary that should be startet, when the Application is terminated.
This allows to return to the same Application that has startet the actual Application.
- if you only need the commandline, then read only the first 32 bytes of "cmd.sys"
Both sections together can build one datablock from $7FB0..$7FFF that can be copied with bytemove from/to the RAM, or
written in one 80 byte file ("cmd.sys") to pass to an application.
This is all handled by the OS, and the Application. The user has only to type in a commandline. And he must be
able to edit the configuration file with a PC, or Spin program.
' Example how an Application is started from the console application:
CON
#0, CLKFQ, #4, CLKRG, SDBASE, KBBASE .... 'the standard Array Indexes
PUB main
fsrw.start(pin) 'use here the precompiled Basepin or search for a SD card
ifnot fsrw.popen("pconfig.sys","r")
fsrw.pread(@config,32) 'overload the precompiled config from sd card
fsrw.pclose
... 'let the user input the exefile and the commandline
PUB runfile
ifnot fsrw.popen("exefile.bin","r")
bytemove($7FB0, @cmdline, 80) 'pass cmdline and config in RAM
fsrw.bootSDCard 'and start application
DAT
cmdline byte 0[noparse][[/noparse]32], "CMDL" 'space for the commandline + MagicNumber
retappl byte "console.bin",0 'own filename as return application
config file "pconfig.sys" 'the precompiled config data, normally overloaded
' Example how to use the cmdline/config in a started Application
CON
#0, CLKFQ, #4, CLKRG, SDBASE, KBBASE .... 'the standard Array Indexes
PUB main
if long[noparse][[/noparse]$7FD0] == MAGIC_NUM 'passed in RAM?
bytemove(@cmdline, $7FB0, 80) 'after this the RAM at $7FB0.. is free usable
clkset config[noparse][[/noparse]CLKRG],long[noparse][[/noparse]@config] 'set the clock
...
fsrw.start(config[noparse][[/noparse]SDBASE]) 'use the passed config or the default config
tv.start(config[noparse][[/noparse]DISPBASE])
kb.start(config[noparse][[/noparse]KBBASE])
tv.str(@cmdline) 'display the passed commandline
...
PUB quit
ifnot fsrw.popen(@retappl,"r") 'return to the calling application
fsrw.bootSDCard
else
reboot
DAT
cmdline byte 0[noparse][[/noparse]32], 0,0,0,0 'empty commandline
retappl byte "console.bin",0 'default return application
config file "pconfig.sys" 'default config
I hope this shows how easy it is to pass the data by MainRAM - no eeprom or sd card driver needed,
no conflict that you need the SD card Basepin from the configuration to read the configuration.
And the MainRAM is only occupied with the Data for a short time, while the new application is booted, and
can before and after be used for the stack or a videobuffer or something else.
Attached are 2 Spin files with a working implementation. You need a Terminal to test it, and you have to set the SD card basepin in the OS_DEMO source, because no config-file is used, but a hardcoded config.
The OS_DEMO pass its config and the commandline, which you entry, to the OS_APPL binary in the MainRAM. See the comments at begin in the souce for usage.
I was not thinking an extra eprom but a common sector into the parallax eprom , a kind of BIOS.bin file to load during the bootstrap phase... in a way what Ariba is doing
Thats really what i was trying to push at first but now there are so many options i think maybe its bet we sit back and let the dust clear a bit, find out which one of these ideas pans out to meet what i hope is the criteria everyone shares:
the standard should be easy to implement
it should be easy to use for newbies
it should work on all hardware
it should eat as few resources as possible
it should make you lunch when your too lazy to get up
ok, that last one is a pipe dream, but a guy can dream can't he?
In the mean time im playing with the idea of some logos, as suggested by someone here. if anyone has any other name suggestsions for the standard, or logo ideas i'd love to hear them
Andy, your post looks awesome, but i must sleep.. i am really looking forward to playing with it first thing in the morning
Top of Ram/Eeprom is the best place for the pindefs and command line, and it would be easy enough
to write tools to inject information into the image. I would index the database from top down ( ie
index 0 at $7FFF ) and put the parameter passing area at location 0 down, then follow it with the
pindefs because that means it can be extended downwards. Actually, at location 0, put two pointers
to the parameter area and to the pindef areas and include details of the size of each. The one thing
that has to be avoided is compromise for compactness which renders it useless as things evolve.
Given that Spin bytecode is position independant, it would be possible to put the lookup routines to
access that database at the top of memory as well. There are mechanisms which can be used to
make a jump to a Spin method at an absolute address.
One thing I do worry about is rushing towards a solution without taking into account why that may
not be the best solution. I was serious about pins such as for keyboard and mouse not necessarily
being contiguous. One could say they have to be for this platform specification, but then it would
become less useful in the general case.
There should really be a spec as perfect as it could be before overly worrying about how it should
be implemented, getting it to fit on SD card or sub-setted to work on games platforms.
To keep the pin array from growing, if you use a 2x32 byte wide array, you can have possible 256 driver definitions
per pin for PropIA. A 2x64 array could be used for Prop2. With word wide array, you get 64k driver definitions per pin.
An array where the index is represents the pin number and value is the type makes a 2 dimensional array unnecessary.
Hippy said...
There should really be a spec as perfect as it could be before overly worrying about how it should
be implemented, getting it to fit on SD card or sub-setted to work on games platforms.
true enough, but there will be flaws no matter how perfect. If we wait until its perfect it will never be implemented. the only way to truly perfect any standard is to release it , and wait for the complaints
I've probably eluded to this before, but I think it's worth saying again:
I believe we need TWO standards: one for pindefs for compiling code, and another (that builds on that?) for those using an OS - which is, I think, what vampyre's after.
I don't actually use an OS (yet) so the former would be of most use to me, and I believe it'd also be useful for compiling any OS too...
HTH.
Oh, and Andy - enjoy your holiday. Don't spend too much time pining for your Propeller!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
There is an interesting issue that not been talked about with the eeprom case. The OS is likely to only define pins for core devices e.g. display, keyboard. The app is likely to want other pins defined for other devices especially if you have the OS on a breadboard. So you ned a way to merge the eeprom and local pins together as long as they dont conflict. This can be solved if you do what I think jazzed is suggesting.
Every device type has a defined constant, the eeprom has a 32 entry array, 1 per pin, containing the device type on that pin. This gives you a way to compare device types and know if its the same device. Then you can merge as long as there are no device conflicts. The attached file contains some code that reads the eeprom and merges that table into a local table. If the eeprom table doesn't exist the local table is used. It doesn't do the same for a sd file but it could be extended handle it.
The possible solutions to the problem are as varied as the problem itself.
Until this has had more time to shake out, I will probably adopt Coley's
auto-detect script to determine keyboard and video. This could be
combined with a some code to look for an SD.HID (Propdos Hidden file)
and if not found, ask the user for the base pin of their SD connection.
Just having Video,Keyboard,and SD will go a long way..
In the meantime, it's sure interesting to see all these ideas surfacing..
Sooner or later everyone will have to settle on *one* option for this
to actually solve the problem. [noparse]:)[/noparse]
Timmoore I like your merge concept; it is close to allowing both predefined pindefs and an "overload" pindef if a magic number is found.
Now if you included a 2x array, with pin index in one dimension and pindef in the other as I had in my previous .zip (though only provided as an example), the PinDefs.spin can be used for the compiled case.
The problem with the approach is bloat, which many will find problematic. Ariba's data structure also allows for clkfreq and others. Can you combine that into your code?
The nicest I have thought of is to have everyone use something similar to the config that I put in an earlier postting but without the eeprom code. This makes it small, it has a CON list of device types that would need to be centralized somewhere, e.g. the wiki. And has a nice list of pins and the device on each pin.
The OS loaders when they load an app should copy a smaller table containing just the pins for keyboard, display and sd, and the ntsc/pal config into the top of ram. The config code doesn't have to read eeprom but just merges from ram which makes the code much smaller. The ram table can be small as well since it only contains a few pins. e.g. 8 bytes, 1 byte per keyboard pin, tv, vga, and 4 sd pins, plus a byte for ntsc/pal config. Each byte has a defined purpose i.e. first byte is keyboard, then tv, etc. The OS can copy the table from its own config.
Using the minimum requirement to do bootstrap is desirable. Having other code handle the rest after boot would also be flexible but not universally desirable. If a two phase approach is accepted, then one problem is getting a definition of minimum. I don't use audio at all for example [noparse]:)[/noparse]
Ariba may have done this already, but if a cookie is found in a memory area, a second stage loader can use that config for finishing startup for non-O/S users. That could reduce code size. To bad one can't conditionally load a spin object with the default language behaviour.
Steven has a "DOL" object that can start an object from SD. One could load an object on demand for O/S to complete bootstrap for that. I don't know if it has a bootstrap loader, but if it did, keeping a copy of DOL would only be necessary for O/S users.
OBC has a wiki entry for PinDefs draft already. Guess you've seen it.
What about this idea. the attachment contains 4 files. config.spin is initialized with a local table passed into it. The table is an 32 entry array containing the device type on each pin. It checks if there is a table at the top of ram (assumed set by the OS), if its there it updates the table. If its not there and the local table doesn't have one of the standard devices (keyboard/display) on pin 12/13 it runs coleys detection code and updates the pin table for known devices for those systems
The ram table can pass clk info, pin info and ntsc/pal info
gpstest and camtest are 2 projects I converted to use this system so you can see how it works.
The device list is different from the current wiki list. Rather than a list of named con assignments to·a pin. You have a enum of devices (see config.spin). In the main spin file you define a 32 word table (plus ntsc/pal) and put the device type in the entry for the pin (see gpstest and camtest for examples). Since I have some non-standard device, enums above $8000 are locally defined, I put them in timconfig.spin. config.spin has a standard list of devices. I would expect as objects for devices are put in propeller object exchange, a device type would get added to the standard enum list.
It has a nice advantage of having a table in the main file, listing the device on each pin in 1 place.
DOL will be useful in some situations but not in others. For instance when I do some more work on it you should be able to use it to do some things like the pipe command in unix. But, because its using the sd card and a heap manager you effectively only have 6000 longs left for your program. So if you were doing a game you may want that extra 2000 longs of hub ram. It should be able to load binaries from a command line soon exactly the same as PropDOS as well.
Options so far are
1. Storing data in the object during compilation (pindefs file) - Smallest but can't be used for binaries
2. File on SD card - No good if you don't have an SD card and possibly hard to parse
3. Autodetect routine - Small and simple but only works for certain configurations
4. Use data stored in OS (using methods 1, 2 or 3) to save data to ram before loading another object from SD - Possibly best option but will probably need an SD card and we all need to agree on a format.
Why is storing data in EEPROM not an option? It is the only device in common for stand-alone boot configurations.
Are you thinking that display, etc do not need to be initialized before launching OS?
@Timmoore
The index of the array defining the pin number is a little different from the predefined expectation or typical thinking by some here. Using index as the pin removes the need for a 2x array and pin data storage growing as there are only so many pins. The mythical PropII will have 64 pins, and one may not want to burden Prop 1 users. Still, the init and getPin functions may require a chipid check.
A user can preload the array with EEPROM or whatever device code with your new example. Good.
5. Store data in the eeprom - Basically everyone uses an eeprom, but, they are not all the same size so the data could get overwritten when storing a new program on the eeprom.
ok it seems we are getting somewhere. i have to admit i dont understand all of these options though.
Does anyone have a problem with the idea of storing the information in the eeprom?
It seems to me thats the best solution, and since apps can be run from ram, its not like were eating application space
Comments
Should we have files that spec' only a single device's pins/ board's config'? e.g.:
pd_keyboard.spin,
pd_mouse.spin,
pd_nes.spin,
pd_tv.spin,
xtal.spin,
colors.spin
(Inside each standard file would be the standard constants).
One other problem: how would we catch any pin conflict - or does that even matter?
Oh, and thanks hippy - your post shows me how I'd use this stuff:
Example 1: OBJ pd : "pindefs" PUB tvPin := pd.PinLookup(String("TV_ADC1")) ' Requires PinLookup in pd Example 2: OBJ pd_tv : "pd_tv" PUB tvPin := pd_tv#TV_ADC1I think that's right - anyone want to check me?
@Baggers: If we do it with object files, even Hydra users get in on the action - as the objects get included when they compile. I guess that works (?) and if they're running an OS I suspect they'll have some equivalent to the SD (an expansion card?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Post Edited (simonl) : 6/23/2008 5:30:44 PM GMT
-Phil
1. Using a straight pinmap[noparse][[/noparse]devindex] is troublesome as the number of devices continue to grow.
2. An array of 32 or 64 byte pairs (depending on PropI or II version) for pin numbers could be used.
3. Mike Green's spin method per pin binary lookup merits more study. Mike, how would that work?
Baggers, can't eeprom storage be used for Hydra.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
One issue I see with this all is what about:
1. Multiple pieces of hardware of the same type (2 mice, 2 SD cards, 4 joysticks, or the like)
2. Changing hardware while a program/OS is running... (Unplug the keyboard and switch it for a mouse (after telling the program that's what your doing))
3. Ever increasing amount of hardware is being used, list will grow large quickly and any project will only use a small subset of all possibilt hardware.
VGA,
Composite video,
mouse,
keyboard,
hosts of LCDs,
controllers from a bunch of counsels,
GPS,
Compas,
Motors,
Accelerometers,
SD cards,
MP3 encloder/decoder chips,
OGG encoder/decoder chips,
Audio Jacks,
MIDI Jacks,
switches,
LEDs,
pots,
etc. etc. etc.
2. If any app' was hot-swap tolerant, I guess it will still be expected to handle that as it does now?
3. Hmm; I guess every original app' creator will need to 'claim' a standard filename for their app's required hardware that's not already got a standard filename. So if my app' requires a keyboard, mouse, and six LEDs, I'd just need to claim a new filename for the LEDs (say pd_SRL_APP01_LEDS1.spin); create the pindefs within that file; then distribute the file with my app'. If the end user wanted the LEDs on different pins, all they need do is redefine the constants in 'pd_SRL_APP01_LEDS1.spin'
[noparse][[/noparse]NOTE: pd_keyboard1.spin, pd_mouse1.spin would reference the user's existing files (although I'd still include mine in the archive, in case they didn't already have them]
{Edited to add the '1' suffix to the standard pindef filenames!}
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Post Edited (simonl) : 6/23/2008 6:20:34 PM GMT
Take it or leave it; just demoing a possible solution.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
what about passing the pin information from the OS to the APP in the ram , using Ariba's method? this wouldn't require an SD card.
jazzed :
trying your demo in a second. thanks for the post, i really like to see things like this and coleys post of working code. gives us a chance to see a theory in practice
Hippy:
I really like how you've broken this down in to digestible logic chunks. Perhaps our pindef should only be considered for compliant operating systems? About the second step, Anything we include on the target hardware, or in the OS should probably be as compact as possible. unless we do indeed require an SD card, which might be a little elitist.
Perhaps we should create a few different 'classifications' of applications and have a different method of passing information to each?
I'm not sure i fully understand your suggestion, all i know is that when i hear "windows registry" my stomach turns
Giemme:
A bios would be awesome. the problem i think would be convincing everyone to purchase an extra eeprom, and hook it up.
I wouldn't be happy leaving anyone out. It is possible to run an OS without an SD card though , and if we put the pin definitions in the OS (and therefor in the eeprom) that would negate the problem i think.
Complete world domination. Oh wait, you mean with this thread?
my ultimate goal is two fold. first to create an OS standard so people can switch between OS's without problems. second, to make it so that people can write applications that dont have to be re-compiled. download and run, no questions asked. (this seems to be the one people have picked up on recently)
thats a good question, but it only applies to the operating system stored in the eeprom. The operating system will have to squeeze the pin data into a few bytes at the end of the EEPROM
applications that 'require' the eeprom are rare enough that they can be hand edited before compliing i think
VIDEO
AUDIO
SD
CLOCK
KEYBOARD
Now most Applications are programmed in Spin, and you can say: change the pindef object and recompile the source. But this will change in future. For an Application programmed in C, you must say: buy the C compiler, make a project, change the Defines in the Header XY, and recompile the source. And perhaps other languages and compiler follows.
The Configuration array has only to define the lowest level, absolutly necessary Pins. Application which uses special hardware should have a CON block or include the pindef-object that defines the special Pins. Then the User can simply use the Application binary unchanged and has to connect the hardware at the predefined Pins, or he must recompile the source if he want to use other Pins.
The most necessary Pins are:
- SD card
- Display basepin (to show an Error message)
- Clock settings (not a Pin but a long and a byte)
Second prority:
- Keyboard basepin
- Mouse basepin
- Audio In/Out Pins
- Ethernet, Software USB (for alternativ Bootloaders)
- RTC, GPS
Serial RX/TX are fixed on 31,30 and EEPROM/I2C ar fixed on 28,29.
This minimal configuration and the commandline has to be passed in the MainRAM, this exists always in any Hardware, because it is part of the Propeller. And an Application can't read it from SD card without to know the SD card pins.
To clarify: An OS can also start binaries which not follows such a standard, you simply not have the benefit of auto configuration and command line passing.
I will assemble a list and some examples of a concrete implementation and post it later...
Andy
or as SD card file (but then from where come the SDcard Basepin?).
- with the magic number we can detect if a cmdline is passed in RAM or not.
- the Return Application is the binary that should be startet, when the Application is terminated.
This allows to return to the same Application that has startet the actual Application.
- if you only need the commandline, then read only the first 32 bytes of "cmd.sys"
Both sections together can build one datablock from $7FB0..$7FFF that can be copied with bytemove from/to the RAM, or
written in one 80 byte file ("cmd.sys") to pass to an application.
This is all handled by the OS, and the Application. The user has only to type in a commandline. And he must be
able to edit the configuration file with a PC, or Spin program.
' Example how an Application is started from the console application: CON #0, CLKFQ, #4, CLKRG, SDBASE, KBBASE .... 'the standard Array Indexes PUB main fsrw.start(pin) 'use here the precompiled Basepin or search for a SD card ifnot fsrw.popen("pconfig.sys","r") fsrw.pread(@config,32) 'overload the precompiled config from sd card fsrw.pclose ... 'let the user input the exefile and the commandline PUB runfile ifnot fsrw.popen("exefile.bin","r") bytemove($7FB0, @cmdline, 80) 'pass cmdline and config in RAM fsrw.bootSDCard 'and start application DAT cmdline byte 0[noparse][[/noparse]32], "CMDL" 'space for the commandline + MagicNumber retappl byte "console.bin",0 'own filename as return application config file "pconfig.sys" 'the precompiled config data, normally overloaded ' Example how to use the cmdline/config in a started Application CON #0, CLKFQ, #4, CLKRG, SDBASE, KBBASE .... 'the standard Array Indexes PUB main if long[noparse][[/noparse]$7FD0] == MAGIC_NUM 'passed in RAM? bytemove(@cmdline, $7FB0, 80) 'after this the RAM at $7FB0.. is free usable clkset config[noparse][[/noparse]CLKRG],long[noparse][[/noparse]@config] 'set the clock ... fsrw.start(config[noparse][[/noparse]SDBASE]) 'use the passed config or the default config tv.start(config[noparse][[/noparse]DISPBASE]) kb.start(config[noparse][[/noparse]KBBASE]) tv.str(@cmdline) 'display the passed commandline ... PUB quit ifnot fsrw.popen(@retappl,"r") 'return to the calling application fsrw.bootSDCard else reboot DAT cmdline byte 0[noparse][[/noparse]32], 0,0,0,0 'empty commandline retappl byte "console.bin",0 'default return application config file "pconfig.sys" 'default configI hope this shows how easy it is to pass the data by MainRAM - no eeprom or sd card driver needed,
no conflict that you need the SD card Basepin from the configuration to read the configuration.
And the MainRAM is only occupied with the Data for a short time, while the new application is booted, and
can before and after be used for the stack or a videobuffer or something else.
Attached are 2 Spin files with a working implementation. You need a Terminal to test it, and you have to set the SD card basepin in the OS_DEMO source, because no config-file is used, but a hardcoded config.
The OS_DEMO pass its config and the commandline, which you entry, to the OS_APPL binary in the MainRAM. See the comments at begin in the souce for usage.
Andy
I was not thinking an extra eprom but a common sector into the parallax eprom , a kind of BIOS.bin file to load during the bootstrap phase... in a way what Ariba is doing
Regards
Gianni
Thats really what i was trying to push at first but now there are so many options i think maybe its bet we sit back and let the dust clear a bit, find out which one of these ideas pans out to meet what i hope is the criteria everyone shares:
the standard should be easy to implement
it should be easy to use for newbies
it should work on all hardware
it should eat as few resources as possible
it should make you lunch when your too lazy to get up
ok, that last one is a pipe dream, but a guy can dream can't he?
In the mean time im playing with the idea of some logos, as suggested by someone here. if anyone has any other name suggestsions for the standard, or logo ideas i'd love to hear them
Andy, your post looks awesome, but i must sleep.. i am really looking forward to playing with it first thing in the morning
to write tools to inject information into the image. I would index the database from top down ( ie
index 0 at $7FFF ) and put the parameter passing area at location 0 down, then follow it with the
pindefs because that means it can be extended downwards. Actually, at location 0, put two pointers
to the parameter area and to the pindef areas and include details of the size of each. The one thing
that has to be avoided is compromise for compactness which renders it useless as things evolve.
Given that Spin bytecode is position independant, it would be possible to put the lookup routines to
access that database at the top of memory as well. There are mechanisms which can be used to
make a jump to a Spin method at an absolute address.
One thing I do worry about is rushing towards a solution without taking into account why that may
not be the best solution. I was serious about pins such as for keyboard and mouse not necessarily
being contiguous. One could say they have to be for this platform specification, but then it would
become less useful in the general case.
There should really be a spec as perfect as it could be before overly worrying about how it should
be implemented, getting it to fit on SD card or sub-setted to work on games platforms.
per pin for PropIA. A 2x64 array could be used for Prop2. With word wide array, you get 64k driver definitions per pin.
An array where the index is represents the pin number and value is the type makes a 2 dimensional array unnecessary.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 6/26/2008 4:12:13 AM GMT
Andy
true enough, but there will be flaws no matter how perfect. If we wait until its perfect it will never be implemented. the only way to truly perfect any standard is to release it , and wait for the complaints
Ariba:
Enjoy your holiday [noparse]:)[/noparse]
I believe we need TWO standards: one for pindefs for compiling code, and another (that builds on that?) for those using an OS - which is, I think, what vampyre's after.
I don't actually use an OS (yet) so the former would be of most use to me, and I believe it'd also be useful for compiling any OS too...
HTH.
Oh, and Andy - enjoy your holiday. Don't spend too much time pining for your Propeller!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Every device type has a defined constant, the eeprom has a 32 entry array, 1 per pin, containing the device type on that pin. This gives you a way to compare device types and know if its the same device. Then you can merge as long as there are no device conflicts. The attached file contains some code that reads the eeprom and merges that table into a local table. If the eeprom table doesn't exist the local table is used. It doesn't do the same for a sd file but it could be extended handle it.
Until this has had more time to shake out, I will probably adopt Coley's
auto-detect script to determine keyboard and video. This could be
combined with a some code to look for an SD.HID (Propdos Hidden file)
and if not found, ask the user for the base pin of their SD connection.
Just having Video,Keyboard,and SD will go a long way..
In the meantime, it's sure interesting to see all these ideas surfacing..
Sooner or later everyone will have to settle on *one* option for this
to actually solve the problem. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
Now if you included a 2x array, with pin index in one dimension and pindef in the other as I had in my previous .zip (though only provided as an example), the PinDefs.spin can be used for the compiled case.
The problem with the approach is bloat, which many will find problematic. Ariba's data structure also allows for clkfreq and others. Can you combine that into your code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The OS loaders when they load an app should copy a smaller table containing just the pins for keyboard, display and sd, and the ntsc/pal config into the top of ram. The config code doesn't have to read eeprom but just merges from ram which makes the code much smaller. The ram table can be small as well since it only contains a few pins. e.g. 8 bytes, 1 byte per keyboard pin, tv, vga, and 4 sd pins, plus a byte for ntsc/pal config. Each byte has a defined purpose i.e. first byte is keyboard, then tv, etc. The OS can copy the table from its own config.
Ariba may have done this already, but if a cookie is found in a memory area, a second stage loader can use that config for finishing startup for non-O/S users. That could reduce code size. To bad one can't conditionally load a spin object with the default language behaviour.
Steven has a "DOL" object that can start an object from SD. One could load an object on demand for O/S to complete bootstrap for that. I don't know if it has a bootstrap loader, but if it did, keeping a copy of DOL would only be necessary for O/S users.
OBC has a wiki entry for PinDefs draft already. Guess you've seen it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The ram table can pass clk info, pin info and ntsc/pal info
gpstest and camtest are 2 projects I converted to use this system so you can see how it works.
The device list is different from the current wiki list. Rather than a list of named con assignments to·a pin. You have a enum of devices (see config.spin). In the main spin file you define a 32 word table (plus ntsc/pal) and put the device type in the entry for the pin (see gpstest and camtest for examples). Since I have some non-standard device, enums above $8000 are locally defined, I put them in timconfig.spin. config.spin has a standard list of devices. I would expect as objects for devices are put in propeller object exchange, a device type would get added to the standard enum list.
It has a nice advantage of having a table in the main file, listing the device on each pin in 1 place.
Options so far are
1. Storing data in the object during compilation (pindefs file) - Smallest but can't be used for binaries
2. File on SD card - No good if you don't have an SD card and possibly hard to parse
3. Autodetect routine - Small and simple but only works for certain configurations
4. Use data stored in OS (using methods 1, 2 or 3) to save data to ram before loading another object from SD - Possibly best option but will probably need an SD card and we all need to agree on a format.
Why is storing data in EEPROM not an option? It is the only device in common for stand-alone boot configurations.
Are you thinking that display, etc do not need to be initialized before launching OS?
@Timmoore
The index of the array defining the pin number is a little different from the predefined expectation or typical thinking by some here. Using index as the pin removes the need for a 2x array and pin data storage growing as there are only so many pins. The mythical PropII will have 64 pins, and one may not want to burden Prop 1 users. Still, the init and getPin functions may require a chipid check.
A user can preload the array with EEPROM or whatever device code with your new example. Good.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 6/25/2008 3:52:55 PM GMT
Here is option 5
5. Store data in the eeprom - Basically everyone uses an eeprom, but, they are not all the same size so the data could get overwritten when storing a new program on the eeprom.
Does anyone have a problem with the idea of storing the information in the eeprom?
It seems to me thats the best solution, and since apps can be run from ram, its not like were eating application space