Chip Gracey (Parallax) said...
The Prop II will likely use an M25Pxx-type device, which is an 8-pin, fast-SPI flash memory that is manufactured by several different companies and comes in densities ranging from 64K bytes to 16M bytes. Also, there will be support for some removable, low-pin-count, popular memory card format.
Chip Gracey (Parallax) said...
Picture one Propeller on a special host board with monitor and keyboard connections, and maybe just one or two signal wires going down to the target Propeller board. Every chip would have this built-in capability, but needn't use it. You could develop on the same chip, or from another, for one chip, or for an array.
I hope Prop II will support USB keyboards and USB mouse, because PS/2 keyboards and PS/2 mouse are going to be extinct in about 5 years.
Oldbitcollector said...
Being one of those nostalgic types from the 80's of course I want an on-board ide, but
to make it useful it's going to need to have the things I have now.
Mouse support
Copy/Paste
Ability to open multiple files
80x25 and 160x40 text equiv text resolutions. (depending on screen attached)
This type of "stable" on-board IDE would be appreciated by all.
BTW, Chip I keep noticing that you keep using Apple][noparse][[/noparse] in your "stability" examples, not Commodore?
Question: since PS2 will become an increasingly painful item to locate in 3-5 years, is there a chance of
USB support in the new Propeller?
OBC
Yes, multiple hi-res monitors, multiple files open, perhaps a simple web-browser tuned to Parallax's OBEX and forums, and certainly USB keyboard/mouse support (slow USB could be done on the current Prop).
OBC, do you really want me to say it again? Okay... the Commodore 64's ROM was an atrocious pig stye. Coming from the Apple ][noparse][[/noparse], I was actually quite shocked. There was a universe of difference between what Wozniak had written and what who-knows-who had done in the C64. Had the C64 been given a better ROM that supported the graphics and sound hardware through a nicer built-in BASIC, it would have been 10x the machine to the average owner. In the end, programmers sussed out the performance through pure assembly coding and floppy driver-code replacement, but it was a shame that it was so hobbled by its poor built-in software. I had developed a cross-assembler system that used the Apple ][noparse][[/noparse] as a host machine, and a cable from its game port went to an expansion card in the C64. The most-used "key" on the C64 was the power switch - off and on all the time. The Apple ][noparse][[/noparse] stayed awake and downloaded code over and over into the C64. I was 14 when designed that system and I sold over 300 of them to Sega, Williams, Activision, and others. I remember riding my bike to the convenience store (in 1982) and filling out the UPS forms to send them all over the country. I used that system to design the ISEPIC. Okay, enough nastalgia. We're in the complicated 21st century now.
jazzed said...
@Chip, would you please talk about what packages might be used for Propeller II ?
Thanks,
--Steve
We're currently looking at making a special 12x12mm 128-pin LQFP that has a big GND plate on the bottom. This way, no pins need to be spent on GND and we can get over three 32-pin ports out.
Okay, you never know what kind of kooky thing Windows will do. Right now, after having had the web browser focused and the chip-design software minimized, I clicked on the chip-design app in the lower tray and only the TCL terminal comes up. The main graphical app won't display itself. Typical unpredictable/unsolvable Windows conundrum. This slowly leads one to madness.
Chip Gracey (Parallax) said...
We're currently looking at making a special 12x12mm 128-pin LQFP that has a big GND plate on the bottom. This way, no pins need to be spent on GND and we can get over three 32-pin ports out.
Excellent! Hope you're getting a good deal on the NRE and production costs.
What would be the pitch between pins? Will 8/8mil trace/clearance be possible?
8mil trace/space would work, but you would have to break the design rule. With a .4mm lead pitch, you could assume .2mm trace/space which would translate to ~7.9 mils.
The LQFP sounds pretty sweet, and a .00787" design rule fudge is no problem. With a .4mm pitch, what would the actual width of the leads be? (I'm just wondering if the pads would have to be wider than 0.2mm to accommodate the leads correctly.)
I'd really like to see space saving features like programmable pullups, integrated voltage regulator, integrated·USB·and more memory.· Silicon labs MCUs have all these features.
I'm not sure I see the benefit of onchip development but I'm not an expert.
Those netbooks with 1024x600 screen, keyboard, usb ports, sd slots, wifi, and power supply·etc can be bought for $149 on sale.
Wouldn't it just be easier to write your own embedded linux loader or something?
Chip: I presume when you say support for some kind of card this will mean we will not have to have an EEPROM/FLASH boot chip on-board? I do hope so.
Did you all notice the >96 I/Os ??? (Chip said "over 3 x 32 pin ports") ·Could also be support for SDRAM?
I am not going to comment on the·posts (it pretty much sums up my sentiments), except to say I think an onboard (or via microSD/etc) development would be great.
FWIW: PS2 vs USB for keyboards and mouses (yes the plural of the hardware mouse is mouses). Many of the current USB keyboards and mouses still support the old PS2 serial. You can use a common footprint to load either a USB or PS2 socket but 1 serial pin changes which can also be corrected in software.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Off topic and maybe already answered question, but will the PropII replace/obsolete the current propeller? Do I need to re-think my design decision to use the Propeller?
On this entire "embedded IDE" topic, I tried very hard to wade through all the thoughts on this thread and in the end, began to think that a "smarter version" of a develpment board (an enitre "embedded" development system" could be a reasonable compromise? With this, deverlopers could have an "Apple" platform with all signals/buses exposed and all the smarts and general purpose I/O needed to host the development efforts, allow for in-circuit debug and testing. Also, externalizing and decoupling the development platform from the design of the device internals allows these two efforts to proceed in parallel (and maybe even be done by any outside company). So, perhaps a better notion would be do define a specification for such a platform and then allow market forces to play themselves out. Another considerion is that once a product is developed do we really need to carry around all the "weight" of the devleopment environment? For example, adding all the connectors etc to support the "in field prgramming and debugging" could add unnecessarily to the costs of any product that will not make use of any such feature.
Sorry, if this is not a useful comment, as I said I tried very hard to follow this disucsion, but am not sure I "got all the finer points" being discussed by others.
The Prop II will not replace or obsolete the Prop I. The Prop I is smaller, cheaper to produce, and takes less power than the Prop II is expected to take. If you don't need the higher speed, greater memory size, or other features specific to the Prop II, the Prop I will work just fine. The two products will coexist for many years.
TinkersALot: Absolutely not. The Prop II will use much more power. I have a volume design in the works and even if the Prop II were available my project would still use the Prop I.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
BradC said...
While I agree the Apple ROM was pretty solid, it had its bugs. Where you say "it could be updated", I guess you mean "You could load a new version of the rom by putting in a special "soft card" that allowed you to load new rom code into bankswitched RAM which was then switched over the old ROM". And just to be a pedant, but the Apple ][noparse][[/noparse] DOS was loaded from disk. The DISK][noparse][[/noparse] card contained a very simple bootstrap that allowed it to load enough of the disk to allow it to load itself. This is how we could use Apple DOS 3.2 with 13 sector disks, and DOS 3.3 with 16 sector disks. Nothing to do with updating the ROM.
No, that is not exactly what I mean, although it is a good point and viable way to make Apple II changes, and it is correct about Apple versions loading DOS by disk (such as DOS and PRODOS), and every system has bugs (some more and some less), though Apple was indeed solid comparatively speaking. The "diskless" system is better exemplified by the TRS-80 Model I level II where there was no disk and the language and the OS was in ROM. However, the reference to modifying the OS (DOS), even when disks are used, still remains. After it loaded into memory, the same procedure that I described for changing memory was initiated for various mods and updates, both in the OS and in the language. The only point I am making, IMO, is in favor of a ROM based OS. There was a plethora a ways to upgrade and add on features. Any features not needed in ROM could simply be ignored. Any additional features needed could simply be added. Consult nearly any of the issues of "80 Microcomputing" for numerous examples and ideas to reworking a modern day version of this successful retro technique and technology.
humanoido
Post Edited (humanoido) : 11/24/2009 6:17:21 AM GMT
The LQFP sounds pretty sweet, and a .00787" design rule fudge is no problem. With a .4mm pitch, what would the actual width of the leads be? (I'm just wondering if the pads would have to be wider than 0.2mm to accommodate the leads correctly.)
Thanks,
-Phil
I don't know, but I imagine it's got to be around .2mm/.2mm.
Here is a SchmartBoard that handles .4mm lead pitch packages. It's pretty dense (6.35x of standard .100" DIP spacing):
Chip: Previously I understood there was likely to be a small section of FLASH (or equiv) - say 16 longs?? Is this still the case? If so, could 1 of these longs be used as configuration bits to shorten the boot process, by skipping the unused boot devices, or change the priority (even better as it takes into account a part not functioning). It could also decide if decryption is required. The default of course, when shipped, is these bits are all off/on.
BTW: Nice. I like the boot from USB (no USB chip)·
I am not sure if this is a can of worms... Could the USB be master or slave? i.e. Plug in a USB memory stick to boot from. I have a miniature USB to microSD converter (about $5) and it is not much bigger than the microSD itself. I guess that may entail royalties and we don't want that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
4) Check for SPI EEPROM (three pins below last two)
5) Check for SD card (? pins below last two)
The first thing found, in that order, will be used to boot from. If nothing is found, the chip will go to sleep.
USB needs 3 pins and probably needs to be at the very end of the sequence. It's incredibly slow to enumerate and you'd be waiting for an excessive timeout before moving on. The other hassle is what type of USB do you use? HID is the only one that windows won't need a .inf file for, but can be a problem across multiple platforms. CDC-ACM is a great choice as it just presents as a serial port, works on all known usb host platforms and is relatively easy to do (the current USB code for the Prop-I does it standing on its head in two cogs). Your biggest hassle with USB is what do you actually do with it? The Host application won't see a port until the prop resets and goes into the bootloader, and the prop won't be able to do anything until it's checked that nothing is waiting to talk to it on the other end. I have a USB-HID bootloader for the Prop-I and an application that allows you to load it on Windows and Linux (I never got HID working properly on OSX), but you either have to have the USB connected full time, or you need to reset the prop and time your application right to try and talk to it.
I'm pretty sure you can reliably do the SD card in 4 pins. That'd be pretty sexy too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Cluso99, there will probably be 32 fuse bits that can be programmed. I don't know if we will program them and protect them during final device testing, or the user will have some ability to do it, and if so, what functionality they will have. I suppose we could boot off a USB memory stick.
BradC, for USB, is the third pin needed to handle the initial pull-up/down on one of the two data pins? If we have pull-up/down on every pin, will it still need three pins then? I see what you are saying about the enumeration headache. The purpose of USB would be, at least,·to provide a development conduit to the PC. Also, users could do other things, as well. SD card in 4 pins would be nice.
> Instead, we're presented with an increasingly treacherous (expletive) with whom we are supposed to partner. I just refuse to play
> their game.
That was a vote for Linux!
> and maybe just one or two signal wires going down to the target Propeller board. Every chip would have this built-in capability,
> but needn't use it. You could develop on the same chip, or from another, for one chip, or for an array.
It still is a waste to have the code in ROM. Except the Prop II is targeted for development and not for being used (in devices). Nobody will stop you from writing a IDE that runs on the Prop, including syntax-highlitghting, write files and directories to USB or backup to CD-ROM. But that code rests well in EEPROM. And if you want it to keep for 100 years, a OTP-ROM is it.
Languages are moving forward and aren't cast in silicon. See the alternative SPIN-compilers with extensions and assemblers. Or other languages like Basic, C and Forth. Or the ZICOG and 6502-efforts. You are heading for a closed system, while users of the Prop go in hundreds of directions.
Whatever the outcome is, I'll never use it (the on-chip-IDE). I prefer working in an open environment.
See the top quote of your statement.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
Thanks,
--Steve
Good choice and good value.
I'm going to see the features, if compatible with the memories of ATMEL (AT45DB321) am saved because I have many. [noparse]:)[/noparse]
Chip,
Thanks for all the information. We are and always will be supporting this company and their inventions.
I hope Prop II will support USB keyboards and USB mouse, because PS/2 keyboards and PS/2 mouse are going to be extinct in about 5 years.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
OBC, do you really want me to say it again? Okay... the Commodore 64's ROM was an atrocious pig stye. Coming from the Apple ][noparse][[/noparse], I was actually quite shocked. There was a universe of difference between what Wozniak had written and what who-knows-who had done in the C64. Had the C64 been given a better ROM that supported the graphics and sound hardware through a nicer built-in BASIC, it would have been 10x the machine to the average owner. In the end, programmers sussed out the performance through pure assembly coding and floppy driver-code replacement, but it was a shame that it was so hobbled by its poor built-in software. I had developed a cross-assembler system that used the Apple ][noparse][[/noparse] as a host machine, and a cable from its game port went to an expansion card in the C64. The most-used "key" on the C64 was the power switch - off and on all the time. The Apple ][noparse][[/noparse] stayed awake and downloaded code over and over into the C64. I was 14 when designed that system and I sold over 300 of them to Sega, Williams, Activision, and others. I remember riding my bike to the convenience store (in 1982) and filling out the UPS forms to send them all over the country. I used that system to design the ISEPIC. Okay, enough nastalgia. We're in the complicated 21st century now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
That's good news regarding USB support!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
What would be the pitch between pins? Will 8/8mil trace/clearance be possible?
Thanks again.
Post Edited (jazzed) : 11/24/2009 1:51:15 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
http://www.practicalcomponents.com/amkor/amkor-pq-lqfp.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
much easier to solder bga then fine pitch chips
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
The LQFP sounds pretty sweet, and a .00787" design rule fudge is no problem. With a .4mm pitch, what would the actual width of the leads be? (I'm just wondering if the pads would have to be wider than 0.2mm to accommodate the leads correctly.)
Thanks,
-Phil
I'm not sure I see the benefit of onchip development but I'm not an expert.
Those netbooks with 1024x600 screen, keyboard, usb ports, sd slots, wifi, and power supply·etc can be bought for $149 on sale.
Wouldn't it just be easier to write your own embedded linux loader or something?
Chip: I presume when you say support for some kind of card this will mean we will not have to have an EEPROM/FLASH boot chip on-board? I do hope so.
Did you all notice the >96 I/Os ??? (Chip said "over 3 x 32 pin ports")
I am not going to comment on the·posts (it pretty much sums up my sentiments), except to say I think an onboard (or via microSD/etc) development would be great.
FWIW: PS2 vs USB for keyboards and mouses (yes the plural of the hardware mouse is mouses). Many of the current USB keyboards and mouses still support the old PS2 serial. You can use a common footprint to load either a USB or PS2 socket but 1 serial pin changes which can also be corrected in software.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
On this entire "embedded IDE" topic, I tried very hard to wade through all the thoughts on this thread and in the end, began to think that a "smarter version" of a develpment board (an enitre "embedded" development system" could be a reasonable compromise? With this, deverlopers could have an "Apple" platform with all signals/buses exposed and all the smarts and general purpose I/O needed to host the development efforts, allow for in-circuit debug and testing. Also, externalizing and decoupling the development platform from the design of the device internals allows these two efforts to proceed in parallel (and maybe even be done by any outside company). So, perhaps a better notion would be do define a specification for such a platform and then allow market forces to play themselves out. Another considerion is that once a product is developed do we really need to carry around all the "weight" of the devleopment environment? For example, adding all the connectors etc to support the "in field prgramming and debugging" could add unnecessarily to the costs of any product that will not make use of any such feature.
Sorry, if this is not a useful comment, as I said I tried very hard to follow this disucsion, but am not sure I "got all the finer points" being discussed by others.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
humanoido
Post Edited (humanoido) : 11/24/2009 6:17:21 AM GMT
1) Check for serial (via last two pins)
2) Check for USB (via last two pins)
3) Check for I2C EEPROM (two pins below last two)
4) Check for SPI EEPROM (three pins below last two)
5) Check for SD card (? pins below last two)
The first thing found, in that order, will be used to boot from. If nothing is found, the chip will go to sleep.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Here is a SchmartBoard that handles .4mm lead pitch packages. It's pretty dense (6.35x of standard .100" DIP spacing):
http://www.curiousinventor.com/store/product/178
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
BTW: Nice. I like the boot from USB (no USB chip)·
I am not sure if this is a can of worms... Could the USB be master or slave? i.e. Plug in a USB memory stick to boot from. I have a miniature USB to microSD converter (about $5) and it is not much bigger than the microSD itself. I guess that may entail royalties and we don't want that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 11/24/2009 6:42:13 AM GMT
USB needs 3 pins and probably needs to be at the very end of the sequence. It's incredibly slow to enumerate and you'd be waiting for an excessive timeout before moving on. The other hassle is what type of USB do you use? HID is the only one that windows won't need a .inf file for, but can be a problem across multiple platforms. CDC-ACM is a great choice as it just presents as a serial port, works on all known usb host platforms and is relatively easy to do (the current USB code for the Prop-I does it standing on its head in two cogs). Your biggest hassle with USB is what do you actually do with it? The Host application won't see a port until the prop resets and goes into the bootloader, and the prop won't be able to do anything until it's checked that nothing is waiting to talk to it on the other end. I have a USB-HID bootloader for the Prop-I and an application that allows you to load it on Windows and Linux (I never got HID working properly on OSX), but you either have to have the USB connected full time, or you need to reset the prop and time your application right to try and talk to it.
I'm pretty sure you can reliably do the SD card in 4 pins. That'd be pretty sexy too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
BradC, for USB, is the third pin needed to handle the initial pull-up/down on one of the two data pins? If we have pull-up/down on every pin, will it still need three pins then? I see what you are saying about the enumeration headache. The purpose of USB would be, at least,·to provide a development conduit to the PC. Also, users could do other things, as well. SD card in 4 pins would be nice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
> their game.
That was a vote for Linux!
> and maybe just one or two signal wires going down to the target Propeller board. Every chip would have this built-in capability,
> but needn't use it. You could develop on the same chip, or from another, for one chip, or for an array.
It still is a waste to have the code in ROM. Except the Prop II is targeted for development and not for being used (in devices). Nobody will stop you from writing a IDE that runs on the Prop, including syntax-highlitghting, write files and directories to USB or backup to CD-ROM. But that code rests well in EEPROM. And if you want it to keep for 100 years, a OTP-ROM is it.
Languages are moving forward and aren't cast in silicon. See the alternative SPIN-compilers with extensions and assemblers. Or other languages like Basic, C and Forth. Or the ZICOG and 6502-efforts. You are heading for a closed system, while users of the Prop go in hundreds of directions.
Whatever the outcome is, I'll never use it (the on-chip-IDE). I prefer working in an open environment.
See the top quote of your statement.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO