Yup, as expected, stinky thread [noparse]:)[/noparse]
Code::Blocks with Mingw GNU is a close functional alternative to MSVC++.
Code::Blocks debug functionality is less useful than MSVC++ though. Both are free.
You should learn C in an environment you are familar with to accomplish tasks which you are interested in using tools which are well documented, supported and easy to use.
Personally, I first "learned" C in high school two decades ago, but I didn't really become proficient until University where I used it for both coursework and personal projects. I still have Borland's free C++ compiler installed on my work laptop for creating tools as I need them. (However, I never really got into C++. The ASM part of my brain thinks objects would generate ugly ML.)
IMHO the main advantages of C are: 1. it's relatively portable 2. the common libraries 3. fun with pointers!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
Note: you are not required to register if you download the ISO image and burn it to a disc. This was to allow deployment to PCs not on a network. [noparse][[/noparse]8^)
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
ericball said...
The ASM part of my brain thinks objects would generate ugly ML.)
I had the great idea of having a look at the code produce for some class programmed using C++ with all the "abstraction" and so on... and was almost the same code as an equivalent C portion... then I thought... what ? everything is a lie to the programmer !... then I just lost faith in OOP (it is just a lie) and well I continued using C and ASM and was happy ever after
Well you should not see much "baggage" in the asm produced by a C++ compiler.
But somewhere it has to put those jump tables that dispatch execution to the right methods of polymorphic classes. vtables. Those you would normally have to code explicitly in structs in C or somewhere anyway to do "object oriented" programming in plain C. Look at the Linux kernel it is full of such tables explicitly coded in C.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re "P.S. I particularly like how you ended up with more RAM than you started with!".. Ha ha, cue scary Theremin music, welcome to the Twilight Zone...
Re NTSC on this board, yes it can - just a matter of putting in the 4 TV driver resistors rather than the 8 VGA resistors. You end up with 4 pins free with TV which is a bonus. But TV doesn't seem as crisp at 80x40 text. Maybe I'm using the wrong driver, but TV seems better suited for graphics and VGA for text. Oh, and I haven't linked a graphics TV driver into the code, though it probably is only a couple of lines of spin. Attached picture is quite blocky and blurry on a big TV (even though the photo has smoothed it out somewhat) and on a small 4" LCD TV it is still blocky and blurry.
Getting back to the topic, RossH, would you be able to do a similar walk-through for Catalina? Maybe it is easy, but a few things are not explicitly stated, eg when you use scanf, is that scanning a local keyboard, or is it scanning a serial port talking to a terminal program that is part of Catalina, or is it something else?
In C, printf always outputs to 'standard output' and scanf always reads from 'standard input'. You don't really need to know what this means - just remember that in Catalina, 'standard output' is always the screen driver you choose to use, and 'standard input' is always the keyboard driver.
So if your board works with the standard parallax keyboard, TV and VGA drivers, it should be a simple matter of adding the appropriate pin and clock definitions for your board into the 'Catalia_Common_Input.spin' file (I'd suggest creating a new target symbol - but you could also just temporarily hack one of the existing targets such as DEMO).
Then you're good to go:
To have Catalina use the keyboard as 'standard input' and the VGA output as 'standard output':
catalina test.c -lc -D DEMO -D VGA
To have Catalina use the keyboard as 'standard input' and the TV display as 'standard output':
catalina test.c -lc -D DEMO -D TV -D NTSC
If you need help in configuring a Catalina target, point me to the spec for your board.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ok, RossH, I'm keen. And for our original poster, I have no idea what I'm doing here but maybe this walkthrough might be useful to someone if we document it as we go.
First question - you typed "catalina xxx xxx" etc
Is that in a dos window or a batch file or the Run command in Windows or something else, eg an IDE of some sort?
Where I am up to - I followed your link then downloaded all the files I could find on the first few posts and extracted them all to C:\Program Files\Catalina. There are some programs and a number of folders so the structure all seems to be there.
Re the hardware, ok, let's start from scratch and install catalina on some new hardware (though for our original poster, the hardware would presumably be the demo board. Even though the 40 pin prop is pretty cool just by itself, sooner or later you want to add a keyboard and display as a bare minimum, and the demo board comes already made).
For my hardware, VGA is P16 to P23. Keyboard is P26 and P27 (standard pins I think). No mouse. SD card is P12 to P15 (DO, CLK, DI and CS in that order). The serial port is 31,30 as per the demo board. www.smarthome.viviti.com/files/documents/Propeller_v2.pdf
Ok - I didn't realize you meant to start from quite so far back - I would encourage you to read the Catalina documents. You've probably already downloaded them - but in case you haven't they're in the 'Catalina_documents.zip' file (second post in this thread).
It sounds like you've already installed correctly, so you're nearly there. One of the documents ("Getting Started with Catalina") is a step-by-step tutorial that goes through the details you need - including setting up, compiling some demo programs, customizing the Catalina_Common_Input.spin file for your platform, and loading and running the compiled result on the Propeller. As well as details on what all the command-line options I used (VGA, NTSC etc) actually mean.
But to answer your first question - yes, these commands are entered in a Windows command interpreter. For the rest, the best thing is to read the tutorial document.
I'm at work at the moment, but this evening I'll use the PIN definitions you provided to set up a Catalina_Common_Input file you can use, and post it in this thread. Or you can have a go yourself - it's not that difficult for a simple single CPU Prop platform (it gets complex for a multi-prop platforms).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ok - lunchtime here, so I had a quick go at a 'Catalina_Input.spin' file. Save it over the existing version in 'C:\Program Files\Catalina\target\input\'.
I have called your board DR_ACULA, so what you need to do is add the following flags to all your compiles:
Great, that seems pretty straightforward. I'm at work for the next 8 hours but am looking forward to getting this "hello world" example going on another compiler.
I see you have a whole lot of spin programs in one of the folders for various hardware configurations, which I think further emphasises the point that the prop is quite a valid platform for learning C.
Correct - but you don't normally need to worry about them. Catalina builds the approproate run-time environment on every compile based on (1) the hardware pin definitions in the Catalina_Common file and (2) the options you specify on the command line.
I really should do some work on generating a Catalina_Common file that specifies ALL the common Prop boards - but the trouble is that if I don't have one then I can't actually test it. That's why I currently only say I support the Hydra, Hybrid, TriBladeProp and Morpheus - even the Demo board I've not actually tested (although I believe it will work ok).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Well I guess I need to send you one. Only catch is that I have run out, but I just got an email saying the next batch have been shipped yesterday. It would be cool to have raw C running rather than C running through CP/M with every instruction emulated. I'd be expecting a speed increase.
If you don't need any new drivers developed for your board, and the definitions I posted work ok, then you don't need to actually send me a board. Just let me know what I should call your board and I will include the definitions in all future releases of Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
A problem - I just compiled this on my Hydra, and it works fine if I make it an EMM or XMM program, but the LMM version is too large. You will probably find the same.
It seems that including 'scanf' pulls in way too much of the C library - including floating point stuff that is not necessary.
I'll investigate tomorrow and see what I can do about it.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
We have 512k of ram to store things (if you want to code the drivers to move data in and out of the ram chip, that is!) I don't know much about LMM and the other memory models - are they more suited to ram or to sd memory?
Ok, I found the problem - I was indeed pulling in floating point stuff I didn't need. Now fixed. I will release a new version of Catalina's C library tomorrow.
I didn't realize your board had addiitonal RAM available. That means you can use Catalina to build XMM programs that use the full 512k - but you'll need an XMM driver. If you want me to write you one, then I definitely will need one of your boards. But if your board uses the same XMM scheme as Cluso's boards, then Catalina may already have a suitable driver - I've written drivers for his TriBladeProp Blades #1 and #2, so if your board uses this type of access then we can use one of those. I haven't written anything for his RamBlade yet, but I seem to remember that he uses the same scheme as the TriBladeProp Blade #2.
I'll have a closer look at your hardware schematics tomorrow.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
JCee said...
I have become familiar with the Propeller+Spin, and a little Assembly over the past 2 years. ·Prior to the Propeller, I experimented with the Basic stamp, flashing LEDs.· As my exposure to microcontrollers and other embedded projects grows I find that C is the dominant language.· ·
I have read other posts asking “Is Spin hard to learn”,· my take is that once you know how to “program” learning different a syntax is not hard it just takes time.· I found the shift from Spin to ASM much harder than from Basic to Spin. ·I had to learn how to “program” all over again with Assembly.· ·
Getting on to the question; I need to learn C and I am wondering if the propeller is the right platform.· I know Catalina and ICC are available to compile C to run on the propeller but this is not the *native* language. ·
Should I try to learn C on the Propeller or (dare I say) Arduino.· ·
Don’t take this post the wrong way, I am not trying to promote another microcontroller just trying to get more tools in my toolbox.
JCee,
I think you would be better off learning C on a PC.· As someone else suggested you can download the Watcom C compiler for free.· It is a simple command-line compiler without an IDE.· Since you already know Spin you shouldn't have any trouble programming in C.· Some of your Spin programs may translate directly to C on a line-by-line basis.· You should be able to write a "Hello World" program in minutes, and you can try different things from that point.
I learned C about 20 years ago after programming in FORTRAN before that.· It was an easy transition for me, even though most of my early C programs looked a lot like FORTRAN.· The trickiest part for me was learning about pointers, and pointers to pointers.· It also took we a while to fully understand C structs.· There are still a few things in the C syntax that I have to look up on occassion, such as doing a typedef of function pointer.
Dave
Dr_Acula said...
Re NTSC on this board, yes it can - just a matter of putting in the 4 TV driver resistors rather than the 8 VGA resistors. You end up with 4 pins free with TV which is a bonus. But TV doesn't seem as crisp at 80x40 text. Maybe I'm using the wrong driver, but TV seems better suited for graphics and VGA for text. Oh, and I haven't linked a graphics TV driver into the code, though it probably is only a couple of lines of spin. Attached picture is quite blocky and blurry on a big TV (even though the photo has smoothed it out somewhat) and on a small 4" LCD TV it is still blocky and blurry.
There's a reason that older computers which used TVs for display either used fewer columns (i.e. 40x25) or monochrome text - the bandwidth of composite TV doesn't allow for better.· For NTSC the color signal is modulated into the luma signal at 3.57MHz which means if your display generates around 320 active pixels or more per line you will get color artifacts unless color is disabled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
The interlaced display significantly improves the usefulness of composite TV graphics. The 8x8 driver I recently tossed in the OBEX was based off your NTSC template. Interlaced makes a marked difference in text quality. Was surprising how much, particularly on newer TV display devices.
I have for testing, a simple LCD running at 320x240, or something. It's resolution limited, of course. Not too useful over 40 columns, as the pixels are just not there. It acts a lot like the Zenith on color artificats too.
Zenith 80's era television, with some color filter, but not an advanced comb filter. It displays color artifacts to a much higher degree than newer devices do. It cannot render 80 column text that's useful, unless color is not part of the signal. It also appears bandwidth limited, not able to resolve smaller monochrome pixels. I think this is typical of older TVs.
SONY WEGA NTSC TV. This one actually renders composite graphics very well. Text, at well aligned color combinations (White on Blue for example), interlaced is readable. Non interlaced is probably only useful to 64 columns. Monochrome is flat out excellent. This TV has more advanced comb filters, and is a CRT display.
Newer full resolution LCD device, looks to be late 90's era. A monochrome composite signal is very good. Color composite signals are nearly as good as the SONY. Non-interlaced signals perform very poorly, interlaced ones are good to 64 columns with a fair amount of color freedom.
Hi-Definition PC capture card. This one will render 80 off a composite display, and does so with more color freedom than any other device I have. Most of my screenies posted here are from that device. Monochrome signals are monitor quality, with very good individual pixel resolution. I find the capabilities of it's composite color rendering flat out excellent. No CRT TV has matched it, though the SONY comes close.
Newer Plasma HDTV. This one exhibits many of the qualities of the capture card. I'll have to take a photo. 80 column text, from a composite display is quite useful, both monochrome and color. It's nearly on par with the capture card. The real difference it it being very picky about the actual signal, where the capture card will actually display a signal with a high percentage of out of spec elements, both sync levels and timing. The HDTV, flat out won't. It's now my regular tester for final driver vetting.
NTSC resolution PC capture card. This is the "EZ-Capture" OBC linked here for $10. It's pretty lousy at anything over 320 pixels. Non-interlaced displays work best, color artifacts are moderate. I'm generally not happy with it for pushing the boundaries. I am happy with it as a representative device though. It's all around average, meaning a useful display on it, probably is useful across the board.
What I want to know is how the HDTV circuits work. They can render color well beyond the accepted norms to the point of being nearly as useful as S-Video is. There are artifacts, but they are no where near what I am used to. Reading 80 column color text on the Plasma was surprising. It should not have worked as well as it does, given the signal characteristics.
On my next board revision, where I plan on hacking something apart, I plan to run a series of S-video captures and display tests.
New catalina library released (see the Catalina 2.2 thread) whcih saves 8kb of RAM for programs that do not need to use floating point I/O. To compile your test program with the new library, use a command like:
The HDTV probably uses a fast A/D converter and signal processing to generate the display, and as such is not constrained by real-world analog component
limits. It's even possible it contains some models of expected content (such as two-color character cells) and optimizes for such when it detects that content.
If you want to learn C for use on controllers then I
would recommend the arduino that you mentioned.
You would probably be programming an AVR on the arduino
using the free gnu C toolchain. This is an excellent setup and
I have written a lot of C code with this free compiler for the Atmega168 chip that
is common on arduino boards.
IMO the propeller is best programmed in PASM and Spin.
There's a little gem at the bottom of the above link. In the "Easy to Learn" section, there's a free e-book. "C++ Beginner's Guide", written by Herbert Schildt. Herbert Schildt is one of my all time favorite technical authors. I have purchased many of his books over the last twenty years and find them all well written, easy to understand, and with good examples. In fact, his book "C - The Complete Reference" has a place on my bookshelf at work and I still refer to it from time to time.
Being a fan of Herbert Schildt, I down loaded all twelve chapters plus the appendix and answer sections and combined them into one pdf. It came out to be 540 pages. This is a major piece of work by a well known author, and it's FREE!
I know that you want to learn C and this e-book is C++, but I still would recommend that you down load it and read through it. The information in the first seven chapters pertain equally to both C and C++ with the only exception being the use of cout/cin instead of printf/scanf. But if you can read through and understand the first seven chapters, then picking up the differences between C and C++ will be easy.
I also agree completely with what Holly said about the Arduino. I have one and find it quite easy to use. But then I also have a prop demo board and find it easy to use as well.
Ok here are my first impressions. I have started working with C on a PC rather than another microcontroller mainly because I already have a PC. I have been using this tutorial www.cprogramming.com/tutorial/c/lesson1.html and I used the Tiny C Compiler bellard.org/tcc/
#include <stdio.h>
int main()
{
int number;
printf( "Please enter a number: " );
scanf( "%d", &number );
printf( "You entered %d", number );
getchar();
return 0;
}
Well that was super easy. In less than an hour I was reading inputs from a keyboard and displaying it on a screen, this leaves me with mixed feelings. I am glad that it worked as expected so easily. But I feel like there is a lot going on behind the scenes that I have no clue about. From what I understand so far stdio.h is a library of functions that get compiled with my program. I assume similar to the way OBEX has functions that I can use as needed. If I was going to do something similar for the Propeller, I would need to use some sort of display driver (VGA or TV) and I would also need a keyboard driver. Or I could use fullduplexserial and a terminal program and get similar results.
C takes care of all the initialization of other functions and pin definitions like "tv.start(12)" would be needed in Spin. There has been countless times I got unexpected results because I forgot to initialize a function. I think the need to initialize functions is based more on the embedded hardware rather than the language. If i was programming C on an embedded controller I assume I would have to make some pin definitions. So comparing C to Spin is a bit of apples-to-oranges.
So far I like Spin/Propeller Tool better because of the transparency, I can tell exactly what get compiled to make up my program. Granted a lot more information is needed in the "header" section of Spin but this makes it easier to understand what is being used. From a learning perspective Spin wins, for ease-of-use C wins. I have a few more tutorials to complete before I attempt C on the Propeller.
JCee said...
... Super easy. In less than an hour I was reading inputs from a keyboard and displaying it on a screen, this leaves me with mixed feelings. I am glad that it worked as expected so easily. But I feel like there is a lot going on behind the scenes that I have no clue about. ....
Sure, there are lots of things going on. For the time being though, you are learning the "common part" of C programming that you can apply to using *any* micro-controller or package. When you know the fundamentals, it makes specializing easy. Embedded systems (micro-controllers and all the baggage that comes with them) is just one specialization. Enjoy the ride. There is much more to learn on the way.
Comments
Done that! And it is as far away from lint as possible.
I'm always working with the highest warning level and I once had PClint.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Code::Blocks with Mingw GNU is a close functional alternative to MSVC++.
Code::Blocks debug functionality is less useful than MSVC++ though. Both are free.
www.codeblocks.org/ <-- Codeblocks home page.
www.codeblocks.org/downloads/5 No strings attached.
www.microsoft.com/Express/VC/ Registration required.
Personally, I first "learned" C in high school two decades ago, but I didn't really become proficient until University where I used it for both coursework and personal projects. I still have Borland's free C++ compiler installed on my work laptop for creating tools as I need them. (However, I never really got into C++. The ASM part of my brain thinks objects would generate ugly ML.)
IMHO the main advantages of C are: 1. it's relatively portable 2. the common libraries 3. fun with pointers!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
What a cool example, I need one of those board to take with me to the in-laws next week. Will it do NTSC.
I had the great idea of having a look at the code produce for some class programmed using C++ with all the "abstraction" and so on... and was almost the same code as an equivalent C portion... then I thought... what ? everything is a lie to the programmer !... then I just lost faith in OOP (it is just a lie) and well I continued using C and ASM and was happy ever after
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
But somewhere it has to put those jump tables that dispatch execution to the right methods of polymorphic classes. vtables. Those you would normally have to code explicitly in structs in C or somewhere anyway to do "object oriented" programming in plain C. Look at the Linux kernel it is full of such tables explicitly coded in C.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ross.
P.S. I particularly like how you ended up with more RAM than you started with!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Re NTSC on this board, yes it can - just a matter of putting in the 4 TV driver resistors rather than the 8 VGA resistors. You end up with 4 pins free with TV which is a bonus. But TV doesn't seem as crisp at 80x40 text. Maybe I'm using the wrong driver, but TV seems better suited for graphics and VGA for text. Oh, and I haven't linked a graphics TV driver into the code, though it probably is only a couple of lines of spin. Attached picture is quite blocky and blurry on a big TV (even though the photo has smoothed it out somewhat) and on a small 4" LCD TV it is still blocky and blurry.
Getting back to the topic, RossH, would you be able to do a similar walk-through for Catalina? Maybe it is easy, but a few things are not explicitly stated, eg when you use scanf, is that scanning a local keyboard, or is it scanning a serial port talking to a terminal program that is part of Catalina, or is it something else?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/17/2009 11:38:30 PM GMT
In C, printf always outputs to 'standard output' and scanf always reads from 'standard input'. You don't really need to know what this means - just remember that in Catalina, 'standard output' is always the screen driver you choose to use, and 'standard input' is always the keyboard driver.
So if your board works with the standard parallax keyboard, TV and VGA drivers, it should be a simple matter of adding the appropriate pin and clock definitions for your board into the 'Catalia_Common_Input.spin' file (I'd suggest creating a new target symbol - but you could also just temporarily hack one of the existing targets such as DEMO).
Then you're good to go:
To have Catalina use the keyboard as 'standard input' and the VGA output as 'standard output':
To have Catalina use the keyboard as 'standard input' and the TV display as 'standard output':
If you need help in configuring a Catalina target, point me to the spec for your board.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
First question - you typed "catalina xxx xxx" etc
Is that in a dos window or a batch file or the Run command in Windows or something else, eg an IDE of some sort?
Where I am up to - I followed your link then downloaded all the files I could find on the first few posts and extracted them all to C:\Program Files\Catalina. There are some programs and a number of folders so the structure all seems to be there.
Re the hardware, ok, let's start from scratch and install catalina on some new hardware (though for our original poster, the hardware would presumably be the demo board. Even though the 40 pin prop is pretty cool just by itself, sooner or later you want to add a keyboard and display as a bare minimum, and the demo board comes already made).
For my hardware, VGA is P16 to P23. Keyboard is P26 and P27 (standard pins I think). No mouse. SD card is P12 to P15 (DO, CLK, DI and CS in that order). The serial port is 31,30 as per the demo board. www.smarthome.viviti.com/files/documents/Propeller_v2.pdf
Is that enough info to tweak your setup file?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/18/2009 2:29:13 AM GMT
Ok - I didn't realize you meant to start from quite so far back - I would encourage you to read the Catalina documents. You've probably already downloaded them - but in case you haven't they're in the 'Catalina_documents.zip' file (second post in this thread).
It sounds like you've already installed correctly, so you're nearly there. One of the documents ("Getting Started with Catalina") is a step-by-step tutorial that goes through the details you need - including setting up, compiling some demo programs, customizing the Catalina_Common_Input.spin file for your platform, and loading and running the compiled result on the Propeller. As well as details on what all the command-line options I used (VGA, NTSC etc) actually mean.
But to answer your first question - yes, these commands are entered in a Windows command interpreter. For the rest, the best thing is to read the tutorial document.
I'm at work at the moment, but this evening I'll use the PIN definitions you provided to set up a Catalina_Common_Input file you can use, and post it in this thread. Or you can have a go yourself - it's not that difficult for a simple single CPU Prop platform (it gets complex for a multi-prop platforms).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 12/18/2009 3:11:07 AM GMT
Ok - lunchtime here, so I had a quick go at a 'Catalina_Input.spin' file. Save it over the existing version in 'C:\Program Files\Catalina\target\input\'.
I have called your board DR_ACULA, so what you need to do is add the following flags to all your compiles:
For example:
If all goes well, this will result in a file called test.binary which you just load using the normal Parallax tools.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I see you have a whole lot of spin programs in one of the folders for various hardware configurations, which I think further emphasises the point that the prop is quite a valid platform for learning C.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Correct - but you don't normally need to worry about them. Catalina builds the approproate run-time environment on every compile based on (1) the hardware pin definitions in the Catalina_Common file and (2) the options you specify on the command line.
I really should do some work on generating a Catalina_Common file that specifies ALL the common Prop boards - but the trouble is that if I don't have one then I can't actually test it. That's why I currently only say I support the Hydra, Hybrid, TriBladeProp and Morpheus - even the Demo board I've not actually tested (although I believe it will work ok).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
If you don't need any new drivers developed for your board, and the definitions I posted work ok, then you don't need to actually send me a board. Just let me know what I should call your board and I will include the definitions in all future releases of Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
A problem - I just compiled this on my Hydra, and it works fine if I make it an EMM or XMM program, but the LMM version is too large. You will probably find the same.
It seems that including 'scanf' pulls in way too much of the C library - including floating point stuff that is not necessary.
I'll investigate tomorrow and see what I can do about it.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Ok, I found the problem - I was indeed pulling in floating point stuff I didn't need. Now fixed. I will release a new version of Catalina's C library tomorrow.
I didn't realize your board had addiitonal RAM available. That means you can use Catalina to build XMM programs that use the full 512k - but you'll need an XMM driver. If you want me to write you one, then I definitely will need one of your boards. But if your board uses the same XMM scheme as Cluso's boards, then Catalina may already have a suitable driver - I've written drivers for his TriBladeProp Blades #1 and #2, so if your board uses this type of access then we can use one of those. I haven't written anything for his RamBlade yet, but I seem to remember that he uses the same scheme as the TriBladeProp Blade #2.
I'll have a closer look at your hardware schematics tomorrow.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I think you would be better off learning C on a PC.· As someone else suggested you can download the Watcom C compiler for free.· It is a simple command-line compiler without an IDE.· Since you already know Spin you shouldn't have any trouble programming in C.· Some of your Spin programs may translate directly to C on a line-by-line basis.· You should be able to write a "Hello World" program in minutes, and you can try different things from that point.
I learned C about 20 years ago after programming in FORTRAN before that.· It was an easy transition for me, even though most of my early C programs looked a lot like FORTRAN.· The trickiest part for me was learning about pointers, and pointers to pointers.· It also took we a while to fully understand C structs.· There are still a few things in the C syntax that I have to look up on occassion, such as doing a typedef of function pointer.
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
The interlaced display significantly improves the usefulness of composite TV graphics. The 8x8 driver I recently tossed in the OBEX was based off your NTSC template. Interlaced makes a marked difference in text quality. Was surprising how much, particularly on newer TV display devices.
I have for testing, a simple LCD running at 320x240, or something. It's resolution limited, of course. Not too useful over 40 columns, as the pixels are just not there. It acts a lot like the Zenith on color artificats too.
Zenith 80's era television, with some color filter, but not an advanced comb filter. It displays color artifacts to a much higher degree than newer devices do. It cannot render 80 column text that's useful, unless color is not part of the signal. It also appears bandwidth limited, not able to resolve smaller monochrome pixels. I think this is typical of older TVs.
SONY WEGA NTSC TV. This one actually renders composite graphics very well. Text, at well aligned color combinations (White on Blue for example), interlaced is readable. Non interlaced is probably only useful to 64 columns. Monochrome is flat out excellent. This TV has more advanced comb filters, and is a CRT display.
Newer full resolution LCD device, looks to be late 90's era. A monochrome composite signal is very good. Color composite signals are nearly as good as the SONY. Non-interlaced signals perform very poorly, interlaced ones are good to 64 columns with a fair amount of color freedom.
Hi-Definition PC capture card. This one will render 80 off a composite display, and does so with more color freedom than any other device I have. Most of my screenies posted here are from that device. Monochrome signals are monitor quality, with very good individual pixel resolution. I find the capabilities of it's composite color rendering flat out excellent. No CRT TV has matched it, though the SONY comes close.
Newer Plasma HDTV. This one exhibits many of the qualities of the capture card. I'll have to take a photo. 80 column text, from a composite display is quite useful, both monochrome and color. It's nearly on par with the capture card. The real difference it it being very picky about the actual signal, where the capture card will actually display a signal with a high percentage of out of spec elements, both sync levels and timing. The HDTV, flat out won't. It's now my regular tester for final driver vetting.
NTSC resolution PC capture card. This is the "EZ-Capture" OBC linked here for $10. It's pretty lousy at anything over 320 pixels. Non-interlaced displays work best, color artifacts are moderate. I'm generally not happy with it for pushing the boundaries. I am happy with it as a representative device though. It's all around average, meaning a useful display on it, probably is useful across the board.
What I want to know is how the HDTV circuits work. They can render color well beyond the accepted norms to the point of being nearly as useful as S-Video is. There are artifacts, but they are no where near what I am used to. Reading 80 column color text on the Plasma was surprising. It should not have worked as well as it does, given the signal characteristics.
On my next board revision, where I plan on hacking something apart, I plan to run a series of S-video captures and display tests.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
New catalina library released (see the Catalina 2.2 thread) whcih saves 8kb of RAM for programs that do not need to use floating point I/O. To compile your test program with the new library, use a command like:
Note the use of the option -lci instead of the previous -lc
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
limits. It's even possible it contains some models of expected content (such as two-color character cells) and optimizes for such when it detects that content.
would recommend the arduino that you mentioned.
You would probably be programming an AVR on the arduino
using the free gnu C toolchain. This is an excellent setup and
I have written a lot of C code with this free compiler for the Atmega168 chip that
is common on arduino boards.
IMO the propeller is best programmed in PASM and Spin.
winavr.sourceforge.net/
Or for gcc with an ARM board instead of an arduino board.
winarm.scienceprog.com/winarm-tools/quick-start-using-winarm.html
Post Edited (HollyMinkowski) : 12/19/2009 1:41:59 AM GMT
JCee
There's a little gem at the bottom of the above link. In the "Easy to Learn" section, there's a free e-book. "C++ Beginner's Guide", written by Herbert Schildt. Herbert Schildt is one of my all time favorite technical authors. I have purchased many of his books over the last twenty years and find them all well written, easy to understand, and with good examples. In fact, his book "C - The Complete Reference" has a place on my bookshelf at work and I still refer to it from time to time.
Being a fan of Herbert Schildt, I down loaded all twelve chapters plus the appendix and answer sections and combined them into one pdf. It came out to be 540 pages. This is a major piece of work by a well known author, and it's FREE!
I know that you want to learn C and this e-book is C++, but I still would recommend that you down load it and read through it. The information in the first seven chapters pertain equally to both C and C++ with the only exception being the use of cout/cin instead of printf/scanf. But if you can read through and understand the first seven chapters, then picking up the differences between C and C++ will be easy.
I also agree completely with what Holly said about the Arduino. I have one and find it quite easy to use. But then I also have a prop demo board and find it easy to use as well.
Jim...
Here are my first C programs
#include <stdio.h> int main() { printf( "Hello World.\n" ); getchar(); return 0; }#include <stdio.h> int main() { int number; printf( "Please enter a number: " ); scanf( "%d", &number ); printf( "You entered %d", number ); getchar(); return 0; }Well that was super easy. In less than an hour I was reading inputs from a keyboard and displaying it on a screen, this leaves me with mixed feelings. I am glad that it worked as expected so easily. But I feel like there is a lot going on behind the scenes that I have no clue about. From what I understand so far stdio.h is a library of functions that get compiled with my program. I assume similar to the way OBEX has functions that I can use as needed. If I was going to do something similar for the Propeller, I would need to use some sort of display driver (VGA or TV) and I would also need a keyboard driver. Or I could use fullduplexserial and a terminal program and get similar results.
C takes care of all the initialization of other functions and pin definitions like "tv.start(12)" would be needed in Spin. There has been countless times I got unexpected results because I forgot to initialize a function. I think the need to initialize functions is based more on the embedded hardware rather than the language. If i was programming C on an embedded controller I assume I would have to make some pin definitions. So comparing C to Spin is a bit of apples-to-oranges.
So far I like Spin/Propeller Tool better because of the transparency, I can tell exactly what get compiled to make up my program. Granted a lot more information is needed in the "header" section of Spin but this makes it easier to understand what is being used. From a learning perspective Spin wins, for ease-of-use C wins. I have a few more tutorials to complete before I attempt C on the Propeller.
Open Watcom has an IDE. Not the most polished one, but workable with.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO