or then again... (does something else but it still has stars.....)
#Include "fbgfx.bi"
Const SCRN_WIDTH = 800
Const SCRN_HEIGHT = 600
Type TStar
x As Single
y As Single
vx As Single
vy As Single
way As Single
Declare Sub create()
Declare Sub update()
Declare Constructor()
End Type
Sub TStar.create()
x = SCRN_WIDTH / 2
y = SCRN_HEIGHT / 2
vx = Rnd * (10 + 1)
vy = 10 - vx
If Rnd > .5 Then vx *= -1
If Rnd > .5 Then vy *= -1
way = 0
End Sub
Sub TStar.update()
x += vx
y += vy
way = Sqr((SCRN_WIDTH / 2 - x) ^ 2 + (SCRN_HEIGHT / 2 - y) ^ 2)
If x >= SCRN_WIDTH Or y >= SCRN_HEIGHT Or x < 0 Or y < 0 Then create()
End Sub
Constructor TStar ()
create()
For i As Integer = 0 To Int(Rnd * 300)
update()
Next
End Constructor
Type TStarfield
stars As TStar Ptr
maxstars As Integer
Declare Sub update(buffer As FB.IMAGE Ptr)
Declare Constructor(maxstars_ As Integer)
Declare Destructor()
End Type
Sub TStarfield.update(buffer As FB.IMAGE Ptr)
If buffer = 0 Then Exit Sub
Line buffer, (0, 0)-(buffer->width - 1, buffer->height - 1), 0, BF
For i As Integer = 0 To maxstars - 1
With stars[i]
.update()
Circle buffer, (.x, .y), .way / 150, -1, , , , F
End With
Next
End Sub
Constructor TStarfield (maxstars_ As Integer)
stars = New TStar[maxstars_]
maxstars = maxstars_
End Constructor
Destructor TStarfield ()
Delete[] stars
End Destructor
Randomize Timer
ScreenRes SCRN_WIDTH, SCRN_HEIGHT, 32
Var starfield = New TStarfield(150)
Var buffer = ImageCreate(SCRN_WIDTH, SCRN_HEIGHT, 0)
Do
ScreenLock
Cls
starfield->update(buffer)
Put (0, 0), buffer, Pset
ScreenUnLock
Sleep 25, 1
Loop Until MultiKey(FB.SC_ESCAPE)
ImageDestroy(buffer)
Delete starfield
Those that have no prior preference and want to work quickly and have fun should talk to me.
I would just be happy to see an equivalent of my "beginners code" written in whatever language for the Prop that results in; a) as self explanatory and b) executes at least as fast....For me, that's where the BS ends.
I didn't want to start a new thread and this one seems to speak a bunch towards the same direction I am curious about.
I am a long time Hobbyist programmer that originally cut my "teeth" on Atari 8bit basic and went on from there. I have Written in many different languages including C and C++ over the years. So I am comfortable with Basic or pretty much any other languages. I have not had the time to dig into my Prop board yet or start learning how to program it but I have a project I will be using these with and I am curious what would be the best language for someone who is versed in many languages. Is Spin the most efficient setup? I currently use C#, Java and PHP in the projects I am currently involved in both in and out of school. I currently own a "Propeller starter kit" and "Programming and customizing the multicore Propeller Microcontroller" book that I got on a special deal last year. Due to some other issues I never was able to get involved with this and start learning anything otherwise I had an idea for the MicroMedic competition last year but didn't end up getting the time to do it due to some medical issues I had.
So I am curious if I should be writing in PropBasic, Spin, C ... Things have matured quite a bit since I first got interested in the Propeller.
I didn't want to start a new thread and this one seems to speak a bunch towards the same direction I am curious about.
I am a long time Hobbyist programmer that originally cut my "teeth" on Atari 8bit basic and went on from there. I have Written in many different languages including C and C++ over the years. So I am comfortable with Basic or pretty much any other languages. I have not had the time to dig into my Prop board yet or start learning how to program it but I have a project I will be using these with and I am curious what would be the best language for someone who is versed in many languages. Is Spin the most efficient setup? I currently use C#, Java and PHP in the projects I am currently involved in both in and out of school. I currently own a "Propeller starter kit" and "Programming and customizing the multicore Propeller Microcontroller" book that I got on a special deal last year. Due to some other issues I never was able to get involved with this and start learning anything otherwise I had an idea for the MicroMedic competition last year but didn't end up getting the time to do it due to some medical issues I had.
So I am curious if I should be writing in PropBasic, Spin, C ... Things have matured quite a bit since I first got interested in the Propeller.
Rodney
Dare you to try Tachyon FORTH, free you mind from compile link download, you will never look back.
I'd say it depends on what you want to do. Some of our C examples make some pretty sophisticated programs super easy, but I find that writing my own C code is still difficult because I'm learning as I go. Almost all of our educational customers use C, and all commercial customers (except just a few) are using Spin. The support on the forums has really evolved to support both languages, but if you need really precise control and want to use more of our established resources, Spin can be the best choice.
PropBASIC I don't know too well, but chances are that language could also be real well-suited for a lot of our customers who have BASIC Stamp experience.
One consideration with C is code space - it can be quite limited once those libraries are downloaded. Depending on what you want to do this may or may not be a problem since the GCC and C developers have done so much optimization.
I share a bit of your hesitation regarding taking a branch away from the C I learned. I did not learn C until both my kids were working on their second degrees. I needed it and 3 other languages to get an AS in MIS so that my boss at the time could justify continuing to give me regular raises. Once I learned it and got up to 40WPM I got the degree. I never once got to use it.
I just got through not actually relearning Basic, as much as learning a litany of things it will do now. Programming these days is a piece of cake compared to the days of code sheets, keypunch, get listing, correct mistakes from your keypunching or the code itself, get time on system for compiler run ..etc...etc.
My concern has to do with portability should I decide to go with a different processor and/or configuration of processors.
For now the book "Programming the Propeller with Spin" which kept coming up during my search for info regards to parallel processing. At one time in my career I was involved using UNIX but since it is not a RTOS language many of the electromechanical aspects of the system required a lot of slack and additional coding.
I am here because a friend disclosed an idea he had that he thought might be patentable. I agreed to help him. I figured that if I can program a solution for the timing of and execution of various task _and_ be able to demonstrate that it does function then I would put on my electronic technician hat and backward engineer it into a circuit board.
My biggest shock came when I found I could no longer stop by Radio Shack and pick up assorted components the way I did for decades of working in field service. ]8>(
Maybe someone needs to write a "Programming the Propeller in C/C++" book. Any volunteers? :-)
It would be a neat book. When I start to think about it, I wonder where to start. Should it teach basic C/C++ programming in the fisrt several chapters and then start introducing Propeller specifics? Should it assume some basic level of C skill and jump right into Propeller specifics? Should it teach C and Propeller hand in hand cover covering small chunks of reqjred information in sidebars and special topic boxes?
I look at other programming book formats and organizations...think a bit..then go off and get disracted.
Someone should write it though, before they sit down a write the Propeller2 PASM book!
Someone should write it though, before they sit down a write the Propeller2 PASM book!
I's be willing to pay real money for a Propeller 2 PASM book. Anything to save having to wade through 10,000 Propeller 2 forum posts, many of which are contradictory (or at least severely out of date!).
As for C, you can't go past "Kernigan and Ritchie" (2nd edition). What else could you possibly need?
Thanks for the comments.. For a little more clarity here is more information:
I am currently a student working on a Bachelors in Computer Programming and specializing in Information Assurance/Security although I haven't decided if I am going to just add it on as a minor to my main degree(24 more credit hours), An associates degree (about another 15 credit hours) or a Bachelors( almost 60 more Credit hours) in Information Assurance/Security.
I have taken a C class in the past and did some work in it. I have done more with C++ and of course C# is very similar to C++. Java and many of the languages out there are derived from C++. I chuckle when I see the waterboarding comment but really OOP isn't THAT bad... One of my teachers said it takes 5 years to become proficient with OOP because it certainly is a different mindset. I am probably 80% of the way there.
I dabbled with Forth but never did anything with it so not sure I want to go there... I also dabbled with 6502 Assembler because I needed to build a character driver to allow me to draw characters on a graphics screen since doing it in Atari Basic was like watching a movie where someone is drawing the character by hand with a pen..
As far as books... I would think a Prop book should build off current C/C++ knowledge and not try to reteach something others have done. An assembly book would probably have to do everything.
Edited... Just read the C\C++ FAQ...
With C\C++ you have to be aware of the memory mode you set it up with. Is that also a consideration with Spin or is spin constrained to stay within the chips onboard ram?
I see where C\C++ is faster which I would think makes sense since Spin is interpreted but am I sensing for real time requirements spin is a better choice than C\C++?
Also, can you dump the Spin Interpreter if you are not going to use it to gain more memory space for use with C\C++?
At this point it looks like I might be best served looking at working with C\C++ instead of trying to learn Spin but I do have a couple Spin books and this quick start board... And what's another language...
I's be willing to pay real money for a Propeller 2 PASM book. Anything to save having to wade through 10,000 Propeller 2 forum posts, many of which are contradictory (or at least severely out of date!).
As for C, you can't go past "Kernigan and Ritchie" (2nd edition). What else could you possibly need?
As for C++, I'd rather be water-boarded!
Ross.
I realize that there are many books that teach C programming. Another is certainly not needed. However, there are lots of details associated with programming the Propeller in C using either PropGCC or Catalina that could be covered in a "Programming the Propeller in C" book. Ken says that education customers are almost all using C so maybe there would even be a market for such a book.
Spin is the the language DESIGNED for the prop, it is interpreted and tends to be the slowest. But it you are more interested in learning over speed, SPIN is a good way to start.
So I am curious if I should be writing in PropBasic, Spin, C ...
My concern has to do with portability should I decide to go with a different processor and/or configuration of processors.
Portability is misimformation except in the context of workstation (or larger) OS and application development. We ALWAYS have to rewrite some code, be it the library in the worst case or in the application in the best case.
New drivers on new hardware is always new from scratch.
If you want interactive development, and the speed of assembler, and you anticipate lots of driver or assembler work, you might want forth.
With C\C++ you have to be aware of the memory mode you set it up with. Is that also a consideration with Spin or is spin constrained to stay within the chips onboard ram?
I see where C\C++ is faster which I would think makes sense since Spin is interpreted but am I sensing for real time requirements spin is a better choice than C\C++?
Also, can you dump the Spin Interpreter if you are not going to use it to gain more memory space for use with C\C++?
At this point it looks like I might be best served looking at working with C\C++ instead of trying to learn Spin but I do have a couple Spin books and this quick start board... And what's another language...
PropGCC supports memory modes that execute from Cog RAM, Hub RAM or external memory. Spin only has one mode that executes from Hub RAM.
The Spin interpreter is located in ROM, so it doesn't use up any Hub RAM when running C. The Prop always boots up in Spin mode, but when running C, the Spin Cog is reloaded with the C interpreter. The hub RAM memory image for the C interpreter could be re-used by the program for data if you don't need to start any other C cogs.
I would suggest working with both C and Spin on the Prop. Spin uses indentation to delineate logical blocks, and most of the operators a the same as C. Just watch out for the ">=" and "<=" operators, which work differently in Spin. The Object Exchange (OBEX) provides many uses Spin objects. I have a CLIB object in the OBEX, which provides C-like routines for the Spin language.
Portability is misimformation except in the context of workstation (or larger) OS and application development.
This is not true.
There is plenty of C code that can be moved from micro-controller to micro-controller without modification. No workstation power or operating system required.
I hold up as an example the heater_FFT that runs everywhere without any changes. Not only that there is a parallel version of that FFT which runs fine on multiple COGs or multiple cores of my Intel PC without change. Did I ever post that here?
Admittedly there will be issues with low level hardware interfacing code. Such as there will be no matter what language you are using on an MCU.
Portability is misimformation except in the context of workstation (or larger) OS and application development. We ALWAYS have to rewrite some code, be it the library in the worst case or in the application in the best case.
New drivers on new hardware is always new from scratch.
If you want interactive development, and the speed of assembler, and you anticipate lots of driver or assembler work, you might want forth.
I've found that C code is easily portable to PropGCC, so I would have to disagree with Doug on this point. If portability is a primary requirement, then C is the best choice for the Prop.
I've found that C code is easily portable to PropGCC, so I would have to disagree with Doug on this point. If portability is a primary requirement, then C is the best choice for the Prop.
I believe that the same is true of Catalina C. Ross once told me that he ported my XLISP language to the Propeller using Catalina and it's a pretty large program. I wonder how much effort would be required to port the Catalina C compiler itself? :-)
Not to argue too much about portability, but in my experience, projects that counted on portability were late because the portable code required significant time and effort for whatever reason. We can't get around the "work" part of the work.
As the above say, for folks of their expert level, its easier, there are many successful examples, and C is a good choice. But often the same code on the same processor (in the same application) proves "unportable". But this is just my experience, and perhaps its a statistical anomaly.
Not to argue too much about portability, but in my experience, projects that counted on portability were late because the portable code required significant time and effort for whatever reason. We can't get around the "work" part of the work.
As the above say, for folks of their expert level, its easier, there are many successful examples, and C is a good choice. But often the same code on the same processor (in the same application) proves "unportable". But this is just my experience, and perhaps its a statistical anomaly.
Well, I guess we know that Forth programs are not portable at all even between different Forths on the same platform. I think the three Forths that I know about for Propeller are all incompatible with each other in fairly fundamental ways. Maybe Forth isn't intended to be portable though.
Projects that count on portability are designed with portability in mind from the get go. I have been involved in control systems that have moved from architecture to architecture with little effort. An operating system is not required but a "layered architecture" is. All architecture specific parts should be separated from the application parts. In one case, for example, I was involved in a control system that moved from Intel 186 to Motorola 68000 to PowerPC. All with no OS support. On the way it was always runnable on Windows and Linux for testing and simulation purposes.
Sure we can't get around the work part, often the porting work is a small fraction of writing the application in the first place.
The worst issues at the application code level have been to do with memory alignment requirements of different CPU's and the big "endian / little endian" thing. They were soon sorted.
Spin/PASM will get you the quickest entry into Propeller programming with the largest collection of ready to run objects to support many hardware features of your project through the OBEX. You will have many examples and experts to draw knowledge from here on the forums.
C/C++ will give you the ability to use any previously gained experience with the language. There is a limited but constantly growing set of libraries to support the hardware features in your project. You will be a pioneer (or at least early settler) as far as examples on the forum. The experts are just as equally helpful!
Forth is a personal journey you must choose to embark on, certainly the road less traveled. Working examples to support hardware are slowly growing but few and far between. Tachyon is the front runner in offering useful hardware support for most projects at this time. PropForth has a number of interesting features and hidden gems. pfth is ANSI standardish and has shone brightly in its short lifespan. All of these have have forum support from a variety of people with varied experiences. Again, Forth is something you have to want to do for the sake of your personal relationship with Forth.
Forth is my playground. What little I try to do productively is either in Spin/PASM or C.
Well, I guess we know that Forth programs are not portable at all even between different Forths on the same platform. I think the three Forths that I know about for Propeller are all incompatible with each other in fairly fundamental ways. Maybe Forth isn't intended to be portable though.
All my professional work has been with C, assembler, or Ada, these are what I was refering to.
Regarding forth: a well made KERNEL maybe generic enough to use on multiple projects, to serve as a starting point. But each project has different needs, and each will need a different set of development tools. When there isn't enough room to fit the whole tool box, you have to remove the tools you don't need. This is why propfroth include 14 kerneles, and provides the ability to create custom kernels easily: because Sal needs to do this often. Next version it should be easy enough that I can do it.
For me, everything is custom everytime, cause I'm a hack. Also, my experience data may well be outdated.
Ada, there is a good example. Look inside a Boeing 777 Primary Flight Computer and you will find three different CPU boards. Based on Intel 486, Motorola 68xxx and AMD29xxx. The same Ada code runs on all of them. That software runs on the target(s) of course but was also running on VAX machines for testing when it was created.
Ada, there is a good example. Look inside a Boeing 777 Primary Flight Computer and you will find three different CPU boards. Based on Intel 486, Motorola 68xxx and AMD29xxx. The same Ada code runs on all of them..
So, they just compiled it for each new processor, and shipped it? Or did they test it, and say, "oh Smile. gimme a couple days" and tweak it for each particular rig, despite the efforts for portability?
While the Ada was less prone to difficulties than the C, the schedule always allowed for the former, and the later ocured instead.
The lead engineers always allowed for tweak time, even for the Ada, based on past experience.
So, they just compiled it for each new processor, and shipped it?
You are joking right? This is fly by wire system we are talking about. You would not believe the amount of testing that went on there.
Thing is the hardware design, constructing the ADA run times and the actual control system application development can all be done at the same time.
Hardware and run-time system testing can be going on whilst the application code is being subjected to a billion unit tests run on those VAX machines.
When all that is done we get down to putting it all together and running a billion integration tests with the target "black boxes" hooked up to test rigs that simulate the aircraft actuators and sensors. I spent nearly two years writing test scripts for those integration tests as part of a team of twenty or so guys working in three shifts so as to keep the test lab in use around the clock.
I don't recall that the 777 first flight was late. And none of the 777 accidents have pointed a finger at bugs in the PFC software.
So, they just compiled it for each new processor, and shipped it? Or did they test it, and say, "oh Smile. gimme a couple days" and tweak it for each particular rig, despite the efforts for portability?
While the Ada was less prone to difficulties than the C, the schedule always allowed for the former, and the later ocured instead.
The lead engineers always allowed for tweak time, even for the Ada, based on past experience.
Tweaking something is not the same as writing it over from scratch which is what you'd pretty much have to do if you tried to move a program written for PropForth to Tachyon or pfth and you'd certainly have to do that for a program written in Spin if you wanted to move it anywhere including to P2.
Edit: Sorry, Spin code would not have to be rewritten from scratch to move from P1 to P2 but it would have to be "tweaked".
Comments
#Include "fbgfx.bi" Const SCRN_WIDTH = 800 Const SCRN_HEIGHT = 600 Type TStar x As Single y As Single vx As Single vy As Single way As Single Declare Sub create() Declare Sub update() Declare Constructor() End Type Sub TStar.create() x = SCRN_WIDTH / 2 y = SCRN_HEIGHT / 2 vx = Rnd * (10 + 1) vy = 10 - vx If Rnd > .5 Then vx *= -1 If Rnd > .5 Then vy *= -1 way = 0 End Sub Sub TStar.update() x += vx y += vy way = Sqr((SCRN_WIDTH / 2 - x) ^ 2 + (SCRN_HEIGHT / 2 - y) ^ 2) If x >= SCRN_WIDTH Or y >= SCRN_HEIGHT Or x < 0 Or y < 0 Then create() End Sub Constructor TStar () create() For i As Integer = 0 To Int(Rnd * 300) update() Next End Constructor Type TStarfield stars As TStar Ptr maxstars As Integer Declare Sub update(buffer As FB.IMAGE Ptr) Declare Constructor(maxstars_ As Integer) Declare Destructor() End Type Sub TStarfield.update(buffer As FB.IMAGE Ptr) If buffer = 0 Then Exit Sub Line buffer, (0, 0)-(buffer->width - 1, buffer->height - 1), 0, BF For i As Integer = 0 To maxstars - 1 With stars[i] .update() Circle buffer, (.x, .y), .way / 150, -1, , , , F End With Next End Sub Constructor TStarfield (maxstars_ As Integer) stars = New TStar[maxstars_] maxstars = maxstars_ End Constructor Destructor TStarfield () Delete[] stars End Destructor Randomize Timer ScreenRes SCRN_WIDTH, SCRN_HEIGHT, 32 Var starfield = New TStarfield(150) Var buffer = ImageCreate(SCRN_WIDTH, SCRN_HEIGHT, 0) Do ScreenLock Cls starfield->update(buffer) Put (0, 0), buffer, Pset ScreenUnLock Sleep 25, 1 Loop Until MultiKey(FB.SC_ESCAPE) ImageDestroy(buffer) Delete starfieldDave
I would just be happy to see an equivalent of my "beginners code" written in whatever language for the Prop that results in; a) as self explanatory and b) executes at least as fast....For me, that's where the BS ends.
Yes, Peter and Daves forths are perfectly good. I just need the extra help.
I am a long time Hobbyist programmer that originally cut my "teeth" on Atari 8bit basic and went on from there. I have Written in many different languages including C and C++ over the years. So I am comfortable with Basic or pretty much any other languages. I have not had the time to dig into my Prop board yet or start learning how to program it but I have a project I will be using these with and I am curious what would be the best language for someone who is versed in many languages. Is Spin the most efficient setup? I currently use C#, Java and PHP in the projects I am currently involved in both in and out of school. I currently own a "Propeller starter kit" and "Programming and customizing the multicore Propeller Microcontroller" book that I got on a special deal last year. Due to some other issues I never was able to get involved with this and start learning anything otherwise I had an idea for the MicroMedic competition last year but didn't end up getting the time to do it due to some medical issues I had.
So I am curious if I should be writing in PropBasic, Spin, C ... Things have matured quite a bit since I first got interested in the Propeller.
Rodney
Dare you to try Tachyon FORTH, free you mind from compile link download, you will never look back.
I'd say it depends on what you want to do. Some of our C examples make some pretty sophisticated programs super easy, but I find that writing my own C code is still difficult because I'm learning as I go. Almost all of our educational customers use C, and all commercial customers (except just a few) are using Spin. The support on the forums has really evolved to support both languages, but if you need really precise control and want to use more of our established resources, Spin can be the best choice.
PropBASIC I don't know too well, but chances are that language could also be real well-suited for a lot of our customers who have BASIC Stamp experience.
One consideration with C is code space - it can be quite limited once those libraries are downloaded. Depending on what you want to do this may or may not be a problem since the GCC and C developers have done so much optimization.
Ken Gracey
I like C++ on the Propeller, and have developed a library of useful objects at libpropeller.org. The PropGCC FAQ has some good information as well.
Especially if you are in school for engineering, C/C++ allow you to practice and become the local programming expert. You won't regret it.
I just got through not actually relearning Basic, as much as learning a litany of things it will do now. Programming these days is a piece of cake compared to the days of code sheets, keypunch, get listing, correct mistakes from your keypunching or the code itself, get time on system for compiler run ..etc...etc.
My concern has to do with portability should I decide to go with a different processor and/or configuration of processors.
For now the book "Programming the Propeller with Spin" which kept coming up during my search for info regards to parallel processing. At one time in my career I was involved using UNIX but since it is not a RTOS language many of the electromechanical aspects of the system required a lot of slack and additional coding.
I am here because a friend disclosed an idea he had that he thought might be patentable. I agreed to help him. I figured that if I can program a solution for the timing of and execution of various task _and_ be able to demonstrate that it does function then I would put on my electronic technician hat and backward engineer it into a circuit board.
My biggest shock came when I found I could no longer stop by Radio Shack and pick up assorted components the way I did for decades of working in field service. ]8>(
Tim
It would be a neat book. When I start to think about it, I wonder where to start. Should it teach basic C/C++ programming in the fisrt several chapters and then start introducing Propeller specifics? Should it assume some basic level of C skill and jump right into Propeller specifics? Should it teach C and Propeller hand in hand cover covering small chunks of reqjred information in sidebars and special topic boxes?
I look at other programming book formats and organizations...think a bit..then go off and get disracted.
Someone should write it though, before they sit down a write the Propeller2 PASM book!
I's be willing to pay real money for a Propeller 2 PASM book. Anything to save having to wade through 10,000 Propeller 2 forum posts, many of which are contradictory (or at least severely out of date!).
As for C, you can't go past "Kernigan and Ritchie" (2nd edition). What else could you possibly need?
As for C++, I'd rather be water-boarded!
Ross.
I am currently a student working on a Bachelors in Computer Programming and specializing in Information Assurance/Security although I haven't decided if I am going to just add it on as a minor to my main degree(24 more credit hours), An associates degree (about another 15 credit hours) or a Bachelors( almost 60 more Credit hours) in Information Assurance/Security.
I have taken a C class in the past and did some work in it. I have done more with C++ and of course C# is very similar to C++. Java and many of the languages out there are derived from C++. I chuckle when I see the waterboarding comment but really OOP isn't THAT bad... One of my teachers said it takes 5 years to become proficient with OOP because it certainly is a different mindset. I am probably 80% of the way there.
I dabbled with Forth but never did anything with it so not sure I want to go there... I also dabbled with 6502 Assembler because I needed to build a character driver to allow me to draw characters on a graphics screen since doing it in Atari Basic was like watching a movie where someone is drawing the character by hand with a pen..
As far as books... I would think a Prop book should build off current C/C++ knowledge and not try to reteach something others have done. An assembly book would probably have to do everything.
Edited... Just read the C\C++ FAQ...
With C\C++ you have to be aware of the memory mode you set it up with. Is that also a consideration with Spin or is spin constrained to stay within the chips onboard ram?
I see where C\C++ is faster which I would think makes sense since Spin is interpreted but am I sensing for real time requirements spin is a better choice than C\C++?
Also, can you dump the Spin Interpreter if you are not going to use it to gain more memory space for use with C\C++?
At this point it looks like I might be best served looking at working with C\C++ instead of trying to learn Spin but I do have a couple Spin books and this quick start board... And what's another language...
Rodney
Spin is the the language DESIGNED for the prop, it is interpreted and tends to be the slowest. But it you are more interested in learning over speed, SPIN is a good way to start.
If you already know C you should use C.
Portability is misimformation except in the context of workstation (or larger) OS and application development. We ALWAYS have to rewrite some code, be it the library in the worst case or in the application in the best case.
New drivers on new hardware is always new from scratch.
If you want interactive development, and the speed of assembler, and you anticipate lots of driver or assembler work, you might want forth.
The Spin interpreter is located in ROM, so it doesn't use up any Hub RAM when running C. The Prop always boots up in Spin mode, but when running C, the Spin Cog is reloaded with the C interpreter. The hub RAM memory image for the C interpreter could be re-used by the program for data if you don't need to start any other C cogs.
I would suggest working with both C and Spin on the Prop. Spin uses indentation to delineate logical blocks, and most of the operators a the same as C. Just watch out for the ">=" and "<=" operators, which work differently in Spin. The Object Exchange (OBEX) provides many uses Spin objects. I have a CLIB object in the OBEX, which provides C-like routines for the Spin language.
There is plenty of C code that can be moved from micro-controller to micro-controller without modification. No workstation power or operating system required.
I hold up as an example the heater_FFT that runs everywhere without any changes. Not only that there is a parallel version of that FFT which runs fine on multiple COGs or multiple cores of my Intel PC without change. Did I ever post that here?
Admittedly there will be issues with low level hardware interfacing code. Such as there will be no matter what language you are using on an MCU.
As the above say, for folks of their expert level, its easier, there are many successful examples, and C is a good choice. But often the same code on the same processor (in the same application) proves "unportable". But this is just my experience, and perhaps its a statistical anomaly.
Sure we can't get around the work part, often the porting work is a small fraction of writing the application in the first place.
The worst issues at the application code level have been to do with memory alignment requirements of different CPU's and the big "endian / little endian" thing. They were soon sorted.
C/C++ will give you the ability to use any previously gained experience with the language. There is a limited but constantly growing set of libraries to support the hardware features in your project. You will be a pioneer (or at least early settler) as far as examples on the forum. The experts are just as equally helpful!
Forth is a personal journey you must choose to embark on, certainly the road less traveled. Working examples to support hardware are slowly growing but few and far between. Tachyon is the front runner in offering useful hardware support for most projects at this time. PropForth has a number of interesting features and hidden gems. pfth is ANSI standardish and has shone brightly in its short lifespan. All of these have have forum support from a variety of people with varied experiences. Again, Forth is something you have to want to do for the sake of your personal relationship with Forth.
Forth is my playground. What little I try to do productively is either in Spin/PASM or C.
All my professional work has been with C, assembler, or Ada, these are what I was refering to.
Regarding forth: a well made KERNEL maybe generic enough to use on multiple projects, to serve as a starting point. But each project has different needs, and each will need a different set of development tools. When there isn't enough room to fit the whole tool box, you have to remove the tools you don't need. This is why propfroth include 14 kerneles, and provides the ability to create custom kernels easily: because Sal needs to do this often. Next version it should be easy enough that I can do it.
For me, everything is custom everytime, cause I'm a hack. Also, my experience data may well be outdated.
So, they just compiled it for each new processor, and shipped it? Or did they test it, and say, "oh Smile. gimme a couple days" and tweak it for each particular rig, despite the efforts for portability?
While the Ada was less prone to difficulties than the C, the schedule always allowed for the former, and the later ocured instead.
The lead engineers always allowed for tweak time, even for the Ada, based on past experience.
Thing is the hardware design, constructing the ADA run times and the actual control system application development can all be done at the same time.
Hardware and run-time system testing can be going on whilst the application code is being subjected to a billion unit tests run on those VAX machines.
When all that is done we get down to putting it all together and running a billion integration tests with the target "black boxes" hooked up to test rigs that simulate the aircraft actuators and sensors. I spent nearly two years writing test scripts for those integration tests as part of a team of twenty or so guys working in three shifts so as to keep the test lab in use around the clock.
I don't recall that the 777 first flight was late. And none of the 777 accidents have pointed a finger at bugs in the PFC software.
Edit: Sorry, Spin code would not have to be rewritten from scratch to move from P1 to P2 but it would have to be "tweaked".