Remy,
I don't know exactly how it will turn out,·and if the idea proved to be a mess, we wouldn't implement it -·don't worry. Making things proprietary is not the goal, either, we just want to make·what works best, all things considered.
About all the exisiting PC and Mac OS's: I think their only value to a Propeller development system, aside from providing·a·GUI of someone's personal choice, is that they load and save files on·what·are·highly-conversant platforms. Beyond that, they each represent·unique headaches for hosting a development system on. The only long-term solution I see to this problem is to cut them out of the picture as much as possible, while making the chip·self-hosting in the process (with the option of using your own computer/OS as a front-end).
Even if we manage to acheive this, anyone could still use the Propeller as a raw material and make, for example, a Mac-hosted Forth development system. What intrigues me so much about the possibility of getting a whole development system onto the chip, itself, is that we could do things exactly as we see fit, without compromise, and it would cost only·a few pennies' worth·of silicon. If someone wanted to do something different, they could easily bypass it, perhaps through a pin state at startup.
Does this put you at ease, at all?
Remy Blank said...
Chip Gracey (Parallax) said...
On the next generation of the Propeller, we will have 96k of unused ROM which we plan to eventually sink a whole development system into.
I'm a bit surprised to read that. I can't help feeling that this will not change anything for users from the current situation: instead of having to maintain Linux as my main system, and a Windows installation in a VM, I will have to maintain Linux and a "Propeller-custom-OS" installation for development. Still two systems to maintain.
Lets face it, Windows and its variants are going to stay with us for a while like it or not.
So do not bury our heads in the sand and pretend does not exist.
I do not see any other OS in the near future to replace Windows. ·
Chip, instrad of an embedded complier accessable through vnc/vga/keyboard/etc, how about offering the next generation to have a hyperterminal/serial access to a "menu" where with a "programmer circuit" connects to the pins 30 and when the term sends say ctrl/r (15hex?) the user will be prompted with a menu, forth, spin/asm basic/ etc. can launch one, and compile /run/save to eeprom there.
Seems to me alot less work than forcing everyone to have the ps2/vga/tv etc running on the breadboard. and anyone with any os and a serial port could program it.
Lilke I said before I am not really interested in this, as I want to hit F1 for keyword help/souce control and all the bells and whistes of a real IDE.
May be able to do this now on other IO ports with femtobasic, sniff ports 1 and 0 wait for hex XXX then display a menu.... Mike?
Sean
Post Edited (bassmaster) : 2/10/2007 5:18:17 PM GMT
El Paisa, well said, monopoly or not, like it or not, we must comply and be assimilated.
Younger generations that refuse to use windows are going to find themselves in a mess when they go to a fortune 500 company, and do not understand MS project / Powerpoint / and and other MS products, even if they are lucky enough to get past the first interview.
Making Propeller development self-hosting so that you can develop embedded code on the same machine that is running the code is an exciting idea. That's why currently I'm building robots that carry laptops - I'm including an entire laptop just so that I can host the Parallax IDE on the robot. I know that I will run into problems in the field, and being able to tweak the code right then and there is important. Self-hosting development is important enough to me that I'm willing to include an entire PC in a control system, if it will fit, just to achieve that.
IMO having a different machine for development than for running the code is the biggest difficulty of coding today's embedded systems vs. PC programs; writing the code on the PC and downloading it to the chip is kind of like putting a ship in a bottle - you hope that once it's in there all the sails unfurl ok, but if they don't your ability to tweak it is limited.
Also, I've found when developing programs for Lego Mindstorms robots that the time it takes to get the code onto the robot adversely effects how quickly you see the changes after you made them. That in turn affects how willing you are to tweak small things, and how well you remember your place from one cycle to the next. It's like the difference between having an interactive terminal and having to submit punched cards in batches. On the other hand, the shorter your code-compile-run sequence is, the faster you can test small tweaks and the faster and more effortlessly you can develop, so even just removing the time to download the code from PC to the chip will speed up development.
Bassmaster,
There's a big difference between the concepts that are part of Project, Powerpoint, Excel, Word and the specifics of those particular products as sold today (or tomorrow). The concepts (and fluency in their use) are indeed necessary for many if not most jobs today much beyond simple retail. There are a variety of non-Microsoft products that provide the functionality of Powerpoint, Excel, and Word as used by most people, many of them available for free or a small fraction of what Microsoft charges. Large companies with expensive, large IT departments may buy expensive corporate licenses for the Microsoft products and expect their employees to use them, but someone who is competent using most of the non-Microsoft products should be able quickly to achieve the same competence with the Microsoft product since the concepts are the same. Microsoft is (and is likely to continue being) dominant in the USA, but is increasingly being displaced elsewhere and, as large corporations become more international, particularly with control moving overseas, you will see less fixation on Microsoft. It will take time, but it is already happening.
Chip Gracey (Parallax) said...
I don't know exactly how it will turn out, and if the idea proved to be a mess, we wouldn't implement it - don't worry.
Oh, I don't worry. Many things are different on the Propeller than on any other microcontroller I know, and most (all?) of them are better. So in my opinion many choices to do things differently have been made wisely.
said...
About all the exisiting PC and Mac OS's: I think their only value to a Propeller development system, aside from providing a GUI of someone's personal choice, is that they load and save files on what are highly-conversant platforms.
I guess I don't know enough of the direction you want to take with the Propeller to comment on that. When you say "getting a whole development system onto the chip", do you mean an editor, a spin compiler, an assembler, a shell, ...?
You are right that some (most?) of the tools we use are a personal preference. I know for one that I hate it when I have to use a proprietary editor for some tasks, when I am used to Eclipse. And I feel very ill at ease if I can't use a revision control system.
But I need a computer all day long for other stuff (browsing, e-mail, displaying PDF datasheet, electronic circuit design, mechanical design, programming, ...), so it is easier for me if I can do Propeller development on the same host. You mention a VNC-like facility, that would already solve the issue.
said...
What intrigues me so much about the possibility of getting a whole development system onto the chip, itself, is that we could do things exactly as we see fit, without compromise, and it would cost only a few pennies' worth of silicon.
I was going to ask if adding a development system in ROM that wouldn't be used at all in production units of whatever device using a Propeller wouldn't make the chip more expensive, but that seems to be solved already.
said...
If someone wanted to do something different, they could easily bypass it, perhaps through a pin state at startup.
Does this put you at ease, at all?
Speaking for myself, as long as you publish the specs of the assembly language so that I can make my own cross-platform, modular, wizbang assembler, I don't really mind.
Now, if the development environment (and compiler) is on the chip, it would be nice to be able to script the thing remotely, so that I can send it a text file and it returns the compiled object. That way I could use any development environment I want, and use a demo board as a compiler co-processor. Sounds quite funny, actually. If that solves your maintenance problem, I'm all for it.
Jeff Martin wrote the Propeller.exe application, and I believe it uses some TrueType font features that only XP supports, but I'm not sure. I know that's no justification for 'forcing' everyone else to upgrade, but our past experience has been that·customers pretty much·lead the charge into the next·Windows, and they definitely expect Parallax software to run in it. This usually requires some special attention from us. And, certainly, we get pushed·along by the·applications we use at work, whose latest versions often dictate the newest Windows, as the old ones often cease to work properly, if you don't stay up-to-date.
One maddening thing I've noticed about the evolution of Windows is that it has a way of eventually breaking all our old software, even software I wrote myself. The original·SX-Key·software now locks up for unknown reasons and exhibits strange behaviors that are definitely not dictated in my source code.·Why is this?·Delphi was used to write all of our Windows apps, and in the case of the SX-Key software, I used only the standard 'events', 'methods', and 'properties' of the most basic objects, like FileOpen, Button, ScrollBar, etc. What went wrong? Was Delphi calling the API routines·in some funny that·Windows sharpened up against, or did Windows·quit supporting some API calls? Who knows? Would things have been different if we had used Microsoft tools, instead? I kind of doubt it. The fact is,·the software that I spent a year writing in 1997 is now acting·like a 3rd grader wrote it.
Had we been more privy to the possibility of making an app that ran on Win98 and up, I bet we would have done that for the Propeller. Our experience·definitely has us conditioned to suppose it's just not possible.
hippy said...
What I don't understand is why the Propeller Tool requires Windows XP and was not designed to run on 98SE. From my perspective, "it's just an IDE", and many others have managed to create those which run across the whole range of Win32 OS's.
1) What is it that specifically, technically requires the Propeller Tool to be Windows XP only ?
2) Why were such specific requirements not circumvented or designed around to deliver an IDE which runs on any Win32 platform ?
Like many, I object to paying Microsoft for things I do not need when what I have serves my purposes perfectly. I really object to having to pay Microsoft simply because another company falls victim to playing the 'Microsoft upgrade game' and forces me to upgrade when I have no need or desire to, and particularly when they could make it that I don't have to.
Companies end up supporting Microsoft by dictating to their customers which OS they must have to use their tools. Sometimes there may be a good reason for that, most often not. I am sure someone could rewrite the Propeller Tool to run under Windows 98, and I am quite disappointed that Parallax could not or chose not to. I would much rather spend my money on Parallax product than with Microsoft.
Mike Green said...
Bassmaster,.... Large companies with expensive, large IT departments may buy expensive corporate licenses for the Microsoft products and expect their employees to use them, but someone who is competent using most of the non-Microsoft products should be able quickly to achieve the same competence with the Microsoft product since the concepts are the same....
I totally agree with you, but I am making a point, that in the real world, this concept will not get past the first interview in a fortune 500 company. There have been extensive write ups· and articles on hiring practices. Large organizations get specific requests from the manager who needs a position, the HR ndepartment will weed out the resume's that do not fit 90% of the qualifications, before even reading the whole resume, the manager rarely gets to choose from a list of resume's until the HR has weeded out the "undesirables".
Back in May of 06 there was a front page article on this in the Wall Street Journal, many applicants never make it to the first interview even though they are more qualified then the ones that do.
Then the first interview is likely with a hiring manager, who knows little about the position and you have to be pretty savvy to get past that one, before you can convince the manager that you can adapt to any software.
I know that there are many students in this forum, and want them to understand that like it or not, that is the way of the world.
I guess I am dense today.
> On the next generation of the Propeller, we will have 96k of unused ROM which we plan to eventually sink a whole development system into.
I checked my machine and the development environment is over 8MB. This doesn't include my jot file with tricks and tips or any source code for my projects or any data sheets. The help file alone is 1MB and is far removed from the functionality of the PBasic help file. Now if the 96k was used to make the Propeller OS independent, that would be nice for people who don't want to use Windows. I don't see a Propeller, keyboard, mouse and VGA/TV and a feasible development environment. It would perhaps have some utility for minor fixes/tweaks to a program developed on a desktop/laptop. Right now I don't know what I would put in that ROM space or if it would be better to use the die space for something else.
John, look at the size of tinyc or any assembler for the z80. Our application that ran 32 pumps and 32 card readers at the gas pumps written in C was 32k, the Bloating you are seeing is a direct result of the GUI IDE and Microsoft runtime, etc. I imagine the IDE Chip envisions would be very basic on the chip.
Post Edited (bassmaster) : 2/10/2007 6:24:54 PM GMT
Still, I'd rather see that 96K be filled with fonts at various sizes (a 5x7, 6x8, 8x8, and 8x12 at least), maybe some standard
support (built-in VGA support and TV support at various resolutions, built-in support for keyboards and serial drivers, maybe
even FAT16), etc., than to fill it with a development environment. I want to be able to do as much as possible with the
chip as cheaply as possible, and filling it with a development environment that just goes to waste during deployment sounds
like a waste of silicon.
Also, I'd much prefer the tools to improve (i.e., better optimization, more high-level support of real objects and the like,
macros, etc.) than to just see them shoehorned into the chip itself.
Essentially, I am afraid that effort spent fitting a development environment into the chip will end up with an overall
inferior IDE. Most of us developers already have a PC with a nice screen and keyboard and network connectivity; let's
continue to leverage that.
If you don't like the bugs introduced by various versions of Windows, open source the IDE so people can fix them
themselves.
You're right that a rich help system may not fit on the chip, but this 8MB you see on your PC is a product of·modern computing, not designer intent.·What is in that 8MB is·mysterious to me. Our·source code is probably a few hundred KB, only,·and calls in some other resources which are about the same size. This still can't explain that 8MB, though. Only on modern computers do·compiled programs actually become·BIGGER than the source code, and WAY bigger, at that.
Before we ported the BASIC Stamp IDE to Windows, it was a DOS program written in assembly language. It had the·same·edit, compile, and download functionality as today's Windows version, but with a single-pane text editor, and no support for a few subsequent Stamp II variants made from SX chips - no big deal. Almost nobody today would guess that it was only 13KB (single .exe file), or in 'modern' terms 0.013MB, or ~1/600th of today's size. This was for a full IDE: editor, compiler, and downloader. It was tight and clean, utterly reliable, and never grew bugs. Everything we've made since then is a relatively sloppy mess. It's not because we can't program, either. Our hands are tied! I want to get back to strong coding, and quit being doomed to writing only perishable code. No more building houses on quicksand! Anyway, 96kB would be·a huge warehouse to us. I bet we could even fit a good help system in their with a little data compression.
There would be some advantages to working on the chip that could justify a keyboard/monitor for some people. It would be lightning fast and very reliable. This, alone,·could go a long way in freeing you to think about your code. Also, I hope we can later make a version of the next chip with external pins to hook to fast ZBT-type SRAM for maybe 32MB of full-speed hub RAM. Then, we could write schematic editors, PCB layout software, and even EDA tools on the Propeller. Imagine your schematic and·PCB layout problems solved once and for all. No more tribute to pay. No more having the rug pulled out from under your feet.·You could use it for the rest of your life.
John Abshier said...
I guess I am dense today.
> On the next generation of the Propeller, we will have 96k of unused ROM which we plan to eventually sink a whole development system into.
I checked my machine and the development environment is over 8MB. This doesn't include my jot file with tricks and tips or any source code for my projects or any data sheets. The help file alone is 1MB and is far removed from the functionality of the PBasic help file. Now if the 96k was used to make the Propeller OS independent, that would be nice for people who don't want to use Windows. I don't see a Propeller, keyboard, mouse and VGA/TV and a feasible development environment. It would perhaps have some utility for minor fixes/tweaks to a program developed on a desktop/laptop. Right now I don't know what I would put in that ROM space or if it would be better to use the die space for something else.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/10/2007 7:41:19 PM GMT
Chip Gracey (Parallax) said...
There would be some advantages to working on the chip that could justify a keyboard/monitor for some people. It would be lightning fast and very reliable. This, alone, could go a long way in freeing you to think about your code. Also, I hope we can later make a version of the next chip with external pins to hook to fast ZBT-type SRAM for maybe 32MB of full-speed hub RAM. Then, we could write schematic editors, PCB layout software, and even EDA tools on the Propeller. Imagine your schematic and PCB layout problems solved once and for all. No more tribute to pay. No more having the rug pulled out from under your feet. You could use it for the rest of your life.
I have to admit that I am clueless as to whether you are serious there or just making fun of our credulity...
About a·year ago, I·had to·get a new version of my PCB layout program because Windows finally broke my last version to the point where it would not work at all,·due to some problem with the security dongle driver. I figured it was time to spend the usual $900 on an 'upgrade'. So, I called Mentor Graphics, who was the new owner of PADS, and they told me that the upgrade would cost something like $6000. This was because I had let my maintenance 'lapse', for which I now must pay 5 missing years' worth, plus a 15% penalty for·my error. I got really mad, and through a lengthy exchange of emails which was emotionally draining for both me and them, it was agreed that I could purchase a year of maintenance for a newly stripped-down version of PADS which would limit me to·4-layers, max. This was for $900, which was reasonable, considering I never make more than 2 layer boards. To put this in perspective, this program was originally acquired in 1991, and it cost $1000 at the time. It's a little better now, but not much. In fact, as of late, they've modernized it with TrueType fonts and now the soldermask bloat creates DRC errors if you try to expose metal text. Before, the simple built-in·vector font worked beautifully. It's gone for good. If this is all 'progress', it's not for me. And if it's not for me, it's probably not for some others, either.
Remy Blank said...
Chip Gracey (Parallax) said...
Then, we could write schematic editors, PCB layout software, and even EDA tools on the Propeller. Imagine your schematic and PCB layout problems solved once and for all. No more tribute to pay. No more having the rug pulled out from under your feet. You could use it for the rest of your life.
I have to admit that I am clueless as to whether you are serious there or just making fun of our credulity...
-- Remy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/10/2007 8:59:20 PM GMT
Let me remove the mystery. The 8 MB is the size of the Propeller tool directory. To be fair, a little over half is the manual. That would go away, but the help file (1MB) would grow. Prop.exe is 810KB. Perhaps it could shrink by approximately a factor of 8 to 96KB. But you need libraries. With only 2 or 3 .spin files added to the Parallax distribution, the zipped size is 162KB. I also have features I would like added to the development environment: The promised debug window. It would be nice to delcare variables as FLOAT and have the IDE take care of the F.FMul(F.FSine(F.Float(x), Amp) stuff.
bassmater, check out wxwindows - i think it is much lighter weight and less dependancies than GTK, and its available for Linux, Windows, OSX and more.
(nice work on the tray tool btw)
bassmaster said...
I think I will try my hand at gtk... embedded compilers are not what I want personally. What I meant to emphasize from this post topic, is that parallax has made a chip like no other.
That said, with some work, and maybe some help from Parallax to release a tokenizer or release the api, for linux and osx, so we all can create what we want, Java would work with all platforms, but I despise it personally. My C Compiler project, hopefully will be a command line tool that kdeveloper or any linux development IDE could use.
If written well in ansi C it will be portable for all platforms.
I have the experience and tools to hack the IDE and the outgoing serial port and probably figure out a way to do this fairly well, as I do it daily at my job with obsolete devices/applications that the company who wrote/created them are no longer in business. But I will not, as Parallax owns this information, and I need their blessing
to do so. (or better yet, a tokenizer for the ASM)
Mike you are correct, the prop to prop loader works flawlessly, the sdcard code is good, your code is good, so a few days and someone could roll it all together for a prop to prop from the prop os deveopment environment, (at least in spin).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
You're right, the executable is under 1MB. I wasn't sure what all the installer was outputing that constituted the development system. BTW, that 810k .exe file was about 4MB before we ran it through an .exe compactor. So, it's already shrunk 5x. It could be done well in 24KB on the Propeller.
In 96k, I think we could have an IDE, essential libraries, help system, and a few more fonts (8x12, 8x8). Before any development system gets set in ROM, though, it would be proven in RAM, and everybody would have had the opportunity to use it.
About the Propeller debug window, that is coming in a month or two. Jeff is planning on spending much of his vacation working on it. It's going to do a lot more than the BASIC Stamp debug window does.
I hear you about the floating point. This is something that could be improved.
John Abshier said...
Let me remove the mystery. The 8 MB is the size of the Propeller tool directory. To be fair, a little over half is the manual. That would go away, but the help file (1MB) would grow. Prop.exe is 810KB. Perhaps it could shrink by approximately a factor of 8 to 96KB. But you need libraries. With only 2 or 3 .spin files added to the Parallax distribution, the zipped size is 162KB. I also have features I would like added to the development environment: The promised debug window. It would be nice to delcare variables as FLOAT and have the IDE take care of the F.FMul(F.FSine(F.Float(x), Amp) stuff.
Thanks for the clarification, I had a doubt there.
I fully agree with your example about the PCB layout program. At work we use Protel (now Altium Designer). I had started using it at version 2.0, and by Protel 98 it was pretty stable and very usable. We would still be using it if I had anything to say about it. But no, we had to upgrade to 99 (made huge project files (>50MB)), to DXP 2002, then DXP 2004, and now the latest (can't remember the designation, I have stopped counting). Every new version added bloat (I really don't need a logic simulator, and actually neither an autorouter), and removed simplicity and even features I liked.
But my dream is a little different than yours: instead of hoping to replace such tools by developing them myself, I hope to find (and if possible contribute to) such tools as open source projects. Unfortunately, schematics and especially PCB design software seems to be a difficult problem, and there are no real contenders to the professional tools.
On the other hand, I understand that this might not be viable for a business. So I eagerly await "Chip's PCB designer" (that even sounds a bit ironical) on Propeller!
I think the easiest way forward for OS independence is to seperate the compiler from the IDE, and to do this across all of the IDEs - PBasic, SX/A/B, and Spin. This would allow users a choice of IDE, and you could still use current IDEs by interfacing with the command line tools.
As for the Propeller, I would like to see something similar to RISC OS developed for it. Think of something like that running on a Hydra. There's your whole computer!
I like the idea of having the development environment on the chip. I can sympathize with the "waste" that might sit there unused in a deployed system. But our application is scientific instruments that quite often need on the spot field upgrades under less than office conditions. A rugged keyboard and display fit to purpose, with no operating system to boot up or to get in the way, with a reliable development environment, that could be a big plus. I'd like to see it accessible either via keyboard/display, or via terminal emulator.
The old Tandy model 100 was a Microsoft product that had its own operating system built around the BASIC programming environment, and it spawned a whole cottage industry. I heard Bill Gates himself say at a BMUG (Macintosh users) meeting once that it was one of their most exiting projects, to fit all that functionality into its 32k ROM. We used to make ram expansions and rom emulators for it.
Mike, it really true that Microsoft is scrapping support for VB macros in the new Macintosh version of Excel? That's a bummer.
OOOOHHHHHH 32MB full speed hub run with a later version of the next prop???? I'm drooling.
Chip, if it helps the ide etc, like I already told you in PM's... use the large model...
I'm working on some software (think large model·assembler/compiler/linker)·that will help with that; unfortunately for development speed (but fortunately for my debts) I'm a bit overloaded with consulting work right now so it will be a while. At least I can keep an eye on the forums during compiles!
Chip Gracey (Parallax) said...
Also, I hope we can later make a version of the next chip with external pins to hook to fast ZBT-type SRAM for maybe 32MB of full-speed hub RAM. Then, we could write schematic editors, PCB layout software, and even EDA tools on the Propeller. Imagine your schematic and·PCB layout problems solved once and for all. No more tribute to pay. No more having the rug pulled out from under your feet.·You could use it for the rest of your life.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Tracy,
I can't find the article now, but there was a lot of discussion in the last few weeks on this. Maybe Microsoft backed off. They (Microsoft's Mac Business Unit) indicated that they'd have to rewrite all of the VB stuff to make it work with the new Mac Office version and that it (the rewrite) would substantially delay its release ... so they'll leave it out.
Mike
Tracy Allen said...
Mike, it really true that Microsoft is scrapping support for VB macros in the new Macintosh version of Excel? That's a bummer.
Here's an article from one of the Microsoft MacBU guys explaining the decision. This is from back in August. I haven't heard anything about them changing their mind. But I don't use Office so it isn't a story I've been following very closely.
Chip Gracey (Parallax) said...
Hippy ... Had we been more privy to the possibility of making an app that ran on Win98 and up, I bet we would have done that for the Propeller. Our experience definitely has us conditioned to suppose it's just not possible.
Thanks for taking the time to respond and clarify.
One approach might be, as Kevin Wood suggests earlier, split the IDE from the tokenizers / compilers. It seems to be the GUI and API's which create the most problems, and there should be relatively few interactions with the OS in the compiler itself.
I would agree with bassmaster ... keyboard, mouse, vga&tv are a bit much for me. The good old serial port or usb port would be great. Other than that 10/100BaseT would be a more serious proposition on the prop2 than on current prop. It would be handy to control things like I do with my unix machines over serial ports and telnets/ftp's.
The news & commentary about this is interesting, as for one thing it points it up as the way of the future (and paranthetically, the cautionary note, can anyone can figure out how to program it outside narrow bounds of specific supercomputer calculations). I wonder who might train engineers to step into such jobs, when it finally emerges from the research labs and comes to market in some form in 5 years or so? Who has a product now?!
Their demo uses floating point units integrated into each of the 80 tiles, and the inter-tile data router, to solve coupled differential equations at 1 teraflop. It has no main memory interface. Also interestingly, it uses a long instruction word, whatever RISCish they may mean by that. The chip is built with 65 nanometer technology, but they are looking toward another 45 nanometer breakthrough technology being pursued by IBM and also Intel. That also takes advantage of the new hafnium oxide high-K gate insulator,
which can be thicker and thus have lower leakage than the conventional silicon dioxide gate.
Comments
I don't know exactly how it will turn out,·and if the idea proved to be a mess, we wouldn't implement it -·don't worry. Making things proprietary is not the goal, either, we just want to make·what works best, all things considered.
About all the exisiting PC and Mac OS's: I think their only value to a Propeller development system, aside from providing·a·GUI of someone's personal choice, is that they load and save files on·what·are·highly-conversant platforms. Beyond that, they each represent·unique headaches for hosting a development system on. The only long-term solution I see to this problem is to cut them out of the picture as much as possible, while making the chip·self-hosting in the process (with the option of using your own computer/OS as a front-end).
Even if we manage to acheive this, anyone could still use the Propeller as a raw material and make, for example, a Mac-hosted Forth development system. What intrigues me so much about the possibility of getting a whole development system onto the chip, itself, is that we could do things exactly as we see fit, without compromise, and it would cost only·a few pennies' worth·of silicon. If someone wanted to do something different, they could easily bypass it, perhaps through a pin state at startup.
Does this put you at ease, at all?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
So do not bury our heads in the sand and pretend does not exist.
I do not see any other OS in the near future to replace Windows.
·
Seems to me alot less work than forcing everyone to have the ps2/vga/tv etc running on the breadboard. and anyone with any os and a serial port could program it.
Lilke I said before I am not really interested in this, as I want to hit F1 for keyword help/souce control and all the bells and whistes of a real IDE.
May be able to do this now on other IO ports with femtobasic, sniff ports 1 and 0 wait for hex XXX then display a menu.... Mike?
Sean
Post Edited (bassmaster) : 2/10/2007 5:18:17 PM GMT
Younger generations that refuse to use windows are going to find themselves in a mess when they go to a fortune 500 company, and do not understand MS project / Powerpoint / and and other MS products, even if they are lucky enough to get past the first interview.
IMO having a different machine for development than for running the code is the biggest difficulty of coding today's embedded systems vs. PC programs; writing the code on the PC and downloading it to the chip is kind of like putting a ship in a bottle - you hope that once it's in there all the sails unfurl ok, but if they don't your ability to tweak it is limited.
Also, I've found when developing programs for Lego Mindstorms robots that the time it takes to get the code onto the robot adversely effects how quickly you see the changes after you made them. That in turn affects how willing you are to tweak small things, and how well you remember your place from one cycle to the next. It's like the difference between having an interactive terminal and having to submit punched cards in batches. On the other hand, the shorter your code-compile-run sequence is, the faster you can test small tweaks and the faster and more effortlessly you can develop, so even just removing the time to download the code from PC to the chip will speed up development.
There's a big difference between the concepts that are part of Project, Powerpoint, Excel, Word and the specifics of those particular products as sold today (or tomorrow). The concepts (and fluency in their use) are indeed necessary for many if not most jobs today much beyond simple retail. There are a variety of non-Microsoft products that provide the functionality of Powerpoint, Excel, and Word as used by most people, many of them available for free or a small fraction of what Microsoft charges. Large companies with expensive, large IT departments may buy expensive corporate licenses for the Microsoft products and expect their employees to use them, but someone who is competent using most of the non-Microsoft products should be able quickly to achieve the same competence with the Microsoft product since the concepts are the same. Microsoft is (and is likely to continue being) dominant in the USA, but is increasingly being displaced elsewhere and, as large corporations become more international, particularly with control moving overseas, you will see less fixation on Microsoft. It will take time, but it is already happening.
I guess I don't know enough of the direction you want to take with the Propeller to comment on that. When you say "getting a whole development system onto the chip", do you mean an editor, a spin compiler, an assembler, a shell, ...?
You are right that some (most?) of the tools we use are a personal preference. I know for one that I hate it when I have to use a proprietary editor for some tasks, when I am used to Eclipse. And I feel very ill at ease if I can't use a revision control system.
But I need a computer all day long for other stuff (browsing, e-mail, displaying PDF datasheet, electronic circuit design, mechanical design, programming, ...), so it is easier for me if I can do Propeller development on the same host. You mention a VNC-like facility, that would already solve the issue.
I was going to ask if adding a development system in ROM that wouldn't be used at all in production units of whatever device using a Propeller wouldn't make the chip more expensive, but that seems to be solved already.
Speaking for myself, as long as you publish the specs of the assembly language so that I can make my own cross-platform, modular, wizbang assembler, I don't really mind.
Now, if the development environment (and compiler) is on the chip, it would be nice to be able to script the thing remotely, so that I can send it a text file and it returns the compiled object. That way I could use any development environment I want, and use a demo board as a compiler co-processor. Sounds quite funny, actually. If that solves your maintenance problem, I'm all for it.
Keep us posted about where this is going!
-- Remy
Jeff Martin wrote the Propeller.exe application, and I believe it uses some TrueType font features that only XP supports, but I'm not sure. I know that's no justification for 'forcing' everyone else to upgrade, but our past experience has been that·customers pretty much·lead the charge into the next·Windows, and they definitely expect Parallax software to run in it. This usually requires some special attention from us. And, certainly, we get pushed·along by the·applications we use at work, whose latest versions often dictate the newest Windows, as the old ones often cease to work properly, if you don't stay up-to-date.
One maddening thing I've noticed about the evolution of Windows is that it has a way of eventually breaking all our old software, even software I wrote myself. The original·SX-Key·software now locks up for unknown reasons and exhibits strange behaviors that are definitely not dictated in my source code.·Why is this?·Delphi was used to write all of our Windows apps, and in the case of the SX-Key software, I used only the standard 'events', 'methods', and 'properties' of the most basic objects, like FileOpen, Button, ScrollBar, etc. What went wrong? Was Delphi calling the API routines·in some funny that·Windows sharpened up against, or did Windows·quit supporting some API calls? Who knows? Would things have been different if we had used Microsoft tools, instead? I kind of doubt it. The fact is,·the software that I spent a year writing in 1997 is now acting·like a 3rd grader wrote it.
Had we been more privy to the possibility of making an app that ran on Win98 and up, I bet we would have done that for the Propeller. Our experience·definitely has us conditioned to suppose it's just not possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Back in May of 06 there was a front page article on this in the Wall Street Journal, many applicants never make it to the first interview even though they are more qualified then the ones that do.
Then the first interview is likely with a hiring manager, who knows little about the position and you have to be pretty savvy to get past that one, before you can convince the manager that you can adapt to any software.
I know that there are many students in this forum, and want them to understand that like it or not, that is the way of the world.
> On the next generation of the Propeller, we will have 96k of unused ROM which we plan to eventually sink a whole development system into.
I checked my machine and the development environment is over 8MB. This doesn't include my jot file with tricks and tips or any source code for my projects or any data sheets. The help file alone is 1MB and is far removed from the functionality of the PBasic help file. Now if the 96k was used to make the Propeller OS independent, that would be nice for people who don't want to use Windows. I don't see a Propeller, keyboard, mouse and VGA/TV and a feasible development environment. It would perhaps have some utility for minor fixes/tweaks to a program developed on a desktop/laptop. Right now I don't know what I would put in that ROM space or if it would be better to use the die space for something else.
Post Edited (bassmaster) : 2/10/2007 6:24:54 PM GMT
support (built-in VGA support and TV support at various resolutions, built-in support for keyboards and serial drivers, maybe
even FAT16), etc., than to fill it with a development environment. I want to be able to do as much as possible with the
chip as cheaply as possible, and filling it with a development environment that just goes to waste during deployment sounds
like a waste of silicon.
Also, I'd much prefer the tools to improve (i.e., better optimization, more high-level support of real objects and the like,
macros, etc.) than to just see them shoehorned into the chip itself.
Essentially, I am afraid that effort spent fitting a development environment into the chip will end up with an overall
inferior IDE. Most of us developers already have a PC with a nice screen and keyboard and network connectivity; let's
continue to leverage that.
If you don't like the bugs introduced by various versions of Windows, open source the IDE so people can fix them
themselves.
You're right that a rich help system may not fit on the chip, but this 8MB you see on your PC is a product of·modern computing, not designer intent.·What is in that 8MB is·mysterious to me. Our·source code is probably a few hundred KB, only,·and calls in some other resources which are about the same size. This still can't explain that 8MB, though. Only on modern computers do·compiled programs actually become·BIGGER than the source code, and WAY bigger, at that.
Before we ported the BASIC Stamp IDE to Windows, it was a DOS program written in assembly language. It had the·same·edit, compile, and download functionality as today's Windows version, but with a single-pane text editor, and no support for a few subsequent Stamp II variants made from SX chips - no big deal. Almost nobody today would guess that it was only 13KB (single .exe file), or in 'modern' terms 0.013MB, or ~1/600th of today's size. This was for a full IDE: editor, compiler, and downloader. It was tight and clean, utterly reliable, and never grew bugs. Everything we've made since then is a relatively sloppy mess. It's not because we can't program, either. Our hands are tied! I want to get back to strong coding, and quit being doomed to writing only perishable code. No more building houses on quicksand! Anyway, 96kB would be·a huge warehouse to us. I bet we could even fit a good help system in their with a little data compression.
There would be some advantages to working on the chip that could justify a keyboard/monitor for some people. It would be lightning fast and very reliable. This, alone,·could go a long way in freeing you to think about your code. Also, I hope we can later make a version of the next chip with external pins to hook to fast ZBT-type SRAM for maybe 32MB of full-speed hub RAM. Then, we could write schematic editors, PCB layout software, and even EDA tools on the Propeller. Imagine your schematic and·PCB layout problems solved once and for all. No more tribute to pay. No more having the rug pulled out from under your feet.·You could use it for the rest of your life.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/10/2007 7:41:19 PM GMT
-- Remy
We in the over-the-hill gang want a better offer :>)
PAR
About a·year ago, I·had to·get a new version of my PCB layout program because Windows finally broke my last version to the point where it would not work at all,·due to some problem with the security dongle driver. I figured it was time to spend the usual $900 on an 'upgrade'. So, I called Mentor Graphics, who was the new owner of PADS, and they told me that the upgrade would cost something like $6000. This was because I had let my maintenance 'lapse', for which I now must pay 5 missing years' worth, plus a 15% penalty for·my error. I got really mad, and through a lengthy exchange of emails which was emotionally draining for both me and them, it was agreed that I could purchase a year of maintenance for a newly stripped-down version of PADS which would limit me to·4-layers, max. This was for $900, which was reasonable, considering I never make more than 2 layer boards. To put this in perspective, this program was originally acquired in 1991, and it cost $1000 at the time. It's a little better now, but not much. In fact, as of late, they've modernized it with TrueType fonts and now the soldermask bloat creates DRC errors if you try to expose metal text. Before, the simple built-in·vector font worked beautifully. It's gone for good. If this is all 'progress', it's not for me. And if it's not for me, it's probably not for some others, either.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/10/2007 8:59:20 PM GMT
(nice work on the tray tool btw)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
You're right, the executable is under 1MB. I wasn't sure what all the installer was outputing that constituted the development system. BTW, that 810k .exe file was about 4MB before we ran it through an .exe compactor. So, it's already shrunk 5x. It could be done well in 24KB on the Propeller.
In 96k, I think we could have an IDE, essential libraries, help system, and a few more fonts (8x12, 8x8). Before any development system gets set in ROM, though, it would be proven in RAM, and everybody would have had the opportunity to use it.
About the Propeller debug window, that is coming in a month or two. Jeff is planning on spending much of his vacation working on it. It's going to do a lot more than the BASIC Stamp debug window does.
I hear you about the floating point. This is something that could be improved.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I fully agree with your example about the PCB layout program. At work we use Protel (now Altium Designer). I had started using it at version 2.0, and by Protel 98 it was pretty stable and very usable. We would still be using it if I had anything to say about it. But no, we had to upgrade to 99 (made huge project files (>50MB)), to DXP 2002, then DXP 2004, and now the latest (can't remember the designation, I have stopped counting). Every new version added bloat (I really don't need a logic simulator, and actually neither an autorouter), and removed simplicity and even features I liked.
But my dream is a little different than yours: instead of hoping to replace such tools by developing them myself, I hope to find (and if possible contribute to) such tools as open source projects. Unfortunately, schematics and especially PCB design software seems to be a difficult problem, and there are no real contenders to the professional tools.
On the other hand, I understand that this might not be viable for a business. So I eagerly await "Chip's PCB designer" (that even sounds a bit ironical) on Propeller!
-- Remy
As for the Propeller, I would like to see something similar to RISC OS developed for it. Think of something like that running on a Hydra. There's your whole computer!
The old Tandy model 100 was a Microsoft product that had its own operating system built around the BASIC programming environment, and it spawned a whole cottage industry. I heard Bill Gates himself say at a BMUG (Macintosh users) meeting once that it was one of their most exiting projects, to fit all that functionality into its 32k ROM. We used to make ram expansions and rom emulators for it.
Mike, it really true that Microsoft is scrapping support for VB macros in the new Macintosh version of Excel? That's a bummer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Chip, if it helps the ide etc, like I already told you in PM's... use the large model...
I'm working on some software (think large model·assembler/compiler/linker)·that will help with that; unfortunately for development speed (but fortunately for my debts) I'm a bit overloaded with consulting work right now so it will be a while. At least I can keep an eye on the forums during compiles! ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
I can't find the article now, but there was a lot of discussion in the last few weeks on this. Maybe Microsoft backed off. They (Microsoft's Mac Business Unit) indicated that they'd have to rewrite all of the VB stuff to make it work with the new Mac Office version and that it (the rewrite) would substantially delay its release ... so they'll leave it out.
Mike
www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
Thanks for taking the time to respond and clarify.
One approach might be, as Kevin Wood suggests earlier, split the IDE from the tokenizers / compilers. It seems to be the GUI and API's which create the most problems, and there should be relatively few interactions with the OS in the compiler itself.
Just my 10 bits,
Doug
New York Times
Intel PR blurb
computerWorld
The news & commentary about this is interesting, as for one thing it points it up as the way of the future (and paranthetically, the cautionary note, can anyone can figure out how to program it outside narrow bounds of specific supercomputer calculations). I wonder who might train engineers to step into such jobs, when it finally emerges from the research labs and comes to market in some form in 5 years or so? Who has a product now?!
Their demo uses floating point units integrated into each of the 80 tiles, and the inter-tile data router, to solve coupled differential equations at 1 teraflop. It has no main memory interface. Also interestingly, it uses a long instruction word, whatever RISCish they may mean by that. The chip is built with 65 nanometer technology, but they are looking toward another 45 nanometer breakthrough technology being pursued by IBM and also Intel. That also takes advantage of the new
hafnium oxide high-K gate insulator,
which can be thicker and thus have lower leakage than the conventional silicon dioxide gate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/13/2007 4:57:43 PM GMT