vampyre said...
could someone explain fully the idea of a 2x32 array? I'm not sure i understand how that works.
A 2x32 array is not necessary. It was an idea to keep the pin mapping from growing.
Not having to grow the pin map array is important for expansion considerations.
Timmore's method is superior. It·keeps the array from growing·using a one dimensional array.
Think of the pin numbers as array indices; the contents of each location would contain an
enumerated value representing the device connection. If you want pin 12 to be the first pin
in the TV_DAC, you fill the value at array index 12 with the TV_DAC identifier.
An array example where the symbolic constants are enumerated values and not pin numbers:
Getting the pin number for TV_DAC10 would then be done by lookup as Timmoore defined:
(Edit Added: Actually, the LOOKDOWNZ spin statement achieves the same thing and is faster.)
PUB GetPin(Type) | index · repeat index from 0 to 31 ··· if word[noparse][[/noparse]PINS][noparse][[/noparse]index] == Type ····· return index · return -1
So instead of using N number of locations to define the·PIN numbers of a list of N devices,
you can use N device enumerations as the definition for a PIN. One can also use this
approach with PropII if it ever comes and distinguish the requirment for the lookup by
checking the chipid and performing the correct steps.
Hope this is clear.
@Steven, RE EEPROM use:
The spin "_FREE" statement lets you reserve a certain amount of memory in the program
space·from being used.·Still, one might accidently erase the config bytes. Given the
emperical evidence, only the required EEPROM space is·programmed with code and not
the entire EEPROM as is the case for some FLASH parts (or sectors thereof). Having a hub
ORG $addr would make using EEPROM space easier. An EEPROM programming utility could
easily be made available with a GUI front end for managing the config bytes.
thanks much jazzed for taking the time to explain it to a simpleton. [noparse]:)[/noparse]
if i understand it correctly, this method requires an exhaustive list of all known hardware that must be updated regularly?
if thats true, how can we keep that from becoming a real headache? (wouldn't everyone that uses it have to constantly update their lists?)
The list needs to contain the devices that people want to be able to exchange software for. But thats the same with the other method. When I tried it, I split the enum space in half, the upper half was locally defined for stuff that wasn't on the standard list. I would expect if someone release software for a device then a standard device number would be allocated for it. The same way a standard device con would be allocated in the current pindefs.spin method.
I had 2 files config.spin that contained a standard device list plus the access routines and timconfig that contained device enums for nonstandard devices that had no standard software.
I like the idea of an array of max pin number size with each entry saying what that pin is used for. There are a few cases where pins may be shared for two functions ( common DAT for mouse and keyboard. separate CLK, SPI and I2C mixed on the same bus ) but that could be said to be unusual and therefore reasonable to exclude.
Taking Jazzed's GetPin() method utilised in application code that becomes something like ...
tvPin := pindefs.GetPin( pindefs#TV_ADC1 )
That dictates a public allocation database which defines the name TV_ADC1 and what it's value is. Not particularly a problem in doing that.
How though would the hardware platform specific database be initialised / created ? I presume that for each hardware platform there will be a definition list in the form of something like ...
TV_ADC1 = 12
If that were held in the OS source code in a CON section, the first thing the OS could do in PUB Main is run a series of database updates ...
pindefs.SetPin( pindefs#TV_ADC1, TV_ADC1 )
For non-OS programmers working with source code, they can either use standard CON definitions and 'tvPin = TV_ADC1" or they can call SetPin() initially and then use GetPin() later.
Both SetPin() and GetPin() can work with Ram only. For non-OS users, Ram will be loaded initially with garbage but set correctly once PUB Main initialises it all with SetPin(). For OS source code a SaveToEeprom() method will update Eeprom from Ram, and after every re-boot (for an application which doesn't know the pin mapping ) Ram will automatically be set as that application needs for its GetPin() calls. SaveToEeprom() can be smart enough to not update Eeprom if the data is already set as required to save unnecessary wear.
A typical application ( normal standalone source, or OS source ) which itself would define what the pin definitions were would look something like ...
CON
TV_ADC1 = 12
OBJ
pindefs : "PinDefs"
VAR
long tvPin
PUB Main
pindefs.ClrPins
pindefs.SetPin( pindefs#TV_ADC1, TV_ADC1)
pindefs.SaveToEeprom ' If an OS
tvPin := pindefs.GetPin( pindefs#TV_ADC1 )
An application which is run via an OS and has no knowledge of pin allocation would look something like ...
OBJ
pindefs : "PinDefs"
VAR
long tvPin
PUB Main
tvPin := pindefs.GetPin( pindefs#TV_ADC1 )
In the earlier, pin setting application code, that still has the pin setting hard-wired in source code; not what we want for platform independence, so to go back to the earlier putting localised pin definitions in a sub object idea, that becomes ...
OBJ
pindefs : "PinDefs Library"
mypindefs : "PinDefs for DemoBoard with USB added"
VAR
long tvPin
PUB Main
pindefs.ClrPins
pindefs.SetPin( pindefs#TV_ADC1, mypindefs#TV_ADC1)
pindefs.SaveToEeprom ' If an OS
tvPin := pindefs.GetPin( pindefs#TV_ADC1 )
The calls to ClrPins() and SetPin() can actually be folded into the localised pin definition object which simplifies the high-level application or OS code quite nicely ...
OBJ
pindefs : "PinDefs Library"
mypindefs : "PinDefs for DemoBoard with USB added"
VAR
long tvPin
PUB Main
mypindefs.SetPins
tvPin := pindefs.GetPin( pindefs#TV_ADC1 )
For anyone who did want named pins rather than directly using the pindefs constants, it would be easy enough to add an extra database lookup which can convert a String("TV_ADC1") into the pindefs#TV_ADC1 pin type number.
Another idea ... make the "what's this pin's type" array a long. Then define the value of a particular pin type, eg TV_ADC1 as if it were a packed 5-bit character name; that's six text chars per name plus a final 0 to 3 in the left over two bits ( no number and it defaults to zero ). Not correct maths but for example, TV_ADC1 = $A53D_5601
That then gets back to not being absolutely crucial to keep a copy of the centralised data base locally. Developers simply choose an unused name ( with reference to the centralised data base ), then use it.
An advantage is that it's reasonably easy to turn a String("TV_ADC1") into a long value, and likewise turn a long value into a string. That is useful for adding an OS application which can list what the pin definitions are in an easily readable way.
It would be nice if the PropTool had a PakedString() directive to do the packing and save code overhead but having to write a method to do that isn't a major problem.
That worked quite well, proof of concept code attached. Very minor changes needed to make an 'existing application' work using platform independent hardware. Just need to remember to change the "OBJ pindefs" definition in the main program and use variables rather than constants for pin numbers - that's not hard as there are no pin number constants in the main program !
This uses text names for pins ( the packing and unpacking code was thrown together and can be improved ) and all the String("...") overhead would disappear if the PropTool supported PackedString("...") compile time conversion to a packed long constant.
Edited : Major bug fixed ( bytes cannot be negative ) and pin name aliasing so I can use whatever names I want within my applications and still have them mapped to standard names as defined by the community.
@Hippy, thanks for looking at the "PinType" array idea and offering good enhancements. I have a few comments below and have added a preliminary API method description.
Also, It would be a good idea to find a way for storing/getting the other key infomation such as clock freq/mode, ntsc/pal, and other information mentioned by Andy and OBC. Not sure how all this information·gets put into a structure. I suppose that all grows down in the memory map now that we have a way to constrain the pin definition size. See end of this post for possible datastructure organization.
hippy said...
Taking Jazzed's GetPin() method utilised in application code that becomes something like ...
Actually, I had quoted Timmoore's method. Just assuring proper credit [noparse]:)[/noparse]
hippy said...
How though would the hardware platform specific database be initialised / created ?
I was thinking a Propeller binary and a Windows or Java GUI could automate this. Using packed strings, a GUI would not be required, though it would be useful for helping deal with the latest specification.
hippy said... For non-OS programmers working with source code, they can either use standard CON definitions and 'tvPin = TV_ADC1" or they can call SetPin() initially and then use GetPin() later.
Yes. The "PinType Array" approach is optional. The "PinDefs.spin" containing pin numbers can be used as is, and a "PinType.spin" containing pin types could be added to "source control". It seems trivial to make this distinction, but having unique, descriptive names clearly communicates the idea to a new user.
Regarding packed strings: I also prefer string definitions for various reasons.
Some key advantages·are 1)·no need to keep enumerations that can become out of sync without monitoring and approval based updates, and 2) an SD config file could be saved as ASCII· (as you have indirectly mentioned) and conveniently interpreted as packed strings. Of course duplicates would still need to be managed.
There are·some drawbacks though, principally: 1) While a large number of unique strings can be defined, a smaller subset of less cryptic names is available (Enums overcome this problem), and 2)·Packed strings require more bytes, but size is still·reasonable.
Timmoores approach of or-ing $8000 for non-approved enumerations is an attractive solution.
Either packed string or enumeration approach is fine with me as long as the considerations are understood in making the decision.
hippy said...
SaveToEeprom() can be smart enough to not update Eeprom if the data is already set as required to save unnecessary wear.
Yes, this is clearly a requirement[noparse]:)[/noparse] Pardon my diving too deep here, but it seems to me that the only time a Propeller program would write EEPROM would be if the config cookie is not found and/or if a RAM -vs- EEPROM checksum or CRC16 has a mismatch. Config cookie would remain the same normally; version and chipid fields should be included in a config structure.
It appears that having a pin database is a requirement for some users and may be leveraged by anyone.
This may seem premature to some at this stage, but it would be useful to define the "PinTypes.spin" API in simple description and method "signature" terms just as an idea of usage. Doing so at this stage helps to shake out problems and helps to create a palatable response to the requirement. (/** ... __ ...*/ are for doxygen tags that make creating an explicit·doc set easy; Propeller IDE has no convenient way to consistently define parameters and return values documentation).
{
Object "PinTypes" Interface:
PUB Init(address) : returnCode
PUB ClrPins : returnCode
PUB EepromLoad(addr) : returncode
PUB EepromSave(addr) : returncode
PUB GetPin(type) : pinNumber
PUB SetPin(type, pindef)
Program: 9 Longs
Variable: 0 Longs
}
PUB Init(address) : returnCode
{{/**
Initialize the object with expected ram storage.
@param address is ram address to use for PinType configuration.
@returns number indicating action taken
__ int Init(int address);
*/}}
PUB ClrPins : returnCode
{{/**
Clear pin type table to a known state with all pin types set to "unused"
@returns number indicating action taken
__ int ClrPins(void);
*/}}
PUB EepromLoad(addr) : returncode
{{/**
Load pins from the EEPROM.
@param ??? config table address ???
@returns number indicating error or successful action taken.
__ int EepromLoad(int addr);
*/}}
PUB EepromSave(addr) : returncode
{{/**
Save config data to the EEPROM.
@param ??? config table address ???
@returns number indicating error or successful action taken.
__ int EepromSave(int addr);
*/}}
PUB GetPin(type) : pinNumber
{{/**
Get pin number for a given device type connection.
@param type is a PinType enumeration or packed string.
@returns PinDefs.spin pin number.
__ int GetPin(PinType_t type);
*/}}
PUB SetPin(type,pindef)
{{/**
Set pin number for a given device type connection.
@param type is a PinType enumeration or packed string.
@param pindef is the pin number from PinDefs.spin to use for the type.
__ void SetPinType(PinType_t type, int pindef);
*/}}
A possible datastructure would be starting at $7ffC and growing down:
Header with cookie, version, (chipid?), (length?) checksum.
PinType array (size dependent on target chipid/version or fixed at 64).
Other info such as clock frequency/mode, ntsc/pal.
Other optional fields based on some kind of feature table (ethernet config?).·
I suppose an SD load/save object would be added on top of this for managing the SD binary storage.
If packed strings were used, the SD file could be ASCII with a packing translator.
Don't get too annoyed if this response is too long [noparse]:)[/noparse]
It appears that having a pin database is a requirement for some users and may be leveraged by anyone.
What's really nice about this, with a minimal amount of overhead, example code can be released for anyone regardless of their hardware. Code can be shipped with "OBJ pindefs" set to either a standard hardware platform ( they'll all be the same everywhere ) or that users specific own settings and all the recipient has to do is make one edit to source code.
Credit to Phil for the idea of using a sub-object as the means of definition.
As long as the top level is clear and simple I don't see a problem and would encourage everyone to adopt the idea. I'm going to
How it works below the top level and how those using OS's want to wangle it around I'm not really too worried about. There are things to sort out and additions to be made but I'm happy that I have a workable system now which can be easily changed as the spec gets closer to completion.
Finally credit to vampyre for promoting the issue and everyone who's has helped so far.
truly amazing stuff, its starting to congeal in a really nice way. Thanks to all for giving this some real consideration and brain cycles. i think once this does get implemented it will benefit everyone
I'm starting to warm up to the idea of an enumerated list. if i'm writing an application that would use the standard, its probably meant to be used by lots of people. and if thats true, it probably doesn't use uncommon hardware anyway. as long as there is a standardized way of adding non-standard hardware definitions i think it'll be fine
I'm gonna reboot into windoze and check out this demo code
@hippy. I dont think there is a reason to pack the string, why not just store the address of the string in the array. Each string has a unique address in memory so you can just go through the array doing string compares
One of the problems I see with strings, is that it is very nice having a file with a list of the standard names for all the devices. You can't do that with strings because the spin compiler isn't smart enough to remove unused strings. So you have to enter the strings you need for each project rather than having a file with a bit list of all the device types.
CON enum gives you the list without any overhead of not using an entry.
This talk of strings vs enumerations sounds strangely like something I asked about when I first started working on DOL Packed strings are nice in theory but a pain in the neck because its not supported by the propeller. Also, you would need at least a long for packed string where as you only need a word for an enumeration.
Pointers to strings in the table won't be as useful because the sd loader won't know where they are and will quite possible overwrite them.
I don't think there's a definitive answer to the string versus defined value choice and each has their merits. I personally favour strings but can appreciate the case against.
Using the address of a string is an interesting option but as locations of strings move around the enumeration will change on every re-compilation of the OS and the location of strings in the OS and in an app compiled for that OS will differ.
The issue of string overhead is something which is a problem but something which can be fixed by a PackedString() directive in the compiler. I'd argue for pushing Parallax to add that as a useful facility ( more useful than just in this case ) rather than simply discounting strings.
In truth it doesn't really matter which is used, string or numeric constant, providing the means of converting string to constant is well defined. SetPin(Packed(String("TV_ADC1"))) is exactly the same as SetPin(PackedString("TV_ADC1")) and SetPin($FEDCBA98). The only overhead is in having to provide the Packed() method and the space taken up by the strings which are used.
Regarding the use of long against word, I don't think 64 bytes more is an excessive overhead.
One thing I did consider was how to deal with awkward people ( like myself ) who will stubbornly insist on using the names they want to use in applications regardless of what names the pindefs system calls for. Regardless of the arguments, people will use what they want to so making it easy to do has to be part of the consideration. To handle this, where I insist on using TV_PIN when the standard s TV_ADC1 say, I would use ...
OBJ
pindefs : "My_Hacked_ProtoBoard"
VAR
long tvPin, ledPin
PUB Main
tvPin := pindefs.GetPin(MyPinName(Packed(String("TV_PIN"))))
ledPin := pindefs.GetPin(MyPinName(Packed(String("LED_PIN"))))
:
PRI MyPinName( enumValue )
pindefs.Alias( Packed(String("TV_PIN")) , Packed(String("TV_ADC1")) )
PRI Packed( strPr )
return pindefs.Packed( strPtr )
If using only numeric constants, that's more complicated because I have to define a constant to enumerate what I call TV_PIN ( which mustn't clash with a genuine enumeration ) and there ends up a mix of self-defined and imported enumerations ...
OBJ
pindefs : "My_Hacked_ProtoBoard"
CON
TV_PIN = 1
VAR
long tvPin, ledPin
PUB Main
tvPin := pindefs.GetPin(MyPinName(TV_PIN))
ledPin := pindefs.GetPin(pindefs#LED_PIN)
:
PRI MyPinName( enumValue )
pindefs.Alias( TV_PIN , pindefs#TV_ADC1 )
While there's a degree of 'sheer bloody mindedness' about that ( people are strange creatures ), I see a far greater elegance and consistency in the former approach.
To encourage adoption by the widest audience I think it's necessary to explain to people how to use this platform independence and make that as simple as possible no matter how they want to do things. I'd argue that documenting how to change existing code which has fixed pin number constants into platform independent code is far simpler in the first case than the second.
To get people to adopt to the new notion of platform independent coding means having to make it easy for them and to pander to their 'peculiar insistences'. It's not like where people have no choice but to do it the way it has to be done, they do have a choice, and if they cannot be convinced of the merits they will do it their way instead. I wouldn't be considering changing all my code if I felt it complicated things or was more trouble than it was worth rather than delivered an advantage.
I'll agree, "you're just being awkward and obstinate"; I am, I'm allowed to be, it's the inventors job to get me to buy into what's proposed
A possible datastructure would be starting at $7ffC and growing down:
1. Header with cookie, version, (chipid?), (length?) checksum.
2. PinType array (size dependent on target chipid/version or fixed at 64).
3. Other info such as clock frequency/mode, ntsc/pal.
4. Other optional fields based on some kind of feature table (ethernet config?).
Any reason for clkfreq/mode & ntsc/pal being after PinType array? If we put them between header & array we'll know they won't move (not sure that's a problem, but my gut feeling is that it's one less thing to worry about).
I can't wait for this to get finalised
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Using your own constant name is not so hard if you're willing to write a new object (this was suggested before?). That would also be small and fast since CON space doesn't take up memory and does not require a method for translation. Then if some microsoft like standard for building symbols comes along that makes you hurl, you can just hide it in one place [noparse]:)[/noparse]
I'm not a fan of using the address of strings or even an offset of strings within a table; this is just a different way of creating an constants or an enumeration.
The whole point of using strings for to me is convenience, but that can be costly depending on implementation. My main concerns for using numbers over strings is in serialized IPC for different endian systems (unlikely) and IPC enum/constant table versioning (likely but managable if done in a serialized way rather than inserting new devices because it makes the file look nice). Whoever does serialized IPC can define their own translation.
It's a tossup for me, but I'm leaning toward enumerations at this point.
@Simonl,
The pin table as currently described is fixed based on chip version (I would like to see it as 64, but can be 32 or 64 based on the chipid). I'm concerned that the "properties block" of clkfreq, video, etc... block would change or have additions more than the pin table. New data can be added after the pin table easily though.
The simplest thing to do for so-called blocks of data would be to have a cookie representing the meaning of each block. Code can easily handle that.
@jazzed: Ah yes - hadn't spotted that. Works for me
So how are we all going to decide on this standard?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I've re-written my demo code to allow Packed(String("TV_ADC1")) or pindefs#TV_ADC1 and that seems to be working okay, but I've hit an obstacle I want to solve before the next release ... how to set the clock mode and frequency at run time. I want -
PUB Main
SetClockModeAndFrequency( XTAL1 + PLL16x, 7_372_800 )
The above has to translate into ClkSet( $6F, 117_964_800 ) and follow the process needed to switch from boot-up RCFAST ( or anything it may be set to ). Has anyone got any pre-written code to do that as I don't seem to be getting anywhere with what I've tried ?
Hmm too! Wouldn't changing the clkfreq/mode be a problem? What'd happen to an OS if a loaded app' changed those?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I had wondered "what's the point" of holding that data let alone changing the settings - which is why I held of commenting on that - but it is very useful for source code compile portability. No need to specify _CLKMODE or _XINFREQ at all, that can be extracted from the personal, hardware specific pindefs.spin. Makes the source cleaner, and the values can be imported if preferred.
For an OS, if the code has been copied to Eeprom and is being launched by re-booting it would need to know the mode and frequency. Not true if there is no re-boot as the settings will already be correct.
I feel it should be there for completeness but I think it's going to add a fair chunk of overhead.
Ah yes - I'd got the wrong end of the stick. Thanks hippy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Wrong end ? Where I grew up that means something like "bad deal" or some other misfortune. Hope that's not the case here.
Simon, What you said before about clkfreq finally hit me. Allowing a casual user to change the clock at will may not be such a great thing. For example: I managed to destroy a $300 TV/VGA panel by changing the clock frequency during some experiments. Of course there is a disclaimer, but I would be really pissed if that happened again. How to proceed? Just ignore it and move on?
I'm joining this conversation a little late, but this was a problem that I ran into with the ybox2. As it turns out, there were a lot of prototypes with different LED hookups... The colors were mixed up, some were common cathode, some were common anode, etc... But I didn't want to throw out these prototypes.
The solution was that I encoded the LED pin configuration information into the EEPROM using the Settings object which I wrote. This object has turned out to be absolutely indispensable to me for managing all sorts of things. As long as you have a 64kb EEPROM, then you don't have to worry about overwriting the settings when you reflash with your prop-plug. I'm slowly building up a standardized list of keys for people to use for storing various information... Things like one-wire bus pin, LED pins, speaker pins, etc...
@vampyre
Perhaps it would be useful if you quickly summarize the requirements and what current proposals may be contributing to your goals?
We have mostly addressed possible configuration mechanisms and practically zero O/S items.
Current runtime config requirements as I understand them:
1. Header with cookie, version, (chipid?), (length?) checksum.
2. PinType array (size dependent on target chipid/version or fixed at 64).
3. Other info such as clock frequency/mode, ntsc/pal.
4. Other optional fields based on some kind of feature table (ethernet config?).
more?
@darco
Nice ideas.
If you were to create a bare bones object for saving/getting properties how big would it be?
How much storage is necessary for your current database? How many entries does it have?
I dont particularly have any requirements, the only thing i would really, really like to see, is something the majority of people agree on, and will/can use.
that is my concern at the moment. if i can't understand the code, im worried someone else might not be able to and that might discourage them. if however, i can come to understand it i can document it in 'idiot friendly' terms [noparse]:)[/noparse]
to clarify what i'd like, but dont really need, to see as a standard for applications:
*something that makes it unnecessary for most people to reconfigure / recompile code
*something that doesn't eat a lot of the space that could be used by applications (small ram requirements)
*something easy to implement, use and understand (so it can be modified by other people)
for operating systems:
*a way to pass the command line
*a list of file types with documentation (pretty easy to do)
*a way to pass pin assignments to the application (could be the same as the above)
for the OS , as far as i'm concerned all of these posts will influence the OS standard. if we can come up with a standard way of defining pins in an application, I can then implement that as the standard way of doing so for an operating system.
I still dont quite understand what the problem with putting the array in the eeprom is though, and then just writing a small spin util to extract the info as needed? is it that people dont wanna give up their eeprom space?
This thread went over my head around page 4... [noparse]:)[/noparse]
Yes, we'll have to challenge these professional software engineers
(It's nice to have experts here!) to find a simple way to present
this information or new users will be completely lost in the solution.
I DO like where this is going, now if we can only streamline the
concepts and make them idiot proof. Heck, if I can wrap my
brain around it, you've made it. <smirk>
Hehe OBC: I think I can rival you on that one - you're way ahead of my abilities, so here's the challenge: get me to understand the standard!
Actually, I think we have all the ingredients now. In fact, I think darco is ahead of us, except that his 'settings' object requires a 64K eeprom :-(
@vampyre:
1. Thanks for getting this started - I'm sure it'll lead to a good standard.
2. I think the 'problem' with using eeprom is that it's too easy to overwrite when programming from PropTool (if I'm right, PropTool overwrites ALL 32K doesn't it?)
3. I think we need a way do code PinDefs.spin so it can be used both for compile AND as a file for OS binaries to reference?
And then we need to properly document it, so even I (and other noob's) can understand how it works.
I'm happy to offer my services to test
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
*something that makes it unnecessary for most people to reconfigure / recompile code
For those without an OS that's probably impossible to achieve. Compilation with minimal effort can be achieved; a one text name change is all that's required to make the program run on their specific hardware.
*something easy to implement, use and understand
There are five types of users - program users, program developers, platform independence systems programmers, OS application developers. OS developers.
Program users - Will need to know how to change the text name to adopt a program to their hardware. Will need to know how to create a definition file for their particular hardware if it is non-standard. Do not need to know how the platform independence works behind the scenes.
Program developers - As per program users but additionally need to know how to use and call the platform independence object to make their programs platform independent. They won't need to know how things work behind the scenes.
Platform independence systems programmers - These are the only people who will need to understand how things work behind the scenes; the others "use it", these people "define it and implement it".
OS application's developers - Really just program developers. The "how to guide" will be much the same with only one minor change; non-OS developers have to call a routine to ensure a user's platform settings are loaded while an OS developer has to call a different routine to load a user's platform settings from SD/Eeprom/somewhere.
OS developers - Really just program developers, but need to know how to get the user's settings stored to SD/Eeprom/whatever for OS applications to later use.
While it would be nice to understand how the internals work, most people shouldn't need to care, and how it works is really a debate amongst platform independence system developers alone. As far as I'm concerned, as long as that provides what I want as a program developer - how to specify and use the pins - I'm happy. That debate is limited to the boundary of the interface. How it works underneath is really a separate issue.
Ideally the debate and discussion should be in two distinct parts; the API ( boundary interface ) and the internal implementation. Obviously the two will get discussed together at this early formative stage which is where I think some confusion and perceptions of over-complexity has crept in.
I still dont quite understand what the problem with putting the array in the eeprom is though
For Propeller OS users that's not a problem, how everything interacts and uses Eeprom can we well defined and compliance insisted upon. For non-OS user's the Eeprom is unprotected and anything can erase settings held; every PropTool download will do that. Thus any platform independent code must use a mechanism which doesn't rely upon what's pre-stored in Eeprom.
It would be possible to mandate the settings database is held in the top 32KB of a 64KB Eeprom ( as per darco ) or in SD Card but not all users will have those and not all programs will be compliant or respect such use. Darco's implementation works because he has defined it as necessary to have 64KB Eeprom and has control over all applications to be downloaded on that hardware. We don't have that luxory.
For a compile source and download program ( which includes the initial OS installation ) it's necessary to keep settings held as definitions in an object file and at run the access settings via the database to achieve platform independence. For an OS, part of its job will be to take those settings and write them to SD/Eeprom/wherever so later OS Apps can get them from.
OS Configuration will occur only once, when the user is compiling and installing the OS on their hardware. When started it updates Eeprom as necessary ( a "run once" action ). Any OS-Based App will load the pre-stored settings and use those.
Comments
Not having to grow the pin map array is important for expansion considerations.
Timmore's method is superior. It·keeps the array from growing·using a one dimensional array.
Think of the pin numbers as array indices; the contents of each location would contain an
enumerated value representing the device connection. If you want pin 12 to be the first pin
in the TV_DAC, you fill the value at array index 12 with the TV_DAC identifier.
An array example where the symbolic constants are enumerated values and not pin numbers:
PINS := @pinConfigArray
word[noparse][[/noparse]PINS][noparse][[/noparse]0] := UNUSED
word[noparse][[/noparse]PINS][noparse][[/noparse]1] := UNUSED
word[noparse][[/noparse]PINS][noparse][[/noparse]2] := UNUSED
word[noparse][[/noparse]PINS][noparse][[/noparse]...] := UNUSED
word[noparse][[/noparse]PINS][noparse][[/noparse]12] := TV_DAC10 (DAC 1 bit 0)
word[noparse][[/noparse]PINS][noparse][[/noparse]13] := TV_DAC11 (DAC·1 bit 1)
word[noparse][[/noparse]PINS][noparse][[/noparse]13] := TV_DAC12 (DAC 1 bit 2)
word[noparse][[/noparse]PINS][noparse][[/noparse]14] := UNUSED
word[noparse][[/noparse]PINS][noparse][[/noparse]...] := UNUSED
word[noparse][[/noparse]PINS][noparse][[/noparse]28] := I2C1_CLK
word[noparse][[/noparse]PINS][noparse][[/noparse]29] := I2C1_DAT
word[noparse][[/noparse]PINS][noparse][[/noparse]30] := UART1_TX
word[noparse][[/noparse]PINS][noparse][[/noparse]31] := UART1_RX
Getting the pin number for TV_DAC10 would then be done by lookup as Timmoore defined:
(Edit Added: Actually, the LOOKDOWNZ spin statement achieves the same thing and is faster.)
PUB GetPin(Type) | index
· repeat index from 0 to 31
··· if word[noparse][[/noparse]PINS][noparse][[/noparse]index] == Type
····· return index
· return -1
So instead of using N number of locations to define the·PIN numbers of a list of N devices,
you can use N device enumerations as the definition for a PIN. One can also use this
approach with PropII if it ever comes and distinguish the requirment for the lookup by
checking the chipid and performing the correct steps.
Hope this is clear.
@Steven, RE EEPROM use:
The spin "_FREE" statement lets you reserve a certain amount of memory in the program
space·from being used.·Still, one might accidently erase the config bytes. Given the
emperical evidence, only the required EEPROM space is·programmed with code and not
the entire EEPROM as is the case for some FLASH parts (or sectors thereof). Having a hub
ORG $addr would make using EEPROM space easier. An EEPROM programming utility could
easily be made available with a GUI front end for managing the config bytes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 6/26/2008 5:35:13 AM GMT
if i understand it correctly, this method requires an exhaustive list of all known hardware that must be updated regularly?
if thats true, how can we keep that from becoming a real headache? (wouldn't everyone that uses it have to constantly update their lists?)
I had 2 files config.spin that contained a standard device list plus the access routines and timconfig that contained device enums for nonstandard devices that had no standard software.
Taking Jazzed's GetPin() method utilised in application code that becomes something like ...
tvPin := pindefs.GetPin( pindefs#TV_ADC1 )
That dictates a public allocation database which defines the name TV_ADC1 and what it's value is. Not particularly a problem in doing that.
How though would the hardware platform specific database be initialised / created ? I presume that for each hardware platform there will be a definition list in the form of something like ...
TV_ADC1 = 12
If that were held in the OS source code in a CON section, the first thing the OS could do in PUB Main is run a series of database updates ...
pindefs.SetPin( pindefs#TV_ADC1, TV_ADC1 )
For non-OS programmers working with source code, they can either use standard CON definitions and 'tvPin = TV_ADC1" or they can call SetPin() initially and then use GetPin() later.
Both SetPin() and GetPin() can work with Ram only. For non-OS users, Ram will be loaded initially with garbage but set correctly once PUB Main initialises it all with SetPin(). For OS source code a SaveToEeprom() method will update Eeprom from Ram, and after every re-boot (for an application which doesn't know the pin mapping ) Ram will automatically be set as that application needs for its GetPin() calls. SaveToEeprom() can be smart enough to not update Eeprom if the data is already set as required to save unnecessary wear.
A typical application ( normal standalone source, or OS source ) which itself would define what the pin definitions were would look something like ...
An application which is run via an OS and has no knowledge of pin allocation would look something like ...
In the earlier, pin setting application code, that still has the pin setting hard-wired in source code; not what we want for platform independence, so to go back to the earlier putting localised pin definitions in a sub object idea, that becomes ...
The calls to ClrPins() and SetPin() can actually be folded into the localised pin definition object which simplifies the high-level application or OS code quite nicely ...
For anyone who did want named pins rather than directly using the pindefs constants, it would be easy enough to add an extra database lookup which can convert a String("TV_ADC1") into the pindefs#TV_ADC1 pin type number.
Post Edited (hippy) : 6/26/2008 1:41:25 PM GMT
That then gets back to not being absolutely crucial to keep a copy of the centralised data base locally. Developers simply choose an unused name ( with reference to the centralised data base ), then use it.
An advantage is that it's reasonably easy to turn a String("TV_ADC1") into a long value, and likewise turn a long value into a string. That is useful for adding an OS application which can list what the pin definitions are in an easily readable way.
It would be nice if the PropTool had a PakedString() directive to do the packing and save code overhead but having to write a method to do that isn't a major problem.
This uses text names for pins ( the packing and unpacking code was thrown together and can be improved ) and all the String("...") overhead would disappear if the PropTool supported PackedString("...") compile time conversion to a packed long constant.
Edited : Major bug fixed ( bytes cannot be negative ) and pin name aliasing so I can use whatever names I want within my applications and still have them mapped to standard names as defined by the community.
Post Edited (hippy) : 6/26/2008 8:02:36 PM GMT
Also, It would be a good idea to find a way for storing/getting the other key infomation such as clock freq/mode, ntsc/pal, and other information mentioned by Andy and OBC. Not sure how all this information·gets put into a structure. I suppose that all grows down in the memory map now that we have a way to constrain the pin definition size. See end of this post for possible datastructure organization.
Actually, I had quoted Timmoore's method. Just assuring proper credit [noparse]:)[/noparse]
hippy said...
How though would the hardware platform specific database be initialised / created ?
I was thinking a Propeller binary and a Windows or Java GUI could automate this. Using packed strings, a GUI would not be required, though it would be useful for helping deal with the latest specification.
Yes. The "PinType Array" approach is optional. The "PinDefs.spin" containing pin numbers can be used as is, and a "PinType.spin" containing pin types could be added to "source control". It seems trivial to make this distinction, but having unique, descriptive names clearly communicates the idea to a new user.
Regarding packed strings: I also prefer string definitions for various reasons.
Some key advantages·are 1)·no need to keep enumerations that can become out of sync without monitoring and approval based updates, and 2) an SD config file could be saved as ASCII· (as you have indirectly mentioned) and conveniently interpreted as packed strings. Of course duplicates would still need to be managed.
There are·some drawbacks though, principally: 1) While a large number of unique strings can be defined, a smaller subset of less cryptic names is available (Enums overcome this problem), and 2)·Packed strings require more bytes, but size is still·reasonable.
Timmoores approach of or-ing $8000 for non-approved enumerations is an attractive solution.
Either packed string or enumeration approach is fine with me as long as the considerations are understood in making the decision.
Yes, this is clearly a requirement[noparse]:)[/noparse] Pardon my diving too deep here, but it seems to me that the only time a Propeller program would write EEPROM would be if the config cookie is not found and/or if a RAM -vs- EEPROM checksum or CRC16 has a mismatch. Config cookie would remain the same normally; version and chipid fields should be included in a config structure.
It appears that having a pin database is a requirement for some users and may be leveraged by anyone.
This may seem premature to some at this stage, but it would be useful to define the "PinTypes.spin" API in simple description and method "signature" terms just as an idea of usage. Doing so at this stage helps to shake out problems and helps to create a palatable response to the requirement. (/** ... __ ...*/ are for doxygen tags that make creating an explicit·doc set easy; Propeller IDE has no convenient way to consistently define parameters and return values documentation).
{ Object "PinTypes" Interface: PUB Init(address) : returnCode PUB ClrPins : returnCode PUB EepromLoad(addr) : returncode PUB EepromSave(addr) : returncode PUB GetPin(type) : pinNumber PUB SetPin(type, pindef) Program: 9 Longs Variable: 0 Longs } PUB Init(address) : returnCode {{/** Initialize the object with expected ram storage. @param address is ram address to use for PinType configuration. @returns number indicating action taken __ int Init(int address); */}} PUB ClrPins : returnCode {{/** Clear pin type table to a known state with all pin types set to "unused" @returns number indicating action taken __ int ClrPins(void); */}} PUB EepromLoad(addr) : returncode {{/** Load pins from the EEPROM. @param ??? config table address ??? @returns number indicating error or successful action taken. __ int EepromLoad(int addr); */}} PUB EepromSave(addr) : returncode {{/** Save config data to the EEPROM. @param ??? config table address ??? @returns number indicating error or successful action taken. __ int EepromSave(int addr); */}} PUB GetPin(type) : pinNumber {{/** Get pin number for a given device type connection. @param type is a PinType enumeration or packed string. @returns PinDefs.spin pin number. __ int GetPin(PinType_t type); */}} PUB SetPin(type,pindef) {{/** Set pin number for a given device type connection. @param type is a PinType enumeration or packed string. @param pindef is the pin number from PinDefs.spin to use for the type. __ void SetPinType(PinType_t type, int pindef); */}}A possible datastructure would be starting at $7ffC and growing down:
- Header with cookie, version, (chipid?), (length?) checksum.
- PinType array (size dependent on target chipid/version or fixed at 64).
- Other info such as clock frequency/mode, ntsc/pal.
- Other optional fields based on some kind of feature table (ethernet config?).·
I suppose an SD load/save object would be added on top of this for managing the SD binary storage.If packed strings were used, the SD file could be ASCII with a packing translator.
Don't get too annoyed if this response is too long [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 6/26/2008 5:46:34 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It appears that having a pin database is a requirement for some users and may be leveraged by anyone.
What's really nice about this, with a minimal amount of overhead, example code can be released for anyone regardless of their hardware. Code can be shipped with "OBJ pindefs" set to either a standard hardware platform ( they'll all be the same everywhere ) or that users specific own settings and all the recipient has to do is make one edit to source code.
Credit to Phil for the idea of using a sub-object as the means of definition.
As long as the top level is clear and simple I don't see a problem and would encourage everyone to adopt the idea. I'm going to
How it works below the top level and how those using OS's want to wangle it around I'm not really too worried about. There are things to sort out and additions to be made but I'm happy that I have a workable system now which can be easily changed as the spec gets closer to completion.
Finally credit to vampyre for promoting the issue and everyone who's has helped so far.
I'm starting to warm up to the idea of an enumerated list. if i'm writing an application that would use the standard, its probably meant to be used by lots of people. and if thats true, it probably doesn't use uncommon hardware anyway. as long as there is a standardized way of adding non-standard hardware definitions i think it'll be fine
I'm gonna reboot into windoze and check out this demo code
One of the problems I see with strings, is that it is very nice having a file with a list of the standard names for all the devices. You can't do that with strings because the spin compiler isn't smart enough to remove unused strings. So you have to enter the strings you need for each project rather than having a file with a bit list of all the device types.
CON enum gives you the list without any overhead of not using an entry.
Pointers to strings in the table won't be as useful because the sd loader won't know where they are and will quite possible overwrite them.
Using the address of a string is an interesting option but as locations of strings move around the enumeration will change on every re-compilation of the OS and the location of strings in the OS and in an app compiled for that OS will differ.
The issue of string overhead is something which is a problem but something which can be fixed by a PackedString() directive in the compiler. I'd argue for pushing Parallax to add that as a useful facility ( more useful than just in this case ) rather than simply discounting strings.
In truth it doesn't really matter which is used, string or numeric constant, providing the means of converting string to constant is well defined. SetPin(Packed(String("TV_ADC1"))) is exactly the same as SetPin(PackedString("TV_ADC1")) and SetPin($FEDCBA98). The only overhead is in having to provide the Packed() method and the space taken up by the strings which are used.
Regarding the use of long against word, I don't think 64 bytes more is an excessive overhead.
One thing I did consider was how to deal with awkward people ( like myself ) who will stubbornly insist on using the names they want to use in applications regardless of what names the pindefs system calls for. Regardless of the arguments, people will use what they want to so making it easy to do has to be part of the consideration. To handle this, where I insist on using TV_PIN when the standard s TV_ADC1 say, I would use ...
OBJ pindefs : "My_Hacked_ProtoBoard" VAR long tvPin, ledPin PUB Main tvPin := pindefs.GetPin(MyPinName(Packed(String("TV_PIN")))) ledPin := pindefs.GetPin(MyPinName(Packed(String("LED_PIN")))) : PRI MyPinName( enumValue ) pindefs.Alias( Packed(String("TV_PIN")) , Packed(String("TV_ADC1")) ) PRI Packed( strPr ) return pindefs.Packed( strPtr )If using only numeric constants, that's more complicated because I have to define a constant to enumerate what I call TV_PIN ( which mustn't clash with a genuine enumeration ) and there ends up a mix of self-defined and imported enumerations ...
While there's a degree of 'sheer bloody mindedness' about that ( people are strange creatures ), I see a far greater elegance and consistency in the former approach.
To encourage adoption by the widest audience I think it's necessary to explain to people how to use this platform independence and make that as simple as possible no matter how they want to do things. I'd argue that documenting how to change existing code which has fixed pin number constants into platform independent code is far simpler in the first case than the second.
To get people to adopt to the new notion of platform independent coding means having to make it easy for them and to pander to their 'peculiar insistences'. It's not like where people have no choice but to do it the way it has to be done, they do have a choice, and if they cannot be convinced of the merits they will do it their way instead. I wouldn't be considering changing all my code if I felt it complicated things or was more trouble than it was worth rather than delivered an advantage.
I'll agree, "you're just being awkward and obstinate"; I am, I'm allowed to be, it's the inventors job to get me to buy into what's proposed
Any reason for clkfreq/mode & ntsc/pal being after PinType array? If we put them between header & array we'll know they won't move (not sure that's a problem, but my gut feeling is that it's one less thing to worry about).
I can't wait for this to get finalised
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm not a fan of using the address of strings or even an offset of strings within a table; this is just a different way of creating an constants or an enumeration.
The whole point of using strings for to me is convenience, but that can be costly depending on implementation. My main concerns for using numbers over strings is in serialized IPC for different endian systems (unlikely) and IPC enum/constant table versioning (likely but managable if done in a serialized way rather than inserting new devices because it makes the file look nice). Whoever does serialized IPC can define their own translation.
It's a tossup for me, but I'm leaning toward enumerations at this point.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The pin table as currently described is fixed based on chip version (I would like to see it as 64, but can be 32 or 64 based on the chipid). I'm concerned that the "properties block" of clkfreq, video, etc... block would change or have additions more than the pin table. New data can be added after the pin table easily though.
The simplest thing to do for so-called blocks of data would be to have a cookie representing the meaning of each block. Code can easily handle that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So how are we all going to decide on this standard?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The above has to translate into ClkSet( $6F, 117_964_800 ) and follow the process needed to switch from boot-up RCFAST ( or anything it may be set to ). Has anyone got any pre-written code to do that as I don't seem to be getting anywhere with what I've tried ?
I've been able to change the frequency with asm after boot while keeping the same mode.
Did not try changing the mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
For an OS, if the code has been copied to Eeprom and is being launched by re-booting it would need to know the mode and frequency. Not true if there is no re-boot as the settings will already be correct.
I feel it should be there for completeness but I think it's going to add a fair chunk of overhead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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, What you said before about clkfreq finally hit me. Allowing a casual user to change the clock at will may not be such a great thing. For example: I managed to destroy a $300 TV/VGA panel by changing the clock frequency during some experiments. Of course there is a disclaimer, but I would be really pissed if that happened again. How to proceed? Just ignore it and move on?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
could someone explain, in simple terms what the current idea is?
The solution was that I encoded the LED pin configuration information into the EEPROM using the Settings object which I wrote. This object has turned out to be absolutely indispensable to me for managing all sorts of things. As long as you have a 64kb EEPROM, then you don't have to worry about overwriting the settings when you reflash with your prop-plug. I'm slowly building up a standardized list of keys for people to use for storing various information... Things like one-wire bus pin, LED pins, speaker pins, etc...
obex.parallax.com/objects/314/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/
[url=mailto:xmpp:darco@deepdarc.com]xmpp:darco@deepdarc.com[/url]
Perhaps it would be useful if you quickly summarize the requirements and what current proposals may be contributing to your goals?
We have mostly addressed possible configuration mechanisms and practically zero O/S items.
Current runtime config requirements as I understand them:
1. Header with cookie, version, (chipid?), (length?) checksum.
2. PinType array (size dependent on target chipid/version or fixed at 64).
3. Other info such as clock frequency/mode, ntsc/pal.
4. Other optional fields based on some kind of feature table (ethernet config?).
more?
@darco
Nice ideas.
If you were to create a bare bones object for saving/getting properties how big would it be?
How much storage is necessary for your current database? How many entries does it have?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
that is my concern at the moment. if i can't understand the code, im worried someone else might not be able to and that might discourage them. if however, i can come to understand it i can document it in 'idiot friendly' terms [noparse]:)[/noparse]
to clarify what i'd like, but dont really need, to see as a standard for applications:
*something that makes it unnecessary for most people to reconfigure / recompile code
*something that doesn't eat a lot of the space that could be used by applications (small ram requirements)
*something easy to implement, use and understand (so it can be modified by other people)
for operating systems:
*a way to pass the command line
*a list of file types with documentation (pretty easy to do)
*a way to pass pin assignments to the application (could be the same as the above)
for the OS , as far as i'm concerned all of these posts will influence the OS standard. if we can come up with a standard way of defining pins in an application, I can then implement that as the standard way of doing so for an operating system.
I still dont quite understand what the problem with putting the array in the eeprom is though, and then just writing a small spin util to extract the info as needed? is it that people dont wanna give up their eeprom space?
Yes, we'll have to challenge these professional software engineers
(It's nice to have experts here!) to find a simple way to present
this information or new users will be completely lost in the solution.
I DO like where this is going, now if we can only streamline the
concepts and make them idiot proof. Heck, if I can wrap my
brain around it, you've made it. <smirk>
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
Actually, I think we have all the ingredients now. In fact, I think darco is ahead of us, except that his 'settings' object requires a 64K eeprom :-(
@vampyre:
1. Thanks for getting this started - I'm sure it'll lead to a good standard.
2. I think the 'problem' with using eeprom is that it's too easy to overwrite when programming from PropTool (if I'm right, PropTool overwrites ALL 32K doesn't it?)
3. I think we need a way do code PinDefs.spin so it can be used both for compile AND as a file for OS binaries to reference?
And then we need to properly document it, so even I (and other noob's) can understand how it works.
I'm happy to offer my services to test
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
*something that makes it unnecessary for most people to reconfigure / recompile code
For those without an OS that's probably impossible to achieve. Compilation with minimal effort can be achieved; a one text name change is all that's required to make the program run on their specific hardware.
*something easy to implement, use and understand
There are five types of users - program users, program developers, platform independence systems programmers, OS application developers. OS developers.
Program users - Will need to know how to change the text name to adopt a program to their hardware. Will need to know how to create a definition file for their particular hardware if it is non-standard. Do not need to know how the platform independence works behind the scenes.
Program developers - As per program users but additionally need to know how to use and call the platform independence object to make their programs platform independent. They won't need to know how things work behind the scenes.
Platform independence systems programmers - These are the only people who will need to understand how things work behind the scenes; the others "use it", these people "define it and implement it".
OS application's developers - Really just program developers. The "how to guide" will be much the same with only one minor change; non-OS developers have to call a routine to ensure a user's platform settings are loaded while an OS developer has to call a different routine to load a user's platform settings from SD/Eeprom/somewhere.
OS developers - Really just program developers, but need to know how to get the user's settings stored to SD/Eeprom/whatever for OS applications to later use.
While it would be nice to understand how the internals work, most people shouldn't need to care, and how it works is really a debate amongst platform independence system developers alone. As far as I'm concerned, as long as that provides what I want as a program developer - how to specify and use the pins - I'm happy. That debate is limited to the boundary of the interface. How it works underneath is really a separate issue.
Ideally the debate and discussion should be in two distinct parts; the API ( boundary interface ) and the internal implementation. Obviously the two will get discussed together at this early formative stage which is where I think some confusion and perceptions of over-complexity has crept in.
I still dont quite understand what the problem with putting the array in the eeprom is though
For Propeller OS users that's not a problem, how everything interacts and uses Eeprom can we well defined and compliance insisted upon. For non-OS user's the Eeprom is unprotected and anything can erase settings held; every PropTool download will do that. Thus any platform independent code must use a mechanism which doesn't rely upon what's pre-stored in Eeprom.
It would be possible to mandate the settings database is held in the top 32KB of a 64KB Eeprom ( as per darco ) or in SD Card but not all users will have those and not all programs will be compliant or respect such use. Darco's implementation works because he has defined it as necessary to have 64KB Eeprom and has control over all applications to be downloaded on that hardware. We don't have that luxory.
For a compile source and download program ( which includes the initial OS installation ) it's necessary to keep settings held as definitions in an object file and at run the access settings via the database to achieve platform independence. For an OS, part of its job will be to take those settings and write them to SD/Eeprom/wherever so later OS Apps can get them from.
For compile source and execute programs ...
For OS-Based applications ...
OS Configuration will occur only once, when the user is compiling and installing the OS on their hardware. When started it updates Eeprom as necessary ( a "run once" action ). Any OS-Based App will load the pre-stored settings and use those.
Post Edited (hippy) : 6/28/2008 1:40:57 PM GMT