"Interesting"? I reckon "impossible" would be more accurate - at least as far as VGA is concerned
Ross.
As I understand it, the word "impossible" in the Propeller community means "hasn't been done yet" :-). Just for the record here's Kye's 160x120x8bpp vga demo re-written completely in C (and I do mean completely, including the video driver itself which runs on another cog). (Note: this code did expose a bug in the generation of the "waitvid" instruction in the alpha gcc, so it needs the most recent version from the propgcc repository to work correctly).
To go back on-topic, this illustrates that whatever inter-cog convention we adopt has to work not just for PASM drivers, but drivers written in other languages as well. This shouldn't be a big issue for C or PASM (since C maps so closely to PASM), but are there any other languages that might be applicable?
As I understand it, the word "impossible" in the Propeller community means "hasn't been done yet" :-). Just for the record here's Kye's 160x120x8bpp vga demo re-written completely in C (and I do mean completely, including the video driver itself which runs on another cog).
To go back on-topic, this illustrates that whatever inter-cog convention we adopt has to work not just for PASM drivers, but drivers written in other languages as well. This shouldn't be a big issue for C or PASM (since C maps so closely to PASM), but are there any other languages that might be applicable?
Eric, that is very nice. It's a good demonstration of using the COG model for writing cog drivers. I didn't think it would work for a display driver, but you demonstrated that it does work.
This speaks well for the C compiler! I've tinkered with the inner loop of Kwabena's tightly-written code and found that it doesn't take more than a few added PASM instructions to bring it down. So I'm impressed!
@Daniel
You asked for comments so I will throw my thoughts in , I agree with pedward in post #53 keep it simple and replace the Spin part of objects with
C++ code and leave the PASM stuff there. Notice I did not use the term driver. I feel if this was done Parallax would have a C ie C++ syntax system
like the Arduino does and it would be easy to use for both pro's as well as hobby types. There can be a spec indicating each object has a minimum of
say a Start() and Stop() method, maybe more but keep it simple.
It scares the daylights out of me when I read people wanting to be so "C" ish that everything connected to the Propeller needs to look like a driver with
fopen() , fclose() etc. The propeller is a microcontroller not a microcomputer you would use to port an operating system to. It makes no sense to me
that every thing you interface to the Propeller in propgcc needs to look like a file . Maybe I am reading this wrong but I do not want to do fopen() on an
a/d chip or PIR sensor.
One of the big advantages for Propeller is multicore and it can look like 8 Arduino's at a time. It could be marketed like that, 8 Arduinos in one chip but
if the development envirorment is to complex and 70's C style it will not show off it's true advantage.
I also want to thank the propgcc team for there efforts and hope my comments are taken as just that, as feedback is what Alpha release is all about.
You do not have to use fopen, etc... for interface. They are used for standard library elements which can be transparent to you. It is the way we provide features to printf, etc... without having to resort to adding special compiler flags. GCC doesn't care how people write their interface code except that if you want "standard printf" output to go a certain way, the driver has to provide the functions that GCC expects. Normally you would not have to worry about such things.
It scares the daylights out of me when I read people wanting to be so "C" ish that everything connected to the Propeller needs to look like a driver with
fopen() , fclose() etc.
Comments
As I understand it, the word "impossible" in the Propeller community means "hasn't been done yet" :-). Just for the record here's Kye's 160x120x8bpp vga demo re-written completely in C (and I do mean completely, including the video driver itself which runs on another cog). (Note: this code did expose a bug in the generation of the "waitvid" instruction in the alpha gcc, so it needs the most recent version from the propgcc repository to work correctly).
To go back on-topic, this illustrates that whatever inter-cog convention we adopt has to work not just for PASM drivers, but drivers written in other languages as well. This shouldn't be a big issue for C or PASM (since C maps so closely to PASM), but are there any other languages that might be applicable?
Eric
@Dave - Display driver code just has to be fast enough in the central display line loop. The other parts of the code can be slow.
-Phil
I'm very impressed.
You asked for comments so I will throw my thoughts in , I agree with pedward in post #53 keep it simple and replace the Spin part of objects with
C++ code and leave the PASM stuff there. Notice I did not use the term driver. I feel if this was done Parallax would have a C ie C++ syntax system
like the Arduino does and it would be easy to use for both pro's as well as hobby types. There can be a spec indicating each object has a minimum of
say a Start() and Stop() method, maybe more but keep it simple.
It scares the daylights out of me when I read people wanting to be so "C" ish that everything connected to the Propeller needs to look like a driver with
fopen() , fclose() etc. The propeller is a microcontroller not a microcomputer you would use to port an operating system to. It makes no sense to me
that every thing you interface to the Propeller in propgcc needs to look like a file . Maybe I am reading this wrong but I do not want to do fopen() on an
a/d chip or PIR sensor.
One of the big advantages for Propeller is multicore and it can look like 8 Arduino's at a time. It could be marketed like that, 8 Arduinos in one chip but
if the development envirorment is to complex and 70's C style it will not show off it's true advantage.
I also want to thank the propgcc team for there efforts and hope my comments are taken as just that, as feedback is what Alpha release is all about.
Just one persons thoughts
Tom
You do not have to use fopen, etc... for interface. They are used for standard library elements which can be transparent to you. It is the way we provide features to printf, etc... without having to resort to adding special compiler flags. GCC doesn't care how people write their interface code except that if you want "standard printf" output to go a certain way, the driver has to provide the functions that GCC expects. Normally you would not have to worry about such things.
Thanks,
--Steve