Chip chose to incorporate elements of various languages into Spin when he felt it would directly benefit the development of the Propeller. It was always viewed as what would help rather than conforming to a pre-conceived notion of doing things. Some elements of object oriented programming were incorporated, but only those which directly aided the development. Unfortunately people rely on what they already know to describe something new, so terms will be used that aren't really accurate. The approach used to develop Spin will always irritate purists who like things in neat packages, but from the development aspect it really helps to be unencumbered by the baggage of the past. (How many years did Microsoft have to work around thier 640K memory limitation?)
That's no so much a reaction to SPIN as to the repeated writeups in the trade press describing it as "object oriented," when it's not. (I do note in that post that the Parallax docs don't use the term.)
However, I do tend to get too fired up about these things, and that was (in hindsight) way harsh. I've taken it down. I'll be reposting soon with a more balanced perspective.
This language discussion is good for all of us in that a more diverse set of tools will eventually come from it. I'm looking at the assembler at some point because I prefer a pure OSS development environment. No biggie for me, just a preference in that I want my skills tied to software that I've no worries about from a licensing point of view.
Having said that, the combination of spin and assembly is excellent. I've had my prop for about a week now. Have had a few hours to tinker with it. IMHO, the hybrid approach embodied in the language really makes it shine. A great example is the graphics functionality. With little learning curve, I was quickly able to back trace one of the included demos to the assembly code that actually builds the screen! (very cool)
With very little learning, it's completely obvious how things are put together. I'm not completely happy with how things end up in memory, but it's a non issue for me at this time. (Like to have more control over data areas and absolute locations of things)
Objects can be a mix of both and that's really powerful when dealing with smaller scale computing. That's really what the prop is all about at this time.
My initial reaction to SPIN was not too sweet. I find the syntax full of cryptic operators and shortcuts. However, this really is more about the author than the language itself. Clearer code can be written and in most instances would not affect performance to any significant degree from what I can tell at this early stage. No biggie all things considered. Once I get the operators down, reading the code and understanding what is happening will get a lot easier. It's nice to know that's really the only major obstacle where I'm concerned.
Assembly took a bit to really grok. (No registers and indexing, self modifying code everywhere sheesh!) The interaction between the COG's and HUB RAM appear less complex, but problematic if one is planning on using multiple COG's to accomplish a task. COGS could be bigger and I'd have no complaints! Again, this is where SPIN really makes a lot of things easier because it's like a wrapper for assembly that frees the developer from a lot of cruft that would otherwise get in the way of actually coding the target of interest.
So, I'm a happy prop owner right now. Love to see this evolve as the prop platform clearly will. Just thought I would toss my first impressions in.
I'm having a lot of fun and that's not happened for me in computing for a good long time!
Chip Gracey (Parallax) said...
Here is some PC-side code that talks to the Propeller. It is a Delphi (Pascal) unit. It doesn't operate stand-alone, but wrapped in an application, it takes over the whole task of locating a Propeller on any COM port and then loading it up. This code packs 3 bits into outgoing bytes, for transmit efficiency.
I am trying to integrate the code upload into a tool I'm writing, and from your Delphi code, I was wondering about the following part in TalkToHardware:
// send count and longs
TLong(LongCount);
for i := 0 to LongCount-1 do TLong(PIntegerArray(@MemoryBuffer)[noparse][[/noparse] i]);
TComm;
// update progress form
ProgressForm.StatusLabel.Caption := 'Verifying RAM';
ProgressForm.StatusLabel.Repaint;
// receive ram checksum pass/fail
if RBit(True, 2500) = 1 then CommError('RAM checksum error on');
More specifically, the timeout for receiving a reply after uploading the code is set to 2.5 seconds. Now, for EEPROM files (size 32768 bytes), the time it takes to send the whole data at 115200 bps with 11 bytes per long is 7.82 seconds. And indeed, measuring the time in my application, I get a total transmit time between 5.6 and 5.9 seconds (which is a bit odd, considering the fixed bitrate).
Is it possible that you rely on some Windows-specific parameters like OS buffer sizes with the timeout? I have been trying to get the Propeller Tool to work on Linux using VMware and a Win2k guest, and have had timeouts 8 times out of 10. Could this be the cause?
Is it possible that you rely on some Windows-specific parameters like OS buffer sizes with the timeout? I have been trying to get the Propeller Tool to work on Linux using VMware and a Win2k guest, and have had timeouts 8 times out of 10. Could this be the cause?
Remy,
Gee, I had to look at the code for a while to figure out how come 2.5 seconds actually works. Here's why: The TX and RX buffer sizes were set to 256 bytes, so any time measurements were taken within the last 256 bytes transmitted.
If you have·a transmit buffer big enough for the whole download, you had better set your timeouts to accommodate the whole data set. Using a timeout of 8 seconds would do it, since it takes 11 bytes to transmit each long, of which there might be 8,192. The good thing about having shorter buffer sizes, like 256, is that you can error out faster if something's wrong. That's why it was done that way.
Chip Gracey (Parallax) said...
Using a timeout of 8 seconds would do it, since it takes 11 bytes to transmit each long, of which there might be 8,192. The good thing about having shorter buffer sizes, like 256, is that you can error out faster if something's wrong. That's why it was done that way.
8 seconds is what I used. It's still surprising that the actual transfers take only about 6 seconds.
As usual I'm behind the Learning curve again. While I am slowly learning Delphi, Is the any reading somewhere that could help me·better understand Checksums?
I'm already looking at Wicopedia so I was hopeing for a "Checksums for Dummies" Somewhere!
I'm "porting" people (college freshmen/sophomores mostly) from pBasic to Spin and what I've been doing is telling them "It works a lot like Basic, except you define your own functions like with C, and you get these nifty looking arrows to decide when an if/then block ends". That plus the bs2 library generally gets the point across in three-four days.
ord() is a type conversion "function" that takes a non-integer argument and returns its equivalent as an integer. In this case, i=10 is a Boolean expression and ord(i=10) returns 0 for false and 1 for true. The overall expression "-ord(i=10)" returns -1 if i is 10 or 0 if i is not 10.
Does this mean you're writing a VB app' that'll download a binary to the Propeller? I suer hope so, I'd love to have a copy when it's done :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
I don't have a vb version, but here is a C# version I found on the forum but I can't fine the thread, so here is the attachment, I could probably convert it to vb.net if anyone is interested.
Yes,simonl, I'm porting the code to VB. I'm able to check the version of the chip(1) at the moment. I've also tried to download a sample bin-file to the prop. (or should there be an EEPROM-file?), but the propeller just resets before I can get the checksum-bit, but I'm not giving up yet!
BTW, I'll post it here as soon I get it working.
I've got a little further now, I'm getting the checksum bit, but it's allways 1 (failure). How is the checksum calculated on the propeller (it's easier to debug when you've got some idea of what's gone wrong)
Hello again, I've made some progress, but I still don't get the verify bit (if i get it it's 1).
But here comes a demo of the program (VB source).
Click Load prop and select a file. If you get the Unknown error it's because the verify bit isn't 0. If you get Hardware Lost Error It's because that byte is never sent. (This is what I don't get working!)
Anyway the Identify works on my demoboard (but not my 'real serial' wired·board (not USB))
WOW - can't wait to try this (Unfortunately I can't download it through the work firewall, but I'll be sure to get it this evening). THANKS
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Hi Filip,
Just unzipped VBLoader and hit the identify button, but got the following error:
Run-time error '339':
Component 'MSCOMM32.OCX' or one of its dependencies not correctly registered: a file is missing or invalid
I'm using WinXP SP2; I have the VB6 run-time files installed, but I guess that means I'm missing the OCX? Would you be so kind as to·supply an installer version of VBLoader?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
I'm sorry, but I don't have the source here and I couldn't even download the file I posted(strange).
But here is the MSCOMM32.OCX-file, it should be enough to put it·in the same directory as the program, but if that doesn't work, search microsoft.com for Microsoft Comm Control or MSCOMM(32) to find an installer to the file.
Once again the work firewall blocks me, so I'll d/load it this evening.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Just for info: I'm using WinXP Pro SP2, and running the setup.exe required me to restart - as it needed to change some system files. After the restart, I re-ran setup.exe, and it said several of my files were newer - so I chose to keep them (!) - and soon after that the setup completed. Running PropLoader I was immediately able to ID the prop, download to RAM, and then download to EEPROM
This is just the utility several forum members have been crying out for, so WELL DONE, and THANK YOU again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Been using this for a while now - what a GREAT utility. MANY MANY THANKS.
One question: are there any command-line 'switches/parameters'? I'd like to be able to call PropLoader with a filename and directive to load to RAM or EEPROM, if that's possible.
Thanks again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
WHOA! You're an absolute star Filip Thank you very much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Lovely tool. I'm definitively gonna find some use for this. [noparse]:)[/noparse]
In GUI mode I was a bit confused by the "Load EEPROM" checker option. To me it would be more natural to call it something like "Save/Flash/Write EEPROM".
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 11/1/2006 7:11:40 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
This language discussion is good for all of us in that a more diverse set of tools will eventually come from it. I'm looking at the assembler at some point because I prefer a pure OSS development environment. No biggie for me, just a preference in that I want my skills tied to software that I've no worries about from a licensing point of view.
Having said that, the combination of spin and assembly is excellent. I've had my prop for about a week now. Have had a few hours to tinker with it. IMHO, the hybrid approach embodied in the language really makes it shine. A great example is the graphics functionality. With little learning curve, I was quickly able to back trace one of the included demos to the assembly code that actually builds the screen! (very cool)
With very little learning, it's completely obvious how things are put together. I'm not completely happy with how things end up in memory, but it's a non issue for me at this time. (Like to have more control over data areas and absolute locations of things)
Objects can be a mix of both and that's really powerful when dealing with smaller scale computing. That's really what the prop is all about at this time.
My initial reaction to SPIN was not too sweet. I find the syntax full of cryptic operators and shortcuts. However, this really is more about the author than the language itself. Clearer code can be written and in most instances would not affect performance to any significant degree from what I can tell at this early stage. No biggie all things considered. Once I get the operators down, reading the code and understanding what is happening will get a lot easier. It's nice to know that's really the only major obstacle where I'm concerned.
Assembly took a bit to really grok. (No registers and indexing, self modifying code everywhere sheesh!) The interaction between the COG's and HUB RAM appear less complex, but problematic if one is planning on using multiple COG's to accomplish a task. COGS could be bigger and I'd have no complaints! Again, this is where SPIN really makes a lot of things easier because it's like a wrapper for assembly that frees the developer from a lot of cruft that would otherwise get in the way of actually coding the target of interest.
So, I'm a happy prop owner right now. Love to see this evolve as the prop platform clearly will. Just thought I would toss my first impressions in.
I'm having a lot of fun and that's not happened for me in computing for a good long time!
I am trying to integrate the code upload into a tool I'm writing, and from your Delphi code, I was wondering about the following part in TalkToHardware:
// send count and longs TLong(LongCount); for i := 0 to LongCount-1 do TLong(PIntegerArray(@MemoryBuffer)[noparse][[/noparse] i]); TComm; // update progress form ProgressForm.StatusLabel.Caption := 'Verifying RAM'; ProgressForm.StatusLabel.Repaint; // receive ram checksum pass/fail if RBit(True, 2500) = 1 then CommError('RAM checksum error on');More specifically, the timeout for receiving a reply after uploading the code is set to 2.5 seconds. Now, for EEPROM files (size 32768 bytes), the time it takes to send the whole data at 115200 bps with 11 bytes per long is 7.82 seconds. And indeed, measuring the time in my application, I get a total transmit time between 5.6 and 5.9 seconds (which is a bit odd, considering the fixed bitrate).
Is it possible that you rely on some Windows-specific parameters like OS buffer sizes with the timeout? I have been trying to get the Propeller Tool to work on Linux using VMware and a Win2k guest, and have had timeouts 8 times out of 10. Could this be the cause?
Gee, I had to look at the code for a while to figure out how come 2.5 seconds actually works. Here's why: The TX and RX buffer sizes were set to 256 bytes, so any time measurements were taken within the last 256 bytes transmitted.
If you have·a transmit buffer big enough for the whole download, you had better set your timeouts to accommodate the whole data set. Using a timeout of 8 seconds would do it, since it takes 11 bytes to transmit each long, of which there might be 8,192. The good thing about having shorter buffer sizes, like 256, is that you can error out faster if something's wrong. That's why it was done that way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
8 seconds is what I used. It's still surprising that the actual transfers take only about 6 seconds.
Thanks for the explanation!
-- Remy
Thank you
As usual I'm behind the Learning curve again. While I am slowly learning Delphi, Is the any reading somewhere that could help me·better understand Checksums?
I'm already looking at Wicopedia so I was hopeing for a "Checksums for Dummies" Somewhere!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://forums.parallax.com/showthread.php?p=650217
meow, i have my own topic now? (sorta)
Filip
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com
Does this mean you're writing a VB app' that'll download a binary to the Propeller? I suer hope so, I'd love to have a copy when it's done :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
BTW, I'll post it here as soon I get it working.
I've got a little further now, I'm getting the checksum bit, but it's allways 1 (failure). How is the checksum calculated on the propeller (it's easier to debug when you've got some idea of what's gone wrong)
Filip
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com
Post Edited (Filip S) : 8/6/2007 8:35:55 AM GMT
But here comes a demo of the program (VB source).
Click Load prop and select a file. If you get the Unknown error it's because the verify bit isn't 0. If you get Hardware Lost Error It's because that byte is never sent. (This is what I don't get working!)
Anyway the Identify works on my demoboard (but not my 'real serial' wired·board (not USB))
//Filip
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com
Here it comes, fully functional to a demoboard (strange, but it doesn't work on a 'real' serial port yet).
The file blinker.spin is a test-file that blinks the LED's on the demoboard I used to try it out.
//Filip
EDIT: I forgot to remove some debug-code which is now fixed!
EDIT: Now it's working even with the 'real' serial ports! (sorry for all the edits!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com
Post Edited (Filip S) : 9/2/2007 6:17:59 PM GMT
WOW - can't wait to try this (Unfortunately I can't download it through the work firewall, but I'll be sure to get it this evening). THANKS
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Just unzipped VBLoader and hit the identify button, but got the following error:
I'm using WinXP SP2; I have the VB6 run-time files installed, but I guess that means I'm missing the OCX? Would you be so kind as to·supply an installer version of VBLoader?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
But here is the MSCOMM32.OCX-file, it should be enough to put it·in the same directory as the program, but if that doesn't work, search microsoft.com for Microsoft Comm Control or MSCOMM(32) to find an installer to the file.
//Filip
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com
Plase it to:
C:\windows\system32\
And it works fine!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sapieha
Once again the work firewall blocks me, so I'll d/load it this evening.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Download the three files to a folder and run setup.exe
//Filip
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com
WOW! That works excellently - many, many thanks
Just for info: I'm using WinXP Pro SP2, and running the setup.exe required me to restart - as it needed to change some system files. After the restart, I re-ran setup.exe, and it said several of my files were newer - so I chose to keep them (!) - and soon after that the setup completed. Running PropLoader I was immediately able to ID the prop, download to RAM, and then download to EEPROM
This is just the utility several forum members have been crying out for, so WELL DONE, and THANK YOU again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Been using this for a while now - what a GREAT utility. MANY MANY THANKS.
One question: are there any command-line 'switches/parameters'? I'd like to be able to call PropLoader with a filename and directive to load to RAM or EEPROM, if that's possible.
Thanks again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
The interface is (add a - or a / in front of the syntax):
? Show command-line parameters
A Promts for file and mode (like the old version, also if no command-line is provided)
U'file' Prompts for mode only (looks like the old version, but you're not allowed to change the file)
R'file' Load file to RAM and run it.
E'file' Load file to EEPROM and run it.
Replace file (not the ':s) with the full path to the file.
PS. You don't need to re-install it, just replace the executable provided here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
In GUI mode I was a bit confused by the "Load EEPROM" checker option. To me it would be more natural to call it something like "Save/Flash/Write EEPROM".
Here is a version of the .exe which says Save to EEPROM instead of Load EEPROM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com
I'm not so hot with java but looking at the source it seems to want something like:
.clkmode "xtal1"
but I just get the error:
Line 2:2: Unknown directive .clkmode
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.