Anyway, this is all out of scope. We have a compiler in GCC not an operating system.
This isn't out of scope though. A kernel isn't an operating system, it's a way of linking modular drivers. Since this forum is all about drivers, I think it's really just a no-brainer that a primitive kernel might make sense given that C is now becoming standardized for the Prop. Writing better code and less of it is all this about.
Anyway, this is all out of scope. We have a compiler in GCC not an operating system.
Yeah, yeah, I know C standards require a standard in and standard out "device". But that is it.
Not quite true. The C language requires more "devices" than just stdin, stdout (and stderr) - it is just that some of the others are not mentioned explicitly. For example, it requires a clock device. It requires a mass storage device. It requires a floating point device (remember that floating point co-processors are often separate hardware).
However, the point I think you are making is certainly true in essence - i.e. that there is a limited number of devices mandated by the C language. I think all the available C compilers have probably already achieved this minimum subset.
But I think what we are talking about here is the "additional" devices that we would like to have access to on the Propeller, and (by extension) how we should support them. A mouse is a perfect example. This is a fairly easy device to implement, and is also highly desirable since the necessary hardware is built-in to many Propeller boards. Also, there are several good versions already available in the OBEX. This is a perfect example to discuss in this thread because it is on Daniel's original list, it is not one of the devices "mandated" by the C language, and also (AFAIK) GCC does not yet support it.
We could define a new architecture that solves the problem for both "mandated" and "non-mandated" devices, but is this the real point? As a user I don't really care (and why should I?) about the internal implementation of any of the "mandated" devices supported by my C compiler - that's for the compiler developers to worry about. I mostly want to know about all the other cool devices I may want or need to add. Especially in an embedded environment where - unlike an O/S environment like Linux, where this is the arcane domain of kernel developers - as a normal user I routinely expect to add new devices for every new project as part of my development process.
So let's think about a mouse driver in particular - it might help clarify the purpose of this thread. Is it that we want to ...
Write a mouse driver entirely in C? (why - to show it can be done? Well, in this case I think it probably can - but this does not mean all drivers can or should be)
Write a common C "wrapper" that can be used with different mouse drivers (this is probably the one that ordinary users would be most interested in).
Re-use one or more of the existing OBEX mouse drivers? (this is not quite the same as the previous point, but it is related - and if this is not the goal of this particular thread, it is probably important enough that it should be discussed separately anyway)
Define a driver interface that would allow any mouse driver to be used from any language - C, C++, SPIN, BASIC or FORTH - by "hiding" the details behind a common interface that takes advantage of the Propeller's unique abilities and limitations (this is what I would like to see this thread discuss!)
Dr A,
I agree. Many existing objects have "linkage" between the PASM part and the variables used by their Spin wrapper. Making it hard to use them in other languages and hard to recycle the precious HUB space the PASM lived in before being loaded to COG.
This has been discussed at length in the past, for example there is Bill Henning and his "mailboxes".
I did at one point suggest that all "Gold Standard" objects should be written in a way that they can be used from any language and loaded from any media. I don't think many people saw the "linkage" problem at the time. I had already met it when trying to use PASM driver code in Zog.
I see no reason why the request for C drivers should not include the use of assembler modules, provided they can be assembled with the GCC assembler. Whilst I did manage to get a fullduplex serial driver written in C and running in COG working I think many drivers will not be amenable to this for size and/or speed reasons.
This reply may be part in and out of band to this thread, but here it is anyway.
I discovered the prop purely by accident while starting the planning stages of a potential research project which is still in the waiting for grants stages as some components are rather beyond the garage developer. I jumped in with both feet to learn anyway, paying little attention to the depth markings on the pool as it looked like there were swimmers at all levels in the pool. I did ask one member to have a look at my ADC object for the purposes of a sort of a peer review, but like most of us was likely just too busy making ends meet to have time then. So as I've heard no raspberries over it, I had to assume it not only met my needs for it, but may be fit for consumption at some level; to the OBEX with it. Same for my three-wire LCD object. Unfortunately, this is the first I have heard of some preferred standard and some ways of doing things making other uses difficult.
Perhaps someone(s) with experience here could create or point us who are new to the propeller and Parallax to a sort of FAQ page containing such things as where to find things like DaSilva's PASM tutorial or the Potato Head Papers, and some level of documentation or discussions of preferred standards rather than leaving it to chance discovery. maybe automatically deliver it when someone registers. It should include information on preferred standards or at least recommendations and best practices as to why they are such. I can kick out a one-off anytime I need to do so, and learn as I go; but that does not mean what I have produced will be easily adaptable or even useful to anyone else. Not a waste of time if what is needed was produced and the problem solved, but if more use can be gained by someone else or the code more stable and efficient, all the better. But standards and experienced mentors make for a better product whether spin, PASM or C.
I realize this may be a bit "rambly", but the heavy hitters seem to be well represented in this thread. Perhaps they could collaborate on recommendations for gold standard code either live or via PM to the benefit of all of us.
Frank
Sorry 'bout that, seems this ended up quite a ways down the thread from where it started, multiple stops and distractions and hours along the way.
The ICC mouse driver would work with Propeller GCC with very few changes. Same goes for most of those drivers.
Among those drivers, one also finds I2C, ADC3208, MEMS2125, Graphics, Keyboard, and a WiiNunchuck driver.
Yes, lots of work has already been done.
C drivers should be written to show that Parallax has a C friendly solution for Propeller.
C drivers should be written to show that Parallax has a C friendly solution for Propeller.
That has already been demonstrated - by ICC, Catalina, Zog and CSPIN (to name just the most obvious ones). I guess you missed the point of my previous post - which was that (and I'm paraphrasing myself heavily here) this thread may provide us a good opportunity to address the obvious lack of standards in the area of device drivers - something that would make the Propeller much more atrtractive to potential users.
That has already been demonstrated - by ICC, Catalina, Zog and CSPIN (to name just the most obvious ones). I guess you missed the point of my previous post
Never before has one had the ability to write a COG program in C - that makes Propeller more C friendly. That was the point of the post fragment you quoted.
Never before has one had the ability to write a COG program in C - that makes Propeller more C friendly. That was the point of the post fragment you quoted.
If this thread is to be only about drivers that can be written in C, then at least it should be refreshingly short!
Perhaps but it lays down a challenge and opens up a whole new hobby - how much functionality can one create in C and squeeze into a COG?
A good question - but is it really pertinent to this thread? I thought this thread was about writing drivers that could be used from C programs?
The confusion seems to arise because Daniel was himself a bit unclear about what he intended in his original post - it is obviously incorrect to claim (as he does) that "we will need to rewrite some of our drivers in C/C++ so that they can be used with other C/C++ programs", since all the available C solutions are perfectly capable of using any of the existing OBEX drivers (or at least Catalina is - but the mechanism it uses could also be used by the other C compilers).
However, as he doesn't seem interested in clarifying, I guess you guys are free to take this thread in any direction you want
"...all the available C solutions are perfectly capable of using any of the existing OBEX drivers"
What?
Not sure I get your drift. Most OBEX drivers are written in Spin/PASM and definitely not useable from C without some minor or major rework.
Do you:
1) Pull out the PASM part, assemble it to a blob. Then rewrite the Spin part in C. Which may require tweaking the PASM part to remove any "linkage" from PASM to Spin as discussed already.
2) Setup some way to run the Spin interpreter and hence the Spin object you want to use.
Both of those are yukky. 1) because you need to assemble the PASM with BSTC or such to extract the binary blob. 2) because, well, the whole point is to have a C solution not mash up of C and Spin.
I'd like to think this thread is all about getting "devices", "drivers", "objects", what ever you want to call them, that can be built with the GCC tool chain. C, C++ or assembler where needed. If the results are some kind of agreement on standard interfaces that can be used by different compilers/languages all the better.
"...all the available C solutions are perfectly capable of using any of the existing OBEX drivers"
What?
Not sure I get your drift. Most OBEX drivers are written in Spin/PASM and definitely not useable from C without some minor or major rework.
Perhaps you haven't tried a recent version of Catalina? There are demos included for using any of the standard Spin/PASM drivers from C - you can even use them as replacements for the stdio drivers. The mechanism used could easily be adapted for use by other C compilers.
Do you:
1) Pull out the PASM part, assemble it to a blob. Then rewrite the Spin part in C. Which may require tweaking the PASM part to remove any "linkage" from PASM to Spin as discussed already.
2) Setup some way to run the Spin interpreter and hence the Spin object you want to use.
Both of those are yukky. 1) because you need to assemble the PASM with BSTC or such to extract the binary blob. 2) because, well, the whole point is to have a C solution not mash up of C and Spin.
(2) - but I disagree it is "yucky" since it allows you to re-use existing code without forcing you to rewrite everything in C. I'm a strong C proponent, but even I don't understand this recent insistence that everything be written in C - for a start, it is simply not possible (I'll believe otherwise if someone can rewrite one of Chip's VGA drivers in C!).
This degree of C "purity" is simply not realistic - even in the world where GCC originated (i.e. Linux) many drivers (or significant parts thereof) are still written in assembly. Ok, you could claim that a C "wrapper" program around some inline assembly is still "C" - but that's bending the truth to the point of absurdity!
I'd like to think this thread is all about getting "devices", "drivers", "objects", what ever you want to call them, that can be built with the GCC tool chain. C, C++ or assembler where needed.
Ok - but why? As shown above, it isn't necessary. It isn't even particularly desirable unless you also plan to (1) rewrite all existing OBEX drivers in C, and (2) insist that everyone write all new drivers in C. But if this were the case, then this thread would seem to be unnecessary!
As a non C programmer, I would simply want a situation (similar to Spin) where I can write a program and include "objects" that enable my program to use "devices" (e.g. TV, serial, ADC, LCD, etc). I don't care what language those "objects" are written in - they're just "black boxes" - but my ideal world would allow me to use those same "objects" in Spin, C, and PropBASIC.
I personally feel that the above would be easier to achieve if the "objects" were written to some standard, maybe allowing others to write wrappers in their preferred language. As it now looks like we're about to re-invent several wheels, perhaps now is the time to agree the standards?
I was aware of Catalina's ability to use Spin objects. Zog can do it to all be it
in not such an clean way.
Yucky or not the idea behind Prop GCC, if I understand correctly, was to appeal to that group
so called "professionals" for who Spin might not be attractive. I have this feeling that mixing C and Spin
is like getting hold of C compiler for the PC and then finding I have to use BASIC for a lot of stuff.
Having said that, Spin on the Prop it has advantages due to the limited memory space and the large size of
C compiled to PASM instructions vs the compact nature of Spin byte codes.
Then again the Prop II is going to have a lot more space and not going to have a Spin
interpreter in ROM so pure C/C++/gas solutions become more attractive.
Did anyone really suggest rewriting Chip's VGA drivers in C? As you say that degree of C purity is not
realistic. I suspect the thing to do is cast the PASM parts into GCC assembler (gas)
syntax and rewrite the Spin wrapper object in C or C++.
Hey guys! In bringing a new language to the Propeller (C and C++ for those who have been away), it occurs to me that we will need to rewrite some of our drivers in C/C++ so that they can be used with other C/C++ programs.
So, quick question: what drivers do you guys think would be useful in a C/C++ driver library? If I get some good suggestions, we will likely need them written - and "prizes" would be issued for professionally done code.
On my needed driver list so far, I have the following:
Asynchronous Serial (like Full Duplex Serial) (may already be done)
Keyboard / Mouse
TV / TV Text
VGA / VGA Text
I2C
SPI
Sigma - Delta ADC driver (this one may require some special sauce)
Clock (a good timing driver)
Servo Controller
Stepper Motor Controller
Real Random
PID Controller
If there is something you would like to see, post it here so we can write it !
Hi,
The Sigma Delta ADC Driver is ported. See Alpha Test Forum -> Device IO Library -> Reply #9
Wow! Religion and Politics have nothing on C when it comes to things NOT to discuss!
I think a lot of the answers to Daniel's question go back to Parallax and what they want to present with PropGCC and the chosen C,C++ Propeller environment. With the choice of GCC, a lot of decisions have been made and the course set as far as standards and the implementation/deployment platform. IDE selection is still up for grabs. Discussion as to who's C compiler can do what or why one choice is better than another is pretty much a bunch of hot air at this point.
I'm not a professional engineer but I'm going to pretend for the sake of this discussion.
1) What does Parallax want to present to a professional engineering looking to use or evaluate the Propeller? A C, C++ environment based on a standard, widely accepted, well understood tool chain that shows an engineer how to possibly solve their engineering problems with Parallax solutions (face it folks, Parallax won't be here for us if they don't sell products and grow). If I'm looking for a solution as an engineer AND I know C or C++, I probably don't want to learn SPIN and PASM and Propeller architecture details in order to evaluate a product and try things on the Propeller environment. I'll dig into C libraries, maybe learn some PASM (since I understand the importance of assembler in embedded solutions). But if I run into examples that use SPIN or lots of PASM, I'm going to get frustrated, decide I don't have the time for this and go elsewhere. That's not how/why this effort should fail.
2) What libraries and examples need to be bundled with the tools? This gets down to the meat of the question. I see at least three (maybe four) distinct sets of libraries and demos:
- A) Basic tutorials for learning PropGCC and the Propeller (C versions of the education curriculum to learn Propeller programming in C). For this, someone is already struggling with the Propeller and C, you really don't want to introduce SPIN (except as an appendix on how to interface existing code) or PASM (until it is needed to exploit speed and size). There should also be a C/PASM/Architecture tutorial/workbook/curriculum to replace "What's a Micro-processor"....but that's just me.
- A C, C++ library to show an engineer how to work with and exploit the Propeller architecture and features. They are coming from an interrupt driven, single core, flat memory model for most parts with multiple built in hardware peripherals. How do you get them from what they know to the Propeller world with little pain while showing them it's possibly a better solution for some of their engineering problems? How can I leverage multiple COGs, How can I use soft-peripherals? (provide example code in C for these), How can I leverage the various memory models and why? How can I run my real-time, timing sensitive world without interrupts (with C examples). I need a micro to talk I2C, SPI, serial, etc., How can I do that easily? (provide standard C examples for these) This items also needs to set the interface standards particular to the Propeller hardware - some of it may be able to be abstracted to existing C standards, others may need to have Parallax standards set due the overhead sometimes incurred by abstraction. At some point a micro engineer needs to learn ugly details but I think you can give them one heck of a good Propeller demo without taking them too far away from the C confort zone.
- C) Parallax really has a good set of sensors and hardware thingies you can attach to Propellers. If you provide basic driver code for these in C,C++, PASM that integrate into the PropGCC environment and models, you can sell more of these!! The solution needed may be the $30 peripheral, using the Prop and leveraging it may be the gravy that hooks someone on the Prop for future solutions. Sell solutions, not technical details and data sheets.
- D) lastly, to point C, the peripherals and thingies can be used by other microprocessors...most of these other guys support C and/or C++ provide example drivers to let someone easily use this hardware on a Arduino, PIC, ATMEL, TI, Beagle Board, etc. Buy the peripheral, grab the C driver, modify it as needed for my environment, and I have a solution. If there are nuances to using the hardware, include it in the driver so they can see how to deal with it.
As an example, I bought a Pololu 3pi robot as part of Black Friday (I also bought 2 x S2s, so I'm sharing the love).
It's pre-loaded demo program has a slave mode that accepts command across the serial interface. If you don;t want to do ATMEL ACR or Arduino programming, read about the slave commands, hook your favorite micro-P onto the serial pins and start talking. Line-tracking experimental robot driven by a QuickStart running PropForth. WITHOUT having to learn AVR details or Arduino details. Problem Solved.
If I do want to program in a mode more native to the 3pi, they provide C and C++ libraries to expose and exploit the 3pi hardware. I can do that thru C and WINAVR with a very shallow learning curve. Another problem solved.
From the looks of this thread things have gotten a little off topic. While I understand some of the comments and discussion surrounding this thread, having this discussion in this thread dillutes the thread and obscures the answers Daniel was looking for. His questions was, "What drivers do you guys think would be useful in a C/C++ driver library?" If we could please limit responses in this thread to what drivers you would like to see, or which objects he listed may need to be converted, it will help out greatly.
The other discussions in this thread should really migrate to a new thread with a subject indicating what the discussion is about and how it is related. Perhaps something useful may even come of that, but we really need to try and stay on topic for continuity. Thanks everyone!
I think the intent is to have a C/C++ object library that contains the basic drivers that Daniel listed. This is something that C programmers could link to without having to compile it themselves. Of course, the source would be available as well if someone needed to create a different version that supported additional features or removed features to save space.
Some drivers are already part of the C stdio library, such as serial console I/O and file I/O. Some of the other devices that Daniel listed could be added to the stdio library, such as VGA/TV text, keyboard and EEPROM. However, they could also have a device-specific API, which could be essentially the same as the Spin API. Most of the other devices would probably be accessed through the API.
I think for the most part this is just a matter of translating the Spin code to C. The PASM code could be left as is. It can be assembled by bstc and converted to a C file that contains the assembled output as hex codes. Or the PASM code could be converted to GAS assembly code. GAS assembly is almost the same as PASM except for the handling of labels, and a few assembler directives.
From the looks of this thread things have gotten a little off topic. While I understand some of the comments and discussion surrounding this thread, having this discussion in this thread dillutes the thread and obscures the answers Daniel was looking for. His questions was, "What drivers do you guys think would be useful in a C/C++ driver library?" If we could please limit responses in this thread to what drivers you would like to see, or which objects he listed may need to be converted, it will help out greatly.
The other discussions in this thread should really migrate to a new thread with a subject indicating what the discussion is about and how it is related. Perhaps something useful may even come of that, but we really need to try and stay on topic for continuity. Thanks everyone!
Hi Chris,
No worries - although if Daniel was only interested in GCC drivers then he should probably have posted in the GCC forum. I thought he may be interested in having drivers that could be used in any C programs. Which then raises the point of "why just C programs ...?" Why do we have to reinvent the wheel each time a new language is added to the Propeller? If a few people put a little effort into developing a sensible common standard, we could all adopt it.
Anyway, to get back to the topic (and add one to Daniel's original list), I'd add a version of the standard Parallax TV graphics driver. The output of this driver is used in many Parallax promo pictures - not having it available from C would look a little odd.
I think the intent is to have a C/C++ object library that contains the basic drivers that Daniel listed. This is something that C programmers could link to without having to compile it themselves. Of course, the source would be available as well if someone needed to create a different version that supported additional features or removed features to save space.
Some drivers are already part of the C stdio library, such as serial console I/O and file I/O. Some of the other devices that Daniel listed could be added to the stdio library, such as VGA/TV text, keyboard and EEPROM. However, they could also have a device-specific API, which could be essentially the same as the Spin API. Most of the other devices would probably be accessed through the API.
I think for the most part this is just a matter of translating the Spin code to C. The PASM code could be left as is. It can be assembled by bstc and converted to a C file that contains the assembled output as hex codes. Or the PASM code could be converted to GAS assembly code. GAS assembly is almost the same as PASM except for the handling of labels, and a few assembler directives.
Thanks Dave - I'm glad to see I'm not the only one confused by the intent of this thread!
Did anyone really suggest rewriting Chip's VGA drivers in C? As you say that degree of C purity is not
realistic. I suspect the thing to do is cast the PASM parts into GCC assembler (gas)
syntax and rewrite the Spin wrapper object in C or C++.
VGA and VGA Text drivers are on Daniel's original list - I assumed he meant Chip's driver, but actually I'd be impressed if you could port any of them to C.
Am I the only one that feels it's silly to rewrite perfectly good PASM as C, for the sake of writing it as C? Why not rewrite those objects to replace the SPIN with C?
Am I the only one that feels it's silly to rewrite perfectly good PASM as C, for the sake of writing it as C? Why not rewrite those objects to replace the SPIN with C?
pedward,
No, indeed! At the risk of getting Chris offside again, I think a lot of people would agree with you.
I understand GCC wants to show off it's ability to generate C code that runs in a cog, but in most cases it makes more sense to just re-use the existing PASM code. I'd just like to see a standardized way of communicating from the higher level interpreted or LMM language components (written in Spin, C, C++ or anything else) with the cog components (written in C or PASM).
And I know it sounds a bit self-serving but I have to point out that Catalina already has one that can work for all drivers, and currently can be used both from Spin and C!
In order not to derail this thread further, I will start a new thread specifically about this subject. Let's take this particular conversation here.
Am I the only one that feels it's silly to rewrite perfectly good PASM as C, for the sake of writing it as C? Why not rewrite those objects to replace the SPIN with C?
Rewriting some drivers in C makes sense, if you can spare a cog. In Spin you always need to start another cog if you need the speed of PASM. Many drivers then start a PASM routine from Spin and just wait until this routine has finished. Because C (and any LMM language) is faster, you don't need to waste another cog just to get some more speed. Examples are: 400kHz I2C driver , some SPI drivers, serial drivers (if you don't need fullduplex, but only higher baudrates), One-Wire drivers and so on.
For sure it makes not much sense to rewrite the PASM part of TV or VGA drivers in C.
The first step in translating Spin to C is to split objects into separate Spin and Pasm parts. Then next, translate the Spin to C.
Splitting the code is easier for some than for others. The hard part is being absolutely certain that the original author has not added in extra variables for pasm/spin communications.
Attached are nine objects that have been split. Fullduplexserial, keyboard, mouse, trig functions, three VGA text drivers, Kye's 160x120 graphics driver and the dracblade memory driver.
Once these have been split, I have compiled the pasm part to a binary file and put this on an sd card. Then cogs can all be loaded through the same 2k memory block, which saves just under half the hub ram and allows much larger spin programs.
The same concept would apply to C.
The "catch" to this concept is you then need code to access an SD card, though there is no reason these precompiled cog files could not be stored on an eeprom.
From the looks of this thread things have gotten a little off topic. While I understand some of the comments and discussion surrounding this thread, having this discussion in this thread dillutes the thread and obscures the answers Daniel was looking for. His questions was, "What drivers do you guys think would be useful in a C/C++ driver library?" If we could please limit responses in this thread to what drivers you would like to see, or which objects he listed may need to be converted, it will help out greatly.
The other discussions in this thread should really migrate to a new thread with a subject indicating what the discussion is about and how it is related. Perhaps something useful may even come of that, but we really need to try and stay on topic for continuity. Thanks everyone!
Hrmm... I feel I may have helped drift this off-topic. (Really sorry for that guys). I have been a long-time lurker but just recently posted because I feel an urgent need for common driver standards on the new C platform. I feel if those standards aren't developed now, they never will be, and that will have ramifications for me professionally. The heading of this thread that people put forward ideas for drivers makes me fear there will be drivers on a case by case basis, and I believe this is fundamentally intractable for commercial development. This last point is pretty serious.
My impression is that the gcc port is being done to facilitate commercial development; if that is really a goal then just using the Spin paradigm of lots of highly-specialized objects is a no-go for me. The issue is when writing software one always has lots of drivers interfacing with higher level code and nobody wants to be rewriting driver hooks all the time. If I have to re-hook all the driver calls and trust a different implementer's code and style of accessing hardware functions every time I change specific ADC chips, LCDs, or whatever, I won't be able to really trust the codebase. Given the unique architecture of the Prop and its memory model, writing abstract interfaces for specific hardware drivers that are already written and having them perform well might be non-trivial.
My unfortunate word choice of "kernel" really could be summed up in having common abstract C driver data structures guided by Parallax which then can interface with lower-level implementations. A hypothetical ADC should be able to be interfaced with an abstraction that can call a low-level vendor specific implementation of the driver. I recognize there are limits to what can be done with certain hardware classes, but if abstraction is to be done at all it's better to be when the software for the driver is written.
My fear is anarchy in driver implementation and no real improvement in the development environment of gcc over Spin or Catalina. Which is a shame, because the flexibility of the prop lends itself to better standards, dynamism and abstraction than other micros.
If someone more knowledgeable about the direction of GCC and/or C on the Prop feels this is worthy of its own thread, I'd be willing to talk about it further there.
* By the way Ross, thank you for your work on Catalina--I really appreciate it.
If someone more knowledgeable about the direction of GCC and/or C on the Prop feels this is worthy of its own thread, I'd be willing to talk about it further there.
Hi Aaron. I started a new thread that sounds more like what you are interested in, because I'm interested also - look here.
I like to think I am a pretty straight forward person, especially when there is the potential for ambiguity (such as in a forum thread). I was/am very happy to have read everybody's contributions in this thread - you guys give me perspective from so many unique frames of reference. It is quite refreshing . However, I did not intend for my post to be read into so deeply. You guys brought up some very "philosophical" questions (with respect to programming practices) about the way Parallax wants to take it's library of C objects/drivers/devices/whatever. Instead of trying to figure out a hidden meaning in my post, just take it at face value. Parallax is looking for some input about what objects/drivers the community deems useful to have in a standardized library.
The way I'd like to see our C/C++ library taken is the way of code re-use. Of course, the Propeller doesn't have an operating system that abstracts the hardware from the software developer, but that doesn't mean that device driver files can't be written in such a way so as to allow for interchangeability. In the end, I believe that was part of the original spirit in which the Propeller was created for. As for the specifics of implementation, I don't really think it matters how its done - C wrapper around PASM, mailboxes to pass things to/from a Spin cog, written completely in C, etc. - as long as it works well and is written with reuse in mind. The library that gets distributed with the PropGCC package will be maintained by Parallax [Semiconductor] directly. This library will be as straight forward, bug-free, and documented as possible.
Everybody's suggestions so far have been recorded. If anybody else has something they'ed like to see, keep the posts coming .
Comments
This isn't out of scope though. A kernel isn't an operating system, it's a way of linking modular drivers. Since this forum is all about drivers, I think it's really just a no-brainer that a primitive kernel might make sense given that C is now becoming standardized for the Prop. Writing better code and less of it is all this about.
That is all.
-Phil
Not quite true. The C language requires more "devices" than just stdin, stdout (and stderr) - it is just that some of the others are not mentioned explicitly. For example, it requires a clock device. It requires a mass storage device. It requires a floating point device (remember that floating point co-processors are often separate hardware).
However, the point I think you are making is certainly true in essence - i.e. that there is a limited number of devices mandated by the C language. I think all the available C compilers have probably already achieved this minimum subset.
But I think what we are talking about here is the "additional" devices that we would like to have access to on the Propeller, and (by extension) how we should support them. A mouse is a perfect example. This is a fairly easy device to implement, and is also highly desirable since the necessary hardware is built-in to many Propeller boards. Also, there are several good versions already available in the OBEX. This is a perfect example to discuss in this thread because it is on Daniel's original list, it is not one of the devices "mandated" by the C language, and also (AFAIK) GCC does not yet support it.
We could define a new architecture that solves the problem for both "mandated" and "non-mandated" devices, but is this the real point? As a user I don't really care (and why should I?) about the internal implementation of any of the "mandated" devices supported by my C compiler - that's for the compiler developers to worry about. I mostly want to know about all the other cool devices I may want or need to add. Especially in an embedded environment where - unlike an O/S environment like Linux, where this is the arcane domain of kernel developers - as a normal user I routinely expect to add new devices for every new project as part of my development process.
So let's think about a mouse driver in particular - it might help clarify the purpose of this thread. Is it that we want to ...
- Write a mouse driver entirely in C? (why - to show it can be done? Well, in this case I think it probably can - but this does not mean all drivers can or should be)
- Write a common C "wrapper" that can be used with different mouse drivers (this is probably the one that ordinary users would be most interested in).
- Re-use one or more of the existing OBEX mouse drivers? (this is not quite the same as the previous point, but it is related - and if this is not the goal of this particular thread, it is probably important enough that it should be discussed separately anyway)
- Define a driver interface that would allow any mouse driver to be used from any language - C, C++, SPIN, BASIC or FORTH - by "hiding" the details behind a common interface that takes advantage of the Propeller's unique abilities and limitations (this is what I would like to see this thread discuss!)
- All of the above!
Daniel? It's your thread - you choose!Ross.
This reply may be part in and out of band to this thread, but here it is anyway.
I discovered the prop purely by accident while starting the planning stages of a potential research project which is still in the waiting for grants stages as some components are rather beyond the garage developer. I jumped in with both feet to learn anyway, paying little attention to the depth markings on the pool as it looked like there were swimmers at all levels in the pool. I did ask one member to have a look at my ADC object for the purposes of a sort of a peer review, but like most of us was likely just too busy making ends meet to have time then. So as I've heard no raspberries over it, I had to assume it not only met my needs for it, but may be fit for consumption at some level; to the OBEX with it. Same for my three-wire LCD object. Unfortunately, this is the first I have heard of some preferred standard and some ways of doing things making other uses difficult.
Perhaps someone(s) with experience here could create or point us who are new to the propeller and Parallax to a sort of FAQ page containing such things as where to find things like DaSilva's PASM tutorial or the Potato Head Papers, and some level of documentation or discussions of preferred standards rather than leaving it to chance discovery. maybe automatically deliver it when someone registers. It should include information on preferred standards or at least recommendations and best practices as to why they are such. I can kick out a one-off anytime I need to do so, and learn as I go; but that does not mean what I have produced will be easily adaptable or even useful to anyone else. Not a waste of time if what is needed was produced and the problem solved, but if more use can be gained by someone else or the code more stable and efficient, all the better. But standards and experienced mentors make for a better product whether spin, PASM or C.
I realize this may be a bit "rambly", but the heavy hitters seem to be well represented in this thread. Perhaps they could collaborate on recommendations for gold standard code either live or via PM to the benefit of all of us.
Frank
Sorry 'bout that, seems this ended up quite a ways down the thread from where it started, multiple stops and distractions and hours along the way.
Among those drivers, one also finds I2C, ADC3208, MEMS2125, Graphics, Keyboard, and a WiiNunchuck driver.
Yes, lots of work has already been done.
C drivers should be written to show that Parallax has a C friendly solution for Propeller.
That has already been demonstrated - by ICC, Catalina, Zog and CSPIN (to name just the most obvious ones). I guess you missed the point of my previous post - which was that (and I'm paraphrasing myself heavily here) this thread may provide us a good opportunity to address the obvious lack of standards in the area of device drivers - something that would make the Propeller much more atrtractive to potential users.
Ross.
If this thread is to be only about drivers that can be written in C, then at least it should be refreshingly short!
Ross.
Perhaps but it lays down a challenge and opens up a whole new hobby - how much functionality can one create in C and squeeze into a COG?
A good question - but is it really pertinent to this thread? I thought this thread was about writing drivers that could be used from C programs?
The confusion seems to arise because Daniel was himself a bit unclear about what he intended in his original post - it is obviously incorrect to claim (as he does) that "we will need to rewrite some of our drivers in C/C++ so that they can be used with other C/C++ programs", since all the available C solutions are perfectly capable of using any of the existing OBEX drivers (or at least Catalina is - but the mechanism it uses could also be used by the other C compilers).
However, as he doesn't seem interested in clarifying, I guess you guys are free to take this thread in any direction you want
Ross.
"...all the available C solutions are perfectly capable of using any of the existing OBEX drivers"
What?
Not sure I get your drift. Most OBEX drivers are written in Spin/PASM and definitely not useable from C without some minor or major rework.
Do you:
1) Pull out the PASM part, assemble it to a blob. Then rewrite the Spin part in C. Which may require tweaking the PASM part to remove any "linkage" from PASM to Spin as discussed already.
2) Setup some way to run the Spin interpreter and hence the Spin object you want to use.
Both of those are yukky. 1) because you need to assemble the PASM with BSTC or such to extract the binary blob. 2) because, well, the whole point is to have a C solution not mash up of C and Spin.
I'd like to think this thread is all about getting "devices", "drivers", "objects", what ever you want to call them, that can be built with the GCC tool chain. C, C++ or assembler where needed. If the results are some kind of agreement on standard interfaces that can be used by different compilers/languages all the better.
This degree of C "purity" is simply not realistic - even in the world where GCC originated (i.e. Linux) many drivers (or significant parts thereof) are still written in assembly. Ok, you could claim that a C "wrapper" program around some inline assembly is still "C" - but that's bending the truth to the point of absurdity! Ok - but why? As shown above, it isn't necessary. It isn't even particularly desirable unless you also plan to (1) rewrite all existing OBEX drivers in C, and (2) insist that everyone write all new drivers in C. But if this were the case, then this thread would seem to be unnecessary! Yes, that's what I would like to see also - but this has little to do with any specific compiler - for any language.
Ross.
As a non C programmer, I would simply want a situation (similar to Spin) where I can write a program and include "objects" that enable my program to use "devices" (e.g. TV, serial, ADC, LCD, etc). I don't care what language those "objects" are written in - they're just "black boxes" - but my ideal world would allow me to use those same "objects" in Spin, C, and PropBASIC.
I personally feel that the above would be easier to achieve if the "objects" were written to some standard, maybe allowing others to write wrappers in their preferred language. As it now looks like we're about to re-invent several wheels, perhaps now is the time to agree the standards?
I was aware of Catalina's ability to use Spin objects. Zog can do it to all be it
in not such an clean way.
Yucky or not the idea behind Prop GCC, if I understand correctly, was to appeal to that group
so called "professionals" for who Spin might not be attractive. I have this feeling that mixing C and Spin
is like getting hold of C compiler for the PC and then finding I have to use BASIC for a lot of stuff.
Having said that, Spin on the Prop it has advantages due to the limited memory space and the large size of
C compiled to PASM instructions vs the compact nature of Spin byte codes.
Then again the Prop II is going to have a lot more space and not going to have a Spin
interpreter in ROM so pure C/C++/gas solutions become more attractive.
Did anyone really suggest rewriting Chip's VGA drivers in C? As you say that degree of C purity is not
realistic. I suspect the thing to do is cast the PASM parts into GCC assembler (gas)
syntax and rewrite the Spin wrapper object in C or C++.
Hi,
The Sigma Delta ADC Driver is ported. See Alpha Test Forum -> Device IO Library -> Reply #9
Nice Weekend
Reinhard
I think a lot of the answers to Daniel's question go back to Parallax and what they want to present with PropGCC and the chosen C,C++ Propeller environment. With the choice of GCC, a lot of decisions have been made and the course set as far as standards and the implementation/deployment platform. IDE selection is still up for grabs. Discussion as to who's C compiler can do what or why one choice is better than another is pretty much a bunch of hot air at this point.
I'm not a professional engineer but I'm going to pretend for the sake of this discussion.
1) What does Parallax want to present to a professional engineering looking to use or evaluate the Propeller? A C, C++ environment based on a standard, widely accepted, well understood tool chain that shows an engineer how to possibly solve their engineering problems with Parallax solutions (face it folks, Parallax won't be here for us if they don't sell products and grow). If I'm looking for a solution as an engineer AND I know C or C++, I probably don't want to learn SPIN and PASM and Propeller architecture details in order to evaluate a product and try things on the Propeller environment. I'll dig into C libraries, maybe learn some PASM (since I understand the importance of assembler in embedded solutions). But if I run into examples that use SPIN or lots of PASM, I'm going to get frustrated, decide I don't have the time for this and go elsewhere. That's not how/why this effort should fail.
2) What libraries and examples need to be bundled with the tools? This gets down to the meat of the question. I see at least three (maybe four) distinct sets of libraries and demos:
- A) Basic tutorials for learning PropGCC and the Propeller (C versions of the education curriculum to learn Propeller programming in C). For this, someone is already struggling with the Propeller and C, you really don't want to introduce SPIN (except as an appendix on how to interface existing code) or PASM (until it is needed to exploit speed and size). There should also be a C/PASM/Architecture tutorial/workbook/curriculum to replace "What's a Micro-processor"....but that's just me.
-
- C) Parallax really has a good set of sensors and hardware thingies you can attach to Propellers. If you provide basic driver code for these in C,C++, PASM that integrate into the PropGCC environment and models, you can sell more of these!! The solution needed may be the $30 peripheral, using the Prop and leveraging it may be the gravy that hooks someone on the Prop for future solutions. Sell solutions, not technical details and data sheets.
- D) lastly, to point C, the peripherals and thingies can be used by other microprocessors...most of these other guys support C and/or C++ provide example drivers to let someone easily use this hardware on a Arduino, PIC, ATMEL, TI, Beagle Board, etc. Buy the peripheral, grab the C driver, modify it as needed for my environment, and I have a solution. If there are nuances to using the hardware, include it in the driver so they can see how to deal with it.
As an example, I bought a Pololu 3pi robot as part of Black Friday (I also bought 2 x S2s, so I'm sharing the love).
It's pre-loaded demo program has a slave mode that accepts command across the serial interface. If you don;t want to do ATMEL ACR or Arduino programming, read about the slave commands, hook your favorite micro-P onto the serial pins and start talking. Line-tracking experimental robot driven by a QuickStart running PropForth. WITHOUT having to learn AVR details or Arduino details. Problem Solved.
If I do want to program in a mode more native to the 3pi, they provide C and C++ libraries to expose and exploit the 3pi hardware. I can do that thru C and WINAVR with a very shallow learning curve. Another problem solved.
OK, I'm done.
Thanks, Bye!
From the looks of this thread things have gotten a little off topic. While I understand some of the comments and discussion surrounding this thread, having this discussion in this thread dillutes the thread and obscures the answers Daniel was looking for. His questions was, "What drivers do you guys think would be useful in a C/C++ driver library?" If we could please limit responses in this thread to what drivers you would like to see, or which objects he listed may need to be converted, it will help out greatly.
The other discussions in this thread should really migrate to a new thread with a subject indicating what the discussion is about and how it is related. Perhaps something useful may even come of that, but we really need to try and stay on topic for continuity. Thanks everyone!
Some drivers are already part of the C stdio library, such as serial console I/O and file I/O. Some of the other devices that Daniel listed could be added to the stdio library, such as VGA/TV text, keyboard and EEPROM. However, they could also have a device-specific API, which could be essentially the same as the Spin API. Most of the other devices would probably be accessed through the API.
I think for the most part this is just a matter of translating the Spin code to C. The PASM code could be left as is. It can be assembled by bstc and converted to a C file that contains the assembled output as hex codes. Or the PASM code could be converted to GAS assembly code. GAS assembly is almost the same as PASM except for the handling of labels, and a few assembler directives.
Hi Chris,
No worries - although if Daniel was only interested in GCC drivers then he should probably have posted in the GCC forum. I thought he may be interested in having drivers that could be used in any C programs. Which then raises the point of "why just C programs ...?" Why do we have to reinvent the wheel each time a new language is added to the Propeller? If a few people put a little effort into developing a sensible common standard, we could all adopt it.
Anyway, to get back to the topic (and add one to Daniel's original list), I'd add a version of the standard Parallax TV graphics driver. The output of this driver is used in many Parallax promo pictures - not having it available from C would look a little odd.
Ross.
Thanks Dave - I'm glad to see I'm not the only one confused by the intent of this thread!
Ross.
VGA and VGA Text drivers are on Daniel's original list - I assumed he meant Chip's driver, but actually I'd be impressed if you could port any of them to C.
Ross.
pedward,
No, indeed! At the risk of getting Chris offside again, I think a lot of people would agree with you.
I understand GCC wants to show off it's ability to generate C code that runs in a cog, but in most cases it makes more sense to just re-use the existing PASM code. I'd just like to see a standardized way of communicating from the higher level interpreted or LMM language components (written in Spin, C, C++ or anything else) with the cog components (written in C or PASM).
And I know it sounds a bit self-serving
In order not to derail this thread further, I will start a new thread specifically about this subject. Let's take this particular conversation here.
Ross.
Rewriting some drivers in C makes sense, if you can spare a cog. In Spin you always need to start another cog if you need the speed of PASM. Many drivers then start a PASM routine from Spin and just wait until this routine has finished. Because C (and any LMM language) is faster, you don't need to waste another cog just to get some more speed. Examples are: 400kHz I2C driver , some SPI drivers, serial drivers (if you don't need fullduplex, but only higher baudrates), One-Wire drivers and so on.
For sure it makes not much sense to rewrite the PASM part of TV or VGA drivers in C.
Andy
Splitting the code is easier for some than for others. The hard part is being absolutely certain that the original author has not added in extra variables for pasm/spin communications.
Attached are nine objects that have been split. Fullduplexserial, keyboard, mouse, trig functions, three VGA text drivers, Kye's 160x120 graphics driver and the dracblade memory driver.
Once these have been split, I have compiled the pasm part to a binary file and put this on an sd card. Then cogs can all be loaded through the same 2k memory block, which saves just under half the hub ram and allows much larger spin programs.
The same concept would apply to C.
The "catch" to this concept is you then need code to access an SD card, though there is no reason these precompiled cog files could not be stored on an eeprom.
The task is to then translate Spin to C.
Hrmm... I feel I may have helped drift this off-topic. (Really sorry for that guys). I have been a long-time lurker but just recently posted because I feel an urgent need for common driver standards on the new C platform. I feel if those standards aren't developed now, they never will be, and that will have ramifications for me professionally. The heading of this thread that people put forward ideas for drivers makes me fear there will be drivers on a case by case basis, and I believe this is fundamentally intractable for commercial development. This last point is pretty serious.
My impression is that the gcc port is being done to facilitate commercial development; if that is really a goal then just using the Spin paradigm of lots of highly-specialized objects is a no-go for me. The issue is when writing software one always has lots of drivers interfacing with higher level code and nobody wants to be rewriting driver hooks all the time. If I have to re-hook all the driver calls and trust a different implementer's code and style of accessing hardware functions every time I change specific ADC chips, LCDs, or whatever, I won't be able to really trust the codebase. Given the unique architecture of the Prop and its memory model, writing abstract interfaces for specific hardware drivers that are already written and having them perform well might be non-trivial.
My unfortunate word choice of "kernel" really could be summed up in having common abstract C driver data structures guided by Parallax which then can interface with lower-level implementations. A hypothetical ADC should be able to be interfaced with an abstraction that can call a low-level vendor specific implementation of the driver. I recognize there are limits to what can be done with certain hardware classes, but if abstraction is to be done at all it's better to be when the software for the driver is written.
My fear is anarchy in driver implementation and no real improvement in the development environment of gcc over Spin or Catalina. Which is a shame, because the flexibility of the prop lends itself to better standards, dynamism and abstraction than other micros.
If someone more knowledgeable about the direction of GCC and/or C on the Prop feels this is worthy of its own thread, I'd be willing to talk about it further there.
* By the way Ross, thank you for your work on Catalina--I really appreciate it.
Hi Aaron. I started a new thread that sounds more like what you are interested in, because I'm interested also - look here.
Ross.
I like to think I am a pretty straight forward person, especially when there is the potential for ambiguity (such as in a forum thread). I was/am very happy to have read everybody's contributions in this thread - you guys give me perspective from so many unique frames of reference. It is quite refreshing
The way I'd like to see our C/C++ library taken is the way of code re-use. Of course, the Propeller doesn't have an operating system that abstracts the hardware from the software developer, but that doesn't mean that device driver files can't be written in such a way so as to allow for interchangeability. In the end, I believe that was part of the original spirit in which the Propeller was created for. As for the specifics of implementation, I don't really think it matters how its done - C wrapper around PASM, mailboxes to pass things to/from a Spin cog, written completely in C, etc. - as long as it works well and is written with reuse in mind. The library that gets distributed with the PropGCC package will be maintained by Parallax [Semiconductor] directly. This library will be as straight forward, bug-free, and documented as possible.
Everybody's suggestions so far have been recorded. If anybody else has something they'ed like to see, keep the posts coming
Thanks all,
Daniel
Is general PWM covered by servo control?
I would also suggest a specific driver for each device Parallax supplies included in a library, as applicable.