"I use Atmel AVR's." - OK, A quite reasonable choice for many applications.
" And no. I am not looking for Verilog or VHDL code from Parallax." - OK, not me either.
"Just enough so that someone could create an open-source tool chain without having to resort to reverse engineering bits." OK, BradC has done that with BST. mpark has done that with HomeSpun. Others have written different language compilers to PASM. RossH has a C compiler to LMM, a mode of operation even Parallax had not thought of for the Prop.
So looks to me to be just as open as any ATMEL or PIC etc.
You may want to point at the down loader protocol and disagree with me because you won't find it in a PDF (Which I think it should be). However it was asked for and it was given.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I could be very wrong but I thought that much of the amazing work by BradC, mpark, etc relies, or relied, on information that was reverse engineered not on openly published specifications.
Chris Kraft said...
I could be very wrong but I thought that much of the amazing work by BradC, mpark, etc relies, or relied, on information that was reverse engineered not on openly published specifications.
I can't speak for mpark, but my work actually began when Chip released the interpreter code.
Yes, the code was released well after the Prop was on the market, and no its release did not appear to be specific to allow people to make a compiler, but none the less, it did the job. Prior to this, a couple of forum members had expended a *massive* amount of effort to reverse engineer all this stuff, and had the interpreter not been released I'd probably have looked at it a bit later (or just gone back to the Motorola and Microchip parts I'd been using for years).
I did do some reverse engineering, but it was not required. Let me explain.
In the beginning, using *only* the code released by Chip for the interpreter and booter, I had a functioning compiler and downloader. The code generated was working and there were no obvious limitations.
I wanted to put a test suite together, and I figured the best way to do this was a load (nearly 2000 now) spin files. Compile each file with Propellent (under WINE), and bstc and do a binary compare of the result. When I started to do this I found *huge* anomalies, so I started to dig. I then did some reverse engineering of the Parallax compiler to find out why my floating point lsb's were wrong, my STRING() allocations were not in the same order, some of my constants were encoded differently and a few other little quirks.
So except for one file (that I've been too lazy to chase down, and it's a single floating point value with a 1LSB error), bstc is absolutely bit for bit compatible with the output of the Parallax compiler. *BUT* none of this was required to make a working toolchain, it's simply because I'm anal.
For completeness, the file that does not compile identically came off the hydra cd. "Hydra-Sources/RB_Hydris_012.spin"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Where reverse engineering was done, it was encouraged.
Enabling technologies, like a microprocessor, are atomic things. How open they are all comes down to knowing what the device will do, and enough of it's structure to be confident in that understanding.
We know what a Propeller will do. The few things where we don't are not closed things, just not known things. There is a difference. Over time the little nooks and crannies will be known.
Where writing code is concerned, it is now possible to boot strap ones own tools to develop for the chip, using only open tools as that bootstrap, up to and including typing in the core tools in binary, if desired. Those boot strap efforts were rewarded, encouraged, and are not going away as they are now part of the pool of open tools and understanding we all share.
That's deffo open.
The sum of this is a very nicely opened core enabling technology. There really are no Propeller secrets, but for those cases where the design is simply more brilliant than it's creators or users. We will grapple with that and get mastery, but that's not closed, just cool.
So, it's open now, period.
When the author of the tech will answer questions and encourage efforts to open it, that's as good as it ever gets folks. Given the rather ugly IP environment we live in, and the experiences many of us, including Parallax, have experienced, going slow about the release of core info is not only understandable, but warranted, particularly given the end product is an open, trusted thing, which the Propeller is.
I would think many years of hard won successes embodied in the chip are not something to be taken lightly. Put simply, some slack is warranted as well. I know many, who would not give us, the users, any where near the consideration I see given consistently. Not only do we get that consideration consistently, but we are encouraged to be who we are, are all appreciated for that, and unabashedly all derive significant value from that, Parallax included. Folks, that's also as good as it ever gets.
These things make it possible to author works on the Propeller in the same fashion that occurs on other, core enabling technology considered open, meaning for all intents and purposes, the Propeller is simply "open enough".
Finally, I think it's very important to realize the role some of us play in this. It is not important that people take advantage of the open tools, only that it remain possible for them to do so. Because of this, criticism on whether or not something is "open enough" to be considered "open", is as warranted as the initial caution Parallax showed with what is likely to become their living over the longer term; the Propeller. If it were exploited, infringed on, litigated away, the lead time for another such innovation is long and lean, potentially fatal.
Maybe given these things, we all can be excellent to one another.
Chris Kraft, Ahh... now I see where you are coming from.
Yes, originally the byte codes of the Spin virtual machine (interpreter if you like) were not published. So at that time yes, you are right, implementing a Spin compiler that compiled to those byte codes would have been a nice reverse engineering job.
OK, as far as I know description of the byte codes is still not to be found in any published document from Parallax. However, as BradC points out the actual interpreter of those byte codes that is used in the Prop has now been released.
Some would say that is even better than having the document. Cluso, for example, looked at it and created a faster interpreter from it, without having to start from scratch.
All in all, at this moment, the Prop is looking pretty open.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Looking forward rather than backward, I think Parallax have been extremely open about the upcoming features of the Prop 2.
Of course its not so much "published" as scattered across many threads. Such openness with the forum has probably had quite a positive influence on the Prop 2 feature set.
I don't know of any other micros that have been discussed so openly during their development.
Now that's a blast. I'd forgotten just how inflamatory some of those responses from Paul were.
Just for the record, none of the available tools are "open" in the traditional sense of the word. They are all free (as in beer) though, and the interpreter source is a very open document of the spin bytecodes.
Chip has also stated previously the interpreter source for the processor under development would be available.
I just started to estimate (at my standard consulting rate) how much I've currently got invested in bst and friends, but I stopped in shock when I exceeded what I paid for my house. Software development is not cheap unless your time is free.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Tubular, if you the to the Propeller Wiki (link below in my sig) you can find a link on the front page to the "collected" info about the "Prop 2" with links back to the threads here. It's not got everything, but I have been updating it when I have time.
As for the threads side topic, I wish more companies were like Parallax in their openess and support of their customers.
As for the main thread topic, I have one of these "scopes" in my wish list! I will have one soon(tm)!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Reading that thread makes me think that the responses were a little sharp, but in
all honestly it's playing the part of a monday morning quarterback and isn't fair.
It takes time to develop materials and human resources to make materials available.
Everyone at Parallax stays very busy with just keep up with all of us. [noparse]:)[/noparse]
There is a good deal more material provided now than in 2007. I doubt that
it had to do with the company being "closed" but more with not enough time
to get everything out. Personally, I'd rather they released the Propeller II sooner
than take an additional year to create materials before releasing it.
Ken.. Weigh in any time.. [noparse]:)[/noparse] I'm taking an educated guess based on what
I've seen since 2006..
The release of information from Parallax has been a function of available staff time. It takes years for us to properly document features that we want to share. I remember the time required to document the USB Oscilloscope (the older, SX-based version) product, for example. As more time passes, we're able to allocate more of our engineering time to these requests. The lack of release has nothing to do with being closed. You've even seen Chip here, dribbling out pieces of information in the forums. That's the best he can do given the project he has undertaken. Come spend a day with him and he'll show you how to design a Propeller.
The BASIC Stamp followed a similar path that required time to make the releases. But, we were so open with releases that our brains nearly fell out. We made mistakes that accidentally aided the creation of competitive products. We shared everything freely and various collaborators stayed at our office for weeks. I've got a list of a half-dozen examples that I'll never share on the forums, but Chip and a few close friends know exactly what I'm talking about.
Even though we had a couple of bad experiences, being "open" spurred several very good results. It helped Murat create a Mac BS2 editor from our tokenizer library, we supported Brian Forbes with his "Inside the BASIC Stamp" publication, and Dr. Tracy Allen freely posted many details on his web site. We posted the SX-Blitz programming protocol and gave the SX-Key debug protocol to whoever asked for it. None of this was under any specific license - it was simply shared long before it was fashionable. One could also consider the extensive Stamps in Class material openness. We continue to introduce many newcomers to microcontrollers in high school and college. We released the Boe-Bot chassis SolidWorks drawings immediately in 1997; the Penguin and Toddler were also released and clones were immediately created by other companies. I'll even post the QuadRover drawings, BOM and manufacturing package when I have the time. The BASIC Stamp tokenizer protocol has been on our web site for at least seven years. Our Asian distributors have been buying PBASIC interpreter chips and making their own BASIC Stamps for many years (we make $1 per; they make 10x that) and we never stopped them, still collaborating with them today and providing them source code files (not PBASIC interpreters, but nearly anything else) whenever they ask because we realize they have a far more cost-sensitive market than we have in the USA. The What's a Microcontroller"? book is published in a half-dozen languages with our copyright support, as is Robotics with the Boe-Bot. Most large companies wouldn't want to support translation efforts - by the time the idea got to legal counsel and an agreement drafted the potential translator would have been scared away from the whole project.
To be more "open" with something like the BASIC Stamp would have meant a release of source code after we released the tokenizer library, and then a total collapse of that business. And, if we did that there would be no Propeller today. The Propeller was funded by our success with the BASIC Stamp, particularly in education, robotics, and with large retailers like RadioShack. A private company has to hold back some core property to generate income.
I can't recall a PCB where the schematics were not posted.
Discussions about doing our designs in Eagle have been frequent for many years, just so we could share files. But it always comes back to the fact that we use PADS or Protel and few people have these programs.
Maybe what's been missing is that this information wasn't blatantly advertised like people expect today. I've seen basic adapter PCBs advertised as "open source". But for years we've given out professionally engineered designs. We never proclaimed any license - files were just sent out by e-mail, posted on the web, or maybe provided on a CD. All we've stated along the way were very simple terms that the recipient share the same way when possible (especially in the case of books). Lawyers would shutter at our informal approach. And never have we pursued anybody for using our material (except one blatant copyright rip-off that would have made any open-source proponent upset).
So, I am very comfortable standing up in front of a very capable crowd like we have on this forum and proclaiming that we're an open company. We are far from a closed company, and the openness exists throughout our company as a basic mode of operation. The biggest sting we get is for our Windows-centric approach.
We shall work on formalizing our open-source approach under a license, and make it very clear. We'd like to make it easier for people like Brad, Terry, Cluso99, and Bill H. to do their work with documented support, too, so they don't have to reverse-engineer anything. We're just now rounding up the horses from the pasture to have those kinds of discussions.
Sincerely,
Ken Gracey
Parallax Inc.
P.S. Oh, Paul didn't handle the situation very well in that thread. Defensive and a bit closed; not sure why.
Another edit - I don't want to sell you on our thoughts, or tell anybody how to think, but I feel totally comfortable telling you that we've been sharing for many years. Guess I'm making part of our case above.
Post Edited (Ken Gracey (Parallax)) : 12/11/2009 5:50:30 AM GMT
Chris Kraft said...
.... The parts I thought were closed were the op-codes. I know that much of the detail has been reverse engineered. But if I look at the specs for the Atmel AVR's for example, its all pretty much published in PDF's on their site.
.....
The opcodes of the CPU (the Assembly instructions) were open from the begin. And thats was is open also for AVRs and PICs and
all the other processors. And also for the propeller they are described in several PDFs.
What was not open was the Spin-bytecodes. But Spin is a compiled high level language, like C for a PIC. And Microchips C-compiler source is not open for example. The Spin-Interpreter code in the cog can be seen as a part of the Spin compiler and is not necessary to program your own Compiler. So it was possible from the begin to make your own language, compiler or what ever.
The fact that the Spin Interpreter in the ROM is encrypted, shows that it was not Parallax's Intention to open this code. But after
Hippy had cracked the encryption, Chip released also the source code of the Interpreter. And that was a very good desicion...
A better description of the Bytecode would be nice, but if you are able to program a compiler, then the Interpreter source is perhaps the best possible description.
Interesting discussion and I think it helps drive the importance of being open and allowing the magic to happen with the PropScope... But this thread is about the PropScope.
Mine should arrive today but I am not sure if my wife will let me open it before Christmas Eve
It sounds like there was only one bug being discussed currently, the voltage offset on 10x probes. I thought someone said that it might be caused by how you set the 10x setting (should it be 10 or 0.1). Can we get this confirmed?
There was also a question about the logic analyzer tab going away without the addon card - thought that was where you would connect the logic probe.
What ideas to people have for add-ons and modifications?
Andrey,
The PropScope can display streaming data. When the display is set to 50 or more ms per division, it will enter streaming mode. The fastest it will stream at is 500 samples per second.
Chris Kraft- Thanks for raising valid points and bringing fresh ideas
to these forums. I haven't seen another company as supportive of it's
customers as Parallax- and in return, look at all the projects people
have built around Parallax's products.
Something special goes on here...
Ok, back to PropScope.
I think the only outstanding questions are lnielson's above- feel free
to correct me, it's hard keeping up with the information overload on
multiple threads!
I've confirmed that I've made an error in the routine which applies the calibration constants to properly scale and offset the ADC values. This results in the offset people are seeing when switching to higher attenuation. Fix coming asap- I wish I could clone myself...
I think I've already covered the "logic analyzer" tab question. To summarize, if you want to use the LSA and/or function generator you must plugin the DAC/LSA card before starting the PropScope software.
The "manual" is now accessible through "Help/PDF Manual" in the PropScope software. Documentation of the PropScope Protocol coming asap.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I think the only outstanding questions are lnielson's above- feel free
to correct me, it's hard keeping up with the information overload on
multiple threads!
I did ask how the Propeller Tool determines the difference between the Propscope and a generic Propeller, but I think the question got lost in the noise.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Hanno said...
I think I've already covered the "logic analyzer" tab question.
But not the "10-bit LSA" question I've asked. What about "1channel DSO + 10 (14?) bit LSA" mode? I suspect that was not planned initially - but obviously this is possible.
Hi Andrey,
Yes, the expansion port is designed for all sorts of future plug in cards. #1 on my list is a wide LSA mode.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Good news, PropScope v1.03 is done. Parallax should have it soon, or click on "Help/Check for Updates" in your old PropScope to get the latest.
Here's what I fixed:
Fixes:
+Using the trigger in step mode works reliably
+Signals are accurately offset/scaled using attenuation factor and
calibration data.
+Help file updated, manual online, plugin page updated
+Log files include timestamps
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Sticking my neck out (and my nose into things), I think I see where Chris Kraft is coming from. On the old referenced thread he said:
"...- To have a tool that is open source so that, if the vendor decides they don't want to support an old platform, I can still program the chips I have around because I have the code and can always make the changes I need...."
In this thread Heater said:
"... OK, BradC has done that with BST. mpark has done that with HomeSpun. Others have written different language compilers to PASM. RossH has a C compiler to LMM, a mode of operation even Parallax had not thought of for the Prop."
Then later Chris stated:
"... I could be very wrong but I thought that much of the amazing work by BradC, mpark, etc relies, or relied, on information that was reverse engineered not on openly published specifications. ..."
I think the point Chris may be trying to make is that all the 3rd party tools are closed source, even if they are free. Ergo, if BradC, mpark et al, decide to abandon the work, or God forbid, depart from us, the tools and their users will be left stranded. OTOH, if the source to these tools were available, then people like Chris could pick up where the originator left off. I have done this myself with 8051-based tools. I was looking for a free assembler (or at least one that did not cost a fortune, or require the user to hock his first born child as part of the EULA). I found one on the internet, but it was outdated, broken, and quirky. I was unable to contact the author, but fortunately the source code was provided free (I think it was public domain). Anyway, I fixed the bugs, made some upgrades, and now have a very nice 8051+ assembler, which I can update as further enhancements are made to that chip family. I think this is what Chris is talking about. Am I correct, Chris?
Anyway, it looks like Parallax *might* be going to release the source of the PropTool (or at least as much as they legally can), so this might solve the issue.
Hanno said...
I think the only outstanding questions are lnielson's above- feel free
to correct me, it's hard keeping up with the information overload on
multiple threads!
I did ask how the Propeller Tool determines the difference between the Propscope and a generic Propeller, but I think the question got lost in the noise.
I'm going to politely ask the same question a third time as I now have one of these in my hands (Thanks Ken!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I'll tell you what I know from the background, so maybe Hanno or David will confirm. Parallax has a USB vendor ID and product ID that's in the FTDI circuit (in external EEPROM?). I'm pretty sure the FTDI circuit tells the Prop IDE version built into Hanno's software that it's talking to a PropScope.
Sorry we didn't answer this question earlier, too.
I'll tell you what I know from the background, so maybe Hanno or David will confirm. Parallax has a USB vendor ID and product ID that's in the FTDI circuit (in external EEPROM?). I'm pretty sure the FTDI circuit tells the Prop IDE version built into Hanno's software that it's talking to a PropScope.
Thanks Ken, yeah after I plugged it in to try and play with it I saw that the non-standard VID/PID stops both Linux and MacOS from seeing the device.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
BradC,
Sorry for missing your posts earlier. The PropScope has a Vendor ID of 0x13E2 and a Product ID of 0x0080. The Windows drivers are the exact same as FTDIs VCP drivers, except for the addition of the Parallax VID and the associated PIDs, so the PropScope still shows up as a virtual com port. The Propeller Tool does not try to download to the port, if it knows it is a PropScope. The Propeller Tool does allow users to overwrite this default, on a port by port basis, by pressing F5 to bring up the "Preferences" dialog, then clicking on the "Operation" tab and then "Edit Ports...", then right clinking on the PropScope's port and choosing "Include Port".
In an unrelated note, I plugged the PropScope into my laptop, which is running Xubuntu 9.10, and it did not load any drivers automatically. I haven't tried any workarounds yet, but it shouldn't be too difficult to force it to load the FTDI drivers with the PropScope.
whicker,
The LSA port on the expansion card has 5 volt tolerant input. The absolute maximum voltage is 7 VDC, with respect to Vss, regardless of Vdd. (This doesn't mean that you should apply 7 volts to it, but 5 volts is plenty safe.)
In an unrelated note, I plugged the PropScope into my laptop, which is running Xubuntu 9.10, and it did not load any drivers automatically. I haven't tried any workarounds yet, but it shouldn't be too difficult to force it to load the FTDI drivers with the PropScope.
It is pretty easy to get the ftdi_sio driver to work, but if you are using Xubuntu 9.10 (or Ubuntu 9.10) I would not bother trying. They _still_ have not fixed the broken ftdi driver in that kernel.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Comments
"I use Atmel AVR's." - OK, A quite reasonable choice for many applications.
" And no. I am not looking for Verilog or VHDL code from Parallax." - OK, not me either.
"Just enough so that someone could create an open-source tool chain without having to resort to reverse engineering bits." OK, BradC has done that with BST. mpark has done that with HomeSpun. Others have written different language compilers to PASM. RossH has a C compiler to LMM, a mode of operation even Parallax had not thought of for the Prop.
So looks to me to be just as open as any ATMEL or PIC etc.
You may want to point at the down loader protocol and disagree with me because you won't find it in a PDF (Which I think it should be). However it was asked for and it was given.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
-- Chris
I can't speak for mpark, but my work actually began when Chip released the interpreter code.
Yes, the code was released well after the Prop was on the market, and no its release did not appear to be specific to allow people to make a compiler, but none the less, it did the job. Prior to this, a couple of forum members had expended a *massive* amount of effort to reverse engineer all this stuff, and had the interpreter not been released I'd probably have looked at it a bit later (or just gone back to the Motorola and Microchip parts I'd been using for years).
I did do some reverse engineering, but it was not required. Let me explain.
In the beginning, using *only* the code released by Chip for the interpreter and booter, I had a functioning compiler and downloader. The code generated was working and there were no obvious limitations.
I wanted to put a test suite together, and I figured the best way to do this was a load (nearly 2000 now) spin files. Compile each file with Propellent (under WINE), and bstc and do a binary compare of the result. When I started to do this I found *huge* anomalies, so I started to dig. I then did some reverse engineering of the Parallax compiler to find out why my floating point lsb's were wrong, my STRING() allocations were not in the same order, some of my constants were encoded differently and a few other little quirks.
So except for one file (that I've been too lazy to chase down, and it's a single floating point value with a 1LSB error), bstc is absolutely bit for bit compatible with the output of the Parallax compiler. *BUT* none of this was required to make a working toolchain, it's simply because I'm anal.
For completeness, the file that does not compile identically came off the hydra cd. "Hydra-Sources/RB_Hydris_012.spin"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
perhaps this is the old thread you were looking for?
http://forums.parallax.com/showthread.php?p=654939
cheers
tubular
Enabling technologies, like a microprocessor, are atomic things. How open they are all comes down to knowing what the device will do, and enough of it's structure to be confident in that understanding.
We know what a Propeller will do. The few things where we don't are not closed things, just not known things. There is a difference. Over time the little nooks and crannies will be known.
Where writing code is concerned, it is now possible to boot strap ones own tools to develop for the chip, using only open tools as that bootstrap, up to and including typing in the core tools in binary, if desired. Those boot strap efforts were rewarded, encouraged, and are not going away as they are now part of the pool of open tools and understanding we all share.
That's deffo open.
The sum of this is a very nicely opened core enabling technology. There really are no Propeller secrets, but for those cases where the design is simply more brilliant than it's creators or users. We will grapple with that and get mastery, but that's not closed, just cool.
So, it's open now, period.
When the author of the tech will answer questions and encourage efforts to open it, that's as good as it ever gets folks. Given the rather ugly IP environment we live in, and the experiences many of us, including Parallax, have experienced, going slow about the release of core info is not only understandable, but warranted, particularly given the end product is an open, trusted thing, which the Propeller is.
I would think many years of hard won successes embodied in the chip are not something to be taken lightly. Put simply, some slack is warranted as well. I know many, who would not give us, the users, any where near the consideration I see given consistently. Not only do we get that consideration consistently, but we are encouraged to be who we are, are all appreciated for that, and unabashedly all derive significant value from that, Parallax included. Folks, that's also as good as it ever gets.
These things make it possible to author works on the Propeller in the same fashion that occurs on other, core enabling technology considered open, meaning for all intents and purposes, the Propeller is simply "open enough".
Finally, I think it's very important to realize the role some of us play in this. It is not important that people take advantage of the open tools, only that it remain possible for them to do so. Because of this, criticism on whether or not something is "open enough" to be considered "open", is as warranted as the initial caution Parallax showed with what is likely to become their living over the longer term; the Propeller. If it were exploited, infringed on, litigated away, the lead time for another such innovation is long and lean, potentially fatal.
Maybe given these things, we all can be excellent to one another.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 12/11/2009 3:00:54 AM GMT
Yes, originally the byte codes of the Spin virtual machine (interpreter if you like) were not published. So at that time yes, you are right, implementing a Spin compiler that compiled to those byte codes would have been a nice reverse engineering job.
OK, as far as I know description of the byte codes is still not to be found in any published document from Parallax. However, as BradC points out the actual interpreter of those byte codes that is used in the Prop has now been released.
Some would say that is even better than having the document. Cluso, for example, looked at it and created a faster interpreter from it, without having to start from scratch.
All in all, at this moment, the Prop is looking pretty open.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Of course its not so much "published" as scattered across many threads. Such openness with the forum has probably had quite a positive influence on the Prop 2 feature set.
I don't know of any other micros that have been discussed so openly during their development.
Now that's a blast. I'd forgotten just how inflamatory some of those responses from Paul were.
Just for the record, none of the available tools are "open" in the traditional sense of the word. They are all free (as in beer) though, and the interpreter source is a very open document of the spin bytecodes.
Chip has also stated previously the interpreter source for the processor under development would be available.
I just started to estimate (at my standard consulting rate) how much I've currently got invested in bst and friends, but I stopped in shock when I exceeded what I paid for my house. Software development is not cheap unless your time is free.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
As for the threads side topic, I wish more companies were like Parallax in their openess and support of their customers.
As for the main thread topic, I have one of these "scopes" in my wish list! I will have one soon(tm)!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
all honestly it's playing the part of a monday morning quarterback and isn't fair.
It takes time to develop materials and human resources to make materials available.
Everyone at Parallax stays very busy with just keep up with all of us. [noparse]:)[/noparse]
There is a good deal more material provided now than in 2007. I doubt that
it had to do with the company being "closed" but more with not enough time
to get everything out. Personally, I'd rather they released the Propeller II sooner
than take an additional year to create materials before releasing it.
Ken.. Weigh in any time.. [noparse]:)[/noparse] I'm taking an educated guess based on what
I've seen since 2006..
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
The release of information from Parallax has been a function of available staff time. It takes years for us to properly document features that we want to share. I remember the time required to document the USB Oscilloscope (the older, SX-based version) product, for example. As more time passes, we're able to allocate more of our engineering time to these requests. The lack of release has nothing to do with being closed. You've even seen Chip here, dribbling out pieces of information in the forums. That's the best he can do given the project he has undertaken. Come spend a day with him and he'll show you how to design a Propeller.
The BASIC Stamp followed a similar path that required time to make the releases. But, we were so open with releases that our brains nearly fell out. We made mistakes that accidentally aided the creation of competitive products. We shared everything freely and various collaborators stayed at our office for weeks. I've got a list of a half-dozen examples that I'll never share on the forums, but Chip and a few close friends know exactly what I'm talking about.
Even though we had a couple of bad experiences, being "open" spurred several very good results. It helped Murat create a Mac BS2 editor from our tokenizer library, we supported Brian Forbes with his "Inside the BASIC Stamp" publication, and Dr. Tracy Allen freely posted many details on his web site. We posted the SX-Blitz programming protocol and gave the SX-Key debug protocol to whoever asked for it. None of this was under any specific license - it was simply shared long before it was fashionable. One could also consider the extensive Stamps in Class material openness. We continue to introduce many newcomers to microcontrollers in high school and college. We released the Boe-Bot chassis SolidWorks drawings immediately in 1997; the Penguin and Toddler were also released and clones were immediately created by other companies. I'll even post the QuadRover drawings, BOM and manufacturing package when I have the time. The BASIC Stamp tokenizer protocol has been on our web site for at least seven years. Our Asian distributors have been buying PBASIC interpreter chips and making their own BASIC Stamps for many years (we make $1 per; they make 10x that) and we never stopped them, still collaborating with them today and providing them source code files (not PBASIC interpreters, but nearly anything else) whenever they ask because we realize they have a far more cost-sensitive market than we have in the USA. The What's a Microcontroller"? book is published in a half-dozen languages with our copyright support, as is Robotics with the Boe-Bot. Most large companies wouldn't want to support translation efforts - by the time the idea got to legal counsel and an agreement drafted the potential translator would have been scared away from the whole project.
To be more "open" with something like the BASIC Stamp would have meant a release of source code after we released the tokenizer library, and then a total collapse of that business. And, if we did that there would be no Propeller today. The Propeller was funded by our success with the BASIC Stamp, particularly in education, robotics, and with large retailers like RadioShack. A private company has to hold back some core property to generate income.
I can't recall a PCB where the schematics were not posted.
Discussions about doing our designs in Eagle have been frequent for many years, just so we could share files. But it always comes back to the fact that we use PADS or Protel and few people have these programs.
Maybe what's been missing is that this information wasn't blatantly advertised like people expect today. I've seen basic adapter PCBs advertised as "open source". But for years we've given out professionally engineered designs. We never proclaimed any license - files were just sent out by e-mail, posted on the web, or maybe provided on a CD. All we've stated along the way were very simple terms that the recipient share the same way when possible (especially in the case of books). Lawyers would shutter at our informal approach. And never have we pursued anybody for using our material (except one blatant copyright rip-off that would have made any open-source proponent upset).
So, I am very comfortable standing up in front of a very capable crowd like we have on this forum and proclaiming that we're an open company. We are far from a closed company, and the openness exists throughout our company as a basic mode of operation. The biggest sting we get is for our Windows-centric approach.
We shall work on formalizing our open-source approach under a license, and make it very clear. We'd like to make it easier for people like Brad, Terry, Cluso99, and Bill H. to do their work with documented support, too, so they don't have to reverse-engineer anything. We're just now rounding up the horses from the pasture to have those kinds of discussions.
Sincerely,
Ken Gracey
Parallax Inc.
P.S. Oh, Paul didn't handle the situation very well in that thread. Defensive and a bit closed; not sure why.
Another edit - I don't want to sell you on our thoughts, or tell anybody how to think, but I feel totally comfortable telling you that we've been sharing for many years. Guess I'm making part of our case above.
Post Edited (Ken Gracey (Parallax)) : 12/11/2009 5:50:30 AM GMT
The opcodes of the CPU (the Assembly instructions) were open from the begin. And thats was is open also for AVRs and PICs and
all the other processors. And also for the propeller they are described in several PDFs.
What was not open was the Spin-bytecodes. But Spin is a compiled high level language, like C for a PIC. And Microchips C-compiler source is not open for example. The Spin-Interpreter code in the cog can be seen as a part of the Spin compiler and is not necessary to program your own Compiler. So it was possible from the begin to make your own language, compiler or what ever.
The fact that the Spin Interpreter in the ROM is encrypted, shows that it was not Parallax's Intention to open this code. But after
Hippy had cracked the encryption, Chip released also the source code of the Interpreter. And that was a very good desicion...
A better description of the Bytecode would be nice, but if you are able to program a compiler, then the Interpreter source is perhaps the best possible description.
Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
Mine should arrive today but I am not sure if my wife will let me open it before Christmas Eve
It sounds like there was only one bug being discussed currently, the voltage offset on 10x probes. I thought someone said that it might be caused by how you set the 10x setting (should it be 10 or 0.1). Can we get this confirmed?
There was also a question about the logic analyzer tab going away without the addon card - thought that was where you would connect the logic probe.
What ideas to people have for add-ons and modifications?
Any time frame for publishing more documentation?
Any time frame for the separate forum?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
BioProp: Robotics - Powered by Bioloids and controlled by the Propeller
The PropScope can display streaming data. When the display is set to 50 or more ms per division, it will enter streaming mode. The fastest it will stream at is 500 samples per second.
-- David Carrier
Parallax Inc.
to these forums. I haven't seen another company as supportive of it's
customers as Parallax- and in return, look at all the projects people
have built around Parallax's products.
Something special goes on here...
Ok, back to PropScope.
I think the only outstanding questions are lnielson's above- feel free
to correct me, it's hard keeping up with the information overload on
multiple threads!
I've confirmed that I've made an error in the routine which applies the calibration constants to properly scale and offset the ADC values. This results in the offset people are seeing when switching to higher attenuation. Fix coming asap- I wish I could clone myself...
I think I've already covered the "logic analyzer" tab question. To summarize, if you want to use the LSA and/or function generator you must plugin the DAC/LSA card before starting the PropScope software.
The "manual" is now accessible through "Help/PDF Manual" in the PropScope software. Documentation of the PropScope Protocol coming asap.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I did ask how the Propeller Tool determines the difference between the Propscope and a generic Propeller, but I think the question got lost in the noise.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Yes, the expansion port is designed for all sorts of future plug in cards. #1 on my list is a wide LSA mode.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Here's what I fixed:
Fixes:
+Using the trigger in step mode works reliably
+Signals are accurately offset/scaled using attenuation factor and
calibration data.
+Help file updated, manual online, plugin page updated
+Log files include timestamps
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I can't find any info in documentation.
"...- To have a tool that is open source so that, if the vendor decides they don't want to support an old platform, I can still program the chips I have around because I have the code and can always make the changes I need...."
In this thread Heater said:
"... OK, BradC has done that with BST. mpark has done that with HomeSpun. Others have written different language compilers to PASM. RossH has a C compiler to LMM, a mode of operation even Parallax had not thought of for the Prop."
Then later Chris stated:
"... I could be very wrong but I thought that much of the amazing work by BradC, mpark, etc relies, or relied, on information that was reverse engineered not on openly published specifications. ..."
I think the point Chris may be trying to make is that all the 3rd party tools are closed source, even if they are free. Ergo, if BradC, mpark et al, decide to abandon the work, or God forbid, depart from us, the tools and their users will be left stranded. OTOH, if the source to these tools were available, then people like Chris could pick up where the originator left off. I have done this myself with 8051-based tools. I was looking for a free assembler (or at least one that did not cost a fortune, or require the user to hock his first born child as part of the EULA). I found one on the internet, but it was outdated, broken, and quirky. I was unable to contact the author, but fortunately the source code was provided free (I think it was public domain). Anyway, I fixed the bugs, made some upgrades, and now have a very nice 8051+ assembler, which I can update as further enhancements are made to that chip family. I think this is what Chris is talking about. Am I correct, Chris?
Anyway, it looks like Parallax *might* be going to release the source of the PropTool (or at least as much as they legally can), so this might solve the issue.
I'm going to politely ask the same question a third time as I now have one of these in my hands (Thanks Ken!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I'll tell you what I know from the background, so maybe Hanno or David will confirm. Parallax has a USB vendor ID and product ID that's in the FTDI circuit (in external EEPROM?). I'm pretty sure the FTDI circuit tells the Prop IDE version built into Hanno's software that it's talking to a PropScope.
Sorry we didn't answer this question earlier, too.
Ken Gracey
Thanks Ken, yeah after I plugged it in to try and play with it I saw that the non-standard VID/PID stops both Linux and MacOS from seeing the device.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
forums.parallax.com/forums/default.aspx?f=40
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Sorry for missing your posts earlier. The PropScope has a Vendor ID of 0x13E2 and a Product ID of 0x0080. The Windows drivers are the exact same as FTDIs VCP drivers, except for the addition of the Parallax VID and the associated PIDs, so the PropScope still shows up as a virtual com port. The Propeller Tool does not try to download to the port, if it knows it is a PropScope. The Propeller Tool does allow users to overwrite this default, on a port by port basis, by pressing F5 to bring up the "Preferences" dialog, then clicking on the "Operation" tab and then "Edit Ports...", then right clinking on the PropScope's port and choosing "Include Port".
In an unrelated note, I plugged the PropScope into my laptop, which is running Xubuntu 9.10, and it did not load any drivers automatically. I haven't tried any workarounds yet, but it shouldn't be too difficult to force it to load the FTDI drivers with the PropScope.
whicker,
The LSA port on the expansion card has 5 volt tolerant input. The absolute maximum voltage is 7 VDC, with respect to Vss, regardless of Vdd. (This doesn't mean that you should apply 7 volts to it, but 5 volts is plenty safe.)
-- David Carrier
It is pretty easy to get the ftdi_sio driver to work, but if you are using Xubuntu 9.10 (or Ubuntu 9.10) I would not bother trying. They _still_ have not fixed the broken ftdi driver in that kernel.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.