There is an explosion of choice now in the 'Controller Module' market.
The RaspPi has pulled things a lot higher in horsepower, and they have a memory-card footprint variant coming.
The 'Ardunio' is no longer simply AVR, with TI and intel putting some sizable corporate muscle behind this area too.
All of that is good news for Prop2, as it makes an excellent real-time-add-on to any of these 'big iron' Processors.
The BeMicro CV proves you can get quite affordable FPGA boards, and it will be very interesting to see how much of
a P1+ can fit into that footprint.
Good FPGA positioning will obviously be important for design verify, but also for software tool flow development as the part moves thru the FAB.
I thought it was interesting to read what the person picked up on and what they didn't.
P1 no datasheet. There is one, and it's reasonable. Clearly, some people will glance at that, or the lack of it and move on. Unless they have a reason to dig deeper.
P1 hobby chip. Fair call there, but notably, "I think they have a C compiler" associated with the implication it's not ready, or inclusive, etc...
P2 "real soon now" and that too is a fair call. Nothing to be done about that one, but to get the chip done.
P2 512KB RAM, correct as of the latest design; however, the TBD KB RAM program storage comment was interesting! To me, it shows some effort to communicate how it is done in P-land continues to make sense. We can run a program from just about anything now on P1, and does that comment reflect that, or is it about the COG, small program memory, hub exec?
Makes me think it would be good to make sure the statement, "If you can connect it, a P2 can run a program from it" might make sense!
potatohead,
I'm pretty sure the program memory vs RAM thing comes from the typical atmel/pic/etc. designs where they have the program in flash, and the chip runs code directly from the flash, and then they have RAM for data.
You typically see things like 64KB flash program memory and 8KB RAM (or whatever combination).
I replied to the short thread there with some info to update that guys thinking (hopefully).
I think they do have a valid point that the most interesting things are done in assembly...
Without the assembly drivers running in other cores (cogs) there's not really much advantage of P1 over Arduino, is there?
But, hubexec could change that... With the new P2, should be able to do same things and even bigger in C where assembly now needed...
If we get compiled SPIN, that and C are going to challenge that idea. Agreed. On P1, yes most interesting things are done in assembly. But then again, many things on that platform are libraries, some in assembly, that people just use. Not a lot of material differences there, given how PASM can be compartmentalized in a way similar to how it's done there.
Without the assembly drivers running in other cores (cogs) there's not really much advantage of P1 over Arduino, is there?
Ouch!
But there are assembler drivers for all kinds of things. All neatly wrapped up and waiting in OBEX to be used. Using them is not any harder than using library code from C++ on an Arduino as most users do.
That makes the Propeller a very flexible device. I can select any combination of drivers and interfaces I like that fit into the COG and RAM resources. How would I drive multiple PWM servos (even up to 32) from a little ATMEL chip? Or have multiple serial ports? Etc etc.
The Arduino is a wonderful thing. The Propeller is a different wonderful thing.
I love the Propeller because it's architecture, instruction set and tools make programming in assembler very easy. It's the simplest most straight forward assembler programming environment I have ever used. For many tasks PASM is easier than writing the equivalent code in C.
That of course will not mean anything to most Arduino users and they will not want to think about assembler. That's fair enough.
One day, the Arduino will be seen as overly complex and low level. Why not just talk JavaScript to your micro-controller? http://www.espruino.com/
I find that the Arduino really has replaced basic stamp as a good place to start. It's very easy to get going. That said, once you want to make a couple things work together you start missing the propeller very fast. I think that GCC for Propeller should try to use as much arduino syntax as possible for some operations and that parallax should consider a P2 arduino platform as Arduino is no longer purely AVR specific. (or wont be shortly).
I think that GCC for Propeller should try to use as much arduino syntax as possible for some operations and that parallax should consider a P2 arduino platform as Arduino is no longer purely AVR specific. (or wont be shortly).
This has been a complicated subject to date, but it may be thawing a little since @Loopybyteloose started his Arduino software thread. Issues include:
1. Do we just get plugged in to the Arduino software environment? Someone worked on this, and I've been able to build and run it ... no test time though.
2. Can some small changes be made to SimpleIDE to make using wiring, etc... painless? (yes, but takes time).
3. Do we just package the Arduino library with SimpleIDE once everything is set up (and picking up rocks doesn't reveal tiny creatures) ?
4. Would the rest of the GCC team be interested in supporting wiring as in the RPi example?
5. Does support for wiring somehow distract from propeller strengths?
6. Does support for wiring reveal propeller weaknesses because (as some think) C/C++ are somehow inappropriate?
7. Would support for wiring demonstrate some propeller strengths?
8. Would support for wiring improve sales?
9. Other?
10. Would it just create more angst in the forums? What doesn't?
Good questions. I've talked with people on the Propeller C development team and encouraged them to do the following:
1) make libraries as similar as possible to arduino (some success)
2) Not require advanced directives in C++ mode, because arduino IDE doesn't (delayed success, still not there. Many converted libraries require C++ mode, plus i like using
some but not all C++ conventions. I like objects, for example.)
3) Think about how people can transition between them (success)
4) I'm working on a propeller C based book for LED projects. Parallax has been really helpful.
I guess my beef with the simple libraries is that it is designed as an upgrade path from basic stamps, with BASIC-like syntax. Yes, that makes sense for parallax, but i think they should make the upgrade path friendlier for arduino users, as there are a LOT more arduino users than STAMP users. You are getting a chunk of a much bigger pie.
The nice thing about the new P2 (simpler version), is that really has no weaknesses compared to any arduino (except built in HID/USB and EEPROM). It can handle just about any software task at a very high speed, even using LMM/hubexec with limitations.
I see Jazzed mentioned my efforts to learn how to port Arduino to Propeller.
Frankly, I feel a bit over my head and eating a lot of humble pie.
Here is the short story....
A. The Arduino is not one device and there are a wide range of architectural differences within the world that is called Arduinio.
B. C and C++ are dependent upon Libraries. The original ideal was Standard Libraries for portability, but anyone can create libraries that are not standard to confound, confuse, and lead astray.
C. Great confusion can evolve from #include <file name> when the exact same name is used in Arduino for one purpose and for a completely different purpose in GCC.
D. With a lot of different architectures, some Arduino applications depend heavily on conditional programing and abstracting hardware into a HAL that may not easily fit into the scheme of Propeller architecture. This is not easy for beginners to sort through as the HAL is now AVR dependent, not a universal HAL (Hardware Abstraction Layer)
E. Anyone can make a Propeller1 or Propeller2 board that will take Arduino sheilds, but that doesn't mean that the existing Arduino software code is going to migrate anywhere as easily. I have been running into ArduinoUNO code in C that accomodates 8 bit i/o ports, the Propellers just don't have this structure.
F. It just might be the GCC should hold to an ANSI C standard rather than get caught up with Wiring and Sketches and special Arduino libraries.
++++++++++++++++
Conclusion -- I am beginning to suspect that there is a side to C in the conditional compiles, adding wrappers, and developing a HAL that actually is intended to block out open sharing of C code across architecture boundaries.
Compliance with the Arduino HAL might make bulky slower code on a Propeller. I am not sure. I just know I struggle with it and see little use for keep it.
It's hopeless. An Arduino program has an "init" part and a "loop" part. This is nice way of presenting C/C++ programming to newcomers without the hassle of "main (int argc, char* argv[])" and so on. So far so good.
Now, we have the Propeller with currently up to 8 init sections and 8 loop sections. Or more if you think about stopping and starting COGS with new tasks.
The Arduino model does not fit.
On top of that I don't believe there will ever be a day when an Arduino user can take his investment in software and hardware shields over to a Propeller board, hit compile/load, and have it work.
On top of that I don't believe there will ever be a day when an Arduino user can take his investment in software and hardware shields over to a Propeller board, hit compile/load, and have it work.
The AVR/ARM/Atom Ardunio HW members cannot do that now, why expect it for a Prop ?
100% button press portability across cores is never going to be the norm, but there are many other levels where 'compatible' can work.
One of the simplest ways to help portability is 'No Surprises' - ensuring that 'using what they already know', new users can make progress on the new core.
From what I've seen, intel has put significant effort into that, but they do not claim button-press cloning.
So that leaves the question "How hard should you try to be similar?"
From the top looking down I might say "Well the Arduinos are programmed in C++ and you can use the same on the Propeller. That's good enough. Go at it"
From the bottom looking up, there are thousands of break out boards for the Arduino. I think they call them "shields". Should the Propeller try to be compatible with all of those? It probably can be. But who is going to put in all the work to make it so?
Adopting that wonky Arduino pin out that only exists due to an error in design back in the day is not enough.
There is a whole ecosystem to fit into. Not so easy.
I don't think Propeller C programs *written for the Propeller* have to be exactly like Arduino. In fact, that would defeat the purpose of offering a unique controller. There obviously must be unique keywords for setting up processes in a given core, for example. It would be nice if simple sketches could compile under Prop C, using some clever repurposing of keywords -- for example, the Arduino hardware interrupts could use Propeller-based techniques, but without exposing the technicalities to the casual programmer.
This is all about leveraging existing skill sets. Schools and industry are not interested in specialty languages. There is nothing wrong with PBASIC or Spin, but to someone who is looking for an education in embedded systems, they'll pick something that is C-based 95%+ of the time, because they know that's the "standard in the industry." If they want a job in the industry they need to know C.
A SPECIFIC Propeller-based board can be nearly 100% Arduino Uno hardware compatible. This allows it to be shield compatible, and so extends the market of the Propeller. Would that not be a good thing? To be hardware compatible it has to provide on-board logic level shifting, six analog inputs (for the Prop1), and a few other things. We've seen this is possible with Martin's board. The Propeller chip itself doesn't need to emulate an AVR, nor would you want it to.
From the bottom looking up, there are thousands of break out boards for the Arduino. I think they call them "shields". Should the Propeller try to be compatible with all of those? It probably can be. But who is going to put in all the work to make it so?
Complicating this, is that the first AVR designs were 5V, and some micros pushing into this space are now 3V.
Some vendors ignore the 3V problem, but others have solutions like this, http://coocox.org/epi.html
which covers both 3V/5V Shields and RasPI connection.
I think the P2 solutions will need to use similar Level Translators, to do this properly.
The number of 5V ARM vendors is growing, so this gives another way to solve the 3V issue.
This is one example http://coocox.org/Cookie.html
- but perhaps a little light-weight on the CPU, however Nuvoton do have M4's sampling in 5V, so a M4 version of this is easy enough to do.
A couple of things are kind of funny. The init/loop thing is added into the editor main() init(); while (1) loop(); ; , otherwise the wiring is really C/C++ with a few rules loosened. They even use the GCC compiler as part of the Arduino IDE. Accessing memory is a real pain on the thing, though.
Parallax users and the Propeller coders might find themselves struggling to hit a moving target.
While the ArduinoUno, Due, etc might be fairly well established standards in both hardware and code; the extension of Arduino (as a concept, as a paradigm, as a 'brand') in more varieties of architecture and shifting from 5V devices to 3.3V devices might just break whatever it is that people consider Arduino.
Ambitous expansions that are presumed to be supported by free authors of code and documentation do run out of steam on their own. At some point, people just feel that they have written enough and learned enough that they should go 'proprietary' and get some income out of their efforts.
Having a lot of different platforms that are called Arduino is going to seriously challenge Arduino's ability to keep together a standard. Conditional compiles do a lot of the work, and I have doubts that that is a good thing. It shifts the focus away from learning what the code actually does.
My own personal experience with conditional compiling for multiple devices began with the expansion of the BS2 into the BS2xx and the variety SX chips. I found that I was getting code examples that had pages of preamble and a degree of abstraction that I have to first remove to learn anything from the code. Senix SX examples were highly counter-productive to newcomers learning from them.
Arduino is headed in that same direction. And I think that it generally makes new users ignore learning what the code is really doing and just become a nest full of chicks that never learn enough to fly on their own. They expect to use the internet and search engines to find a library or example that will suffice.
What was refreshing about the original Arduino is that it was easy, the documentation offered comparative brevity, and of course the cost was reasonable.
++++++++++++
I just suspect that honeymoon is over.
As it is, to port Arduino to the Propeller ... I have to learn all of the Propelleruino library just to know what's available and feasible. And I have know quite a bit about the Arduino architecture that the code originally targeted. If the code targets a wide variety of Arduino architectures, I have to break through the conditional compile and set up files that often combine choices of which Arduino is to be selected with choices of targeted hardware and interfaces (it would be easier if these were is separate files).
I am learning a lot that is making me a better coder, but this is a nightmare for the naive beginner.
The more I think about it, the more it seems very obvious that a conservative approach might be best.
A. Provide a clear welcome to having Propeller code for specific Arduino Shields that are submitted to OBEX.
B. Develop porting Arduino code step-by-step in particular platform specific solutions ... ArduinoUNO, and beyond.
C. Avoid the creation of one package that is supposed to do it all. It maybe possible, the resulting code will likely offer very little to most people that want to read code to learn. Only the most geekish will appreciate such orchestration.
Actually when I first ever considered that there might one day be a C compiler for the Prop, when Bill invented LMM, I thought generating COG code would be useless. COG space is so small right? Wrong, the GCC guys did wonders with this.
The C version of the heater_FFT runs nearly as fast as the hand-crafted PASM version. Why? Because GCC compiles the inner loops to native PASM and runs them in COG with FCACHE. That code is portable C that runs petty much anywhere.
I managed to make a C version of FullDuplexSerial in COG that works up to 115200 baud. Not bad. That's not portable but some folks might be happier creating medium speed bit-banging drivers in C rather than assembler.
Edit: I do expect the C version of FDS to be portable from P1 to P2 with no code changes at all. Or at least be able to fix it up so that the same code runs on both.
Other edit: That FFT, with a few standard OpenMP directives added can run it's inner loops in two, four or more COGS for a bit of a boost.
Hi Heater,
I started another thread on the question of how to get a Watchdog timer in C for an Arduino port, and how to not waste a whole Cog for the one function. So I am considering having the cog deploy other Arduino-similar timer functions at the same time.
It seems like I might require Cog C to deploy that. But how does that integrate into other cogs deployed for other purposes?
I don't have much idea how the watchdog works on AVR's or how Arduino uses it but I would imagine:
1) It's a hardware timer.
2) It get's reset by the user software at regular intervals.
3) If the software crashes and burns the reset is not done, the watchdog times out and causes a reset.
As such I have to ask: "Is it even possible to build such a watchdog in software."
But, let's say a COG is dedicated to a watchdog function and it runs without any dependency on external code. That's almost as robust as a real hardware watchdog. Except for the fact that errant code in other COGs can stop the watch dog running, say by doing a COGINIT on it. So such a watchdog is not as totally fail-safe as a real one. Is that good enough? I would say no but you may disagree.
It's a while since I looked at this but if I understand correctly with GCC if you put the code intended to be run in a COG in a source file with the .cogc extension it will get compiled correctly for COG use and can be started with a coginit call in your main program.
At least I think that's what SimpleIDE does now. I did it all with Makefiles and compiler options back in the day.
After that "integration" proceeds the same as any other Propeller code. You are sharing variables in HUB RAM between COGS. You will have passed pointers around to give access to shared data. Much the same as you do in Spin.
Cool, but pointless. A C compiler will only ever use about 10-20% of all the available opcodes on the Propeller (yes, you can use "inline" - but that's really just using PASM in a C "wrapper"). You can argue this exact percentage if you like, and I would probably concede you could get it up to 20-30% if you were willing to spend enough years of development on the C compiler.
But this is still pointless. Most cog objects will continue to be hand-coded in PASM on any Propeller. Being able to execute C code in a cog is a really cool feature (and I may one day add it to Catalina - but I won't make the mistake of pretending it is anything other than a gimmick) - the Propeller architecture is simply not designed for efficient execution of high-level languages, unlike the AVR or ARM architectures. And in a way, that's what makes the Propeller so attractive.
If the compiler can take normal everyday C code and compile inner loops to native PASM and load them to COG for execution then and get almost the same performance as hand written PASM. With no special effort on the part of the programmer...Then I would say it has great utility.
Compiling source code to native instruction is what C compilers are expected to do. If a compiler can't do that then it's pretty pointless
Franklin
Posts: 4,747
Comments
The RaspPi has pulled things a lot higher in horsepower, and they have a memory-card footprint variant coming.
The 'Ardunio' is no longer simply AVR, with TI and intel putting some sizable corporate muscle behind this area too.
All of that is good news for Prop2, as it makes an excellent real-time-add-on to any of these 'big iron' Processors.
The BeMicro CV proves you can get quite affordable FPGA boards, and it will be very interesting to see how much of
a P1+ can fit into that footprint.
Good FPGA positioning will obviously be important for design verify, but also for software tool flow development as the part moves thru the FAB.
P1 no datasheet. There is one, and it's reasonable. Clearly, some people will glance at that, or the lack of it and move on. Unless they have a reason to dig deeper.
P1 hobby chip. Fair call there, but notably, "I think they have a C compiler" associated with the implication it's not ready, or inclusive, etc...
P2 "real soon now" and that too is a fair call. Nothing to be done about that one, but to get the chip done.
P2 512KB RAM, correct as of the latest design; however, the TBD KB RAM program storage comment was interesting! To me, it shows some effort to communicate how it is done in P-land continues to make sense. We can run a program from just about anything now on P1, and does that comment reflect that, or is it about the COG, small program memory, hub exec?
Makes me think it would be good to make sure the statement, "If you can connect it, a P2 can run a program from it" might make sense!
I'm pretty sure the program memory vs RAM thing comes from the typical atmel/pic/etc. designs where they have the program in flash, and the chip runs code directly from the flash, and then they have RAM for data.
You typically see things like 64KB flash program memory and 8KB RAM (or whatever combination).
I replied to the short thread there with some info to update that guys thinking (hopefully).
Without the assembly drivers running in other cores (cogs) there's not really much advantage of P1 over Arduino, is there?
But, hubexec could change that... With the new P2, should be able to do same things and even bigger in C where assembly now needed...
@Roy: Of course! That makes a lot of sense.
But there are assembler drivers for all kinds of things. All neatly wrapped up and waiting in OBEX to be used. Using them is not any harder than using library code from C++ on an Arduino as most users do.
That makes the Propeller a very flexible device. I can select any combination of drivers and interfaces I like that fit into the COG and RAM resources. How would I drive multiple PWM servos (even up to 32) from a little ATMEL chip? Or have multiple serial ports? Etc etc.
The Arduino is a wonderful thing. The Propeller is a different wonderful thing.
I love the Propeller because it's architecture, instruction set and tools make programming in assembler very easy. It's the simplest most straight forward assembler programming environment I have ever used. For many tasks PASM is easier than writing the equivalent code in C.
That of course will not mean anything to most Arduino users and they will not want to think about assembler. That's fair enough.
One day, the Arduino will be seen as overly complex and low level. Why not just talk JavaScript to your micro-controller? http://www.espruino.com/
1. Do we just get plugged in to the Arduino software environment? Someone worked on this, and I've been able to build and run it ... no test time though.
2. Can some small changes be made to SimpleIDE to make using wiring, etc... painless? (yes, but takes time).
3. Do we just package the Arduino library with SimpleIDE once everything is set up (and picking up rocks doesn't reveal tiny creatures) ?
4. Would the rest of the GCC team be interested in supporting wiring as in the RPi example?
5. Does support for wiring somehow distract from propeller strengths?
6. Does support for wiring reveal propeller weaknesses because (as some think) C/C++ are somehow inappropriate?
7. Would support for wiring demonstrate some propeller strengths?
8. Would support for wiring improve sales?
9. Other?
10. Would it just create more angst in the forums? What doesn't?
1) make libraries as similar as possible to arduino (some success)
2) Not require advanced directives in C++ mode, because arduino IDE doesn't (delayed success, still not there. Many converted libraries require C++ mode, plus i like using
some but not all C++ conventions. I like objects, for example.)
3) Think about how people can transition between them (success)
4) I'm working on a propeller C based book for LED projects. Parallax has been really helpful.
Frankly, I feel a bit over my head and eating a lot of humble pie.
Here is the short story....
A. The Arduino is not one device and there are a wide range of architectural differences within the world that is called Arduinio.
B. C and C++ are dependent upon Libraries. The original ideal was Standard Libraries for portability, but anyone can create libraries that are not standard to confound, confuse, and lead astray.
C. Great confusion can evolve from #include <file name> when the exact same name is used in Arduino for one purpose and for a completely different purpose in GCC.
D. With a lot of different architectures, some Arduino applications depend heavily on conditional programing and abstracting hardware into a HAL that may not easily fit into the scheme of Propeller architecture. This is not easy for beginners to sort through as the HAL is now AVR dependent, not a universal HAL (Hardware Abstraction Layer)
E. Anyone can make a Propeller1 or Propeller2 board that will take Arduino sheilds, but that doesn't mean that the existing Arduino software code is going to migrate anywhere as easily. I have been running into ArduinoUNO code in C that accomodates 8 bit i/o ports, the Propellers just don't have this structure.
F. It just might be the GCC should hold to an ANSI C standard rather than get caught up with Wiring and Sketches and special Arduino libraries.
++++++++++++++++
Conclusion -- I am beginning to suspect that there is a side to C in the conditional compiles, adding wrappers, and developing a HAL that actually is intended to block out open sharing of C code across architecture boundaries.
Compliance with the Arduino HAL might make bulky slower code on a Propeller. I am not sure. I just know I struggle with it and see little use for keep it.
It's hopeless. An Arduino program has an "init" part and a "loop" part. This is nice way of presenting C/C++ programming to newcomers without the hassle of "main (int argc, char* argv[])" and so on. So far so good.
Now, we have the Propeller with currently up to 8 init sections and 8 loop sections. Or more if you think about stopping and starting COGS with new tasks.
The Arduino model does not fit.
On top of that I don't believe there will ever be a day when an Arduino user can take his investment in software and hardware shields over to a Propeller board, hit compile/load, and have it work.
It seems a bit unrealistic to me.
The AVR/ARM/Atom Ardunio HW members cannot do that now, why expect it for a Prop ?
100% button press portability across cores is never going to be the norm, but there are many other levels where 'compatible' can work.
One of the simplest ways to help portability is 'No Surprises' - ensuring that 'using what they already know', new users can make progress on the new core.
From what I've seen, intel has put significant effort into that, but they do not claim button-press cloning.
I agree.
So that leaves the question "How hard should you try to be similar?"
From the top looking down I might say "Well the Arduinos are programmed in C++ and you can use the same on the Propeller. That's good enough. Go at it"
From the bottom looking up, there are thousands of break out boards for the Arduino. I think they call them "shields". Should the Propeller try to be compatible with all of those? It probably can be. But who is going to put in all the work to make it so?
Adopting that wonky Arduino pin out that only exists due to an error in design back in the day is not enough.
There is a whole ecosystem to fit into. Not so easy.
This is all about leveraging existing skill sets. Schools and industry are not interested in specialty languages. There is nothing wrong with PBASIC or Spin, but to someone who is looking for an education in embedded systems, they'll pick something that is C-based 95%+ of the time, because they know that's the "standard in the industry." If they want a job in the industry they need to know C.
A SPECIFIC Propeller-based board can be nearly 100% Arduino Uno hardware compatible. This allows it to be shield compatible, and so extends the market of the Propeller. Would that not be a good thing? To be hardware compatible it has to provide on-board logic level shifting, six analog inputs (for the Prop1), and a few other things. We've seen this is possible with Martin's board. The Propeller chip itself doesn't need to emulate an AVR, nor would you want it to.
Complicating this, is that the first AVR designs were 5V, and some micros pushing into this space are now 3V.
Some vendors ignore the 3V problem, but others have solutions like this,
http://coocox.org/epi.html
which covers both 3V/5V Shields and RasPI connection.
I think the P2 solutions will need to use similar Level Translators, to do this properly.
The number of 5V ARM vendors is growing, so this gives another way to solve the 3V issue.
This is one example
http://coocox.org/Cookie.html
- but perhaps a little light-weight on the CPU, however Nuvoton do have M4's sampling in 5V, so a M4 version of this is easy enough to do.
Freescale also have 5V ARM's
While the ArduinoUno, Due, etc might be fairly well established standards in both hardware and code; the extension of Arduino (as a concept, as a paradigm, as a 'brand') in more varieties of architecture and shifting from 5V devices to 3.3V devices might just break whatever it is that people consider Arduino.
Ambitous expansions that are presumed to be supported by free authors of code and documentation do run out of steam on their own. At some point, people just feel that they have written enough and learned enough that they should go 'proprietary' and get some income out of their efforts.
Having a lot of different platforms that are called Arduino is going to seriously challenge Arduino's ability to keep together a standard. Conditional compiles do a lot of the work, and I have doubts that that is a good thing. It shifts the focus away from learning what the code actually does.
My own personal experience with conditional compiling for multiple devices began with the expansion of the BS2 into the BS2xx and the variety SX chips. I found that I was getting code examples that had pages of preamble and a degree of abstraction that I have to first remove to learn anything from the code. Senix SX examples were highly counter-productive to newcomers learning from them.
Arduino is headed in that same direction. And I think that it generally makes new users ignore learning what the code is really doing and just become a nest full of chicks that never learn enough to fly on their own. They expect to use the internet and search engines to find a library or example that will suffice.
What was refreshing about the original Arduino is that it was easy, the documentation offered comparative brevity, and of course the cost was reasonable.
++++++++++++
I just suspect that honeymoon is over.
As it is, to port Arduino to the Propeller ... I have to learn all of the Propelleruino library just to know what's available and feasible. And I have know quite a bit about the Arduino architecture that the code originally targeted. If the code targets a wide variety of Arduino architectures, I have to break through the conditional compile and set up files that often combine choices of which Arduino is to be selected with choices of targeted hardware and interfaces (it would be easier if these were is separate files).
I am learning a lot that is making me a better coder, but this is a nightmare for the naive beginner.
A. Provide a clear welcome to having Propeller code for specific Arduino Shields that are submitted to OBEX.
B. Develop porting Arduino code step-by-step in particular platform specific solutions ... ArduinoUNO, and beyond.
C. Avoid the creation of one package that is supposed to do it all. It maybe possible, the resulting code will likely offer very little to most people that want to read code to learn. Only the most geekish will appreciate such orchestration.
I recall certain people saying that it was silly for GCC to do that from the start ;-)
It will be a lot less silly when some of that moves to the next chip fairly easily.
But, it's a nice capability now, and it works. All good as far as I am concerned.
Actually when I first ever considered that there might one day be a C compiler for the Prop, when Bill invented LMM, I thought generating COG code would be useless. COG space is so small right? Wrong, the GCC guys did wonders with this.
The C version of the heater_FFT runs nearly as fast as the hand-crafted PASM version. Why? Because GCC compiles the inner loops to native PASM and runs them in COG with FCACHE. That code is portable C that runs petty much anywhere.
I managed to make a C version of FullDuplexSerial in COG that works up to 115200 baud. Not bad. That's not portable but some folks might be happier creating medium speed bit-banging drivers in C rather than assembler.
Edit: I do expect the C version of FDS to be portable from P1 to P2 with no code changes at all. Or at least be able to fix it up so that the same code runs on both.
Other edit: That FFT, with a few standard OpenMP directives added can run it's inner loops in two, four or more COGS for a bit of a boost.
In COG C is very cool.
I started another thread on the question of how to get a Watchdog timer in C for an Arduino port, and how to not waste a whole Cog for the one function. So I am considering having the cog deploy other Arduino-similar timer functions at the same time.
It seems like I might require Cog C to deploy that. But how does that integrate into other cogs deployed for other purposes?
I don't have much idea how the watchdog works on AVR's or how Arduino uses it but I would imagine:
1) It's a hardware timer.
2) It get's reset by the user software at regular intervals.
3) If the software crashes and burns the reset is not done, the watchdog times out and causes a reset.
As such I have to ask: "Is it even possible to build such a watchdog in software."
But, let's say a COG is dedicated to a watchdog function and it runs without any dependency on external code. That's almost as robust as a real hardware watchdog. Except for the fact that errant code in other COGs can stop the watch dog running, say by doing a COGINIT on it. So such a watchdog is not as totally fail-safe as a real one. Is that good enough? I would say no but you may disagree.
It's a while since I looked at this but if I understand correctly with GCC if you put the code intended to be run in a COG in a source file with the .cogc extension it will get compiled correctly for COG use and can be started with a coginit call in your main program.
At least I think that's what SimpleIDE does now. I did it all with Makefiles and compiler options back in the day.
After that "integration" proceeds the same as any other Propeller code. You are sharing variables in HUB RAM between COGS. You will have passed pointers around to give access to shared data. Much the same as you do in Spin.
Cool, but pointless. A C compiler will only ever use about 10-20% of all the available opcodes on the Propeller (yes, you can use "inline" - but that's really just using PASM in a C "wrapper"). You can argue this exact percentage if you like, and I would probably concede you could get it up to 20-30% if you were willing to spend enough years of development on the C compiler.
But this is still pointless. Most cog objects will continue to be hand-coded in PASM on any Propeller. Being able to execute C code in a cog is a really cool feature (and I may one day add it to Catalina - but I won't make the mistake of pretending it is anything other than a gimmick) - the Propeller architecture is simply not designed for efficient execution of high-level languages, unlike the AVR or ARM architectures. And in a way, that's what makes the Propeller so attractive.
Ross.
If the compiler can take normal everyday C code and compile inner loops to native PASM and load them to COG for execution then and get almost the same performance as hand written PASM. With no special effort on the part of the programmer...Then I would say it has great utility.
Compiling source code to native instruction is what C compilers are expected to do. If a compiler can't do that then it's pretty pointless