Phil's "constant object" is a good work round to get what I was thinking of, especially as OBC notes the XTAL configuration can be imported.
For the definitions in pindefs, I would not have any DAT, only constant definitions ( IP_ADDR0=192, IP_ADDR1=168 etc ). Anyone needing to have a DAT can build it from those constants. I would also have a definition for every I/O line. For the keyboard and mouse that's two lines, CLK and DAT, and they may not be in order nor contiguous across hardware platforms. For PAL/NTSC selection, simple boolean flags, PAL=True, same for interlaced, broadcast etc.
Naming "annoyances" shouldn't be a problem. Someone who doesn't like the choice of names can create their own object as an abstraction layer which imports and passes the pindefs names up as named constants they like. Other programmers who like the naming convention will have imported pindefs directly.
What I miss:
- Software-USB D+, D-, PullUp Pins
- Servos Basepin (and Number of Servos)
Are this Left,Right Up... constants for NES not provided by the NES driver? I think we should only define Pins, Clock settings and Modes, not specific driver constants.
And for the DS1302: why not RTC_CS, RTC_INIO ... so you can also use a DS1307 or others.
For the IP address: a constant IP_ADDR = 192 + 168<<8 + 1<<16 + 200<<24
PAL/NTSC: a constant PAL_MODE = 0 | 50 | 60 '0=NTSC, 50/60 = PAL with 50 or 60 Hz.
Here's a question, when you make a zip file of your project it will pick up your config file. That means that when someone else unzips the project they will have your config file and the compiler will use your config file instead of theirs unless you delete the one from the zip file. Anyone got any good ideas except for deleting the file when you download the object?
how would an application know if hardware its looking for isn't hooked up?
That goes with setting a pin to -1 to indicate that hardware doesn't exist and relying on the program to check the pin is valid before using it. Without conditional compilation that means extra run-time checking, but cannot be avoided at present.
If you mean, how does the program know if hardware which is expected to be there is plugged-in or not, that will mean probing the hardware to see if it's present ( may not always be possible ) or the end user must edit their pindefs / select the right pindef to match what they actually have at the time.
the compiler will use your config file instead of theirs unless you delete the one from the zip file
I think we'll have to live with that unless PropTool changes. The end user can keep their pindefs in the PropTool library file so that will automatically be used once the pindefs file in the downloaded local directory is deleted.
Both cases are where integration within PropTool would be beneficial ( a pindef editor pop-up would beat manually editing the files for many people ) but if that's not going to happen we have to make the best of what there is. With Propellent available it shouldn't hopefully be too long before we see alternative IDE's which can better deal with things the PropTool cannot. As they'll be just front-end GUI editors rather than home-grown 'maybe not quite exactly the same as PropTool' compilers, there should be considerable less resistance to using them over PropTool.
In this case, a third-party IDE can copy the selected pindef over "pindefs.spin" in the current directory before invoking Propellent, so that will get round that problem. It also means someone who hasn't got such an IDE and no clue about this pindef stuff can edit the pindef file as they'd normally edit the CON block so it's the best of both worlds.
stevenmess2004 said...
Here's a question, when you make a zip file of your project it will pick up your config file. That means that when someone else unzips the project they will have your config file and the compiler will use your config file instead of theirs unless you delete the one from the zip file. Anyone got any good ideas except for deleting the file when you download the object?
Jeff has promised to support PATH declarations in an upcoming version of the IDE. This will solve the config file issue, because you can always prepend the directory name of your own config file ahead of the one where the unzipped archive lives. That way your own config file will automatically preempt the unzipped verison. I just hope there's a way to alter the PATH from the IDE without having to do it from a DOS command line or by changing a registry entry.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 6/22/2008 5:28:44 PM GMT
If this is the way we are going to go, i'd like to see some example code that we can include in the standards definition for making use of the pindefs file, something we can post to get new users up and running quickly with it.
also interesting to note, at the moment the winning choice on the poll is "data in the eeprom and on the card". its not winning by much, but if someone wants another option and hasn't voted, please do so
OK Here is a binary that should work on Hybrid and Hydra.
Obviously I have tested it on my Hybrid and it works fine, I would be grateful if someone with a Hydra can test it for me.
If successful then I can adapt it for the demoboard too.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
The test is simplicity itself as you will see and I am sure it can be expanded upon to take additional hardware configurations.
Basically it goes like this:-
Start the Prop in RCSlow mode
Change to RCFast and wait for PLL to warmup
Check state of P12-P13 for harware configuration
Set TV basepin and switch clock to a setting appropriate for the target board
For Protoboards things may be a little difficult as I previously mentioned as there is no hardware predefined.
Maybe the best way for Protoboard users is to match their hardware to one of the configurations in this code.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
Thats a very promising design, simple and clean. thanks for posting the code for it.
I'm not sure this can be made to detect custom designs. if anyone can think of a way to mitigate that issue then were set.
Right now as far as pins go, i'm still torn between using eeprom, and using the spin object include suggestion. the vote poll still has another 6 days so i guess i should just shut up and be patient [noparse]:D[/noparse]
OBC:
I have a question about the spin object include you've written up. I've noticed some -1 lines, i'm guessing thats to tell that the hardware isn't there? If so are we trying to create a list of all possible hardware? Wouldn't it make more since to simply omit an entry if that hardware isn't present? I cant immagine trying to keep everyones list up to date with all possible hardware.
Example:
'pindef
'un-comment the code that matches your system, and change the pins where needed
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
' Primary TV Connection Single
TV_DAC1 = 12
' Primary Audio Connection Single
AUDIO1 = 10
' Secondary Audio Connection
'AUDIO2 = 11
' Primary Keyboard Single
KEYBOARD1 = 26
The above code would be a complete def file.
Would there be a way for an application to test for 'missing' hardware in the list, other than a compile error?
the other problem i see is that ever time someone adds a new peice of hardware, say, ROBOT_CAM to the list,
they then have to convince everyone who's downloads their applications , and is using the file, to modify their
files using the correct name
it seems to me that just changing pin definitions in the con block would be easier.
so my question is, have i missed something about how this could work? or are my assumptions basically correct?
also, the word PAL_MODE is a bit confusing since you can use it to define NTSC. perhaps VIDEO_SIGNAL would be better?
Coley, you might want to make it a seperate object, so it's easy to add to projects, and can then if any other mods get done to it, it's easy to replace stuff with it in [noparse]:D[/noparse]
I think we are missing some of the plot to a certain extent. For an OS to run it needs to know what basic hardware is installed and where it is installed. For instance you could have an OS that starts VGA, TV or serial depending on what was available. Most of us are also assuming that we need an sd card but it is possible to use an OS with just the eeprom (femtoBasic).
So it seems to me that we really need to specify some minimum level of resources available and then make the os capable of finding out what/where this is either at compile time or run time. The advantage of compile time is that it is more likely to work if your board has some weird (non-standard) configuration and the binary should be slightly smaller. Doing it at run time means that you could release just the binary if you wanted to. For example, some of the drivers from the hydra book.
So the spec would have three parts.
1. Diagrams to say what was connected where on the hydra, hybrid and demoboards. - Easy to do just put a link the the schematic.
2. An object to detect (at run time) which of the three boards is present and setup things properly. - Easy to do since Coley has already done it
-This can't really be the only option because too many people like experimenting with different things e.g. crystals.
3. Another object that just lists a whole bunch of constants that people can change for their board. - OBC has done some good work on this.
-May have to be careful with the number of constants. I think there is a limit (~256?)
Of course the other issue is standard interfaces for input/output drivers. I think that this has basically happened but do we want to make a set of standard methods required?
And shouldn't someone do a logo for things that are standards compliant? Who's good at ascii art?
Edit: some of that didn't make sense. Hope everyone else can figure it out [noparse]:tounge:[/noparse]
Edit2: If you edit your post quick enough it doesn't seem to add the edited at tag.
Edit3: See, the second time I took too long and it added it.
Post Edited (stevenmess2004) : 6/23/2008 12:35:53 PM GMT
stevenmess2004 said...
Doing it at run time means that you could release just the binary if you wanted to. For example, some of the drivers from the hydra book.
I think the easiest thing from a binary release perspective is to state the platforms that the code will run on.
This is what I will be doing in future with intermediate releases of any code I am writing.
I don't quite understandthe rest of this thread though, what exactly are you aiming for???
If the OS is already running to be able to read SD or EEPROM then surely pin definitions will already be set???
Or is this that you want generic code to be able to run and self modify to use the correct pin defines??
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?
In my opinion when code is released it should state the minimum specification that the code requires and maybe a method within the code explaining where to change pin definitions.
Otherwise you are going to struggle to cater for every eventuality which is gonna be nearly impossible!
Just my two pence worth...
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
I'm probably saying much as stevenmess2004 does, but here's my take on it: There are two parts to the subject -
1) The pindefs constant file for the 'load source, compile, download, run' brigade who want to take source from others and run it with minimum fuss.
2) Those pindefs being stored somewhere within the target platform so pre-compiled code can still work when copied to other hardware via SD cards etc.
There's some overlap because (1) will be used when configuring the OS itself for a particular platform.
For those working only from source code, 'compile time constants' are perfect, but for transportable code, programs need 'run-time determined constants' ( ie, the compile time constants used at OS compilation being retrievable at run time ).
So Step 1 is defining the pindefs.spin file, constant names etc. Step 2 is defining a data structure which can hold those constants ( ie, the array name, where it is, how it's accessed ). Step 3 is getting people to use the Step 2 data structure rather than hard-coded in source values. In effect, Step 2 and 3 is moving to using a Windows Registry for Propeller programs.
Step 1 is likely of interest to the entire Propeller community, Steps 2 and 3 probably only of interest to those who are looking at transportable programming directed at SD card.
PS : The "edited" tag doesn't appear unless someone has read the post before a subsequent change is committed.
I think we should define a common layer, a kind of BIOS or Open Firmware so that an I/O card can be executed by any Propeller system that uses that BIOS (plug and play.
I vote that we work from Hippy's last reply - it appears to cover the bases for all
So, I think we need to get the following sorted first:
1. Standard pindefs.spin
2. Documentation on how to use it (that'll be within pindefs.spin then!)
Probably best if someone posts a first draft, then we can provide input from there... (I'd do it, but I don't know how!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
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
I think we have enough of the concept grasped to be able to move forward but there is still some high-level debate to be had ...
Q : What happens if someone's code uses new device and new I/O lines ?
For the source-compilers the missing pin names will be obvious and can be added to pinsdef.spin, but how does that work for people with a pre-compiled platform which doesn't know those pins ?
Assuming the OS database is fundamentally an array or list of pin definitions, how do we relate a pin name for runtime use into an index into that array, how do we stop / help avoid two developers using the same array index for different things ?
Do we have a standard list of indexes of where a particular pin will be, necessitating a central repository and hoping everyone plays ball with that process, or go for a more complicated but flexible scheme where the database can be looked up by pin name ?
I think getting that right is going to be crucial to success and adoption. Text names add unnecessary bloat ( and again we hit a PropTool limitation of not supporting packed text ), but then a straight array having to support numerous pins, most unused adds bloat as well. Sparse arrays save space but have overhead.
Does there need to be a mechanism for extending the pindefs array/list so OS users can add a new pin definition without having to re-compile their OS every time a new program comes out which uses a new device or I/O pin ?
Then comes the harder sell - Should everyone writing for the Propeller be using this mechanism even though they are compile-source-only developers ? There's little runtime overhead, "tvPin := pd.PinLookup(String("TV_ADC1"))" at the start of PUB Main rather than a constant definition but will developers suck up the need to include a pindefs object and the overhead it comes with ?
What of the existing Parallax Objects, like TV_text, should they be changed to use pindefs ? How do we achieve consistency across the board ?
Added : Should we also be looking at something beyond just pin allocation, something which is more akin to the Windows Registry so things like IP addresses, 'This Unit ID', colour choices and keyboard mappings can be determined ? Can it be used for user preferences - mouse / keyboard / NES gameplay, high-score tables ?
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?
Comments
For the definitions in pindefs, I would not have any DAT, only constant definitions ( IP_ADDR0=192, IP_ADDR1=168 etc ). Anyone needing to have a DAT can build it from those constants. I would also have a definition for every I/O line. For the keyboard and mouse that's two lines, CLK and DAT, and they may not be in order nor contiguous across hardware platforms. For PAL/NTSC selection, simple boolean flags, PAL=True, same for interlaced, broadcast etc.
Naming "annoyances" shouldn't be a problem. Someone who doesn't like the choice of names can create their own object as an abstraction layer which imports and passes the pindefs names up as named constants they like. Other programmers who like the naming convention will have imported pindefs directly.
A lot of people seem to be interested.
I have one question about the spin object file
how would an application know if hardware its looking for isn't hooked up?
(poll was pre-mature, and will be reposted for new votes when new ideas stop showing up)
Post Edited (vampyre) : 6/23/2008 8:43:01 PM GMT
- Software-USB D+, D-, PullUp Pins
- Servos Basepin (and Number of Servos)
Are this Left,Right Up... constants for NES not provided by the NES driver? I think we should only define Pins, Clock settings and Modes, not specific driver constants.
And for the DS1302: why not RTC_CS, RTC_INIO ... so you can also use a DS1307 or others.
For the IP address: a constant IP_ADDR = 192 + 168<<8 + 1<<16 + 200<<24
PAL/NTSC: a constant PAL_MODE = 0 | 50 | 60 '0=NTSC, 50/60 = PAL with 50 or 60 Hz.
Andy
That goes with setting a pin to -1 to indicate that hardware doesn't exist and relying on the program to check the pin is valid before using it. Without conditional compilation that means extra run-time checking, but cannot be avoided at present.
If you mean, how does the program know if hardware which is expected to be there is plugged-in or not, that will mean probing the hardware to see if it's present ( may not always be possible ) or the end user must edit their pindefs / select the right pindef to match what they actually have at the time.
the compiler will use your config file instead of theirs unless you delete the one from the zip file
I think we'll have to live with that unless PropTool changes. The end user can keep their pindefs in the PropTool library file so that will automatically be used once the pindefs file in the downloaded local directory is deleted.
Both cases are where integration within PropTool would be beneficial ( a pindef editor pop-up would beat manually editing the files for many people ) but if that's not going to happen we have to make the best of what there is. With Propellent available it shouldn't hopefully be too long before we see alternative IDE's which can better deal with things the PropTool cannot. As they'll be just front-end GUI editors rather than home-grown 'maybe not quite exactly the same as PropTool' compilers, there should be considerable less resistance to using them over PropTool.
In this case, a third-party IDE can copy the selected pindef over "pindefs.spin" in the current directory before invoking Propellent, so that will get round that problem. It also means someone who hasn't got such an IDE and no clue about this pindef stuff can edit the pindef file as they'd normally edit the CON block so it's the best of both worlds.
Here is the link http://forums.parallax.com/showthread.php?p=715732
At the moment it only tests for differences between Hybrid and Hydra but could easily be expanded to check for Demoboard.
Unfortunately I don't know how you could do this for Protoboard as it doesn't have any hardware already committed.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
Please share your input!
propeller.wikispaces.com/PinDefs.spin
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
This is a command line exe that when called processes the spin file and then passes it to the propellent dll for compiling/downloading etc.
The downside of this approach is non standard spin source code and the requirement of a third party IDE.
Jeff has promised to support PATH declarations in an upcoming version of the IDE. This will solve the config file issue, because you can always prepend the directory name of your own config file ahead of the one where the unzipped archive lives. That way your own config file will automatically preempt the unzipped verison. I just hope there's a way to alter the PATH from the IDE without having to do it from a DOS command line or by changing a registry entry.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 6/22/2008 5:28:44 PM GMT
Thanks for starting the page on the wiki
If this is the way we are going to go, i'd like to see some example code that we can include in the standards definition for making use of the pindefs file, something we can post to get new users up and running quickly with it.
also interesting to note, at the moment the winning choice on the poll is "data in the eeprom and on the card". its not winning by much, but if someone wants another option and hasn't voted, please do so
Obviously I have tested it on my Hybrid and it works fine, I would be grateful if someone with a Hydra can test it for me.
If successful then I can adapt it for the demoboard too.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
Post Edited (Coley) : 6/22/2008 10:38:19 PM GMT
When run on Hybrid, Hydra or demo board it will display on the TV the name of the board and the clock speed.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
Ok, spit it out.. How did you do it? [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
Post Edited (Oldbitcollector) : 6/23/2008 12:23:27 AM GMT
The test is simplicity itself as you will see and I am sure it can be expanded upon to take additional hardware configurations.
Basically it goes like this:-
Start the Prop in RCSlow mode
Change to RCFast and wait for PLL to warmup
Check state of P12-P13 for harware configuration
Set TV basepin and switch clock to a setting appropriate for the target board
For Protoboards things may be a little difficult as I previously mentioned as there is no hardware predefined.
Maybe the best way for Protoboard users is to match their hardware to one of the configurations in this code.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
I'm not sure this can be made to detect custom designs. if anyone can think of a way to mitigate that issue then were set.
Right now as far as pins go, i'm still torn between using eeprom, and using the spin object include suggestion. the vote poll still has another 6 days so i guess i should just shut up and be patient [noparse]:D[/noparse]
OBC:
I have a question about the spin object include you've written up. I've noticed some -1 lines, i'm guessing thats to tell that the hardware isn't there? If so are we trying to create a list of all possible hardware? Wouldn't it make more since to simply omit an entry if that hardware isn't present? I cant immagine trying to keep everyones list up to date with all possible hardware.
Example:
'pindef 'un-comment the code that matches your system, and change the pins where needed _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 ' Primary TV Connection Single TV_DAC1 = 12 ' Primary Audio Connection Single AUDIO1 = 10 ' Secondary Audio Connection 'AUDIO2 = 11 ' Primary Keyboard Single KEYBOARD1 = 26The above code would be a complete def file.
Would there be a way for an application to test for 'missing' hardware in the list, other than a compile error?
the other problem i see is that ever time someone adds a new peice of hardware, say, ROBOT_CAM to the list,
they then have to convince everyone who's downloads their applications , and is using the file, to modify their
files using the correct name
it seems to me that just changing pin definitions in the con block would be easier.
so my question is, have i missed something about how this could work? or are my assumptions basically correct?
also, the word PAL_MODE is a bit confusing since you can use it to define NTSC. perhaps VIDEO_SIGNAL would be better?
Baggers.
Nice piece of code btw [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
So it seems to me that we really need to specify some minimum level of resources available and then make the os capable of finding out what/where this is either at compile time or run time. The advantage of compile time is that it is more likely to work if your board has some weird (non-standard) configuration and the binary should be slightly smaller. Doing it at run time means that you could release just the binary if you wanted to. For example, some of the drivers from the hydra book.
So the spec would have three parts.
1. Diagrams to say what was connected where on the hydra, hybrid and demoboards. - Easy to do just put a link the the schematic.
2. An object to detect (at run time) which of the three boards is present and setup things properly. - Easy to do since Coley has already done it
-This can't really be the only option because too many people like experimenting with different things e.g. crystals.
3. Another object that just lists a whole bunch of constants that people can change for their board. - OBC has done some good work on this.
-May have to be careful with the number of constants. I think there is a limit (~256?)
Of course the other issue is standard interfaces for input/output drivers. I think that this has basically happened but do we want to make a set of standard methods required?
And shouldn't someone do a logo for things that are standards compliant? Who's good at ascii art?
Edit: some of that didn't make sense. Hope everyone else can figure it out [noparse]:tounge:[/noparse]
Edit2: If you edit your post quick enough it doesn't seem to add the edited at tag.
Edit3: See, the second time I took too long and it added it.
Post Edited (stevenmess2004) : 6/23/2008 12:35:53 PM GMT
I think the easiest thing from a binary release perspective is to state the platforms that the code will run on.
This is what I will be doing in future with intermediate releases of any code I am writing.
I don't quite understandthe rest of this thread though, what exactly are you aiming for???
If the OS is already running to be able to read SD or EEPROM then surely pin definitions will already be set???
Or is this that you want generic code to be able to run and self modify to use the correct pin defines??
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?
In my opinion when code is released it should state the minimum specification that the code requires and maybe a method within the code explaining where to change pin definitions.
Otherwise you are going to struggle to cater for every eventuality which is gonna be nearly impossible!
Just my two pence worth...
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
1) The pindefs constant file for the 'load source, compile, download, run' brigade who want to take source from others and run it with minimum fuss.
2) Those pindefs being stored somewhere within the target platform so pre-compiled code can still work when copied to other hardware via SD cards etc.
There's some overlap because (1) will be used when configuring the OS itself for a particular platform.
For those working only from source code, 'compile time constants' are perfect, but for transportable code, programs need 'run-time determined constants' ( ie, the compile time constants used at OS compilation being retrievable at run time ).
So Step 1 is defining the pindefs.spin file, constant names etc. Step 2 is defining a data structure which can hold those constants ( ie, the array name, where it is, how it's accessed ). Step 3 is getting people to use the Step 2 data structure rather than hard-coded in source values. In effect, Step 2 and 3 is moving to using a Windows Registry for Propeller programs.
Step 1 is likely of interest to the entire Propeller community, Steps 2 and 3 probably only of interest to those who are looking at transportable programming directed at SD card.
PS : The "edited" tag doesn't appear unless someone has read the post before a subsequent change is committed.
Regards
Gianni
So, I think we need to get the following sorted first:
1. Standard pindefs.spin
2. Documentation on how to use it (that'll be within pindefs.spin then!)
Probably best if someone posts a first draft, then we can provide input from there... (I'd do it, but I don't know how!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
It's posted... hack away..
Needs some standards for various clock chips instead of just the 1307
and some generic standards for SPI connections.
propeller.wikispaces.com/PinDefs.spin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
So we have step 1 - now for step 2...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Q : What happens if someone's code uses new device and new I/O lines ?
For the source-compilers the missing pin names will be obvious and can be added to pinsdef.spin, but how does that work for people with a pre-compiled platform which doesn't know those pins ?
Assuming the OS database is fundamentally an array or list of pin definitions, how do we relate a pin name for runtime use into an index into that array, how do we stop / help avoid two developers using the same array index for different things ?
Do we have a standard list of indexes of where a particular pin will be, necessitating a central repository and hoping everyone plays ball with that process, or go for a more complicated but flexible scheme where the database can be looked up by pin name ?
I think getting that right is going to be crucial to success and adoption. Text names add unnecessary bloat ( and again we hit a PropTool limitation of not supporting packed text ), but then a straight array having to support numerous pins, most unused adds bloat as well. Sparse arrays save space but have overhead.
Does there need to be a mechanism for extending the pindefs array/list so OS users can add a new pin definition without having to re-compile their OS every time a new program comes out which uses a new device or I/O pin ?
Then comes the harder sell - Should everyone writing for the Propeller be using this mechanism even though they are compile-source-only developers ? There's little runtime overhead, "tvPin := pd.PinLookup(String("TV_ADC1"))" at the start of PUB Main rather than a constant definition but will developers suck up the need to include a pindefs object and the overhead it comes with ?
What of the existing Parallax Objects, like TV_text, should they be changed to use pindefs ? How do we achieve consistency across the board ?
Added : Should we also be looking at something beyond just pin allocation, something which is more akin to the Windows Registry so things like IP addresses, 'This Unit ID', colour choices and keyboard mappings can be determined ? Can it be used for user preferences - mouse / keyboard / NES gameplay, high-score tables ?
Post Edited (hippy) : 6/23/2008 3:39:46 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·