Oddly enough the areas where the Prop could shine, it's advocates instead ignore it.
Earlier a poster was asking if someone could port several languages used in industrial control standard IEC 61131. Zero interest in a Prop PLC with LL and ST. Heck this should have been done a year or two ago.
That said, C will probably be relegated to apps that are not compute intensive because of the performance hit C takes on the Prop. If you want anything near the full ability of the Cog, PASM is the only route.
Not zero interest, just zero time! I agree that this could be a "niche" area where the Prop might shine.
As heater and I have both pointed out, PASM is fine if you can fit your application in 512 longs. After that, you are going to get a significant slowdown whether you're using PASM, LMM PASM, C, Basic or SPIN. It's not fair to call this a "performance hit" for C - it's a consequence of the Prop architecture and applies to any language once you go beyond the 512 long barrier (or even before that if you need to fetch or store data outside the cog itself).
I think the Prop will begin to shine when people acknowledge that there is no single "one language fits all" solution. Use PASM if it suits. Use C if it suits. Use SPIN if it suits.
For me, the most potent and interesting combination is many cogs running C, implementing the complexities of a concurrent main application, plus a few cogs running PASM for stuff that is not so complex but which just has to run "like the clappers".
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Milke Green said...
The big difference is that C comes with a very large library of subroutines and functions that are part of the standard. You can force the compiler to not use the library, but it's not pretty and not the default and it makes a lot of assumptions about what hardware is available. A really good optimizing compiler can minimize what gets dragged in, but the C user has to be careful about how things are written.
I'm not with you on this one. What compilers are you referring to?
My Zog interpreter runs C code compiled with GCC. There are only some basic library things available, like strcmp, memcpy, printf. etc. But anyway if I don't use them in a program they don't get linked in. There is no "forcing" the compiler to not use the library. There is nothing "not pretty" about it. The simplest compile of a main program with no printf etc in it produces a very small executable.
Moving on you may have noticed my experiments with C++ which is famous for producing being bloated and huge code. Well, turns out that used in a way that is sensible on an MCU it produces the same small code as C.
Don't forget that the Arduino uses C++ on tiny little AVRs to good effect. It uses GCC. It is a breeze to program in the Arduino IDE or using you favorite editor and the command line tools.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
All you've shown is that it's not the C++ compiler that produces huge bloated programs. So you're saying the fault lies with the C++ programmer?
Ross.
P.S. I agree with you about the C library - I quite often write C programs that do not link with the standard C library at all. You can write very useful programs that do not need it - especially in embedded environments.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
@Ross: True, I have not seen your multi processor demo. I have done, and so no doubt many others, made leds flash with different cogs in parallel. Seriously though it is not my point. I am sure when the need is there, there will be a solution in the prop.
In the meantime, the intelligent peripherals is a real case. Noone seems to be taking this seriously. Once you have coded the small parts required in pasm your main code is most likely not time sensitive any more, so C or Spn will be fine.
@Leon: The code to do SPI, I2C, etc are already done (in pasm and also done in spin). But, the addiition for intelligent processing of that data can be done in pasm (or spin in other cogs for FAT16/32 handling). Similarly with VGA and TV. These are all things that have to be done on 1 processor in other micros (PIC, AVR, etc) excluding the "other" micro. Once you have to process all these things in 1 cpu, the timing becomes a major issue, interrput latency, and all the other things. These just simply are just not a problem with the prop and here is where we should be pushing it's advantages.
I should also add, that any professional will find it quite easy to take an existing object and add to it what they want. This forum is great for helping those learn anything they do not understand. They only have to ask and within hours they will have lots of answers, particularly if they are well thought out questions that taxes the minds. We direct the level of the answer to the assumed level of the asker.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso said...
In the meantime, the intelligent peripherals is a real case. No one seems to be taking this seriously.
I take it seriously. In fact I think that is the only sensible way to use a Propeller.
Potentially one could partition the high level non-time critical part into a couple or so threads but the principle is the same.
1) The high speed peripheral device code is in the COGs
2) There is often space left over in those COG for more intelligence which tends to go unused at the moment.
Case in point:
FullDuplexSerial is not so big PASM wise. That means those Spin functions it has for HEX DEC I/O could well be in PASM in the COG.
Or higher level parts of any serial line could be added into the COG as well.
Basically I'm sure there is a lot of capacity in COG space that is generally wasted. Not to mention that normally COG DAT sections are wasting space in HUB after the COG is loaded, but that is another issue.
Problem is, all this extra functionality is kind of application specific. So you won't see it turn up on OBEX much. And it's kind of non trivial to integrate application specific bits of PASM into an existing object like FDX.
Perhaps with the arrival of tools that compile BASIC or other high level (ish) language to PASM that integration of different PASM parts into one COG could become easier and more widely used.
Hmmm...Thinks, perhaps I should re-target my version of Jack Crenshaws TINY language to raw PASM COG code rather than LMM....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso99 said...
@Ross: True, I have not seen your multi processor demo. I have done, and so no doubt many others, made leds flash with different cogs in parallel. Seriously though it is not my point. I am sure when the need is there, there will be a solution in the prop.
Hang on. I have a fruit machine program that uses 3 render cogs using identical code with a separate offset, and my propscope code uses 4 identical cogs using a separate offset. Doesn't that count as effective use of SMP ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Absolutely! I think we may just have found our "killer app"!
The fruit machine was my first real prop code after the USB stack. It used a modified version of Potatoheads tv driver that alternated between 2 lines in memory, and three cogs simultaneously rendered each display line while the previous was being clocked out. I thought it was cool [noparse]:)[/noparse]
The first bitmap I used for one of the cards was a Vegemite icon [noparse]:)[/noparse]
In all honesty the code was not very clever, but I thought it was at the time.
It was completely written, compiled and downloaded on Linux though using no Parallax tools, which was a first for me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
The I2C and SPI stuff for peripherals I was referring to were for C compilers. I know they are available in PASM, I've even used them. Are they just as efficient when using the C versions. Perhaps they are written in PASM, also.
I've just downloaded Catalina C, I'll have a play with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Not sure what you mean exactly Leon but Zog uses the PASM guts extracted from FullDuplexSerial.spin and Bills VMCog.spin directly from C with no Spin code anywhere on the chip after starting the C system.
I guess Catalina does something like that as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I was wondering if, say, there is an SPI function in the Catalina library, and whether it is written in C or PASM. I see from the manual that it can use standard PASM drivers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Catalina can use modified versions of most standard Parallax (or Parallax-style) drivers - the modifications required are spelled out in the Catalina documents. I have not bothered to modify them all, since I generally only do them as I need them myself.
Catalina drivers are generally written in PASM. I've not found a need to write any drivers of my own, so there are none written in C.
I have not modified a general purpose SPI driver, but there are specific drivers for SPI devices such as SD Cards. Look at the file 'Catalina_SD_Plugin_Input.spin' - it is a fairly standard SPI driver (in this case the 'spsdi' driver developed by Radical Eye Software) modified to turn it into a Catalina plugin. This should provide all the information you might need on how to modify other similar drivers.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Brad: Yes, thats a SMP program. They unfortunately seem to be in the minority. Of course now you mention it, so does my datalogger - it uses 4 cogs to clock external pin data into memory on each successive clock cycle (12.5ns @ 80MHz or 10ns @ 100MHz).
I do think that rendering cogs is an excellent application, and one that is easy for people to actually see the results. This would be an excellent demo of the props capabilities. Perhaps you might see if you could find the time to tart up the code. Perhaps I could do the same for the datalogger (I was storing and then displaying on the PC) and display on the screen, like Beau? originally did with his version. These could make some exciting demos of the abilities of the prop.
Any other ideas???
As far as the Intelligent Peripherals, I agree that they tend to be app specific. That is OK though - the work would be done anyway as part of the main code in a single cpu micro. Here we have the advantage to relegate it to another process and remove the timing constraints from the main code. This is a definate advantage for the prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Shortly after the Prop came out·(perhaps it was the advertising contest thread, near the 1 year anniversary), Ken said that it took about 5 years for engineers to recognize and start using Parallax product. While it may look from the outside like the Prop should be doing better in the industrial markets, it looks to me·as though·Parallax has nearly all its ducks in a row.··········
> My wife is always telling me that men are lousy at multi-tasking. ??
Men lousy at multi-tasking? Mostly an urban myth propagated by some husbands as part of the conspiracy.
Parallelism? The conspiracy has revealed itself... or has reached another level entirely.
Most EE engineers get exposure as part of their curriculum/class projects to 'mainstream' MCUs in college and when they graduate tend to stick with what they know when they design new products. How many engineers have you seen that have old calculators that they used in their college days? We stick with what we are most familiar and comfortable with. Furthermore companies and management will tend to stick with what works rather than take a risk...their POR having been established long ago by once upon a time EE students with their preferences. So the odds are stacked against companies like Parallax due to this phenomena.
To pull attention you need to out perform your competition and ease the transition for a skeptical engineer. For the Prop to succeed it would need to address items like....
1) An efficient C compiler...i.e. compiles to very low count ASM and follows industrial standards.
2) Address interrupts, the industry depends on deterministic processing..interrupts can be simulated by allocating a cog to monitoring one or more trigger sources but the poor engineer mainly motivated by coffee has to do more work. Why would he/she want to?
3) DMA
4) Dedicated hardware peripheries...specifically ADC & USB but not necessarily SPI, i2C, UARTs, etc....hacking ADCs with capacitors and resistors might work for hobbyist but not in industry where calibrating channels and verifying they meet specs consistently is like reinventing the wheel. A hard sell for all involved in new product design from upper management down to the design engineer.
5) I/O that meets the competitor's offerings, pull-ups, open drain and so on.
6) Internal EEPROM for program memory...this assures code security.
Suppose you are an engineer designing a product. In one hand the a PIC with integrated USB and ADC both of which the product needs and the other the Prop I. The negatives for the Prop based design implementation would be...
1) Need to add a USB chip
2) Need to have an external EEPROM
3) Need to have an external ADC
4) Need to add pull-ups on the digital lines (SD card, buttons, EEPROM and so on)
How do you sell the added cost of the external components to your manager? What about the extra layout complexity and space? What about the extra layout work on your part, do you want to do that? What of the extra code complexity of communicating with the external ADC and USB?
Prop Pros...
1) 160 MIPS, is hard to beat
2) Video Generators
3) Copious counters
4) 32 bit bus
5) Lack of complexity..other PICs have copious registers, modes and so on...this is not to mention the Erratas which cause product selection to become difficult. This is the downside to integrating peripheries, bug bugs bugs...so SPI, I2C and UARTs should be software driven...Erratas are a pain to navigate, Parallax could leverage this weakness of other processors.
6) True programming concurrency...most designs don't require this but some do, in either case programming tasks becomes much easier.
Post Edited (Miner_with_a_PIC) : 7/26/2010 5:41:44 PM GMT
Miner_with_a_PIC said...
Most EE engineers get exposure as part of their curriculum/class projects to 'mainstream' MCUs in college and when they graduate tend to stick with what they know when they design new products. How many engineers have you seen that have old calculators that they used in their college days? We stick with what we are most familiar and comfortable with.
Consider introducing the prop in colleges, in addition to the spectrum of micro-controllers that are already standard.
Relevant point could be: interrupts vs no interrupts
Adding additional u-controllers vs a multi-core solution
Descrete resources (as on new 8051s) versus resources from software object
I'm thinking about a package for homeschooling engineering curriculum. Alas, I'm not in education, so the going is slow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world: those who understand binary, and those who don't
I agree with many of your points, but I'm not sure about point 2 (interrupts). But perhaps I'm misunderstanding it - interrupts don't make a program deterministic, they do the opposite:
Stephen Brosky, Chief Scientist, Concurrent Computer Corp. ** said...
The largest source of non-deterministic program execution in any type of computer system is external interrupts. Interrupts can occur at any point in time during a program’s execution and can preempt program execution for as little as 50 microseconds to as much as several milliseconds. An interrupt is always scheduled at a higher priority than any program level execution, so even interrupts associated with low priority processes can affect the execution of a high priority process. A real-time kernel makes every attempt to minimize the length of its interrupt service routines. However, even when the time spent at interrupt level has been minimized – the delays caused by processing interrupts are generally unacceptable in a hard real-time environment.
Interrupts can also dramatically complicate an otherwise simple program, and are also a common source of bugs that can be almost impossible to track down since they may only occur under obscure run-time conditions.
One of the key advantages of the Propeller is that it is a symmetric multiprocessing system that doesn't need interrupts to do what other processors most commonly use them for - i.e. either responding to external events in real-time, or to simulate multi-tasking. In fact, interrupts are the means other processors must use to simulate what symmetric multiprocessing systems like the Propeller do naturally.
We need to move people away from the interrupt model and guide them into thinking how to solve problems using symmetric multiprocessing instead. If we fail to exploit this capability, the Propeller loses much of its unique attraction.
As to the need to use external chips, I agree that if you need to add too many external chips to achieve your goal then you've probably chosen the wrong base MCU to start with. But the number of aplications where you don't need any external components is rare.
We need to identify the kind of applications for which the Propeller typically requires a lower number of external components than it's competitors, or where the need for its unique capabilities (like symmetric multiprocessing) make the number of external components irrelevant.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
[noparse][[/noparse]quote=Miner_with_a_PIC]Address interrupts, the industry depends on deterministic processing..interrupts can be simulated by allocating a cog to monitoring one or more trigger sources but the poor engineer mainly motivated by coffee has to do more work. Why would he/she want to?
I'm flabbergasted. You have been here long enough to know better. How backwards can that statement be?
Yes, often deterministic timing is required. And that's what the Prop provides. But really "interrupts can be simulated". It's the other way around. Interrupts are a poor way of simulating simultaneous execution of threads. Interrupts are what you have to do when you only have one CPU. In my experience "the poor engineer" would rather do less work by having multiple cores than have to fight with the cludge that is interrupts. Especially when the are multiple sources of external events, all with different timing requirements that have to somehow be prioritized to work together.
Note:. Actually I don't think you can "simulate interrupts" on the Prop. A Cog running some code cannot be stalled, stopped or otherwise messed up by events in the rest of the chip (apart from reset and clock frequency changes). That is the beauty of the Prop. That's what makes it so easy to mix and match any old objects you find for an application.
If you want interrupts you really want a totally different architecture. The fact that the Prop has no interrupts and does not need them is one of it's main reasons for being.
Ah, but I see you don't really want interrupts, as you state in your last paragraph about Prop pros..." 6) True programming concurrency...."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think something like an interrupt model could be useful where 8 cogs isn't sufficient, and certain routines don't require a dedicated cog anyways. Sure, you can combine many of those routines in a single object, especially with LMM or the spin, but I think this adds complexity to an object. I know what you're thinking, but just bear with me. Here's a thought that has been recently floating around in my brain:
Lets say you have your main program running in cog 0, you have another cog (call it overlord cog) waiting for the various states that would require the execution of an ISR.. Then you also have several cogs running (perhaps a LMM loop), waiting to execute whatever ISR the overlord cog requests. Once the execution is complete, the cog returns back to it's initial state, waiting to execute another request. If an additional ISR needs to be handled while one is already being executed, the next available ISR cog would run the requested routine, and so on.
I'd like to think that this would be simpler than combining multiple objects into a single object because there are not enough available cogs. But alas, I'm not much of a programmer, so I'm probably wrong.
Hm,
am I the only one here, who has worked with interrupts and found them to be very helpful and not toooo complicated? Of course I had the help of good compilers which do a good part of the work.
I once suggested to implement polled interrupts into PropBasic. After each (of n-th?) BASIC instruction, the compiler could code a call to a user defined routine to check, if there is anything to be done. I think this could be very helpful sometimes. Of course you have to be aware of possible sideeffects and of course it is less complicated, if you can spend a dedicated cog.
That would suggest that all of the cogs waiting to do the ISR type routines contained the code for all routines, it doesn't sound like anything has been gained.
Christof,
I think it depends a lot on the application, the amount of hardware you have letting you off the hook (essentially acting like a single function processor) and how often multiple interrupts raise their head.
A polled interrupt? Isn't that rather like normal coding? I often check something periodically in a loop, works fine as long as the loop period is shorter than the requirement to act on the event, checking for a key press is a good example.
Also known as 'Wasted cycles' or 'Delay Included'?
To fit that into the various Basic Stamps and you wanted would probably require a complete rewrite of the onboard interpreter, to make it even halfway responsive. And that would mean a speed-loss for everyone else who doesn't need the functionality, but still gets the BS with that code revision. And well... the BS MCUs aren't exactly speed demons...
I've done interrupts...
On 8051, 8085, Z80... Looked at it on assorted PIC and AVRs, but gave up.
Have seen what 'pro dev. tools' make out of interrupts on Z80, and shudder.
(It's a hobby, picking apart code)
Maybe the Prop needs more supporting ICs than some, but...
As the functions can be tied to any pin on it, unlike other MCUs, board-layout can be greatly simplified.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Leon said...
That's not quite true. Newer 16-bit PICs have a feature called "Peripheral Pin Select".
Which greatly simplifies board layout. I strayed away from the PIC's for a few years (after all, who could love the bletcherous 14 bit instruction set), but the dsPIC33F has brought me right on back. They make a fantastic sibling to a Prop with a fast SPI connection between the two, and you have to love the dual single-cycle 40 bit MAC units.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Comments
Earlier a poster was asking if someone could port several languages used in industrial control standard IEC 61131. Zero interest in a Prop PLC with LL and ST. Heck this should have been done a year or two ago.
That said, C will probably be relegated to apps that are not compute intensive because of the performance hit C takes on the Prop. If you want anything near the full ability of the Cog, PASM is the only route.
Not zero interest, just zero time! I agree that this could be a "niche" area where the Prop might shine.
As heater and I have both pointed out, PASM is fine if you can fit your application in 512 longs. After that, you are going to get a significant slowdown whether you're using PASM, LMM PASM, C, Basic or SPIN. It's not fair to call this a "performance hit" for C - it's a consequence of the Prop architecture and applies to any language once you go beyond the 512 long barrier (or even before that if you need to fetch or store data outside the cog itself).
I think the Prop will begin to shine when people acknowledge that there is no single "one language fits all" solution. Use PASM if it suits. Use C if it suits. Use SPIN if it suits.
For me, the most potent and interesting combination is many cogs running C, implementing the complexities of a concurrent main application, plus a few cogs running PASM for stuff that is not so complex but which just has to run "like the clappers".
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm not with you on this one. What compilers are you referring to?
My Zog interpreter runs C code compiled with GCC. There are only some basic library things available, like strcmp, memcpy, printf. etc. But anyway if I don't use them in a program they don't get linked in. There is no "forcing" the compiler to not use the library. There is nothing "not pretty" about it. The simplest compile of a main program with no printf etc in it produces a very small executable.
Moving on you may have noticed my experiments with C++ which is famous for producing being bloated and huge code. Well, turns out that used in a way that is sensible on an MCU it produces the same small code as C.
Don't forget that the Arduino uses C++ on tiny little AVRs to good effect. It uses GCC. It is a breeze to program in the Arduino IDE or using you favorite editor and the command line tools.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/21/2010 9:00:44 AM GMT
All you've shown is that it's not the C++ compiler that produces huge bloated programs. So you're saying the fault lies with the C++ programmer?
Ross.
P.S. I agree with you about the C library - I quite often write C programs that do not link with the standard C library at all. You can write very useful programs that do not need it - especially in embedded environments.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
A friend of mine is always saying "You get what you order".
If a C++ programmer orders big features in his program he should not complain when the result does not fit in a tiny AVR or Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In the meantime, the intelligent peripherals is a real case. Noone seems to be taking this seriously. Once you have coded the small parts required in pasm your main code is most likely not time sensitive any more, so C or Spn will be fine.
@Leon: The code to do SPI, I2C, etc are already done (in pasm and also done in spin). But, the addiition for intelligent processing of that data can be done in pasm (or spin in other cogs for FAT16/32 handling). Similarly with VGA and TV. These are all things that have to be done on 1 processor in other micros (PIC, AVR, etc) excluding the "other" micro. Once you have to process all these things in 1 cpu, the timing becomes a major issue, interrput latency, and all the other things. These just simply are just not a problem with the prop and here is where we should be pushing it's advantages.
I should also add, that any professional will find it quite easy to take an existing object and add to it what they want. This forum is great for helping those learn anything they do not understand. They only have to ask and within hours they will have lots of answers, particularly if they are well thought out questions that taxes the minds. We direct the level of the answer to the assumed level of the asker.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 7/21/2010 9:37:48 AM GMT
I take it seriously. In fact I think that is the only sensible way to use a Propeller.
Potentially one could partition the high level non-time critical part into a couple or so threads but the principle is the same.
1) The high speed peripheral device code is in the COGs
2) There is often space left over in those COG for more intelligence which tends to go unused at the moment.
Case in point:
FullDuplexSerial is not so big PASM wise. That means those Spin functions it has for HEX DEC I/O could well be in PASM in the COG.
Or higher level parts of any serial line could be added into the COG as well.
Basically I'm sure there is a lot of capacity in COG space that is generally wasted. Not to mention that normally COG DAT sections are wasting space in HUB after the COG is loaded, but that is another issue.
Problem is, all this extra functionality is kind of application specific. So you won't see it turn up on OBEX much. And it's kind of non trivial to integrate application specific bits of PASM into an existing object like FDX.
Perhaps with the arrival of tools that compile BASIC or other high level (ish) language to PASM that integration of different PASM parts into one COG could become easier and more widely used.
Hmmm...Thinks, perhaps I should re-target my version of Jack Crenshaws TINY language to raw PASM COG code rather than LMM....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hang on. I have a fruit machine program that uses 3 render cogs using identical code with a separate offset, and my propscope code uses 4 identical cogs using a separate offset. Doesn't that count as effective use of SMP ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Absolutely! I think we may just have found our "killer app"!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The fruit machine was my first real prop code after the USB stack. It used a modified version of Potatoheads tv driver that alternated between 2 lines in memory, and three cogs simultaneously rendered each display line while the previous was being clocked out. I thought it was cool [noparse]:)[/noparse]
The first bitmap I used for one of the cards was a Vegemite icon [noparse]:)[/noparse]
In all honesty the code was not very clever, but I thought it was at the time.
It was completely written, compiled and downloaded on Linux though using no Parallax tools, which was a first for me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
The I2C and SPI stuff for peripherals I was referring to were for C compilers. I know they are available in PASM, I've even used them. Are they just as efficient when using the C versions. Perhaps they are written in PASM, also.
I've just downloaded Catalina C, I'll have a play with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/21/2010 11:40:11 AM GMT
I guess Catalina does something like that as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/21/2010 2:29:46 PM GMT
Catalina can use modified versions of most standard Parallax (or Parallax-style) drivers - the modifications required are spelled out in the Catalina documents. I have not bothered to modify them all, since I generally only do them as I need them myself.
Catalina drivers are generally written in PASM. I've not found a need to write any drivers of my own, so there are none written in C.
I have not modified a general purpose SPI driver, but there are specific drivers for SPI devices such as SD Cards. Look at the file 'Catalina_SD_Plugin_Input.spin' - it is a fairly standard SPI driver (in this case the 'spsdi' driver developed by Radical Eye Software) modified to turn it into a Catalina plugin. This should provide all the information you might need on how to modify other similar drivers.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I do think that rendering cogs is an excellent application, and one that is easy for people to actually see the results. This would be an excellent demo of the props capabilities. Perhaps you might see if you could find the time to tart up the code. Perhaps I could do the same for the datalogger (I was storing and then displaying on the PC) and display on the screen, like Beau? originally did with his version. These could make some exciting demos of the abilities of the prop.
Any other ideas???
As far as the Intelligent Peripherals, I agree that they tend to be app specific. That is OK though - the work would be done anyway as part of the main code in a single cpu micro. Here we have the advantage to relegate it to another process and remove the timing constraints from the main code. This is a definate advantage for the prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Men lousy at multi-tasking? Mostly an urban myth propagated by some husbands as part of the conspiracy.
Parallelism? The conspiracy has revealed itself... or has reached another level entirely.
To pull attention you need to out perform your competition and ease the transition for a skeptical engineer. For the Prop to succeed it would need to address items like....
1) An efficient C compiler...i.e. compiles to very low count ASM and follows industrial standards.
2) Address interrupts, the industry depends on deterministic processing..interrupts can be simulated by allocating a cog to monitoring one or more trigger sources but the poor engineer mainly motivated by coffee has to do more work. Why would he/she want to?
3) DMA
4) Dedicated hardware peripheries...specifically ADC & USB but not necessarily SPI, i2C, UARTs, etc....hacking ADCs with capacitors and resistors might work for hobbyist but not in industry where calibrating channels and verifying they meet specs consistently is like reinventing the wheel. A hard sell for all involved in new product design from upper management down to the design engineer.
5) I/O that meets the competitor's offerings, pull-ups, open drain and so on.
6) Internal EEPROM for program memory...this assures code security.
Suppose you are an engineer designing a product. In one hand the a PIC with integrated USB and ADC both of which the product needs and the other the Prop I. The negatives for the Prop based design implementation would be...
1) Need to add a USB chip
2) Need to have an external EEPROM
3) Need to have an external ADC
4) Need to add pull-ups on the digital lines (SD card, buttons, EEPROM and so on)
How do you sell the added cost of the external components to your manager? What about the extra layout complexity and space? What about the extra layout work on your part, do you want to do that? What of the extra code complexity of communicating with the external ADC and USB?
Prop Pros...
1) 160 MIPS, is hard to beat
2) Video Generators
3) Copious counters
4) 32 bit bus
5) Lack of complexity..other PICs have copious registers, modes and so on...this is not to mention the Erratas which cause product selection to become difficult. This is the downside to integrating peripheries, bug bugs bugs...so SPI, I2C and UARTs should be software driven...Erratas are a pain to navigate, Parallax could leverage this weakness of other processors.
6) True programming concurrency...most designs don't require this but some do, in either case programming tasks becomes much easier.
Post Edited (Miner_with_a_PIC) : 7/26/2010 5:41:44 PM GMT
Consider introducing the prop in colleges, in addition to the spectrum of micro-controllers that are already standard.
Relevant point could be: interrupts vs no interrupts
Adding additional u-controllers vs a multi-core solution
Descrete resources (as on new 8051s) versus resources from software object
I'm thinking about a package for homeschooling engineering curriculum. Alas, I'm not in education, so the going is slow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world: those who understand binary, and those who don't
I agree with many of your points, but I'm not sure about point 2 (interrupts). But perhaps I'm misunderstanding it - interrupts don't make a program deterministic, they do the opposite:
(** source = www.ccur.com/pdf/reprints-Sym-Muliprocessing.doc)
Interrupts can also dramatically complicate an otherwise simple program, and are also a common source of bugs that can be almost impossible to track down since they may only occur under obscure run-time conditions.
One of the key advantages of the Propeller is that it is a symmetric multiprocessing system that doesn't need interrupts to do what other processors most commonly use them for - i.e. either responding to external events in real-time, or to simulate multi-tasking. In fact, interrupts are the means other processors must use to simulate what symmetric multiprocessing systems like the Propeller do naturally.
We need to move people away from the interrupt model and guide them into thinking how to solve problems using symmetric multiprocessing instead. If we fail to exploit this capability, the Propeller loses much of its unique attraction.
As to the need to use external chips, I agree that if you need to add too many external chips to achieve your goal then you've probably chosen the wrong base MCU to start with. But the number of aplications where you don't need any external components is rare.
We need to identify the kind of applications for which the Propeller typically requires a lower number of external components than it's competitors, or where the need for its unique capabilities (like symmetric multiprocessing) make the number of external components irrelevant.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 7/29/2010 4:47:13 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I'm flabbergasted. You have been here long enough to know better. How backwards can that statement be?
Yes, often deterministic timing is required. And that's what the Prop provides. But really "interrupts can be simulated". It's the other way around. Interrupts are a poor way of simulating simultaneous execution of threads. Interrupts are what you have to do when you only have one CPU. In my experience "the poor engineer" would rather do less work by having multiple cores than have to fight with the cludge that is interrupts. Especially when the are multiple sources of external events, all with different timing requirements that have to somehow be prioritized to work together.
Note:. Actually I don't think you can "simulate interrupts" on the Prop. A Cog running some code cannot be stalled, stopped or otherwise messed up by events in the rest of the chip (apart from reset and clock frequency changes). That is the beauty of the Prop. That's what makes it so easy to mix and match any old objects you find for an application.
If you want interrupts you really want a totally different architecture. The fact that the Prop has no interrupts and does not need them is one of it's main reasons for being.
Ah, but I see you don't really want interrupts, as you state in your last paragraph about Prop pros..." 6) True programming concurrency...."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/29/2010 4:02:56 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Lets say you have your main program running in cog 0, you have another cog (call it overlord cog) waiting for the various states that would require the execution of an ISR.. Then you also have several cogs running (perhaps a LMM loop), waiting to execute whatever ISR the overlord cog requests. Once the execution is complete, the cog returns back to it's initial state, waiting to execute another request. If an additional ISR needs to be handled while one is already being executed, the next available ISR cog would run the requested routine, and so on.
I'd like to think that this would be simpler than combining multiple objects into a single object because there are not enough available cogs. But alas, I'm not much of a programmer, so I'm probably wrong.
am I the only one here, who has worked with interrupts and found them to be very helpful and not toooo complicated? Of course I had the help of good compilers which do a good part of the work.
I once suggested to implement polled interrupts into PropBasic. After each (of n-th?) BASIC instruction, the compiler could code a call to a user defined routine to check, if there is anything to be done. I think this could be very helpful sometimes. Of course you have to be aware of possible sideeffects and of course it is less complicated, if you can spend a dedicated cog.
Christof
When there is no better mechanism available, of course you must resort to using interrupts.
However, on the Propeller there is a better mechanism available - so why use them to simulate interrupts?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
That would suggest that all of the cogs waiting to do the ISR type routines contained the code for all routines, it doesn't sound like anything has been gained.
Christof,
I think it depends a lot on the application, the amount of hardware you have letting you off the hook (essentially acting like a single function processor) and how often multiple interrupts raise their head.
A polled interrupt? Isn't that rather like normal coding? I often check something periodically in a loop, works fine as long as the loop period is shorter than the requirement to act on the event, checking for a key press is a good example.
Graham
Also known as 'Wasted cycles' or 'Delay Included'?
To fit that into the various Basic Stamps and you wanted would probably require a complete rewrite of the onboard interpreter, to make it even halfway responsive. And that would mean a speed-loss for everyone else who doesn't need the functionality, but still gets the BS with that code revision. And well... the BS MCUs aren't exactly speed demons...
I've done interrupts...
On 8051, 8085, Z80... Looked at it on assorted PIC and AVRs, but gave up.
Have seen what 'pro dev. tools' make out of interrupts on Z80, and shudder.
(It's a hobby, picking apart code)
Maybe the Prop needs more supporting ICs than some, but...
As the functions can be tied to any pin on it, unlike other MCUs, board-layout can be greatly simplified.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Which greatly simplifies board layout. I strayed away from the PIC's for a few years (after all, who could love the bletcherous 14 bit instruction set), but the dsPIC33F has brought me right on back. They make a fantastic sibling to a Prop with a fast SPI connection between the two, and you have to love the dual single-cycle 40 bit MAC units.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"