In mulling over this rather amazing thread, I wonder if, by concentrating on "pins", we might be overlooking the bigger picture, which is "functions". From the earliest PC days, it's been the BIOS that has defined a functional system to shield applications from such details as which peripherals are connected to which pins. If I want to read a data block from a floppy drive, for example, I call a routine in the BIOS that does that for me, and I don't have to care which pins the floppy drive is connected to or what the BIOS has to do to talk to it. The BIOS can also define what is meant by STDIN and STDOUT. That way, if I want to use TV_Text for STDOUT, instead of the serial port, I tell the BIOS to make that association for me. So I wonder if it would make more sense for each Propeller platform to have its own BIOS object instead of a list of pin assignments. Such an object could handle the nitty-gritty details of the hardware interface so the higher level code doesn't even have to know that TV_BasePin equals 12, for example.
This would be easier to accomplish, of course, if Spin provided a way to pass method pointers as arguments to other methods. I think Chip mentioned this as a future goal. Perhaps the future is banging on the door.
Valid point Phil. We would have eventually arrived there of course. This abstraction is acheived by "software interrupts" in the old PC BIOS as you know (does it still exist?). Since interrupt is spat-upon word around here· one must say "services" or "functions" as you mentioned.
There is a functional model for product evolution based on 4 words: why, what, how, who. The why's are like a marketing requirement, etc.... Engineers tend to focus on implementation of what·or how [noparse]:)[/noparse] ... often the why and description of what is already defined.
I mentioned before ...
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.
I bring this list up only so that a separation of purpose between a PC BIOS and a Propeller BIOS, bootrom,·whatever can achieve. Of these, only some tasks apply.
Initial startup and potentially memory configuration
Device configuration (ignoring pins/config utility etc for now)
Services or functions
Starting O/S or embedded applications
So this is kind of a list of the "why" or the description of "what" .... Does this offer any roadmap ?
But how do you suppose one could possibly implement a services module without too much bloat? It seems to come down to the absolute minimum services. Then some O/S or embedded app does the rest.
jazzed said...
But how do you suppose one could possibly implement a services module without too much bloat?
That's a good question. The Spin compiler is smart, in that it doesn't include methods in the object file that aren't called.[noparse][[/noparse]See below.] So long as the BIOS object is written to take advantage of this fact (i.e. without a string of method calls in a SELECT-CASE statement, for example), bloat could be kept to a minimum. But this only works in a compile-and-run environment, which some have already stated is not adequate. And it eliminates a lot of possibilities for abstraction layers.
-Phil
Correction: Oops! I misspoke:
Jeff Martin said...
Optimizing out unreferenced methods is something we'd really like to do, but it horribly complicates the compilation process and we have not reached a point yet where we wanted to take on that task.
Phil Pilgrim (PhiPi) said...
This would be easier to accomplish, of course, if Spin provided a way to pass method pointers as arguments to other methods. I think Chip mentioned this as a future goal. Perhaps the future is banging on the door.
That is the crux.
This is exactly what I wanted as a subset to my Basic Interpreter and my PICAXE/BS1 emulator. Open an "output" and whatever gets sent goes to the desired output or device, serial port pin, TV display, VGA, via Telnet, whatever. It's output vectoring, so there'd be single number formatting routines and so on which then route to the particular device handler. Turned out to be incredibly complicated to do it that way with massive overhead and bloat. Maybe with more experience now I'd do better but lack of function pointers is a pain.
Not sure Chip said function pointers were a goal, but hopefully they are. They would simplify an awful lot of things.
You dont need function pointers to do something like this. There are serveral examples around that does this type of thing but on a smaller scale e.g. float. Run a COG as the function handler, it waits on a memory command variable. A set of spin routines interface between the app and the COG routine saving and restoring parameters into memory. The cog waits for input paramters does the work and saves info back. The OS starts a cog containing its function routines, it loads the app into another cog and the app can call on functionality in the other cog. The app loses a COG e.g. it only has 7 rather than 8 to play with.
I've been watching this thread with both interest and trepidation!
It would be great if we could all agree on a standard but there is always someone who will want to do it differently, that is life.
Regarding the passing of parameters could we not have a way of reserving specific ram locations from the os and create a command that would write the values to ram then load and run the object, which in turn will look at these ram locations for pin definitions. We could just reserve the top 16 longs in ram just for this.
eg:
run tvtext.bin,12 (start TV Text console starting at pin 12)
Obviously this would need parsing by the OS to first write a value of 12 to the ram location and then the object would have to look there for this value, and if not there default to something else.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
@Timmore,
I think the point is not so much of function pointer flexibility, but is more of a desire to have all methods of an object be "overloaded" by another object or be passed to another object. I've often had the same urge. Being able to use the "data" to define behaviour rather than "structure" has spoiled me, and that seems unfinished in spin mainly by lack of polymorphic attributes. The usual answer to such a quandry is "think different" [noparse]:)[/noparse] Oh well.
This is starting to sound a lot like DOL. The latest (not released) build is almost loading a binary from a command line off an sd card and then giving it access to keyboard and tv. This gets around the problem of pins by providing standard input and output streams. However, by that stage you are using 1 cog for sd, 1 cog for tv, 1 cog for keyboard and then you only have 5 of your 8 cogs left. Plus the os takes up around 2000 longs so you only have 6000 left. However, it is a pain in the neck passing object addresses around. You have to do something like this
You should be able to do a similar kind of thing with methods but that is a pain as well. However, if we had a good preprocessor it shouldn't be too hard to write a small tool/macro to expand something a lot simpler such as
obj:=newObj
Any way, that's enough of me pushing my project and it still doesn't solve how you tell DOL where the SD card is
I was thinking about what Timmoore said a little more, and while it is not as easy to trace or as simple as Hippy's printing example, in the context of unlinked services, it would not be so bad. After all, the crude PC BIOS services example uses lookup calls. There is little that can be done to fix the bloat problem, but at least a compiled configuration of specific objects and pin designations could provide the services. For example, I wanted to have an asm print function because I got tired of watching the scope and loading the debugger, so I created a dispatch mechanism to call methods in TV.spin.
Thing is, a well defined interface in hub space can make "basic input output services" very easy to handle, and a BIOS.spin wrapper or any language for that matter can ease the user burden so that the services can define a simple to use API. I'll work on an example later I guess, but I bet someone can come up with an example faster than me [noparse]:)[/noparse]
@Steven, you can push DOL all you like [noparse]:)[/noparse] I was always intrigued by it and still am. If not used in whole, your experience with it is valuable here.
the things you guys discuss never cease to amaze me. Again its gone way over my head, but if you guys can figure out a way to make interchangeable functions, that would be awesome.
I'm currently writing up some documentation and example code for my currently suggested version of the standard, i'll post them in a day or two. I'm really looking forward to seeing where this thread ends up.
vampyre said...
the things you guys discuss never cease to amaze me. Again its gone way over my head, but if you guys can figure out a way to make interchangeable functions, that would be awesome.
You are in the hands of engineers now.. [noparse]:)[/noparse]
@ vampyre : This is the world of people who enjoy getting square pegs to fit in round holes and finding the holes which are normally invisible.
Don't worry that some things go over your head. It takes some experience, a detailed knowledge of what works underneath the hood, a love of pulling things to pieces to see how they work, lateral thinking, some lucky breaks plus obsession and passion, Most people have 'real lives' instead
Hippy said...
Don't worry that some things go over your head.
I'm not too worried about it, i just am enjoying the show, watching you guys do the impossible.
I've got the obsession and lack of a 'real life', i just don't have the IQ anymore to get it like i used to. I just pick and choose the bits i need to understand and focus on those
@CassLan:
I don't think we decided to standardize any specific RTC but there is no reason they couldn't be added to the hardware list once its standardized. Personally, i'm not using a button cell because my prop system is battery powered and portable, i just run a power line right to the clock.
Ok, here is a small demo of a BIOS services design. Not perfect of course and
open to suggestions, but it is·a way of looking at a services solution.
Items of note:
Two BIOS.spin copies are included in the demo. BIOS.spin has pre-processor
macros and is intended to be the repository of all possible services.
BIOS-select.spin has only VGA_Text.spin included as an object. The two files
are essentially the same for now because no other module has been added
except VGA_Text.spin
The BIOS_Demo.spin file includes BIOS-select.spin just to start up the
service provider. In an O/S situation, this would be done by the boot code,
and the only items required of the user application would be the desired
API client. I had some trouble trying to make use of dynamic clock settings
apparently because _clkmode and clkmode have entirely different values.
One file BIOS_Constant.spin would contain all services available in the BIOS.
Only the BIOS.spin and client objects such as BIOS_VGA_Text.spin need
to include the constant file.
Each major service type such as VGA_Text would have it's own client file
that defines the user API to the services. In the VGA case shown, the client
file used is BIOS_VGA_Text.spin
The heart of the design is the BIOS.spin "PRI spin" method. After init in its
cog, the routine "spins" waiting for commands to process. For now the
command structure is made up of longs and live in $7FF0 address space.
The first long is the command to execute, the rest are argument variables.
This design uses the compile-time constants from my local PinDefs.spin.
Have a look and consider the usability of all this. Comments are encouraged
and will taken in the friendliest spirit I can muster.
Excellent! That·is what I was thinking...
It would be nice if it could be possible to configure the BIOS on the fly. For example by pressing "ESC" or "F2" button we will enter in SETUP modus, so that we can set on a text screen different options like: System Time/Date, Boot sequence, Mouse/Keyboard configuration, etc...
It would be nice if it could be possible to configure the BIOS on the fly. For example by pressing "ESC" or "F2" button we will enter in SETUP modus, so that we can set on a text screen different options like: System Time/Date, Boot sequence, Mouse/Keyboard configuration, etc...
Gianni,
Yes, you're right. Of course one would need a run-time pin definition as previously proposed for that though
Such ideas have been considered already for those who care.
BTW: is your avatar pic a Sinclair or copy? That was my 3rd computer [noparse]:)[/noparse]
So far, this BIOS_Demo.zip package has not produced much excitement, so it may be D.O.A.
Until some suggests I'm wasting my time, I'll continue.
Below is another installment that includes support for TV, VGA, and FullDuplexSerial.
Next up would be adding Keyboard, Mouse, and SD card·support.
Notes:
The BIOS_CMD_BASE moved to $7FE0 to allow up to 7 long arguments. In current Propeller,
only word·values·are·necessary; longs are used for expansion with the mythical PropII.
Changing to word size would not be so hard.
FullDuplexSerial is treated differently here since a user might want a special baudrate.
Don't know if that is a reasonable idea or not. If an app needs more than one serial port,
it can define and start·it's own object.
Hey jazzed - don't take the (near) silence as an indication of a bad idea! I've dl'd your demo and had a look. At first glance it seemed scary (and that could be an issue for noob's), but I think I get what you're doing
Maybe the inclusion of full & selected versions in the same demo is what's scary - dunno.
I've got two job interviews tomorrow, so won't be able to spend any time on it now. Hope I'm happy enough to take a look tomorrow!
Thanks for your efforts so far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Same here. It's the first of the month, i.e. bill-paying day, so I'm a bit distracted with more mundane stuff right now. Ugh! :-(
I did glance through your code, though, and can appreciate the enormous amount of work that went into it. It's unfortunate that the compiler is not yet able to detect and remove methods that aren't being used. Otherwise a lot of conditional compilation stuff could be removed, and all the I/O routines could simply be rolled into the BIOS object without penalty. I'm in a position now where I need to do something like this, but I've got the additional burden of a daughterboard connector and the unknown/unanticipated stuff that plugs into it.
It's a dilemma whether to accept the necessary awkwardness now and plow ahead with a BIOS using the tools we've got or to appeal to a higher authority (i.e. Chip) for object/method "weeding" and method pointers and wait until it happens.
Its highly unlikely that we will get function pointers on the current propeller. Will it would be possible with just compiler changes it would be a fair bit of work to support it well and I don't think that Parallax really have the time. Its also unlikely that we will get object/method "weeding" because it would probably require some major changes to the compiler. If someone developed an ide that supported pre-processing it would be possible to do all this but it would be a fair amount of work.
@vampyre:· I hope this is not hijacking your thread too much. If you like I can move this to
a new thread. I'll probably start an independent thread anyway later just for maintenance.
Let me summarize this package from a user perpective:
This package can be used·by O/S applications (which may be spawned by a future·O/S)
or a single purpose embedded applications. The full package is heavy, but is easily customized.
An application can call API "Application Program Interface" client stubs to perform hardware
related tasks. The API clients send commands and arguments that are executed by a single
threaded server (repeat loop in a COG). All API transactions are synchronous, that is every
call will complete before the next call can start. The API clients are provided by wrappers
in BIOS_<device>.spin files.
This fulfills one of the jobs of a BIOS (from the old days at least) to provide services that any
application or O/S could use to interact with system hardware without having to be
concerned much about the hardware connections ... some people call this a HAL or Hardware
Abstraction Layer. BIOS services are called to perform Basic IO Services.
Notes on BIOS_Demo3.zip:
This is an update with Keyboard & Mouse support. SD card & EEPROM will be next.
I've done basic testing with BIOS_Demo.spin ... more per-method unit testing is required.
Since Simon mentioned that having two versions of the BIOS.spin file in one package is
confusing, I thought I would just include the "monolith" version. Full code is 2K+ longs now.
@Phil, you might consider having a small eeprom on your daughter-cards containing an
identifier and other pertinent feature information. This approach has been used by the
internet core router system for a couple of decades now. The trouble comes as the
number of devices grow very large (without loadable drivers) and so does the software
in monolithic embedded images. Ya, they get huge, and that's·the main reason I don't
mess with it anymore. You can imaging the source control nightmare adding new products?
Here's my latest incarnation of a pin number lookup database. Got the clock setting done so that's platform independent as well.
Have moved away from a table of one per pin entries; it doesn't work with the hardware I have.
I have a pin which can be a serial output or a LED output so that should map to a serial out for a program which wants a serial port and map to a LED for a program which wants a LED. The one entry per pin doesn't allow a pin to be two things and it's not possible to map/alias the two together in the top application because other platforms do not have both on the same pin.
For a platform with separate serial and LED ana pp will get a pin number handed back for each, when dual-role pins, only the first asked for gets a pin number. Thus an app which is serial based will get a serial port but no diagnostics LED, or a LED controlling app gets the LED but loses the serial debug reports.
I have compromised on using numbered name constants in the low-level drivers to save code usage but to save having to export up all imported name constants in every hardware definition file I use Packed(String()) at the higher levels. Otherwise every pin definition file in the universe has to be be updated just because someone's had the bright idea of creating a new name for a new hardware pin.
The entire overhead is around 350 longs ( code + vars ).
In theory, all one has to do is change the "OBJ pindefs :" and it should work on your platform which shows how easy it is to use. Some of the pin definitions may be wrong for some platforms and not all possible pins are named.
I looked at the pindef problem slightly differently. I see 2 different issues.
1. The list of devices and what pin they are on that the application is expecting
2. The list of devices and the pin they are on that the OS will override
I see 2 being a small subset of 1. @hippy from your description the multiple pin problem isn't 1 what the app wants to use but you seem to be wanting to describe all the hardware whether the app wants to use it or not. Is that necessary?
There may be a case for multiple devices on a pin that the app wants, I can think of SPI devices sharing DI/DO/CLK lines (e.g. the data logging example using 2 sd cards on a different thread) but I would define a SPI_DI,etc enum for that case. There are probably some similar cases of dis-similar devices that work in a similar way, i.e. a pin each that enables/disables the device and some shared pins to control the devices.
Then the question I have is whether the additional complexity is worth it. A single table with an access function is much smaller and simpler (at least I think so). Dis-similar devices sharing pins would have to be handled as an exception.
I recently realized yesterday that the 32 pin array in the eeprom wouldn't work well because of I2C and SPI devices, its more than possible to have multiples of those. If I'm going to continue beating this dead horse, i'll have to put a backpack on him to carry info about the addresses of those devices or something. (i'll have to increase the size of the list by some number of entries, and hope its enough)
Jazzed said...
@vampyre: I hope this is not hijacking your thread too much. If you like I can move this to
a new thread. I'll probably start an independent thread anyway later just for maintenance.
not at all. I'm looking forward to seeing how your version plays out. If you do start another thread i'll be one of its regular readers. i actually thought of starting a seperate thread for the hardware issue, but splitting up the conversation at this point i think would only serve to polarize and prematurely kill the conversation.
@ Timmoore : What I describe in my platform files is all the hardware that platform has. That seems to be all that's necessary and also the minimum required.
For the whole system to work it has to handle any app asking for any specific hardware pin which could exist whether that program knows about it or not, whether it supports it or not.
Should someone update their code to include support for a new piece of hardware which isn't a pre-requisite for use it's my belief that this version should still compile and run on my hardware regardless that I haven't updated any pindefs files. This is why I kept with the Packed(String()) idea rather than pindefs#name at the top level; the later would throw a compile error and stop me dead until I had updated my libraries. Somewhat defeats the purpose of it all IMO.
@ vampyre : The way I'd handle shared I2C/SPI is to have three types of pin ...
I2C_SDA =
SPI_DAT =
I2C_SDA_SPI_DAT =
If I2C_SDA and/or I2C_SPI were asigned I2C_SDA_SPI_DAT wouldn't be and vice-versa. I2C_DAT and SPI_DAT would never be set to the same pin, if so it becomes one or the other, not both. Ditto for clock line.
The top level app would look for separate pins and if not found looks for a shared pin and use that ( or vice-versa ). The low-level code could offer up the other if it were being clever but that's overhead for platforms which don't have unusual configurations.
A similar issue exists with audio; some have mono output, some have separate left and right,
some ( like mine ) have a mono and a left and right output. IMO it's up to the top-level app to seek out the pins it wants and then fall back to something else or bale out.
@ All : I think the best way to check if any mechanism works is to try it and run it against a variety of platforms. That's how I found what I was trying wasn't going to work.
In my specific case of LED and serial out combined, if someone gives me an app and it sends serial out then I should be able to fire it up and watch the terminal ( whilst ignoring the LED ), if it's a LED flashing app I can watch the LED and ignore the garbage on the Terminal. Regardless of my weird setup both applications will behave as expected, neither author has to worry about my weird configuration. This is really the goal I'm after.
@Jazzed, It looks like you bios code is similar to what I did with the original DOL. One of the reasons I changed to the current scheme was because I was worried that the extra method calls would make something that was marginal on speed too slow. It also introduces some extra code that takes up space. You could get around this if we could use macros. This isn't meant to have a go at your good work, just some things to consider.
@All, If we had a good pre-processor than we wouldn't need to do a lot of this. Maybe instead of all this focus on making a pin-def file/bios we should really be working on an ide with a good pre-processor.
The ide could have a nice graphical user interface for setting a bunch of constants such as pin settings and other things similar to what some of the C compilers have. You could also add standard libraries such as display and serial drivers with automatic setups. Then when you hit the compile/load button it simply goes through and does any necessary pre-processing and then calls propellant. We could even use the standard c pre-processor and eclipse or something now that we have propellant. It seems like there are 101 different code editors out there and there must be some that are easy to modify. Something like this will probably also have more chance of working with the c compiler than what we are currently talking about.
A lot of the solutions that we have come up with are great but introduce a fairly significant overhead of either performance or memory that isn't really needed. One other quick note, it's not really that easy to pin down a particular area in memory that is guaranteed to be free even at the top of memory. The graphics driver uses this area so things are aligned properly and I believe that someone also developed a memory manager that used this area of memory.
To go back to the requirements they are
1. Provide a way to set up the pin/clock configuration once and then have it work for all the programs you compile
2. Provide a way for binaries to determine what pin/clock configuration to use when launched from an OS
3. Be easy for the programmer to use <- this is probably the most important, if its not easy people won't use it.
4. Have a small size and runtime footprints
I think we've seen options that do 2 or 3 of these so far but not all 4. It may not be possible to get all four so we really want something that will do 1, 3, and 4 and another option to do 2, 3 and 4.
Jazzed has also taken this to another level with his bios code so that you can completely swap out one driver for another so we could make this requirement number five
5. Provide a consistent interface to input/output devices (i.e. tv, vga or serial)
I know, I'm playing the devil's advocate but someone has to
(Does anyone know of a way to run propellant on a mac from a command line using wine/crossover?)
With 1-3-4 it should be possible for someone familiar with a particular OS to make that somehow work.
Speed isn't so much a problem as it just extends start-up times a little but there is code overhead then it's full-speed execution. For an OS the extra code for Eeprom/SD access if needed shouldn't be too bad in itself and I'd expect an OS to have to include that anyway although an OS-launched App might not - I've never used any of these OS's.
Despite all the good and useful discussion we're still no closer to any standard. I suspect everyone outside the OS market will do their own thing with the option chosen for the OS down to whoever maintains it. In the fullness of time something 'standardised' may fall out.
For my part I'm happy with what I have now. I've removed what have been thorns in my side so I'll probably stick with what I have at least in developing and publishing my own code. At least it's now just a one line change when I move apps between my different ProtoBoards and I can change hardware itself without having to do lots of edits to all my code base, just edit one file, re-compile and download.
I think I'm now going to move on to seeing how callbacks can be implemented with as much transparency
An IDE that employs a pre-processor and other developer friendly features would be useful.
I have an Eclipse project that builds .spin code using Propellent, and have considered writing a .spin plug-in. It·would be great·if a plug-in would allow .spin syntax highlighting, reference and declaration lookup, one-click jump to declarations, function API help during edit, and object element drop-down selectors. Of course the other Eclipse feature that can help greatly with group projects is built-in CVS source control.
On the BIOS thing, I'm glad for any helpful comments you have -·thanks. The ability to use a pre-processor to select what the user wants the BIOS to do is key for me. Some projects hardware don't have keyboard, mouse, or display at all, others don't need a serial port, etc.... I would like to have an easier way to add any module to the infrastructure, and am considering breaking out the big case statement to different calls, but that just slows things down. Time-critical services should most likely be done differently anyway though.
Guess it's time for me to have a·look at DOL again. Now where was that link....
On consistent interface, TV/VGA are simple to do, and·serial port is a super-set of them. Other devices have different·requirements. In the linux world all devices are files and can be used with·open, close, select, read, and write; of course there is overhead with that,·and·I doubt it can be done with Propeller. Even if possible, it would most likely not be welcomed [noparse]:)[/noparse]
@Hippy,
Is there a function in your code or an external program that can build an initial packed string ?
Good luck with callbacks.
I'm sure I'll need more than just pin numbers for a BIOS configuration. I'm still torn on the database implementation. At this point a generic key/value hash table or linked list would be great, but both are costly (190 longs just for a good malloc with block recovery). I guess I'll go experiment with Darco's settings code.
Comments
This would be easier to accomplish, of course, if Spin provided a way to pass method pointers as arguments to other methods. I think Chip mentioned this as a future goal. Perhaps the future is banging on the door.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
There is a functional model for product evolution based on 4 words: why, what, how, who. The why's are like a marketing requirement, etc.... Engineers tend to focus on implementation of what·or how [noparse]:)[/noparse] ... often the why and description of what is already defined.
I bring this list up only so that a separation of purpose between a PC BIOS and a Propeller BIOS, bootrom,·whatever can achieve. Of these, only some tasks apply.
So this is kind of a list of the "why" or the description of "what" .... Does this offer any roadmap ?
But how do you suppose one could possibly implement a services module without too much bloat? It seems to come down to the absolute minimum services. Then some O/S or embedded app does the rest.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Phil
Correction: Oops! I misspoke:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 6/30/2008 7:15:52 PM GMT
That is the crux.
This is exactly what I wanted as a subset to my Basic Interpreter and my PICAXE/BS1 emulator. Open an "output" and whatever gets sent goes to the desired output or device, serial port pin, TV display, VGA, via Telnet, whatever. It's output vectoring, so there'd be single number formatting routines and so on which then route to the particular device handler. Turned out to be incredibly complicated to do it that way with massive overhead and bloat. Maybe with more experience now I'd do better but lack of function pointers is a pain.
Not sure Chip said function pointers were a goal, but hopefully they are. They would simplify an awful lot of things.
It would be great if we could all agree on a standard but there is always someone who will want to do it differently, that is life.
Regarding the passing of parameters could we not have a way of reserving specific ram locations from the os and create a command that would write the values to ram then load and run the object, which in turn will look at these ram locations for pin definitions. We could just reserve the top 16 longs in ram just for this.
eg:
run tvtext.bin,12 (start TV Text console starting at pin 12)
Obviously this would need parsing by the OS to first write a value of 12 to the ram location and then the object would have to look there for this value, and if not there default to something else.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
I think the point is not so much of function pointer flexibility, but is more of a desire to have all methods of an object be "overloaded" by another object or be passed to another object. I've often had the same urge. Being able to use the "data" to define behaviour rather than "structure" has spoiled me, and that seems unfinished in spin mainly by lack of polymorphic attributes. The usual answer to such a quandry is "think different" [noparse]:)[/noparse] Oh well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PRI RouteOutput( outputDevice ) Case outputDevice DEV_TX : printCharHandler := @Serial.Tx DEV_TV : printCharHandler := @Tv.Out PRI PrintChar( ch ) *printCharHandler( ch )You should be able to do a similar kind of thing with methods but that is a pain as well. However, if we had a good preprocessor it shouldn't be too hard to write a small tool/macro to expand something a lot simpler such as
Any way, that's enough of me pushing my project and it still doesn't solve how you tell DOL where the SD card is
I was thinking about what Timmoore said a little more, and while it is not as easy to trace or as simple as Hippy's printing example, in the context of unlinked services, it would not be so bad. After all, the crude PC BIOS services example uses lookup calls. There is little that can be done to fix the bloat problem, but at least a compiled configuration of specific objects and pin designations could provide the services. For example, I wanted to have an asm print function because I got tired of watching the scope and loading the debugger, so I created a dispatch mechanism to call methods in TV.spin.
Thing is, a well defined interface in hub space can make "basic input output services" very easy to handle, and a BIOS.spin wrapper or any language for that matter can ease the user burden so that the services can define a simple to use API. I'll work on an example later I guess, but I bet someone can come up with an example faster than me [noparse]:)[/noparse]
@Steven, you can push DOL all you like [noparse]:)[/noparse] I was always intrigued by it and still am. If not used in whole, your experience with it is valuable here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm currently writing up some documentation and example code for my currently suggested version of the standard, i'll post them in a day or two. I'm really looking forward to seeing where this thread ends up.
You are in the hands of engineers now.. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
Rick
Don't worry that some things go over your head. It takes some experience, a detailed knowledge of what works underneath the hood, a love of pulling things to pieces to see how they work, lateral thinking, some lucky breaks plus obsession and passion, Most people have 'real lives' instead
I've got the obsession and lack of a 'real life', i just don't have the IQ anymore to get it like i used to. I just pick and choose the bits i need to understand and focus on those
@CassLan:
I don't think we decided to standardize any specific RTC but there is no reason they couldn't be added to the hardware list once its standardized. Personally, i'm not using a button cell because my prop system is battery powered and portable, i just run a power line right to the clock.
open to suggestions, but it is·a way of looking at a services solution.
Items of note:
Two BIOS.spin copies are included in the demo. BIOS.spin has pre-processor
macros and is intended to be the repository of all possible services.
BIOS-select.spin has only VGA_Text.spin included as an object. The two files
are essentially the same for now because no other module has been added
except VGA_Text.spin
The BIOS_Demo.spin file includes BIOS-select.spin just to start up the
service provider. In an O/S situation, this would be done by the boot code,
and the only items required of the user application would be the desired
API client. I had some trouble trying to make use of dynamic clock settings
apparently because _clkmode and clkmode have entirely different values.
One file BIOS_Constant.spin would contain all services available in the BIOS.
Only the BIOS.spin and client objects such as BIOS_VGA_Text.spin need
to include the constant file.
Each major service type such as VGA_Text would have it's own client file
that defines the user API to the services. In the VGA case shown, the client
file used is BIOS_VGA_Text.spin
The heart of the design is the BIOS.spin "PRI spin" method. After init in its
cog, the routine "spins" waiting for commands to process. For now the
command structure is made up of longs and live in $7FF0 address space.
The first long is the command to execute, the rest are argument variables.
This design uses the compile-time constants from my local PinDefs.spin.
Have a look and consider the usability of all this. Comments are encouraged
and will taken in the friendliest spirit I can muster.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Excellent! That·is what I was thinking...
It would be nice if it could be possible to configure the BIOS on the fly. For example by pressing "ESC" or "F2" button we will enter in SETUP modus, so that we can set on a text screen different options like: System Time/Date, Boot sequence, Mouse/Keyboard configuration, etc...
Regards
Gianni
Yes, you're right. Of course one would need a run-time pin definition as previously proposed for that though
Such ideas have been considered already for those who care.
BTW: is your avatar pic a Sinclair or copy? That was my 3rd computer [noparse]:)[/noparse]
So far, this BIOS_Demo.zip package has not produced much excitement, so it may be D.O.A.
Until some suggests I'm wasting my time, I'll continue.
Below is another installment that includes support for TV, VGA, and FullDuplexSerial.
Next up would be adding Keyboard, Mouse, and SD card·support.
Notes:
The BIOS_CMD_BASE moved to $7FE0 to allow up to 7 long arguments. In current Propeller,
only word·values·are·necessary; longs are used for expansion with the mythical PropII.
Changing to word size would not be so hard.
FullDuplexSerial is treated differently here since a user might want a special baudrate.
Don't know if that is a reasonable idea or not. If an app needs more than one serial port,
it can define and start·it's own object.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Maybe the inclusion of full & selected versions in the same demo is what's scary - dunno.
I've got two job interviews tomorrow, so won't be able to spend any time on it now. Hope I'm happy enough to take a look tomorrow!
Thanks for your efforts so far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Same here. It's the first of the month, i.e. bill-paying day, so I'm a bit distracted with more mundane stuff right now. Ugh! :-(
I did glance through your code, though, and can appreciate the enormous amount of work that went into it. It's unfortunate that the compiler is not yet able to detect and remove methods that aren't being used. Otherwise a lot of conditional compilation stuff could be removed, and all the I/O routines could simply be rolled into the BIOS object without penalty. I'm in a position now where I need to do something like this, but I've got the additional burden of a daughterboard connector and the unknown/unanticipated stuff that plugs into it.
It's a dilemma whether to accept the necessary awkwardness now and plow ahead with a BIOS using the tools we've got or to appeal to a higher authority (i.e. Chip) for object/method "weeding" and method pointers and wait until it happens.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
my avatar is a pic of a ZX81. I am working on an emulator for the Hydra.....
http://forums.parallax.com/forums/default.aspx?f=33&p=1&m=241640
as soon as· t is finished, I will start with a gameboy emulator
... but now I am distracted with the BIOS thread
a new thread. I'll probably start an independent thread anyway later just for maintenance.
Let me summarize this package from a user perpective:
This package can be used·by O/S applications (which may be spawned by a future·O/S)
or a single purpose embedded applications. The full package is heavy, but is easily customized.
An application can call API "Application Program Interface" client stubs to perform hardware
related tasks. The API clients send commands and arguments that are executed by a single
threaded server (repeat loop in a COG). All API transactions are synchronous, that is every
call will complete before the next call can start. The API clients are provided by wrappers
in BIOS_<device>.spin files.
This fulfills one of the jobs of a BIOS (from the old days at least) to provide services that any
application or O/S could use to interact with system hardware without having to be
concerned much about the hardware connections ... some people call this a HAL or Hardware
Abstraction Layer. BIOS services are called to perform Basic IO Services.
Notes on BIOS_Demo3.zip:
This is an update with Keyboard & Mouse support. SD card & EEPROM will be next.
I've done basic testing with BIOS_Demo.spin ... more per-method unit testing is required.
Since Simon mentioned that having two versions of the BIOS.spin file in one package is
confusing, I thought I would just include the "monolith" version. Full code is 2K+ longs now.
@Phil, you might consider having a small eeprom on your daughter-cards containing an
identifier and other pertinent feature information. This approach has been used by the
internet core router system for a couple of decades now. The trouble comes as the
number of devices grow very large (without loadable drivers) and so does the software
in monolithic embedded images. Ya, they get huge, and that's·the main reason I don't
mess with it anymore. You can imaging the source control nightmare adding new products?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have moved away from a table of one per pin entries; it doesn't work with the hardware I have.
I have a pin which can be a serial output or a LED output so that should map to a serial out for a program which wants a serial port and map to a LED for a program which wants a LED. The one entry per pin doesn't allow a pin to be two things and it's not possible to map/alias the two together in the top application because other platforms do not have both on the same pin.
For a platform with separate serial and LED ana pp will get a pin number handed back for each, when dual-role pins, only the first asked for gets a pin number. Thus an app which is serial based will get a serial port but no diagnostics LED, or a LED controlling app gets the LED but loses the serial debug reports.
I have compromised on using numbered name constants in the low-level drivers to save code usage but to save having to export up all imported name constants in every hardware definition file I use Packed(String()) at the higher levels. Otherwise every pin definition file in the universe has to be be updated just because someone's had the bright idea of creating a new name for a new hardware pin.
The entire overhead is around 350 longs ( code + vars ).
In theory, all one has to do is change the "OBJ pindefs :" and it should work on your platform which shows how easy it is to use. Some of the pin definitions may be wrong for some platforms and not all possible pins are named.
1. The list of devices and what pin they are on that the application is expecting
2. The list of devices and the pin they are on that the OS will override
I see 2 being a small subset of 1. @hippy from your description the multiple pin problem isn't 1 what the app wants to use but you seem to be wanting to describe all the hardware whether the app wants to use it or not. Is that necessary?
There may be a case for multiple devices on a pin that the app wants, I can think of SPI devices sharing DI/DO/CLK lines (e.g. the data logging example using 2 sd cards on a different thread) but I would define a SPI_DI,etc enum for that case. There are probably some similar cases of dis-similar devices that work in a similar way, i.e. a pin each that enables/disables the device and some shared pins to control the devices.
Then the question I have is whether the additional complexity is worth it. A single table with an access function is much smaller and simpler (at least I think so). Dis-similar devices sharing pins would have to be handled as an exception.
not at all. I'm looking forward to seeing how your version plays out. If you do start another thread i'll be one of its regular readers. i actually thought of starting a seperate thread for the hardware issue, but splitting up the conversation at this point i think would only serve to polarize and prematurely kill the conversation.
For the whole system to work it has to handle any app asking for any specific hardware pin which could exist whether that program knows about it or not, whether it supports it or not.
Should someone update their code to include support for a new piece of hardware which isn't a pre-requisite for use it's my belief that this version should still compile and run on my hardware regardless that I haven't updated any pindefs files. This is why I kept with the Packed(String()) idea rather than pindefs#name at the top level; the later would throw a compile error and stop me dead until I had updated my libraries. Somewhat defeats the purpose of it all IMO.
@ vampyre : The way I'd handle shared I2C/SPI is to have three types of pin ...
I2C_SDA =
SPI_DAT =
I2C_SDA_SPI_DAT =
If I2C_SDA and/or I2C_SPI were asigned I2C_SDA_SPI_DAT wouldn't be and vice-versa. I2C_DAT and SPI_DAT would never be set to the same pin, if so it becomes one or the other, not both. Ditto for clock line.
The top level app would look for separate pins and if not found looks for a shared pin and use that ( or vice-versa ). The low-level code could offer up the other if it were being clever but that's overhead for platforms which don't have unusual configurations.
A similar issue exists with audio; some have mono output, some have separate left and right,
some ( like mine ) have a mono and a left and right output. IMO it's up to the top-level app to seek out the pins it wants and then fall back to something else or bale out.
@ All : I think the best way to check if any mechanism works is to try it and run it against a variety of platforms. That's how I found what I was trying wasn't going to work.
In my specific case of LED and serial out combined, if someone gives me an app and it sends serial out then I should be able to fire it up and watch the terminal ( whilst ignoring the LED ), if it's a LED flashing app I can watch the LED and ignore the garbage on the Terminal. Regardless of my weird setup both applications will behave as expected, neither author has to worry about my weird configuration. This is really the goal I'm after.
@All, If we had a good pre-processor than we wouldn't need to do a lot of this. Maybe instead of all this focus on making a pin-def file/bios we should really be working on an ide with a good pre-processor.
The ide could have a nice graphical user interface for setting a bunch of constants such as pin settings and other things similar to what some of the C compilers have. You could also add standard libraries such as display and serial drivers with automatic setups. Then when you hit the compile/load button it simply goes through and does any necessary pre-processing and then calls propellant. We could even use the standard c pre-processor and eclipse or something now that we have propellant. It seems like there are 101 different code editors out there and there must be some that are easy to modify. Something like this will probably also have more chance of working with the c compiler than what we are currently talking about.
A lot of the solutions that we have come up with are great but introduce a fairly significant overhead of either performance or memory that isn't really needed. One other quick note, it's not really that easy to pin down a particular area in memory that is guaranteed to be free even at the top of memory. The graphics driver uses this area so things are aligned properly and I believe that someone also developed a memory manager that used this area of memory.
To go back to the requirements they are
1. Provide a way to set up the pin/clock configuration once and then have it work for all the programs you compile
2. Provide a way for binaries to determine what pin/clock configuration to use when launched from an OS
3. Be easy for the programmer to use <- this is probably the most important, if its not easy people won't use it.
4. Have a small size and runtime footprints
I think we've seen options that do 2 or 3 of these so far but not all 4. It may not be possible to get all four so we really want something that will do 1, 3, and 4 and another option to do 2, 3 and 4.
Jazzed has also taken this to another level with his bios code so that you can completely swap out one driver for another so we could make this requirement number five
5. Provide a consistent interface to input/output devices (i.e. tv, vga or serial)
I know, I'm playing the devil's advocate but someone has to
(Does anyone know of a way to run propellant on a mac from a command line using wine/crossover?)
Speed isn't so much a problem as it just extends start-up times a little but there is code overhead then it's full-speed execution. For an OS the extra code for Eeprom/SD access if needed shouldn't be too bad in itself and I'd expect an OS to have to include that anyway although an OS-launched App might not - I've never used any of these OS's.
Despite all the good and useful discussion we're still no closer to any standard. I suspect everyone outside the OS market will do their own thing with the option chosen for the OS down to whoever maintains it. In the fullness of time something 'standardised' may fall out.
For my part I'm happy with what I have now. I've removed what have been thorns in my side so I'll probably stick with what I have at least in developing and publishing my own code. At least it's now just a one line change when I move apps between my different ProtoBoards and I can change hardware itself without having to do lots of edits to all my code base, just edit one file, re-compile and download.
I think I'm now going to move on to seeing how callbacks can be implemented with as much transparency
An IDE that employs a pre-processor and other developer friendly features would be useful.
I have an Eclipse project that builds .spin code using Propellent, and have considered writing a .spin plug-in. It·would be great·if a plug-in would allow .spin syntax highlighting, reference and declaration lookup, one-click jump to declarations, function API help during edit, and object element drop-down selectors. Of course the other Eclipse feature that can help greatly with group projects is built-in CVS source control.
On the BIOS thing, I'm glad for any helpful comments you have -·thanks. The ability to use a pre-processor to select what the user wants the BIOS to do is key for me. Some projects hardware don't have keyboard, mouse, or display at all, others don't need a serial port, etc.... I would like to have an easier way to add any module to the infrastructure, and am considering breaking out the big case statement to different calls, but that just slows things down. Time-critical services should most likely be done differently anyway though.
Guess it's time for me to have a·look at DOL again. Now where was that link....
On consistent interface, TV/VGA are simple to do, and·serial port is a super-set of them. Other devices have different·requirements. In the linux world all devices are files and can be used with·open, close, select, read, and write; of course there is overhead with that,·and·I doubt it can be done with Propeller. Even if possible, it would most likely not be welcomed [noparse]:)[/noparse]
@Hippy,
Is there a function in your code or an external program that can build an initial packed string ?
Good luck with callbacks.
I'm sure I'll need more than just pin numbers for a BIOS configuration. I'm still torn on the database implementation. At this point a generic key/value hash table or linked list would be great, but both are costly (190 longs just for a good malloc with block recovery). I guess I'll go experiment with Darco's settings code.
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔