How close is the propeller v2 ?
octal
Posts: 67
Hello,
I wanted to know if there were any new info about a new version of the propeller (v2.xx) ?
Any update about that?
Regards
I wanted to know if there were any new info about a new version of the propeller (v2.xx) ?
Any update about that?
Regards
Comments
Why do you ask?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Cause it's not forbidden !
I just wanted to know the (near) future of this chip.
Actually the main problem with using the propeller in my commercial products is the lack of code protection option (no comment), and the somewhat limited memory size for some applications.
This is why I wanted to know if this could change in near future or not.
Regards
There have been discussions lately regarding this. Both Chip and Beau have graciously posted comments in this thread:
http://forums.parallax.com/forums/default.aspx?f=25&m=424853
There's a few juicy discussions in it. In particular, I enjoy reading Cluso99's posts. He's got a good perspective (he's not alone) in my opinion. The less hamstrung the prop2 design, the better it will be. It's unfortunate when a good designer/engineer/architect attempts to predict how we would like to use a device. What's telling about Cluso's and Chip's discussions is that Chip can be motivated by good arguments/discussions. This is good.
I bet hover1 is correct and it's probably at least a year away. I base this on approximately how long it takes the shop where I work to produce boards and then productize them once they get to the layout phase.
I'd love to use a parallax chip in a professionally designed product like you. Unfortunately, it is unlikely I could convince my team to use a non-standard programming language, spin, despite the utility of an eight core micro. The main argument is; "Why would I want to learn a language that is only applicable to one device (career limiting)?"
ICC and Catalina are great efforts to demonstrate the demand and interest in a systems language like C on the prop platform. Although, the need to execute code under a small kernel and fetch instructions from the hub does not lend itself to a strong argument for adoption among professional engineers, when atmel, microchip and others provide reasonable C/C++ compilers without a workaround.
If the prop2 contains:
1) Better hardware support for a systems language like C/C++
2) More I/O (Check, 64 last count)
3) Faster execution (Check, I think I saw ~160 MHz/cog, wow!)
4) Built in A/D (Check)
5) More memory (Check)
6) A mul/div instruction (Check)
7) Method to communicate to other cogs directly (no hub) (Maybe)
...it will be a happy few years and it wouldn't be a stretch to see the prop2 make inroads into professional market segments. There's probably a small army of professional engineers (like myself) who love playing with the prop at home and on the side, who are eager to use it in the workplace.
Have fun!
I think you will find that the prop is already used quite frequently in commercial and industrial applications..
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
'Those who can, do.Those who can’t, teach.'
'Convince a man against his will, he's of the same opinion still.'
·
http://forums.parallax.com/showthread.php?p=880775
Jim
I agree with that. But people at Parallax seems very confident with their vision to market. Propeller will never be the heart of a lot of products maybe because of Spin specific which is perhaps a bit anvoidable because of the parallel nature of Propeller and its unusual architecture, but the main problem I see is the absence of code protection.
I know and have read al threads about that .... and I still DONT agree with what is said about the possibility to defeat most protection systems. A lot of companies working in electronic industry that I know makes little series of products, like command units which are never made with more than 200 to 500 units. These small companies are very numerous, and they are a very big market in europe. Most of these companies will never use a non protected chip. Pirate companies will never do the effort to break a product that will be made in 300 to 500 units and sold at arround 100 to 200 euro. Pirates goes to mass market.
A lot of little companies I know use PIC, AVR and ARM because of that. The little protection theses chips provide are sufficient to let them make products that sells well, they make 3 to 4 products per year, each product sold in arround 300 to 500 units (sometimes more depending on some costumers needs). This means for a little company about 5000 to 10.000 chip per year.
With most of these companies, when I talk to friend working at or owning these companies, they all say that propeller is a very nice chip that do almost all what they need (speed, signal generation, multitasking, ...) but they will never use it cause of non existing protection.
When I read all topics about propeller, for me either Parallax technique is not able to provide such feature, ot it seems that Parallax is happy with the schools and proof of concept little proto market. They dont seem to be interrested with the huge ammount of companies that can introduce the propeller to the mass market in true industrial applications. Not that the propeller is not able to handle such serious tasks, but because it does not fit in the of companies on using a protected code system.
Regards
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
I should have been more explicit. It's fairly obvious that the prop is getting used in professional products. Yet its penetration into that market is hampered due to the use of a non-standard programming language by default.
C/C++ are beautiful languages. Why not leverage decades of language iterations, billions of lines of code, and familiarity to good use?
Keep spin as a spring board tutoring language, and explicitly add hardware support for standard systems languages like C/C++ without the need for a the current kernel-per-cog-fetch-instruction-from-hub workaround.
The fact that ICC-C, Catalina-C, and ZiCog-C/C++ exist is testament to the demand for standard systems language support.
This isn't a criticism of the prop., simply a request.
[noparse][[/noparse]Edit]
A modest attempt at a code protection technique wouldn't hurt.
[noparse][[/noparse]/Edit]
graham
Post Edited (greitz) : 2/21/2010 5:18:17 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ron aka sailman58
More seriously:
greitz: "Why not leverage decades of language iterations, billions of lines of code, and familiarity to good use"
Good point except:
1) Those billions of lines of code don't fit in the Prop [noparse]:)[/noparse]
2) All that familiarity does not help much when you have 8 processors running in parallel. Only 496 instructions in each. No stack. No interrupts. No peripheral hardware crutches.
Actually I did not quite get what your request is.
If it is for C on the Prop we now have multiple solutions as you know.
If it is to make the Prop more friendly to the C language and it's compilers well fair enough. It's just that if you do that you probably find you have warped the Prop away from the Propeller architecture into a run of the mill processor. In which case there are many of those on the market already so there is no point.
3) C just is not a good fit to the propeller architecture.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'd like to see if we are comparing apples to apples here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Code protection? Potting compound [noparse]:)[/noparse]
Graham
No, I think it's this.
If a company designs some new widget that needs a bit of intelligence they have a huge range of cheap micro-controllers to choose from. There are many ARM variants, there are AVR32's. PIC32 etc etc. They all have their different features and quirks but for many applications there are numerous suitable candidates.
So, said company chooses one and codes up the application in C. The expectation here is that if your selected device becomes obsolete or unavailable or something cheaper comes a long you have the possibility of easily migrating the bulk of your investment in C code over to that new device. You are confident that there will be a steady stream of such devices into the foreseeable future.
Now you are offered the Prop. A jolly fine device. The catch is that without C you are now being asked to put all your eggs in one basket with no way to easily migrate.
In that market the Prop can only sell into those applications that those other, run of the mill, devices actually cannot do at the price.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I agree for Spin, for having worked with almost all widely used languages in embedded world (asm, C/C++, Basic and even pascal) I read the Spin manual in about one day and become able to write/read spin programs very quickly. When you understand the philosophy behind Propeller arch, it becomes easy to master spin.
Sorry but what do you mean (I dont understand)?
ics.nxp.com/products/lpc1000/datasheet/lpc1111.lpc1112.lpc1113.lpc1114.pdf
In the post I was responding to, the Propeller was being suggested as an alternative to devices like the PIC. The Cortex-M0 competes more with them than the Propeller, perhaps.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/21/2010 6:43:47 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
pPropellerSim - A propeller simulator for ASM development sourceforge.net/projects/ppropellersim
Well, it has 1 pin with 20mA output drive... yes ONE pin. Plus two I2C bus pins with 20mA sink... yes 2. And I don't even know if they are on the version for 65c.
The largest on the datasheet has 32KB Flash and 8KB SRAM. Less than we have and we are complaining!!
Up to 50MHz, single core. Ho Hum.
Two things I like... On-chip 1% xtal and a unique serial number (code security maybe ??).
And 65c in 10,000 quantities for the LPC1100. Presume 8KB Flash & 2KB SRAM QFN33. Not bad for what it does, but it is definately NO propeller!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 understand, but I'm still amazed at these discussions. The Propeller is a very different concept from any of the "competition". While the ARM Cortex-M0 is nice, it's not very different from PICs, AVRs, etc. in that you have a processor core (with flash memory and SRAM) surrounded by special purpose peripheral processors. There are different processor cores, each with its own advantages and disadvantages, but they're not very different from each other.
The Prop has 8 essentially identical 32-bit processors with local memory, a shared memory with interface logic, and common I/O. The individual processors are optimized for speed and determinacy and the instruction design is straightforward for writing in assembly language which is a good match for the limited size of the processor's local memory. There is a built-in interpreter for a compact, reasonably fast interpretive code that's well matched to the native instruction set. Spin is a reasonable language design for this interpreter and provides access to essentially all of the underlying processor's capabilities.
One can argue that having C as the high level language would have been a better choice. I would argue that C would not allow direct access to some of the important hardware features of the Propeller without some extensions and that the interpreter could not have been done given the base requirements of C plus the necessary extensions and the limited memory space available. Given the experience with the processor over several years, it might be possible now to redesign the interpreter to support some extensions in ROM and/or RAM that would make it possible to implement a C interpreter. Why bother? There is a good free C compiler already (Catalina) and an excellent standard C commercial compiler (ImageCraft) for the Propeller. Neither one is used widely. The combination of Spin and assembly seems to work well for many people.
This is what I does (with XMOS) but XMOS does not exist in DIP and 40 pins (or less) packages. Also needed component to make the propeller work are less than XMOS, and XMOS needs a very careful desing of the PCB!
A little code protect on actual Propeller will bring a very big number of developpers and make it an ideal solution for a lot of embedded systems.
Rubbish I tell you rubbish[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For applications like this one I think a better solution is to use ARM9 boards !
I used a mini2440 (ARM9 based on a Samsung MCU) board from www.friendlyarm.net/products you can find them arround 65 euro on ebay with a 3.5" touch disp from NEC. You got a 400MHz ARM9 board with 64MBytes of Nand Flash and 128MBytes of RAM and a lot of onboard goodies [noparse];)[/noparse]
If you dont need the screen, the Mini2440 board (the full one, not the Stamp one) costs about 45 euro, a very low cost if you compare the ammount of ram/flash, a 400MHz mcu and the very well already done PCB (and all its connectors).
Regards
But will it fit the whole CP/M computer in a matchbox as Cluso has done with ZiCog?
hackaday.com/2009/12/27/zilog-in-a-matchbox/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Multi-threaded and multi-processor programming is nothing new to the C/C++ language. In fact it is now part of the C/C++ standard: www2.research.att.com/~bs/C++0xFAQ.html#std-thread
Notice the pure simplicity of the sample code.
C/C++ is not coupled to the concepts of hardware interrupts, and a hardware stack; ICC-C, Catalina, and ZiCog C/C++ demonstrate that. We would expect that from a systems language versus a non-systems language like java.
The current C solutions require a workaround to execute code exclusively from the hub. This has not been received well by my working peers. They would much rather use a product where it's clear the company has expressed a desire to support standard systems languages, such as C/C++.
If Parallax's intended market is limited to hobbyists, schools, and a few professional applications you're right there is no point. Personally, I feel this is a waste of a unique microchip architecture.
I couldn't disagree more. The prop is no less suited for C/C++ than the Arm, Cisc, Risc, Harvard, and Von Neumann architectures are. There are C/C++ applications that run on ridiculously small amounts of memory in the PIC.
YES!
The hope is that Chip will be more open and explicit with the prop2 than the prop1 with regard to C/C++(or other) language support.
I recall that Parallax was less than forthcoming when handing over the details needed to make a kernel work on the prop1. Chip has mentioned in a post somewhere that this will be remedied but stopped short of offering any specific hardware support.
Kindly,
graham
Sure you can get a nice ARM board with lots of memory and on-board goodies pretty cheaply. It can do lots of things much better and much faster than something made with a Propeller. So? You use different tools for different needs. A Propeller can do a lot with very little in the way of hardware around it and with very little power. heater mentioned running a Z80 emulator that, in turn, runs CP/M, all with a VT100 emulator producing NTSC or PAL video with a PS/2 keyboard interface, all of this done with only a 32K standard EEPROM, 64K SRAM, crystal, a few resistors and capacitors, and a micro-SD card for the CP/M files and filesystem. More importantly, it all fits on 1-2 square inches of PCB and can run for hours and hours on a set of AA batteries.
I'm not sure if I understand You.
Most of C programs are memory hungry, badly structured, Not speed efective.
Most of them are endles loops.
WHY not learn nonthing new that fit correctly CPU's architecture and resources?
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
What I meant about the "billions of lines of code not fitting" is that currently all the C compilers we have available for the Prop produce excessively large code (Note 1) . This a result of having to generate 32 bit PASM instructions for their kernels to execute. So size wise C is not a good fit.
Multi-threading is for sure nothing new. But the Prop has hard real-time multi-processing with deterministic timing down to 50ns. A world away from pthreads or std::thread or whatever.
C may not be coupled to interrupts but it for sure helps to have stack support in the target processor. PASM or LMM has no direct stack support. ICC, Catalina, Zog have to make a stack in software. C is not a good fit.
Yes there are C/C++ applications that run on ridiculously small amounts of memory in the PIC. But still I think targeting a C compiler at the 496 instruction space we have in the COG is a complete waste of time. By the time C has worked out how to build a stack, do indexed addressing, do byte and word variable access etc it will have used most of the space. Seems others agree. No one has stepped up to target a C compiler at PASM. C is not a good fit. (Note 2)
Note 1 - The exception is the BDS C compiler generating Z80 code for ZiCog[noparse]:)[/noparse]
Note 2 - Despite the fact that C on the Prop is shown to be such a mind bendingly bad idea I will be continuing to get the GNU C compiled code for ZPU running as best it can with Zog and VMCog [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.