What I want to see in new Propeller (some toughts)
octal
Posts: 67
Hello,
1- I wonder when the new Propeller chip (if any) will be available.
2- I'm coming from PIC/AVR world, and I must agree that the propeller is really another world, a really awful and very powerful chip. What I would like to see in it is
- More shared memory (64KB would be very nice), as more power (most of the time) means more data to handle and with 32bit proc 64KB is not too much [noparse];)[/noparse]
- Code protection: I dont agree with all posts on this forum. Code protection is mandatory. for big projects that will be manufactured at 10000 or more units, it's not that important as big piracy companies will of coure put enought money to bypass code protection and stole the project, but for little made project with arround 40 to 100 units, nobody will spend enought money on cracking the protection especially if each unit is not that expensive. Code protection, in this later case, garantee that we can sell products in small quantities without the fear of being pirated. Having a flash memory inside the propeller would be also nice. I actually have three products that are sold well at little quantities, and I didnt switched to the propeller because of code protection. It's a pitty, I'm trying to move to ARM mcu (and avoid propeller) just because of code protection. I have a lot of friends who make specific calibration and measurement tools and where the propeller is really the best candidate, but they still avoid it because of code protection!!! maybe you dont like arguments or statements like that but it's a commercial fact.
- It would be nice to have a dedicated hardware MSSP module, a module that can do I2C master and slave and SPI communication (using some internal config registers). it's mandatory as simulating slave I2C comm is a bit complicated by software.
Best regards
octal
1- I wonder when the new Propeller chip (if any) will be available.
2- I'm coming from PIC/AVR world, and I must agree that the propeller is really another world, a really awful and very powerful chip. What I would like to see in it is
- More shared memory (64KB would be very nice), as more power (most of the time) means more data to handle and with 32bit proc 64KB is not too much [noparse];)[/noparse]
- Code protection: I dont agree with all posts on this forum. Code protection is mandatory. for big projects that will be manufactured at 10000 or more units, it's not that important as big piracy companies will of coure put enought money to bypass code protection and stole the project, but for little made project with arround 40 to 100 units, nobody will spend enought money on cracking the protection especially if each unit is not that expensive. Code protection, in this later case, garantee that we can sell products in small quantities without the fear of being pirated. Having a flash memory inside the propeller would be also nice. I actually have three products that are sold well at little quantities, and I didnt switched to the propeller because of code protection. It's a pitty, I'm trying to move to ARM mcu (and avoid propeller) just because of code protection. I have a lot of friends who make specific calibration and measurement tools and where the propeller is really the best candidate, but they still avoid it because of code protection!!! maybe you dont like arguments or statements like that but it's a commercial fact.
- It would be nice to have a dedicated hardware MSSP module, a module that can do I2C master and slave and SPI communication (using some internal config registers). it's mandatory as simulating slave I2C comm is a bit complicated by software.
Best regards
octal
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
If you read the whole thing, could you post a summary? [noparse]:)[/noparse]
i agree it would be nice to have some dedicated silicon for SPI. I implemented a slave SPI code (and posted it in this forum) but could not get SPI connection to run at anything over 1Mbps. The problem was the long time it takes to make hub calls. Master SPI should be better on a prop as it determines the clock. (btw, do people have any speed figures for a good one-cog Master SPI implementation on a prop?)
But things are not that simple for hardwired peripherials, as there are no interrupts nor dedicated buffers.
I suppose one could make a dedicated SPI macrocell feed a ring buffer in the hub ram similarly to how the fullduplex object does it for serial connection. Does anyone see a problem with this approach?
Similarly operating CAN/USB macrocell would be nice aswell. (to save silicon, ST, for example, reuses the silicon area for these, so you can either have CAN or USB but not both at the same time. Not sure how much they are reusing, but they are definitely reusing the large register arrays required for CAN and USB)
1) Nobody knows and, for good reason, nobody's promising.
2) The plan is to provide more memory (probably 256K shared memory).
3) Code protection. It's not mandatory. As you said it doesn't really work, and it probably will not be there. There was some discussion of a small (32-bit) fuse ROM to hold a serial number or hash code, but not anything fancier.
4) One of the major design decisions in the current Propeller (and future ones) was to not have dedicated modules. There has been "assist" hardware like the current video generator and it looks like the Prop II will have additional hardware to assist in things like Ethernet I/O, but there won't be dedicated modules. For one, they're buggy. Read any manufacturer's errata and you'll see. If the functions are done in software, the software can be quickly changed as opposed to figuring out work-arounds when possible and waiting for the next chip revision when the work-arounds are incomplete or messy.
5)Slave I2C comm is very doable in software. The issue is that it takes time, work, and interest to implement and those things take away from similar effort on the processor itself.
Post Edited (Mike Green) : 1/14/2009 11:40:28 PM GMT
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 1/16/2009 12:55:33 AM GMT
Oh, and do you guys want a summary of the discusion for the prop 2? I'm not sure if I have all the facts in my head right...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
1) scrap the external flash chip and put it on board.
2) if scrapping the flash chip repurpose those pins for some high speed inter chip comunication bus. Would love to be able to parallel up 4 or more proppeler chips together for added processing power and io lines possebly even having a cog on chip 0 being able to tell pin 15 on chip 3 to turn high
3) More cogs(32 would be nice number)
4) the ring hub is great for deterministic but it slows things down. Would be nice if there was a couple different modes it could be set in at compile time my sugestions:
4a)Timed Ring connecting first 8 cogs only(deterministic but not so long lag time if not using all)
4b)Timed Ring connecting all cogs(same as current assuming there will be more cogs)
4c) predicitve(non deterministic but faster, don't check deactivated cogs, and try to anticipate the need of hub access)
5) Much higher clock speed. I want to be able to render DVI outputs.
my 4 was addressed well with the idea of different bandwidth slots available for different cogs.
more then 8 is seldom needed unless you just want to be really lazzy and not bother interleaving tasks together and some kind of built in inter propeller communication system would fix for people that need more then 8
My 2cents again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
3) Last I heard there will only be room on the chip for 8 cogs
4) Discussed a lot. Last I heard there won't be any special hub modes.
5) System clock up to 160MHz with a new instruction (pipelined) starting every clock cycle (in each cog).
However, I also remember some threading specific instructions, that combined with things like auto increment and the rep instruction, will pack a lot of code into a COG! Also, a cog running like that can do LMM code much better than the current Propeller does, meaning larger programs get some serious speed, without having to break the thing to get it otherwise.
Because LMM is hard, and the memory space on Prop I is tight, I think this is glossed over too. Seriously, at the Prop II clock, LMM code is going to be great! All the goodies can run there. Real C environment, threads per COG (that discussion was had here too, and it looks encouraging), all without having to actually break the thing. Code will do that, and those that want complex behavior can just put it into a nice software kernel, and be done with it. (they can share it easily too)
There are a coupla things to remember about the Propeller and Parallax in general, that get missed or glossed over. And these are things that are obvious after both interacting and using the tech.
Phil makes an extremely good point. Enabling silicon will be in the chip. That can be fully and completely debugged, and this is important because Parallax wants to sell ONE propeller II, and ONE propeller I. Derivatives and or re-releases because of tech changes are a killer. Look at how long the design cycle can be! Granted it's a bit longer than would other wise be with Prop II, because they want the thing right, the first time, so that it's always right and it can just be sold.
That's where the stability is, and the longer term dollars are. So the pieces needed to get best use of the silicon are there, just missing some grey matter time to realize them, and Parallax ships ONE propeller, and all the code runs anywhere, on any Propeller, on any cog, and in most any project, with out a lot of hassle. (that's a good value proposition)
And here's the kicker for you all (that I think gets missed)
The determinism and symmetry in the Propeller means being able to pick up some code for a protocol or interface, and just USE IT. It's not necessary to weave that into your greater body of project code to the degree often necessary with non-deterministic single processor, multi-code designs. Of course, you can, if you want to, and that's all good too.
This is the most often cited reason for having the stuff in silicon in the first place! If the silicon is more dedicated, then there is less code. But, code is cheap, once realized. It's easy to share code. It's easy to fix code, and it's easy to improve code and do new things. None of those things are easy with dedicated hardware.
In these discussions, I always factor out clock speed too. It is what it is for this generation. If time is spent upping the clock of Prop I, then we don't get the very serious and significant improvements in Prop II.
Also, if symmetry and determinism are lost, we then suffer a kludge. That kludge then will scale, leaving us with a mess. Look around at the various controllers, that suffer kludges. What are they today? Messes that's what! They are built upon not fully thought out designs, then add to them, and add and add and we end up with hot running, buggy, complex devices.
Frankly, I've come to realize that determinism makes one think through the problem and resolve it fully, or resolve it to a point where some ambiguity doesn't matter. Same thing really. On the silicon side, the same thing is true! And this is why the Propeller is the Propeller.
Given these things, it's much better to apply the Propeller in the way it works today, get good at it, then leverage all of that in Prop II, often changing little code, and when it does have to change, it's in predictable ways, than to branch off and make the thing something else, which is essentially a kludge for the now instead of building for the max potential in the future. We've lots of those design decisions, realized in many somewhat ugly devices. Why bother?
On the Prop, I can see that getting good at something basically ONCE does the trick. It's over. Tool for the tool box. This is not unlike getting good at utilizing a particular dedicated bit of silicon, but with one major league difference. If the CPU doesn't change, then the code is always good. Dedicated bits 'n pieces come and go and change, meaning the skill acquired is diminished each time and that costs time and money, and really doesn't serve the goal of getting stuff done.
Having been on this grind with computer software. Believe me when I see the merits of this clearly. Re-purposing the same skills over and over just sucks. That's one of the appeals the Propeller has for me personally --not having to do that!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 1/15/2009 5:16:38 AM GMT
that is still enough to thread some basic tasks that are not time critical or take little time. I have threaded together a monitering circuit and my system clock easily into 1 cog. the monitering circuit starts up new cogs to deal with real world events to make sure the run time does not exced 1ms.
Running at 160MIPx8 instead of 20MIPx8 means these tasks don't have to stay on as long as they would with the Prop1.
I would still like as many as possible but would rather have faster hub access times then more. obviously the ideal method would be if a single cog could be allotted multiple time slots with the hub. So if cog 0 is getting 2 blocks it could use the hub during cog 8 turn also. Obviously this would mean cog 8 would not be usable.
We should stop this thread here. If someone has a "new" Prop II idea they should read the entirety of the thread linked above before posting. I'm sure they'll find it not so new and thoroughly discussed already. If not then come back here [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well, that is all I think I want in prop II. Nothing else. 256k means you can emulate a CP/M machine on one chip. 64k for the emulation of the CP/M, and the rest for running the prop code. Perfect.
Of course this could be done with a prop I and an external SRAM but it uses so many lines. Emulating CP/M opens up a vast library of software - many different languages for instance. So the Propeller is no longer a Spin chip, it is also a C chip and a Basic chip and Fortran etc. There is nothing wrong with old-school languages either - Basic on PCs got more and more complex and then people discovered RISC for machine code and simplified Basic for things like the Basic Stamp. Multiple languages opens up opportunities for more customers. You can show them Print "Hello World" in basic running on CP/M, and then they will ask "how is that being emulated, what language is this spin all about?" etc.
So for me, Prop II sounds perfect. Hopefully not too long to wait...
[noparse][[/noparse]addit - heater you pipped me by 1 minute with your suggestion to stop the thread! BTW I posted you a CP/M board today. 41C here today. -41C where you are on the other side of the world? The programs should all be intact as long as the battery doesn't freeze!]
Post Edited (Dr_Acula (James Moxham)) : 1/15/2009 5:43:00 AM GMT
Personally, I'd just be happy for more memory and speed at this point. [noparse]:)[/noparse]
I'm starting to think that the target market for the PropII is people who want an FPGA that runs spin. [noparse]:)[/noparse]
@James, good deal, glad you've got a board on it's way to heater.. Just a little more work and we'll have a nice Propller/CPM board up and running.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.