Propeller wishlist

Erik Friesen

Here is a few things I'd like to see. There are probably good reasons why they are not implemented but none the less-

1. Native support within spin for LMM. Why couldn't it be squeezed in somewhere to allow code blocks of assembly to be run? It can be a real limitation to not be able to do both in the same cog.

2. Built in flash.

3. One USB sie on one cog. Perhaps preconfigured to be an HID bootloader/programmer.

4. 4 cog/cheaper version for low cost/low power applications. Lets just say in the $6-7 @ 100 pieces range.

5. A way to implement different peripherals like uart, i2c, without running 4-6 cogs at 80mhz which ends up being power hungry. Perhaps could be remedied with number 1 or with the new tasknew proposed by chip.

Mike Green

1) The Spin interpreter is very very tight and essentially fills the cog memory. Even a minimal LMM interpreter would take more cog memory than is available and there really are no features in the current Spin interpreter that could be left out to make more room. Perhaps the multiply and divide operations could be run as LMM code. That would slow them down all the time by several times.

2) The manufacturing process used to make the Propeller is incapable of providing flash memory.

3) Theoretically a good idea now that USB is even more ubiquitous. Practically, there's a tradeoff between using an existing product (FTDI's chip) that's simple to use, well supported by the manufacturer including the provision of IDs, etc. vs. the development effort, chip area, and additional support required. It'll be interesting to see how well the Prop II does with a software-only USB HID interface since there's a not-quite-standard interface already running on the Prop I.

4) This would require a complete redesign of the Propeller. You can't just leave out a couple of cogs. Maybe if Parallax were a huge company with lots of people available to develop a new product, this could be done, but it's not and it's more important to develop the Prop II than a cut-down Prop I.

5) Running 4-6 cogs at 80MHz to provide things like UARTs, I2C support, etc. doesn't have to gobble power. If the cog is actually in use, it needs the power. If the cog is idle (not active), it can spend most of its time in a wait state (with WAITCNT, WAITPNE, WAITPEQ) where it uses very little power, yet awaken at full speed when necessary. It's mostly a matter of how the code is written.

Cluso99

Mike, I am not sure 1) is entirely correct. It depends on how LMM is implemented. A minimal LMM interpreter is entirely possible in my RamInterpreter as I have spare space with all features enables. If LMM requires data to be in cog, then it would not be feasible, but if the data was in hub it could work. After all, I have a LMM style debugger residing in the RamInterpreter now.

I think the answer is more like is it worth the trouble ??? , because it also will require the compiler to be modified. Of course we now have two compilers by others, so it is no longer impossible.

All other answers make sense. The best way to get the prop price down is to sell more, not to bring out a cutdown prop. The development costs are ultimately a large proportion of the cost due to lower volumes. Now if only we could use one in a hot mobile phone.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

cruising][noparse][[/noparse]url=http://www.bluemagic.biz]cruising[noparse][[/noparse]/url][/url]

This is a [noparse][[/noparse]b]bold[noparse][[/noparse]/b] test.

Fred Hawkins

I'd like it to be SD card aware. And let you boot from the card if it's present (on pins 0 to 3, say) and there's valid code. Plus spin SD words...