For those people who aren't quite following the discussion, having an understanding but think it all sounds a little too complicated, I've included a rough draft HowTo.Pdf of how this would work from a program user and program developer's perspective.
Program users and developers would not need to know anything more than is contained in this short document.
Had to put it in a .Zip because the forum won't take .Pdf's.
For framework developers : I did start to use constant enumerations - pindefs.#TV_ADC1 rather than Packed(String("TV_ADC1")) - but ran into a problem. Because an enumeration can only be imported from an immediate sub-object that means every sub-object which defines a user's particular hardware has to contain a long constant list of every pin defined in the lowest sub-object ( which is the list of standardised names and values ). That's necessary to import those names from a lower level to export upwards to the main application. Using Packed(String()) means the names don't need to be imported and can be passed straight down to the lowest level. It also avoids the multiple naming issue of TV_ADC1 and ENUM_TV_ADC1 where the first defines the pin number used for a function and the second defines the enumerated value for what that pin will be called.
@hippy I dont understand the problem you have with multiple enums. I have attached a project with how I use enums which doesn't have that problem.
The top object of the project rui.spin contain a DAT table configinfo of the pin info for the project. So you have all the pin info for the prokect in one table.
It uses enums from config.spin and appconfig.spin. config.spin contains the "standard" enums, appconfig.spin contains non-standard enums.
config.spin also contains access routines like GetPin, which the rest of the code uses to find pins.
config.spin also during init looks for an in ram table to override the app table. The RAM table is assumed to come from an OS if the app was loaded by an OS. It could also read the eeprom for the table but currently config.spin is small and it gets about 50% larger adding eeprom reading code. If config.spin doesn't find a RAM table it then runs coleys hardware detection and changes keyboard/display pins.
Eggscellent .pdf [noparse]:)[/noparse] (thinking about breakfast)
Are you looking at the "EditPindefs.exe program" ?
I was thinking of doing a Java GUI though a .net exe may be adequate.
Would be interesting to see how many people care about GUI independence in the forum.
I'm afraid I let my attention to this thread lapse, and in the meantime things have gotten very complicated. Hippy, can you explain in short sentences why the packed string variables are necessary? I can't see, offhand, what it benefits compile-and-run situations over and above the simpler constant references (e.g. PinDefs#TV_BasePin) I proposed back on page one.
OBC said...
This thread went over my head around page 4... [noparse]:)[/noparse]
Thank goodness, i was starting to feel like the kid wearing a dunce cap in the corner. Since I know your smarter than I am OBC, somehow i dont feel quite so bad
I don't think anything discussed so far is inherently hard to comprehend, its just that its not yet presented in simple to understand terms.
simonl said...
I think the 'problem' with using eeprom is that it's too easy to overwrite when programming from PropTool
Good point. see my response to hippy's statements below
Hippy:
I think i'm starting to see where the complexity is coming from. forgive me if i've misunderstood, but i'm going to operate the way i normally do, by pretending i know whats going on. if i've missed something , feel free to correct me with a swift kick in the head [noparse]:D[/noparse]
The concept i originally had was to turn the eeprom into something of a Bios. All props have a connected eeprom, its the one common factor. It seems to me that you guys are trying to come up with a way to make it simple to re-compile code for any prop-based machine and program. I myself wouldn't have taken on that task, i'm no where near smart enough, but i'm glad you guys have.
Hippy said...
For non-OS user's the Eeprom is unprotected and anything can erase settings held
why wouldn't someone be an OS user? The only reason I can see for not using your EEPROM to hold a BIOS or an OS, is that you need the eeprom for some other purpose.
needlessly writing apps to the eeprom just adds wear and tear to the eeprom.
If you need the eeprom for some other purpose, your probably doing something non-standard. (a large video game, a semi-perminant application, etc). If your doing something non-standard, your probably smart enough to reconfigure pins.
If the above assumptions are correct, then any program intended to be written to an eeprom could fit into a seperate summer standard category. We could call it the BIOS category, which would be a subset of the OS standard (in that it only requires a standard way of defining its hardware usage, which is what most of the conversation up till now seems to have been about)
For something like this, just defining a standard comment string that users can search for, as well as a string that tells what objects should be modified when compiling might be adequate. for example :
CON
'hardware settings exist in main.spin, cow.spin
'hydra settings ***
'{
BOB = 1
'}
'protoboard settings ***
{
BOB = 2
}
is that too overly simplistic?
It seems that if we did define 'standard' comments such as those, a pre-processor could then later be programmed that would conditionally compile our code if we wanted true automation for not-so-common programs using this subset of the standard
I just find the use of imported enumerated constants more complicated and less elegant.
In the rui.spin there's a table at the bottom which specified the I/O pins. It would be better to have that in either config.spin or appconfig.spin to reduce clutter in the main program. In this form the table has to be added to every program; okay, not a lot of effort but it would be better if it came in as part of appconfig.spin ( also less error prone ). Also having config.spin and appconfig.spin is two objects not one. Again not a lot of effort but it's starting to add up, and becoming more than just a one line change to alter things ...
If I want to change your rui.spin to run on my hardware I have to alter much of that table in rui.spin, which rather defeats the goal of making a one line change to get it to run on any hardware.
@ Phil : Packed(String("NAME")) is in abstract terms a unique self-enumerating long value. Technically no different to pindefs#NAME but has the unique attribute that it will be unchanging compared to enumerated values coded by hand where value depends on order of declaration or what it's equalled to. Intrinsically it means not having to worry about what the enumerated value is because it's implied. Not sure if that's any clearer but I cannot think of a better way to describe it at the moment - I know what I mean, but don't think I'm explaining it too well.
vampyre said...
The concept i originally had was to turn the eeprom into something of a Bios. All props have a connected eeprom, its the one common factor. It seems to me that you guys are trying to come up with a way to make it simple to re-compile code for any prop-based machine and program. I myself wouldn't have taken on that task, i'm no where near smart enough, but i'm glad you guys have.
Yes, there has been something a change to what you originally proposed, it's really evolved into how can we make this work for load and compile users and OS users, how can we have a common framework which will work for both.
vampyre said...
Hippy said...
For non-OS user's the Eeprom is unprotected and anything can erase settings held
why wouldn't someone be an OS user? The only reason I can see for not using your EEPROM to hold a BIOS or an OS, is that you need the eeprom for some other purpose.
I think the case is that most users are not OS users. They download source, load it into the PropTool, edit configuration, compile, download and go "wow". In that process the Eeprom will have been wiped, we get no choice over that.
Phil Pilgrim (PhiPi) said...
I can't see, offhand, what it benefits compile-and-run situations over and above the simpler constant references (e.g. PinDefs#TV_BasePin) I proposed back on page one.
@Phil,
The simpler constant references are fine for compile and run only; however, they do not address the need·in situations where there is no re-compile. Such situations may occur with running applications loaded from SD storage by an O/S (of course there are other concerns with that without O/S services). Obviously compile and run is a base requirement here.
@Hippy,
Timmoore's code allows for something of an "overload" in that a base configuration is provided but properties may be changed by the new user's preference. His demo code shows passing the data block to a driver rather than encapsulating it. Passing the block would allow a choice of hardware device storage for the config database. Too bad flexibility often brings complexity.
Are you sure all 32KB of EEPROM gets wiped when it is reprogrammed? If so this is a glorious waste of time for me. If not, it seems one can use the spin _FREE statement to ensure no data is written in config space. No? Maybe I mis-understand.
@vampyre,
The tasks typically performed by a PC BIOS are: 1) initial startup,·cache init, exception handler setup,·and memory configuration, 2) configuration of devices based on detected and·saved configurations, 3) a configuration utility, 4) software interrupt handlers for services,·and 5)·starting O/S ... among others. ... some of this is being addressed.
Tasks typically performed by an O/S are 1) kernel services including memory management and multi-tasking management, 2) application context creation and management (run application, stop, clean up mess), 3) application - O/S interface API as·POSIX or otherwise, 4) semaphore, mutex, timers, etc..., and 5) disk and other device interface management ... among others. Some portions of this is necessary, others are built-in.
@hippy, there is a reason for separating into multiple files. Each file changes for a different reason
config.spin supports the config, it is unchanged for all implementions and is in the obect library directory. It contains nothing that you should need to change. I never need to change it for any project I have.
The config table lists is in the main project file because it lists the devices that that project uses. If you need to change that table then you have different devices or devices on different pins, in either case you will need to change just as many lines for your system - the number of devices that change pins is unchanged in either case. Every project I have has a different set of devices so needs a different table. Putting it into config.spin means I need a different config.spin whereas currently the code doesn't change between projects and documents the pin/device usage for the project in the top project file
I put appconfig.spin in a separate file becuse it contains all the non-standard devices I have, if I use them in multiple projects I just include that file. You could include it in the main project file but I do use these devices in multiple projects so it made sense to put them in a separate file. Everytime I write a new device driver I add it to the appconfig.spin file in my library directory at the same time I copy the device driver into the library directory. So the device is then available to any project.
Prehaps the difference is that almost everything I do uses the prop to drive different devices so one of the most important things to me is the list of devices that the project uses and what pins they are on. Now-a-days I just open the main project file, go to the end and look at the table and I know exactly how the hardware needs to be configured. If I want to add a new device then the table tells me the spare pins without trying to look though the code. Its for the same reason that top project file, lists the number of COGs against each object. Again it allows me to quickly look at a project and work out what prop resources it uses.
If you mostly use the same set of devices in the same place then the config table isn't as useful. For me the rui project is the only project I have that uses standard keyboard/display devices.
hippy said...
I just find the use of imported enumerated constants more complicated and less elegant.
Enumerated constants (if you mean what I think you mean) in this context are certainly unwieldy and error-prone. But what's wrong with declared constants? viz:
Hippy said...
I think the case is that most users are not OS users. They download source, load it into the PropTool, edit configuration, compile, download and go "wow". In that process the Eeprom will have been wiped, we get no choice over that.
1. why not require that people use an OS for general purpose applications?
2. if the eeprom is accidentally written to, all thats required is that the user write the OS to the eeprom again.
Jazzed said...
The tasks typically performed by a PC BIOS are: <snip>
all good points, but i wasn't actually suggesting a full bios. im just not sure what to call a program that 'requires' the EEPROM. a better name for such an application is more than welcome.
why not require that people use an OS for general purpose applications?
Because they can say no, and will say no. For those who have bought into using an OS that's fine, but it's a whole new and much bigger proposition getting people to install and use an OS all the time.
This all depends of course on what one means by an OS. I'm presuming you mean PropDOS and similar, something more than a means of specifying pin allocation. Such an OS has requirements, keyboard or mouse and SD card probably, what about people with hardware which does not have those and they aren't needed to run the application they are interested in ?
Hippy said...
This all depends of course on what one means by an OS
I misrepresented my idea as usual, my apologies. I dont mean to say that everyone will have to have propDOS or PorthOS (gotta pimp my own stuff [noparse]:)[/noparse] ). Simply the hardware data for their platform stored in the eeprom (which could be accomplished with a sort of a minimal OS, or BIOS, or what ever u wanna call it)
all summer compliant applications could be packaged together with this minimal BIOS file, or could simply link to a download of it. Just the pin data with possibly clock information such as what crystal is installed. Once the user configured and installed their OS into the eeprom (or what ever its called), thats the last time they'd have to do it (as long as they were running compliant applications).
The advantages are:
1) everyone has an eeprom.
2) we aren't eating much application space, pulling info out of the eeprom can be done with very little code i think ?
3) it discourages multiple eeprom re-writes for newbies (which is never a bad idea)
4) even a simpleton like myself can understand the concept
if people dont understand how the standard works, they certainly wont use it.
What you guys are doing is still great stuff, and there's no reason we can't do both. The pin file settings that you guys are coming up with could be used as the standard for the minimal BIOS as well as non-normal applications. hmm, what about calling it a mini-bios?
yup, thats what imma call it unless someone with a bigger brain has another suggested name.
Rather than trying to explain the idea you guys are working on , perhaps you could simply give me a run down of its advantages over this method?
And thanks , both for all the thought you've put into this, and for putting up with me and my ignorance [noparse]:D[/noparse]
PS. i totally missed the PDF earlier, reading it now
P.P.S - *sigh*, still confused. however it should be noted that my IQ has dropped a significant amount in the last months, dont let my stupidity stop you guys from inventing.
jazzed said...
The simpler constant references are fine for compile and run only; however, they do not address the need in situations where there is no re-compile. Such situations may occur with running applications loaded from SD storage by an O/S (of course there are other concerns with that without O/S services).
Understood. I guess my difficulty with the added complication boils down to "why not recompile?" Having to do so for a particular platform doesn't preclude storing object code on an SD card in binary format. Basically what's being proposed in lieu of that is the late binding of a symbol table located somewhere in a target-resident operating system or BIOS. For embedded applications, this is a job usually relegated to a linking loader on the development PC, not on the target system. For embedded systems on the Propeller's typical scale, I wonder if the tail isn't starting to wag the dog a little by trying to do this in the target. Given the development tools we've been handed (i.e. no late-binding linking loaders), isn't recompiling the simpler, less messy option?
Now, having said all that, my comments are predicated on the ready availability of free development tools. Imagecraft has thrown a wrench of sorts into this discussion with their commercially-priced C compiler. Should that become lingua franca in some quarters, the availability of pre-compiled object code becomes more attractive for those who don't want to shell out the bucks for a compiler just to redefine a few constants. (In fairness to Imagecraft, I'm not familiar enough with their product to know that they haven't solved this issue in other ways — perhaps with a freeware linker?) But for Spin and assembly, I'm afraid I don't see an advantage to the extra rigamarole.
In any event, I have to agree with Vampyre: if it isn't simple for the user, it simply won't get used.
Playing devil's advocate once again (and missing deSilva's incisive take on such matters),
-Phil
From what I have seen so far we have multiple differing requirements
1. Simple method to allow projects to be moved between systems with differing keyboard/mouse/display systems, for people who will recompile the projects
2. Simple method for above for people who dont want to re-compile, just load and run
3. Method to allow reconfiguration of projects with large number of non-straight forward devices.
I dont think 1 answer fits all.
1. The simple approach of a pindefs file seems the easest solution for this problem
2. Coleys hardware detection approach seems the best fit for this problem
3. The solution I use: a table of device definitions for each pin, I think is a solution that fits this problem best. Its an overkill for a small number of standard devices e.g. keyboard/mouse/display but needed for a lot of device types.
If you try to combine the solutions it will get too big and complicated for people to use. 1 and 2 can be easily combined without adding much in complexity. 3 is best for those types of problems with many devices so keep it separate.
Are you sure all 32KB of EEPROM gets wiped when it is reprogrammed? If so this is a glorious waste of time for me. If not, it seems one can use the spin _FREE statement to ensure no data is written in config space. No? Maybe I mis-understand.
To quote the code in "booter.spin" as posted by Chip....
program mov smode,#1 'set mode in case error
mov address,#0 'reset address
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]age call #ee_write 'send program command
mov count,#$40 'page-program $40 bytes
:byte rdbyte eedata,address 'get ram byte
call #ee_transmit 'send ram byte
if_c jmp #shutdown 'if no ack, shutdown
add address,#1 'inc address
djnz count,#:byte 'loop until page sent
call #ee_stop 'initiate page-program cycle
cmp address,h8000 wz 'check for address $8000
if_nz jmp #[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]age 'loop until done (z=1 after)
call #tx_bit_align 'program done, send okay (z=1)
So *yes*, when you download anything to the eeprom it wipes the _entire_ 32KB
agreed. But then, i never intended for the standard to cover as much.
I think 1 and 2 in your post can be combined. Programs that only use 'normal' hardware are also, generally, programs that can be easily modified to run without being modified by the end user (using some kind of standards system). And of course, no one will be required to use the standard. I do fully believe however that if we can agree on one thats simple, and doesn't eat a lot of memory that it will be more of a blessing than a curse and a lot of people will adopt it.
Those who wish to re-configure the code can always do so even if the standard has been used, as long as the implementation is simple enough. (for instance if we use the EEPROM to store the info, and they dont want that, they could always just add in constants, and delete the eeprom reading code - (the standard no matter what it ends up being should make doing this easy)
category 3, what i consider unique code, shouldn't be standardized at all i think. the fact that it is unusual means creating a standard for it would be limiting to developers.
Coley's hardware detection program is a thing of beauty, but it fails to be able to recognize custom built hardware, as far as i can tell. The standard would address that issue.
I looked at Coleys code and how to change it for custom hardware. Its doable but the problem is that it needs to know whether there is custom hardware on pins 12/13. With a pin array this is easy but without it there is no standard way to tell if there is anything on those pins. The pindefs system doesn't give you a way to lookup whats on a pin.
Do you need to worry about that case, most people who want to load/run without compile will have fairly standard hardware? So why not compile using pindefs but include coleys hardware detect. That will work with standard hardware, if you dont then you must recompile. That will probably solve the majority of cases without needing to add eeprom code - I found adding eeprom table to a pin array lookup system increased the code size by about 50%
I think that the scope of this has grown too large as well. First of all there are a couple of categories of uses.
1. Those who use an OS (propDOS etc.) and
2. those who don't
For number 1 users we can probably say fairly safely that the minimum equipment will be
- TV
- sd card
- eeprom
- keyboard
With several possible extras
- sound
- ethernet
- serial console
- vga
- mouse
The problems come from not everyone using the same pins for their hardware and different boards using different clock values. If you set this just once when you compile the OS then any application loaded should have a standard way of finding these peripherals without recompiling. This is easy to do by either putting a list at the top of memory or using Coley's auto config file.
For number 2 users the options become either using Coley's solution or a recompile using some standard spin code that everyone agrees to.
So to wrap this mostly useless post up. The problems are
1. There are at least two groups of users that want different things
2. There probably isn't a simple solution two fit everyone's needs
3. Everybody has something of their own that isn't going to fit in any standard
So I think that we will need to standards. One for use with OSs that doesn't require a recompile and another for people that aren't using an OS. The OS standard should identify a minimum level of peripherals and some way of figuring out what pins they are on at load time
Just a side note, I don't think that there are any true OSs for the prop yet, they are really just ways of starting a file from an sd card.
@ stevenmess2004 : I think that sums it up, but not sure the scope has grown too large. Maybe it's just not clear how it logically merges towards a single standard which isn't that complicated.
For compile and download; what's wanted is a simple means to change any source to use their hardware. That's also going to apply to an OS itself because that's how it will arrive and need to be installed on hardware so this is useful for all.
An OS-based application needs to read a database, so working backwards it makes sense for that database to also be used by a compile and download system. The common ground is the database in Ram once it's loaded or written.
For compile and load - As it runs, it determine the pin mapping, fills the database, runs the main application code which gets its data from the database.
When installing an OS - As it runs, determines the pin mapping, fills the database, runs the rest of the OS itself which gets its data from the database. It writes the database to Eeprom for subsequent OS-based Apps to load.
Running an OS-based App - Loads the database from Eeprom, runs the application which gets its data from the database.
As can be seen there's a lot of commonality there.
The main post-initialisation part of a compile and download application can be considered exactly the same as an OS-based App, both get their data from the database. The only difference is that a compile and download program has to pre-initialise the database. An OS-based App will simply assume it has been initialised and use what's there. Cut the pre-initialisation from a normal App and it becomes an OS-based App, take an OS-based App and add database initialisation and it becomes a normal App. With the right framework just a few minor changes allow the same program to be used in either way.
It may not be necessary to use an Eeprom database at all because I cannot think of any OS-based App which would be standalone and could simply be booted, it would require an OS or Loader to launch it and that OS or Loader will have been compiled for the hardware. The OS or Loader can move its database to somewhere safe in Ram, load the OS-based App and that can bring the Ram back into its own database.
Having the database is key. Having all apps read the database is crucial. How the database is initialised is really the only difference, and that's a minor difference. This is why I see a common framework as working in all cases.
Perhaps we're getting too deeply into implementation and missing the high-level overview and big picture ?
You might want to look at the Propeller OS I wrote about 2 years ago (here: http://forums.parallax.com/showthread.php?p=598350). This used a definitions object to configure it for the Demo Board, Protoboard, or Hydra and included support for either VGA or TV video, a keyboard, and I2C driver and loader. Because the Propeller Tool didn't allow conditional compilation, you had to manually provide either a TV driver or a VGA driver, but the Spin code for the display was essentially the same. This was later used for the underpinnings of FemtoBasic. You have to recompile it for different configurations, but I did eventually come up with a test version that included both a VGA and TV driver and a keyboard driver for either Hydra or Demo Board conventions. It would start the proper low-level video driver, but I didn't think in terms of a configurable table in EEPROM or in the program EEPROM image and you still had to recompile.
vampyre said...
here's a question:
do we really need a memory hungry system for programs that aren't standard? (programs that use more than the average hardware)
wouldn't a simpler, less memory hungry solution be to simply standardize the way in which we define the constant block for such apps?
and for goodness sakes, someone please answer this question, as most of my questions in this thread have been ignored [noparse]:D[/noparse]
Perhaps the PinDefs.spin file that OBC posted should be finished and we would be done with pins.
The more exotic uses of pin configurations don't appear to have enough momentum to justify further effort as a standard, but could instead be considered as a recommendation of one solution to a problem. Maybe such works could be added to a "white-papers" (industry term) section of the wiki.
Regarding some of the problems with 32KB EEPROM: it would be very easy to create an alternate·programmer if people want to use it for data storage. Being able to configure a product in the field where a programming connection is not available beats the heck out of FedEx overnight [noparse]:)[/noparse]
Since you started this thread 142 posts ago, you deserve an answer to your question. As I've stated in a prior post or two, I too question the need for so much cruft and feel that things have sprialed way out of control vis a vis your original post. So the short answer to your question above — from me, at least — is "no".
But due to the response this thread has engendered (and partially because of your use of those heavily-laden letters "OS" in your lead-off paragraph),
vampyre said...
I think it would be in the best interest of all of us to create some kind of optional clearly documented standards system that covers OS/application protocols.
I'd say a raw nerve regarding an unmet need in more esoteric realms has been touched. These things happen in the forums occasionally when a perceived, pent-up need gets the right stimulus. Your original query apparently set off such a chain reaction. My guess is that, once the dust has settled, nothing of any lastng influence will come of it, though. This isn't to say that the ideas presented here are bad. Quite the contrary: some real insight and programming prowess — even if a bit convoluted — has been brought to bear.
Forums such as this are typically ineffective for creating standards that a majority of users will adhere to. ('Sorry guys: no affront intended. It's just been my experience.) For something of any lasting value to take hold, someone — yes, one single person and not a committee — has to take the bull by the horns and create some well-documented software so compelling that everyone will want to use it. And that, my friends, is how standards are born.
thank you guys for your replies, was starting to feel like i was talking to myself [noparse]:)[/noparse]
I agree with most of what Phil said.
sorry if i made it sound like i was irritated , i wasn't.
perhaps a committee is a bad idea for putting together a standard, however the conversation we've all had has been very beneficial. There've been a lot of great ideas, that i think a lot of people will get use out of.
Even if a standard comes out of this, i think many people will use code they've discovered here that isn't in the standard, which is great.
My OS statement at the beginning of the thread hasn't been addressed much so far and thats completely fine with me. I'm glad to see so much interest in a standard way of defining pins without such a beast.
I believe most people have realized by now that this 'standard' really does require two sections, the first of which is some kind of hardware description, the second of which would be OS standards.
I think that the thread has started to go stale and its about time to bring this to a vote.
Would you guys who have suggested a standard way of defining pins please write a short paragraph describing your approach so i can include it in the poll?
suggested format for description:
summary: messenger pigeons
description: info about hardware connections, clock and display type will be written on parchment and super glued to the foot of a pigeon thats been trained to fly to the user. the user then uses a paper clip to form a switch shorting 3.3v to pin one or two, that is then used to enter this information on these pins of the chip in binary code
advantages:
low memory usage
portability (pigeons can fly)
in extreme situations, pigeons can be used as food
P.S, or perhaps we should all just implement our own standards, document them, and see which one if any gets adopted by the community? If there is not real interest in a vote I suppose thats the method we'll go with?
Phil Pilgrim (PhiPi) said...
Forums such as this are typically ineffective for creating standards that a majority of users will adhere to. ('Sorry guys: no affront intended. It's just been my experience.) For something of any lasting value to take hold, someone — yes, one single person and not a committee — has to take the bull by the horns and create some well-documented software so compelling that everyone will want to use it. And that, my friends, is how standards are born.
I have to agree, or least one person has to come up with a "this is it, use it" solution which can then be improved upon and tailored to better meet the needs of a larger audience.
That's usually the motivation which takes something from theory into becoming something which actually has legs.
Wherever we end up it has for me been a very useful and worthwhile thread. The next Spin code I release will almost certainly use this technique whether a standard or not. I've got a pair of ProtoBoards each wired up differently ( the one I built when I didn't have a clue what I was doing with the Propeller and one when I did ) and it's been a nightmare. This has given me what I think is an elegant solution to my problem, if not anyone else's.
vampyre said...
here's a question:
do we really need a memory hungry system for programs that aren't standard? (programs that use more than the average hardware)
What's memory hungry is quite subjective. Obviously excessive bloat isn't desirable but nor is an absolutely minimal system which doesn't deliver what it sets out to achieve or is too limited to have a useful purpose. It's really a question of how much extra usage is acceptable for the gains it gives.
vampyre said...
wouldn't a simpler, less memory hungry solution be to simply standardize the way in which we define the constant block for such apps?
That depends on where the constants are and which constant blocks you are talking about. I think we're all largely agreed that the core is a 32 word/long array, one per pin, with a number in it which indicates what that pin is used for.
One could go with a list of named constants for what pin types are and stick with that and there's not a lot more needs to be done. The debate has really been about how to make it easy to use and adopt, which is key to the success of anything hoping to be standardised upon. It's questioning "is simplest best?". Simplest and easiest are not necessarily the same.
vampyre said...
and for goodness sakes, someone please answer this question, as most of my questions in this thread have been ignored [noparse]:D[/noparse]
One problem is that it's not easy to give good answers, comments or critiques without something concrete to see as an example, and that applies to most design discussions where ideas are being thrown in the air and knocked all over the place with competing suggestions coming from all directions.
hippy said...
One problem is that it's not easy to give good answers, comments or critiques without something concrete to see as an example, and that applies to most design discussions where ideas are being thrown in the air and knocked all over the place with competing suggestions coming from all directions.
You nailed that one pretty good[noparse]:)[/noparse]· In a professional setting there is usually an architect,·group lead, or manager that understands what works best for the business. This environment has no such bounds and requires great patience.
Such chaos is often frustrating, but it certainly takes one out of the box. Sometimes a pissing contest will happen, but all in all it's worth the effort. Those who "know it all" end up learning·they don't ...·hahahaha [noparse]:)[/noparse]··Hurts a little to have to admit such things[noparse]:)[/noparse]
as for my 'someone answer me' rant , i think another problem is that most of my posts are just realllly long winded and poorly thought out. the whole statement was somewhat out of line and meant to be humorous. sorry if i sounded childish there.
Hippy said...
That depends on where the constants are and which constant blocks you are talking about.
..<snip>.....
It's questioning "is simplest best?". Simplest and easiest are not necessarily the same.
Thats actually an excellent summary of my question.
It seems to me that simpler is best in the situation of a non-standard app, because its easier to modify, update, change and understand and (i think) uses less memory
the specific idea that i'm referring to is the one i proposed near the top of page six in this thread.
Something I feel i should mention is that everything you've posted is amazing stuff, i only wish i had your skills.
To all:
dont take offense at me desperately trying to poke holes in your ideas. I simply feel that this type of debate/banter/analysis helps flesh out ideas. Its also a great way for me personally to learn , by being corrected
what we need first is a standardized bus system for the propeller (ISA, PCI, S-100, etc) so that everybody could develop his own card and plug it into the bus.
This is the basics if we would develop hardware that is propeller compatible.
vampyre said...
To all:
dont take offense at me desperately trying to poke holes in your ideas. I simply feel that this type of debate/banter/analysis helps flesh out ideas. Its also a great way for me personally to learn , by being corrected
Never worry about poking holes in people's ideas ( unless they are standing there holding an axe or loading a gun in which case whatever they say sounds fine to me [noparse]:)[/noparse] ).
You're right, it's the only way to discover the pros and cons of any idea. The real problems come when trying to decide between competing incompatible ideas and when people get polarised for and against particular ideas.
Further to what Phil said earlier about creating actual standards: There's always a chaotic start, before things start to fall into place. People go away and hopefully think about the ideas and take into account the pros and cons and modify their own in that light. Build prototypes and test ideas. That's when a standard or prototype standard gets produced. That then gets moulded into what's needed.
In the Real World(TM) that's likely a marketing meeting where all sorts of fanciful ideas are imagined followed by an R&D team attempting to turn that into something workable and going back with a, "this is what we've come up with, how do you like it ?". Moving on from there is usually much smoother sailing.
Giemme said...
what we need first is a standardized bus system for the propeller (ISA, PCI, S-100, etc) so that everybody could develop his own card and plug it into the bus.
There's merit in that but it's set against many existing hardware designs which don't use any bus and people who won't use a bus if that adds what they see as unnecessary overhead.
I don't think a lack of standardised bus system stops us developing a solution to the existing problems we have, and I/O pin mapping will still be needed where I/O lines to that bus may vary from platform to platform.
Comments
Program users and developers would not need to know anything more than is contained in this short document.
Had to put it in a .Zip because the forum won't take .Pdf's.
For framework developers : I did start to use constant enumerations - pindefs.#TV_ADC1 rather than Packed(String("TV_ADC1")) - but ran into a problem. Because an enumeration can only be imported from an immediate sub-object that means every sub-object which defines a user's particular hardware has to contain a long constant list of every pin defined in the lowest sub-object ( which is the list of standardised names and values ). That's necessary to import those names from a lower level to export upwards to the main application. Using Packed(String()) means the names don't need to be imported and can be passed straight down to the lowest level. It also avoids the multiple naming issue of TV_ADC1 and ENUM_TV_ADC1 where the first defines the pin number used for a function and the second defines the enumerated value for what that pin will be called.
The top object of the project rui.spin contain a DAT table configinfo of the pin info for the project. So you have all the pin info for the prokect in one table.
It uses enums from config.spin and appconfig.spin. config.spin contains the "standard" enums, appconfig.spin contains non-standard enums.
config.spin also contains access routines like GetPin, which the rest of the code uses to find pins.
config.spin also during init looks for an in ram table to override the app table. The RAM table is assumed to come from an OS if the app was loaded by an OS. It could also read the eeprom for the table but currently config.spin is small and it gets about 50% larger adding eeprom reading code. If config.spin doesn't find a RAM table it then runs coleys hardware detection and changes keyboard/display pins.
Are you looking at the "EditPindefs.exe program" ?
I was thinking of doing a Java GUI though a .net exe may be adequate.
Would be interesting to see how many people care about GUI independence in the forum.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thanks,
Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Thank goodness, i was starting to feel like the kid wearing a dunce cap in the corner. Since I know your smarter than I am OBC, somehow i dont feel quite so bad
I don't think anything discussed so far is inherently hard to comprehend, its just that its not yet presented in simple to understand terms.
Good point. see my response to hippy's statements below
Hippy:
I think i'm starting to see where the complexity is coming from. forgive me if i've misunderstood, but i'm going to operate the way i normally do, by pretending i know whats going on. if i've missed something , feel free to correct me with a swift kick in the head [noparse]:D[/noparse]
The concept i originally had was to turn the eeprom into something of a Bios. All props have a connected eeprom, its the one common factor. It seems to me that you guys are trying to come up with a way to make it simple to re-compile code for any prop-based machine and program. I myself wouldn't have taken on that task, i'm no where near smart enough, but i'm glad you guys have.
why wouldn't someone be an OS user? The only reason I can see for not using your EEPROM to hold a BIOS or an OS, is that you need the eeprom for some other purpose.
needlessly writing apps to the eeprom just adds wear and tear to the eeprom.
If you need the eeprom for some other purpose, your probably doing something non-standard. (a large video game, a semi-perminant application, etc). If your doing something non-standard, your probably smart enough to reconfigure pins.
If the above assumptions are correct, then any program intended to be written to an eeprom could fit into a seperate summer standard category. We could call it the BIOS category, which would be a subset of the OS standard (in that it only requires a standard way of defining its hardware usage, which is what most of the conversation up till now seems to have been about)
For something like this, just defining a standard comment string that users can search for, as well as a string that tells what objects should be modified when compiling might be adequate. for example :
CON 'hardware settings exist in main.spin, cow.spin 'hydra settings *** '{ BOB = 1 '} 'protoboard settings *** { BOB = 2 }is that too overly simplistic?
It seems that if we did define 'standard' comments such as those, a pre-processor could then later be programmed that would conditionally compile our code if we wanted true automation for not-so-common programs using this subset of the standard
I just find the use of imported enumerated constants more complicated and less elegant.
In the rui.spin there's a table at the bottom which specified the I/O pins. It would be better to have that in either config.spin or appconfig.spin to reduce clutter in the main program. In this form the table has to be added to every program; okay, not a lot of effort but it would be better if it came in as part of appconfig.spin ( also less error prone ). Also having config.spin and appconfig.spin is two objects not one. Again not a lot of effort but it's starting to add up, and becoming more than just a one line change to alter things ...
If I want to change your rui.spin to run on my hardware I have to alter much of that table in rui.spin, which rather defeats the goal of making a one line change to get it to run on any hardware.
@ Phil : Packed(String("NAME")) is in abstract terms a unique self-enumerating long value. Technically no different to pindefs#NAME but has the unique attribute that it will be unchanging compared to enumerated values coded by hand where value depends on order of declaration or what it's equalled to. Intrinsically it means not having to worry about what the enumerated value is because it's implied. Not sure if that's any clearer but I cannot think of a better way to describe it at the moment - I know what I mean, but don't think I'm explaining it too well.
Yes, there has been something a change to what you originally proposed, it's really evolved into how can we make this work for load and compile users and OS users, how can we have a common framework which will work for both.
I think the case is that most users are not OS users. They download source, load it into the PropTool, edit configuration, compile, download and go "wow". In that process the Eeprom will have been wiped, we get no choice over that.
The simpler constant references are fine for compile and run only; however, they do not address the need·in situations where there is no re-compile. Such situations may occur with running applications loaded from SD storage by an O/S (of course there are other concerns with that without O/S services). Obviously compile and run is a base requirement here.
@Hippy,
Timmoore's code allows for something of an "overload" in that a base configuration is provided but properties may be changed by the new user's preference. His demo code shows passing the data block to a driver rather than encapsulating it. Passing the block would allow a choice of hardware device storage for the config database. Too bad flexibility often brings complexity.
Are you sure all 32KB of EEPROM gets wiped when it is reprogrammed? If so this is a glorious waste of time for me. If not, it seems one can use the spin _FREE statement to ensure no data is written in config space. No? Maybe I mis-understand.
@vampyre,
The tasks typically performed by a PC BIOS are: 1) initial startup,·cache init, exception handler setup,·and memory configuration, 2) configuration of devices based on detected and·saved configurations, 3) a configuration utility, 4) software interrupt handlers for services,·and 5)·starting O/S ... among others. ... some of this is being addressed.
Tasks typically performed by an O/S are 1) kernel services including memory management and multi-tasking management, 2) application context creation and management (run application, stop, clean up mess), 3) application - O/S interface API as·POSIX or otherwise, 4) semaphore, mutex, timers, etc..., and 5) disk and other device interface management ... among others. Some portions of this is necessary, others are built-in.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
config.spin supports the config, it is unchanged for all implementions and is in the obect library directory. It contains nothing that you should need to change. I never need to change it for any project I have.
The config table lists is in the main project file because it lists the devices that that project uses. If you need to change that table then you have different devices or devices on different pins, in either case you will need to change just as many lines for your system - the number of devices that change pins is unchanged in either case. Every project I have has a different set of devices so needs a different table. Putting it into config.spin means I need a different config.spin whereas currently the code doesn't change between projects and documents the pin/device usage for the project in the top project file
I put appconfig.spin in a separate file becuse it contains all the non-standard devices I have, if I use them in multiple projects I just include that file. You could include it in the main project file but I do use these devices in multiple projects so it made sense to put them in a separate file. Everytime I write a new device driver I add it to the appconfig.spin file in my library directory at the same time I copy the device driver into the library directory. So the device is then available to any project.
Prehaps the difference is that almost everything I do uses the prop to drive different devices so one of the most important things to me is the list of devices that the project uses and what pins they are on. Now-a-days I just open the main project file, go to the end and look at the table and I know exactly how the hardware needs to be configured. If I want to add a new device then the table tells me the spare pins without trying to look though the code. Its for the same reason that top project file, lists the number of COGs against each object. Again it allows me to quickly look at a project and work out what prop resources it uses.
If you mostly use the same set of devices in the same place then the config table isn't as useful. For me the rui project is the only project I have that uses standard keyboard/display devices.
PinDefs#TV_BasePin still yields a value of 12 in the parent object when defined this way in pindefs.spin.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
1. why not require that people use an OS for general purpose applications?
2. if the eeprom is accidentally written to, all thats required is that the user write the OS to the eeprom again.
all good points, but i wasn't actually suggesting a full bios. im just not sure what to call a program that 'requires' the EEPROM. a better name for such an application is more than welcome.
Because they can say no, and will say no. For those who have bought into using an OS that's fine, but it's a whole new and much bigger proposition getting people to install and use an OS all the time.
This all depends of course on what one means by an OS. I'm presuming you mean PropDOS and similar, something more than a means of specifying pin allocation. Such an OS has requirements, keyboard or mouse and SD card probably, what about people with hardware which does not have those and they aren't needed to run the application they are interested in ?
I misrepresented my idea as usual, my apologies. I dont mean to say that everyone will have to have propDOS or PorthOS (gotta pimp my own stuff [noparse]:)[/noparse] ). Simply the hardware data for their platform stored in the eeprom (which could be accomplished with a sort of a minimal OS, or BIOS, or what ever u wanna call it)
all summer compliant applications could be packaged together with this minimal BIOS file, or could simply link to a download of it. Just the pin data with possibly clock information such as what crystal is installed. Once the user configured and installed their OS into the eeprom (or what ever its called), thats the last time they'd have to do it (as long as they were running compliant applications).
The advantages are:
1) everyone has an eeprom.
2) we aren't eating much application space, pulling info out of the eeprom can be done with very little code i think ?
3) it discourages multiple eeprom re-writes for newbies (which is never a bad idea)
4) even a simpleton like myself can understand the concept
if people dont understand how the standard works, they certainly wont use it.
What you guys are doing is still great stuff, and there's no reason we can't do both. The pin file settings that you guys are coming up with could be used as the standard for the minimal BIOS as well as non-normal applications. hmm, what about calling it a mini-bios?
yup, thats what imma call it unless someone with a bigger brain has another suggested name.
Rather than trying to explain the idea you guys are working on , perhaps you could simply give me a run down of its advantages over this method?
And thanks , both for all the thought you've put into this, and for putting up with me and my ignorance [noparse]:D[/noparse]
PS. i totally missed the PDF earlier, reading it now
P.P.S - *sigh*, still confused. however it should be noted that my IQ has dropped a significant amount in the last months, dont let my stupidity stop you guys from inventing.
Post Edited (vampyre) : 6/29/2008 6:05:37 AM GMT
Now, having said all that, my comments are predicated on the ready availability of free development tools. Imagecraft has thrown a wrench of sorts into this discussion with their commercially-priced C compiler. Should that become lingua franca in some quarters, the availability of pre-compiled object code becomes more attractive for those who don't want to shell out the bucks for a compiler just to redefine a few constants. (In fairness to Imagecraft, I'm not familiar enough with their product to know that they haven't solved this issue in other ways — perhaps with a freeware linker?) But for Spin and assembly, I'm afraid I don't see an advantage to the extra rigamarole.
In any event, I have to agree with Vampyre: if it isn't simple for the user, it simply won't get used.
Playing devil's advocate once again (and missing deSilva's incisive take on such matters),
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 6/29/2008 7:16:52 AM GMT
1. Simple method to allow projects to be moved between systems with differing keyboard/mouse/display systems, for people who will recompile the projects
2. Simple method for above for people who dont want to re-compile, just load and run
3. Method to allow reconfiguration of projects with large number of non-straight forward devices.
I dont think 1 answer fits all.
1. The simple approach of a pindefs file seems the easest solution for this problem
2. Coleys hardware detection approach seems the best fit for this problem
3. The solution I use: a table of device definitions for each pin, I think is a solution that fits this problem best. Its an overkill for a small number of standard devices e.g. keyboard/mouse/display but needed for a lot of device types.
If you try to combine the solutions it will get too big and complicated for people to use. 1 and 2 can be easily combined without adding much in complexity. 3 is best for those types of problems with many devices so keep it separate.
To quote the code in "booter.spin" as posted by Chip....
program mov smode,#1 'set mode in case error mov address,#0 'reset address [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]age call #ee_write 'send program command mov count,#$40 'page-program $40 bytes :byte rdbyte eedata,address 'get ram byte call #ee_transmit 'send ram byte if_c jmp #shutdown 'if no ack, shutdown add address,#1 'inc address djnz count,#:byte 'loop until page sent call #ee_stop 'initiate page-program cycle cmp address,h8000 wz 'check for address $8000 if_nz jmp #[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]age 'loop until done (z=1 after) call #tx_bit_align 'program done, send okay (z=1)So *yes*, when you download anything to the eeprom it wipes the _entire_ 32KB
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
agreed. But then, i never intended for the standard to cover as much.
I think 1 and 2 in your post can be combined. Programs that only use 'normal' hardware are also, generally, programs that can be easily modified to run without being modified by the end user (using some kind of standards system). And of course, no one will be required to use the standard. I do fully believe however that if we can agree on one thats simple, and doesn't eat a lot of memory that it will be more of a blessing than a curse and a lot of people will adopt it.
Those who wish to re-configure the code can always do so even if the standard has been used, as long as the implementation is simple enough. (for instance if we use the EEPROM to store the info, and they dont want that, they could always just add in constants, and delete the eeprom reading code - (the standard no matter what it ends up being should make doing this easy)
category 3, what i consider unique code, shouldn't be standardized at all i think. the fact that it is unusual means creating a standard for it would be limiting to developers.
Coley's hardware detection program is a thing of beauty, but it fails to be able to recognize custom built hardware, as far as i can tell. The standard would address that issue.
Do you need to worry about that case, most people who want to load/run without compile will have fairly standard hardware? So why not compile using pindefs but include coleys hardware detect. That will work with standard hardware, if you dont then you must recompile. That will probably solve the majority of cases without needing to add eeprom code - I found adding eeprom table to a pin array lookup system increased the code size by about 50%
1. Those who use an OS (propDOS etc.) and
2. those who don't
For number 1 users we can probably say fairly safely that the minimum equipment will be
- TV
- sd card
- eeprom
- keyboard
With several possible extras
- sound
- ethernet
- serial console
- vga
- mouse
The problems come from not everyone using the same pins for their hardware and different boards using different clock values. If you set this just once when you compile the OS then any application loaded should have a standard way of finding these peripherals without recompiling. This is easy to do by either putting a list at the top of memory or using Coley's auto config file.
For number 2 users the options become either using Coley's solution or a recompile using some standard spin code that everyone agrees to.
So to wrap this mostly useless post up. The problems are
1. There are at least two groups of users that want different things
2. There probably isn't a simple solution two fit everyone's needs
3. Everybody has something of their own that isn't going to fit in any standard
So I think that we will need to standards. One for use with OSs that doesn't require a recompile and another for people that aren't using an OS. The OS standard should identify a minimum level of peripherals and some way of figuring out what pins they are on at load time
Just a side note, I don't think that there are any true OSs for the prop yet, they are really just ways of starting a file from an sd card.
For compile and download; what's wanted is a simple means to change any source to use their hardware. That's also going to apply to an OS itself because that's how it will arrive and need to be installed on hardware so this is useful for all.
An OS-based application needs to read a database, so working backwards it makes sense for that database to also be used by a compile and download system. The common ground is the database in Ram once it's loaded or written.
For compile and load - As it runs, it determine the pin mapping, fills the database, runs the main application code which gets its data from the database.
When installing an OS - As it runs, determines the pin mapping, fills the database, runs the rest of the OS itself which gets its data from the database. It writes the database to Eeprom for subsequent OS-based Apps to load.
Running an OS-based App - Loads the database from Eeprom, runs the application which gets its data from the database.
As can be seen there's a lot of commonality there.
The main post-initialisation part of a compile and download application can be considered exactly the same as an OS-based App, both get their data from the database. The only difference is that a compile and download program has to pre-initialise the database. An OS-based App will simply assume it has been initialised and use what's there. Cut the pre-initialisation from a normal App and it becomes an OS-based App, take an OS-based App and add database initialisation and it becomes a normal App. With the right framework just a few minor changes allow the same program to be used in either way.
It may not be necessary to use an Eeprom database at all because I cannot think of any OS-based App which would be standalone and could simply be booted, it would require an OS or Loader to launch it and that OS or Loader will have been compiled for the hardware. The OS or Loader can move its database to somewhere safe in Ram, load the OS-based App and that can bring the Ram back into its own database.
Having the database is key. Having all apps read the database is crucial. How the database is initialised is really the only difference, and that's a minor difference. This is why I see a common framework as working in all cases.
Perhaps we're getting too deeply into implementation and missing the high-level overview and big picture ?
do we really need a memory hungry system for programs that aren't standard? (programs that use more than the average hardware)
wouldn't a simpler, less memory hungry solution be to simply standardize the way in which we define the constant block for such apps?
and for goodness sakes, someone please answer this question, as most of my questions in this thread have been ignored [noparse]:D[/noparse]
The more exotic uses of pin configurations don't appear to have enough momentum to justify further effort as a standard, but could instead be considered as a recommendation of one solution to a problem. Maybe such works could be added to a "white-papers" (industry term) section of the wiki.
Regarding some of the problems with 32KB EEPROM: it would be very easy to create an alternate·programmer if people want to use it for data storage. Being able to configure a product in the field where a programming connection is not available beats the heck out of FedEx overnight [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Since you started this thread 142 posts ago, you deserve an answer to your question. As I've stated in a prior post or two, I too question the need for so much cruft and feel that things have sprialed way out of control vis a vis your original post. So the short answer to your question above — from me, at least — is "no".
But due to the response this thread has engendered (and partially because of your use of those heavily-laden letters "OS" in your lead-off paragraph),
I'd say a raw nerve regarding an unmet need in more esoteric realms has been touched. These things happen in the forums occasionally when a perceived, pent-up need gets the right stimulus. Your original query apparently set off such a chain reaction. My guess is that, once the dust has settled, nothing of any lastng influence will come of it, though. This isn't to say that the ideas presented here are bad. Quite the contrary: some real insight and programming prowess — even if a bit convoluted — has been brought to bear.
Forums such as this are typically ineffective for creating standards that a majority of users will adhere to. ('Sorry guys: no affront intended. It's just been my experience.) For something of any lasting value to take hold, someone — yes, one single person and not a committee — has to take the bull by the horns and create some well-documented software so compelling that everyone will want to use it. And that, my friends, is how standards are born.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
I agree with most of what Phil said.
sorry if i made it sound like i was irritated , i wasn't.
perhaps a committee is a bad idea for putting together a standard, however the conversation we've all had has been very beneficial. There've been a lot of great ideas, that i think a lot of people will get use out of.
Even if a standard comes out of this, i think many people will use code they've discovered here that isn't in the standard, which is great.
My OS statement at the beginning of the thread hasn't been addressed much so far and thats completely fine with me. I'm glad to see so much interest in a standard way of defining pins without such a beast.
I believe most people have realized by now that this 'standard' really does require two sections, the first of which is some kind of hardware description, the second of which would be OS standards.
I think that the thread has started to go stale and its about time to bring this to a vote.
Would you guys who have suggested a standard way of defining pins please write a short paragraph describing your approach so i can include it in the poll?
suggested format for description:
summary: messenger pigeons
description: info about hardware connections, clock and display type will be written on parchment and super glued to the foot of a pigeon thats been trained to fly to the user. the user then uses a paper clip to form a switch shorting 3.3v to pin one or two, that is then used to enter this information on these pins of the chip in binary code
advantages:
low memory usage
portability (pigeons can fly)
in extreme situations, pigeons can be used as food
P.S, or perhaps we should all just implement our own standards, document them, and see which one if any gets adopted by the community? If there is not real interest in a vote I suppose thats the method we'll go with?
Post Edited (vampyre) : 6/30/2008 4:16:40 AM GMT
I have to agree, or least one person has to come up with a "this is it, use it" solution which can then be improved upon and tailored to better meet the needs of a larger audience.
That's usually the motivation which takes something from theory into becoming something which actually has legs.
Wherever we end up it has for me been a very useful and worthwhile thread. The next Spin code I release will almost certainly use this technique whether a standard or not. I've got a pair of ProtoBoards each wired up differently ( the one I built when I didn't have a clue what I was doing with the Propeller and one when I did ) and it's been a nightmare. This has given me what I think is an elegant solution to my problem, if not anyone else's.
What's memory hungry is quite subjective. Obviously excessive bloat isn't desirable but nor is an absolutely minimal system which doesn't deliver what it sets out to achieve or is too limited to have a useful purpose. It's really a question of how much extra usage is acceptable for the gains it gives.
That depends on where the constants are and which constant blocks you are talking about. I think we're all largely agreed that the core is a 32 word/long array, one per pin, with a number in it which indicates what that pin is used for.
One could go with a list of named constants for what pin types are and stick with that and there's not a lot more needs to be done. The debate has really been about how to make it easy to use and adopt, which is key to the success of anything hoping to be standardised upon. It's questioning "is simplest best?". Simplest and easiest are not necessarily the same.
One problem is that it's not easy to give good answers, comments or critiques without something concrete to see as an example, and that applies to most design discussions where ideas are being thrown in the air and knocked all over the place with competing suggestions coming from all directions.
Such chaos is often frustrating, but it certainly takes one out of the box. Sometimes a pissing contest will happen, but all in all it's worth the effort. Those who "know it all" end up learning·they don't ...·hahahaha [noparse]:)[/noparse]··Hurts a little to have to admit such things[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thats actually an excellent summary of my question.
It seems to me that simpler is best in the situation of a non-standard app, because its easier to modify, update, change and understand and (i think) uses less memory
the specific idea that i'm referring to is the one i proposed near the top of page six in this thread.
Something I feel i should mention is that everything you've posted is amazing stuff, i only wish i had your skills.
To all:
dont take offense at me desperately trying to poke holes in your ideas. I simply feel that this type of debate/banter/analysis helps flesh out ideas. Its also a great way for me personally to learn , by being corrected
what we need first is a standardized bus system for the propeller (ISA, PCI, S-100, etc) so that everybody could develop his own card and plug it into the bus.
This is the basics if we would develop hardware that is propeller compatible.
Regards
Gianni
Never worry about poking holes in people's ideas ( unless they are standing there holding an axe or loading a gun in which case whatever they say sounds fine to me [noparse]:)[/noparse] ).
You're right, it's the only way to discover the pros and cons of any idea. The real problems come when trying to decide between competing incompatible ideas and when people get polarised for and against particular ideas.
Further to what Phil said earlier about creating actual standards: There's always a chaotic start, before things start to fall into place. People go away and hopefully think about the ideas and take into account the pros and cons and modify their own in that light. Build prototypes and test ideas. That's when a standard or prototype standard gets produced. That then gets moulded into what's needed.
In the Real World(TM) that's likely a marketing meeting where all sorts of fanciful ideas are imagined followed by an R&D team attempting to turn that into something workable and going back with a, "this is what we've come up with, how do you like it ?". Moving on from there is usually much smoother sailing.
There's merit in that but it's set against many existing hardware designs which don't use any bus and people who won't use a bus if that adds what they see as unnecessary overhead.
I don't think a lack of standardised bus system stops us developing a solution to the existing problems we have, and I/O pin mapping will still be needed where I/O lines to that bus may vary from platform to platform.