In retrospect, I think it would have been much better to have released the Prop with a PBasic language for beginning programmers and programmers that wanted to upgrade from the Stamp to the Prop.
I could not agree more! I still find it surprising that they did not create an updated version PBasic for the Prop when it was first released. Why alienate all of the Basic Stamp users? I think a fast multicore Basic Stamp would be a very powerful product. For me, simple and easy to understand tools are the best tools.
I've been doing firmware in the storage industry (disk, tape, optical), and other industries since '82. This processor would never have been able to do any of the projects I've worked on, except maybe the 8031/assembly code project I worked on in the early 80s.
This sounds similar to the whinging about the PS3.
Firmware doing what? Give some examples. Bit-bashing the full data stream or just controlling DMA functionality? The Prop can do either just fine.
Ok, immediate code space is seriously limited. Making the Prop unsuited to standard C binary blobs sitting in a COG. But there needs to be a very good performance reason for running at native speed.
I'd like to see an example of why a storage controller would be a non-option.
Better yet, you could research what it takes to handle a real-time, disk drive servo (normally handled by a DSP, but I'm confident you could convince hundreds of servo engineers the error of their ways), data/cache management, and a SCSI or Fibre Channel protocol stack and then you'd know exactly what a good example is. Then you could publish a white paper describing how a Propeller could do it better and turn the storage industry upside down.
Not sure what "whinging" is, nor a PS3. Is that a toy?
I could not agree more! I still find it surprising that they did not create an updated version PBasic for the Prop when it was first released. Why alienate all of the Basic Stamp users? I think a fast multicore Basic Stamp would be a very powerful product. For me, simple and easy to understand tools are the best tools.
Hello Everyone,
After reading this thread, I came to one conclusion ........
I don't think that the Prop 1 chips potential has been fully realized yet !!
I may be out in left field but I think that there may be an opportunity to do something outstanding ! Why not take SPIN and make it a true symbolic language ? Not just something like MS Visual Basic, but a truely fundamental building block/modular interface ! Somthing like...... I want to have a pin on the chip send a pulse @ 60hz . You would grab a let's call it a (Action Block) from a menu and place it on the work window field. On the main field there is a diagram of the Prop chip. You place your command " Pulse 60hz" into the Action block and draw a line from the action block to pin 6 for instance. So this symbolic approach would be something like a electronics circuit simulator, where you can watch your programming in real time ! Or slow it down so you can follow every action like watching flow chart as it goes thru every step !
Everyone, young and old can program at this point !!
So..... why not put the SPIN on SYMBOLS, you already have some of them in your video characters and fonts ??
There are plenty of great programmers on here all they need is direction from you guys and gals at PARALLAX !!!
OK, I'm off the soapbox !
JTD
There already is a most excellent "block programming" for the prop
Yes, Hanno's 12 Block's is great !! There's still some issues.... One being, the need for a flow chart type layout for de-bugging ! Watching the programing scroll across the screen with all it's task for each cog or all at once would be fantastic for newbie or pro ! I think that anyone watching that feature would drop jaws from here to Intel !! I will leave the other dreams for later, except for this ... Could Hanno and Parallax come together and make 12 Blocks/Spin an open source project ! That alone would insure it's longevity for eons !! Or at least package 12 Blocks with the Prop BOE just think of it even elementary schools could afford that !
TNX
Lots of good things, including visual debugging coming to 12Blocks soon. Just like with ViewPort, you'll be able to "pause" a 12Blocks program by clicking "pause", and then stepping one block at a time, while watching variables and IO states change in real time. I'm a big fan of open source- see my IODreamkit and DanceBot as part of Lachlan's Smorgasboard, but I can't give my software away for free. There are site licenses for 12Blocks, we've sold a bunch of those lately...
Hanno
... don't think that the Prop 1 chips potential has been fully realized yet !!
... make it a true symbolic language ?
Please look at propforth. It comes closer.
Symbolic language => If you can define how it is to operate (the functions, the inputs and outputs of each) these can be coded. If they are designed within the parameters of the prop architecture, it can be coded in any language. If its coded in forth, the bottlenecks can be optimized in assembler in many cases, and design to operate more reasonably in others.
The Propeller is ... not very well suited to embedded development in today's commercial world.
Some of the issues are, as you say, hardware and software limitations. There's no hardware debug capability, such as JTAG, for one.
Language support is another. The embedded community is overwhelmingly C oriented.
Beg to differ, in fact I've seen the opposite to be true. For example, the using the proper tools as in propforth, the software interface allow the same funtion as JTAG in most cases, and the tradeoff of cost benefit to functhionality is very attractive.
Speaking from a C only view, I would agree. C is not as well suited to embedded microcontroller development as it is to workstation OS development. But if you can select the proper tool for the job, the prop is an excellent choise for many sitations, particularly if not limited to C.
... I will one day ,ake a computer with this controller
Check out Jupiter ACE. This allows the prop demo board to run VGA, keyboard, mouse etc and is a complete,statnalone development system. The next version will allow the same on the C3 and similar.
A participant is creating an on board editor, there is a file system the lives in EEPROM or SD. Since the parts are all simple and streamlined, we can use SD as memory instead of simply storage, we don't support FAT overhead so the speed impact is reduced. All this allows the key functionality we expect from a PC, without most of the overhead. Remember, a prop will never be a PC but mine does everything I would expect a PC should do for me, so it is easy to pretend its a mini workstation.
... what it takes to handle a real-time, disk drive servo (normally handled by a DSP, ..., data/cache management, and a SCSI or Fibre Channel protocol stack ...
I don't see any theoretical show-stoppers there. The raw data-flow has it's dedicated hardware.
There's obviously multiple cores and multiple IO devices involved. The Prop has to emulate everything so maybe one Prop couldn't do it all at once, dunno.
Protocol stacks may be a problem when it comes to licensing binary blobs. The peculiarities of the Prop makes it much easier if the source is available.
C is not as well suited to embedded microcontroller development as it is to workstation OS development.
Really? How did you come up with that gem? Considering that at least 90% of commercial embedded development is done in C, I'd like to see you justify that statement.
Really? How did you come up with that gem? Considering that at least 90% of commercial embedded development is done in C, I'd like to see you justify that statement.
I have to admit I don't understand it either since C was developed for the express purpose of being used for embedded software development.
Uh, no. C was developed for UNIX. I'll edit to add a citation later.
That's interesting since Unix predates C!! I have found a number of cites online which support that C was developed for Unix. Interestingly enough this directly contradicts what I was told while working at Lucent. As it was told to me C was developed to program the phone switches. The large number of people involved in the code development of the switches (I knew the "name" of them then) made programming them in assembly unworkable. Alas, I don't have any cites for that but was told that during a lecture of a person working for Bell Labs at the time.
Edit: The lecturer worked at Bell Labs at the time and I was at Lucent in the late '90s when the lecture was given.
If that's the case I stand corrected and retract my statement. One thing I do know is that C was intended to be (and is) a very low level language and library code aside generates for small and efficient assembly output.
Uh, no. C was developed for UNIX. I'll edit to add a citation later.
Check out wikipedia - the original version of Unix was in assembler on a PDP-7. But it was redeveloped in C after being ported to a PDP-11. The C language was specifically developed for this purpose by the same people (i.e. Denis Ritchie and Ken Thompson) .
C was designed to work very efficiently on the type of hardware they had, but the PDP-11 was very advanced for the time, and is similar in basic architecture to most computers developed over the next 30 or 40 years - and this type of architecture is still widely used today.
Consequently C soon became the most widely used language for embedded software development, and remains so today.
Ross.
P.S. This is not intended to start (or contribute to) any kind of language war. The facts are easily checked, and have been posted in these forums many times before.
So to my understanding parallax introduced the world to the propeller in 2006. But what has been done with it? This chip is absolutely amazing! I praise the engineers and the brains behind this and the genius of a president who had the guts to set a new standard. So, who agree and disagrees?
I agree - and liked the eight RISC parallel processor chip concept so much - over a hundred of these chips were put together to form a big brain with some results that I personally think are remarkable. http://humanoidolabs.blogspot.com/p/specs.html
the PDP-11 was very advanced for the time, and is similar in basic architecture to most computers developed over the next 30 or 40 years - and this type of architecture is still widely used today.
Ah, that brings back a lot of memories. One of the first programming languages I learned back in the day was PDP-11 assembly language. One of my all-time favorite processors, the Motorola 68K, had a very similar architecture.
I often wonder what today's personal computers would be like if IBM chose the 68K instead of the 8088 when they were designing the original PC. Just think of all the Smile we wouldn't have had to deal with: segment registers, 64K segments, the 640K limit, etc.
Ah the MC68k. I may be a noob at this stuff, but by far it is my favorite processor too. I love it's us in Sega's system sixteen, Mega Drive/Genesis, and of course the legendary Amiga! It was the first assembler I had ran, and is the first assembly language I started learning!!!!!!! It was so much fun
move.b 85,d0
(insert other commands I forgot.....)
(repeat....)
Ah the memories!
... what it takes to handle a real-time, disk drive servo (normally handled by a DSP, ..., data/cache management, and a SCSI or Fibre Channel protocol stack ...
I don't see any theoretical show-stoppers there. The raw data-flow has it's dedicated hardware. ...
You do realize the Prop couldn't do even handle the lowest rate of Fibre channel. Even the oldest SCSI standards would be too much for the Prop.
Like I said, the raw data flows will have dedicated DMA hardware on both examples.
I was making a rough equivalent comparison between a HDD with it's embedded uController/DSP combo compared to embedding a Prop as the uC/DSP replacement. Not a replacement for the data buffers, amplifiers, serialisers, ECC hardware and whatever else is used to pump the burst data through at max rate.
Comments
I could not agree more! I still find it surprising that they did not create an updated version PBasic for the Prop when it was first released. Why alienate all of the Basic Stamp users? I think a fast multicore Basic Stamp would be a very powerful product. For me, simple and easy to understand tools are the best tools.
This sounds similar to the whinging about the PS3.
Firmware doing what? Give some examples. Bit-bashing the full data stream or just controlling DMA functionality? The Prop can do either just fine.
Ok, immediate code space is seriously limited. Making the Prop unsuited to standard C binary blobs sitting in a COG. But there needs to be a very good performance reason for running at native speed.
I'd like to see an example of why a storage controller would be a non-option.
Not sure what "whinging" is, nor a PS3. Is that a toy?
There are a couple of Basic options with the Prop
1 PropBasic: http://forums.parallax.com/showthread.php?118611-Download-PropBASIC-here...-00.01.14-July-27-2011
or
2 The BS2 Functions object: http://obex.parallax.com/objects/30/
There already is a most excellent "block programming" for the prop
http://12blocks.com/
TNX
Hanno
Please look at propforth. It comes closer.
Symbolic language => If you can define how it is to operate (the functions, the inputs and outputs of each) these can be coded. If they are designed within the parameters of the prop architecture, it can be coded in any language. If its coded in forth, the bottlenecks can be optimized in assembler in many cases, and design to operate more reasonably in others.
Beg to differ, in fact I've seen the opposite to be true. For example, the using the proper tools as in propforth, the software interface allow the same funtion as JTAG in most cases, and the tradeoff of cost benefit to functhionality is very attractive.
Speaking from a C only view, I would agree. C is not as well suited to embedded microcontroller development as it is to workstation OS development. But if you can select the proper tool for the job, the prop is an excellent choise for many sitations, particularly if not limited to C.
Check out Jupiter ACE. This allows the prop demo board to run VGA, keyboard, mouse etc and is a complete,statnalone development system. The next version will allow the same on the C3 and similar.
A participant is creating an on board editor, there is a file system the lives in EEPROM or SD. Since the parts are all simple and streamlined, we can use SD as memory instead of simply storage, we don't support FAT overhead so the speed impact is reduced. All this allows the key functionality we expect from a PC, without most of the overhead. Remember, a prop will never be a PC but mine does everything I would expect a PC should do for me, so it is easy to pretend its a mini workstation.
I don't see any theoretical show-stoppers there. The raw data-flow has it's dedicated hardware.
There's obviously multiple cores and multiple IO devices involved. The Prop has to emulate everything so maybe one Prop couldn't do it all at once, dunno.
Protocol stacks may be a problem when it comes to licensing binary blobs. The peculiarities of the Prop makes it much easier if the source is available.
To heater.....
(I am speechless to!)
The propeller chip stand only is cheap
= all the processing power you need under less than $200......
Really? How did you come up with that gem? Considering that at least 90% of commercial embedded development is done in C, I'd like to see you justify that statement.
I have to admit I don't understand it either since C was developed for the express purpose of being used for embedded software development.
That's interesting since Unix predates C!! I have found a number of cites online which support that C was developed for Unix. Interestingly enough this directly contradicts what I was told while working at Lucent. As it was told to me C was developed to program the phone switches. The large number of people involved in the code development of the switches (I knew the "name" of them then) made programming them in assembly unworkable. Alas, I don't have any cites for that but was told that during a lecture of a person working for Bell Labs at the time.
Edit: The lecturer worked at Bell Labs at the time and I was at Lucent in the late '90s when the lecture was given.
If that's the case I stand corrected and retract my statement. One thing I do know is that C was intended to be (and is) a very low level language and library code aside generates for small and efficient assembly output.
Check out wikipedia - the original version of Unix was in assembler on a PDP-7. But it was redeveloped in C after being ported to a PDP-11. The C language was specifically developed for this purpose by the same people (i.e. Denis Ritchie and Ken Thompson) .
C was designed to work very efficiently on the type of hardware they had, but the PDP-11 was very advanced for the time, and is similar in basic architecture to most computers developed over the next 30 or 40 years - and this type of architecture is still widely used today.
Consequently C soon became the most widely used language for embedded software development, and remains so today.
Ross.
P.S. This is not intended to start (or contribute to) any kind of language war. The facts are easily checked, and have been posted in these forums many times before.
Ah, that brings back a lot of memories. One of the first programming languages I learned back in the day was PDP-11 assembly language. One of my all-time favorite processors, the Motorola 68K, had a very similar architecture.
I often wonder what today's personal computers would be like if IBM chose the 68K instead of the 8088 when they were designing the original PC. Just think of all the Smile we wouldn't have had to deal with: segment registers, 64K segments, the 640K limit, etc.
move.b 85,d0
(insert other commands I forgot.....)
(repeat....)
Ah the memories!
Like I said, the raw data flows will have dedicated DMA hardware on both examples.
I was making a rough equivalent comparison between a HDD with it's embedded uController/DSP combo compared to embedding a Prop as the uC/DSP replacement. Not a replacement for the data buffers, amplifiers, serialisers, ECC hardware and whatever else is used to pump the burst data through at max rate.