I seemed to have touched a little bit of a nerve so I won't quote everyone but respond as a whole, and maybe that's the spark this project needs.
First, I'm pleasantly surprised that Chip and Ken replied and I understand that you may not have the staff to do what should have been done over the past 7 years as a cumulative project. I think you are overlooking your biggest resource though and that is that you have a lot of die hard supporters on this forum. Again, I don't know anything about the staff situation, but if you tasked someone to put serious time into heading up this effort, a lot of people would be willing to pitch in including myself as I indicated in my other thread. I am a technician, not a tech writer or organizational person, but I would like to pay forward what some of the very helpful forum members have taken their time to help me along the way with and I'm willing to work for free for you as long as I feel you have the same basic end goal as I do for this and have a vested interest in getting this done, as opposed to placation or only a slight interest. I believe many forum members feel this same way as I do, but I say this explicitly as I want to set proper expectations.
I know some of the things I listed are documented, that doesn't meant I didn't look for them or read them. I have probably read the manual more then most people on this forum because I have nothing else, this is my first and only uC and I can't rely on past experiences with previous uC's like some of the other forum members. I came to Parallax because I saw their product in Radio Shack marketed towards learners. I actually thought I was Parallax's target audience (new to uC's, new to programming, new to electronics) but I may be wrong about that and would like to know if I was mistaken in that. I take full responsibility for learning on my own (Cluso I'm not expecting too much and you've misunderstood me if you feel that) and do not think it is Parallax's responsibility, although I do think it is their responsibility to provide some of the basic tools such as what I listed above to help me help myself. I can teach myself given a decent set of tools and to be honest I don't want to have to rely on others, although sometimes this is inevitable. Thanks to MagIO2, I learned PASM in a month or two (with literally 0 prior ASM experience), this by no means is me saying I'm smart, but I think it shows that given the right tools, an average motivated person can learn things. I would have still been trying to figure out PAR without the help of MagIO2 and a few other forum members, but because I was able to build a good foundation before referring to the manual, the manual was reasonably useful and I actually think PASM is a little easier then SPIN. The risc/cisc thing helped me with knowing why there were not MUL and DIV commands and without 1 response from Kye posting a way that I could call the multiply and divide routines, I would really be hosed with PASM. Him posting the code from the SPIN interpreter for multiply and divide is the type of code examples I would like to see Parallax provide. I have it set up so that I can call it and return a value, it could be inserted into anyone's PASM code with very little interruption else wise.
I will help with code examples that should be in the manual (although there are many many better programmers on here compared to me), not just the OBEX which is kind of like the wild wild west, but in the manual. This is why the sanctioned oversight from Parallax is necessary. You know your product best and there are people here willing to do some of the leg work for you to help others in the future. I really don't think you could ask for more from your users, give us 1 good resource from Parallax, task them with this for the rest of 2012 as their primary task and I bet none of this is even an issue come 2013. The same with the prop tool/IDE ... I'm very hesitant to jump to the GCC and would like the small improvements done on the prop tool that I suggested, you can even make them so that they can be turned on or off which makes it a win win for everyone. I tried looking at the prop tools source code, but I don't know anything about Python unfortunately.
I'm very hesitant to jump to the GCC and would like the small improvements done on the prop tool that I suggested, you can even make them so that they can be turned on or off which makes it a win win for everyone. I tried looking at the prop tools source code, but I don't know anything about Python unfortunately.
So what say you? Are you in?
First off,
Demanding the Propeller tool to be rewritten is asking a bit too much.
It is what it is - and it works well at what it does.
I just spend more time dealing with structural changes cause by indentation than I want to.
But that's a personal thing.
GCC is proving itself to be stable and useful.
I'm rewriting most of my earlier SPIN experiments to see how well that goes.
If it continues to please me the way it has so far I'll keep it as my main tool.
As for the "Are you in?" challenge, I'm way ahead of you.
And I suspect others are as well.
I wanted a QuickStart Manual for the QuickStart board hanging on the shelf at Radio Shack
(along side the DOZEN or so there for the Ardunio).
So I started writing my own.
I don't really expect it to be a commercial release, but who knows? Stranger things have happened!
Like the Forrest Mimm books (and in that same format), lots of examples and incremental development.
It's just a collection of experiments that I did to get going with the Propeller.
Scope -
First time user, or first time Propeller user...
Little or no programming experience needed, but experience always helps
things go faster and smoother.
NO extra hardware needed - just usi whats on-board.
So, no wiring, no soldering, nothing else to buy.
I'm 45 pages into now - but hung up on a few things that I don't yet know well, but feel like it should there to
complete the scope of the book.
Those things would be -
Bits, bytes and words - how to dig data from longs (doing it, but not happy with my examples)
Arrays
???
My table of contents - so far...
Propeller QuickStart Guide
Getting Started:
Installing software!
Editor screen:
A special note about indentation…
Top Object
Propeller Serial Terminal:
Projects:
Blinky1.spin Blinks an LED
Blinky2.spin Does it better?
Chase1.spin Chase light string
Cylon.spin Robotic cyborg eye display
Heartbeat.spin Pulse display
Tick.spin Accurate Timing Loops
Throb.spin Pulse Width Modulation
Tpad.spin Scan the touch pads
PWM.SPIN
Accurate Timing
Going Parallel
APPENDEX
Running the QuickStart board on battery power
Popular Propeller Expansion circuits
Propeller LED and Switch Interface
Propeller Composite Video (TV Out)
Propeller VGA Video
Propeller Audio Out (Stereo)
Propeller High Impedance Microphone
Propeller Secure Data Card Interface (S.P.I)
QuickStart board schematics
Web Addresses (LINKS)
Downloading Propeller Tool and related software
OBEX
Forum
Just to clarify, I'm not demanding anything. I have a business relationship with Parallax in that I buy their stuff, I don't have to buy their stuff but I choose to. I can't demand anything from them, I can only suggest and my suggestion is only weighted as heavily as a single money spending customer, this I am fully aware of.
At this point I've learned enough the hard way to where I don't struggle nearly as much as I did, although I still need help from the forum and am not experienced enough to be a very good teacher ... I'm interested in saving others from that struggle, who enter into the Propeller from a similar background as I did, so my motivation is more philanthropic than anything else.
turbo, it kinda looked like you were demanding by using bold font with a text size of +2, but maybe we all misinterpretted your rant. BTW, I don't think the Spin tool was written in python, unless delphi is some version of python. Also, the Spin compiler itself was written in x86 assembly. The Spin compiler has been rewritten in C, and the source is available online somewhere. I also think I read that SIDE will handle Spin files in the future. This should open up the door for enhancements to the compiler and the IDE.
Imagine it's 1980 and you have on your desk a Motorola 6809 eight bit microprocessor chip. No documentation except the hardware technical reference and the instruction set description.
No assembler language and no high level language support.
Now your task is to build a board in which this chip can run. Plus you have to program some software environment, using HEX codes, that makes it useful.
That is the Prop chip, except Parallax has done a great job providing a dead easy programming language for it and a dead easy IDE in which to write that code.
I don't know what there is to complain about.
I had to laugh at Heater's remark because that was exactly my intro to the 68000. I'd designed a VME board for the Transputer, and now I had to test it with a 68000 master. Only I had no OS, no compiler, and no assembler. I ended up borrowing some time on a NeXT machine at a near-by university.
Parallax has indeed provided us with much more than that. Still, I love the idea of a collection of coding examples of intermediate and advanced topics...along with helpful comments. I think Graham Stabler provided the perfect example of proper commenting here.
I want to share a short story about my own experiences, unfortunately the story does expose a couple of crucial mistakes I made.
To get the mistakes out first: a) I chose a chip that had really bad documentation and closed development tools. b) I bought 500 of them at ~$5.10 each
If you go to www.dainst.com you will see a datalogging device I designed. I only made 2 of these, though the protos worked excellent at what I designed them to do.
I came across the Hitachi H8/3664 chip in some manner and decided I would use it as the center of my project. Mind you this was after doing much of the ground work with a BASIC stamp, but the $29 cost for a BASIC stamp was way too much for this product.
I wrote all of the firmware for the acquisition unit in C and had a program that ran on the PC, written in C++ using the Qt library. All of this worked very well and looked great. The primary target was the Sharp Zaurus PDA, but I could never get my program to run on it without core dumping. Further compounding the problem was debugging with the device.
Ultimately I had missed the target price (I aimed too low), my PDA uplink wasn't working, and the acquisition unit had no memory of it's own except on-chip flash.
I wanted to be able to execute field upgrades of the unit or use the flash for storing data, which turned out to be a HUGE freaking mess. Hitachi didn't put a proper flash controller on the chip, so the mCU had to be the flash controller. The process of writing to the flash wasn't well documented, there was no example code, and the flow charts omitted crucial elements that were necessary to make it work. In short, I wasn't prepared to write the necessary code to burn to flash, and they didn't provide a library or proper documentation to do it. But they didn't really care because 6 months later they had another part number and in a year that part was EOL and they didn't have to support it. Their attitude is to shovel Smile out to the customer and let them toy with it, but only to find out they need to buy the next best chip, then the next best chip, then the next best chip, etc.
If I was to take up this project again (which may happen), I would certainly target the whole kit and kaboodle at the Propeller. It would be almost trivial to reimplement it with the Propeller and have a load more features than I could originally implement.
For instance, I could have multi-GB SD card support for log data, I could have dashboard visualization with an LCD monitor, I could have more channels of timer data, and I could implement the output triggers I wanted to. One platform could be repurposed into several different products, from datalogging to traction control.
I still stand by my original statement, the Propeller is a great chip because it doesn't have a 300 page datasheet full of obtuse and erroneous information, it has a long term commitment from the manufacturer, the lifecycle is infinite in comparison to other chips, and the chip is very accessible with the tools and documentation provided. Furthermore, the community makes it very easy to ask questions and find answers. There isn't a lot of useless replies and banter to serious questions.
My case in point, search google for "executing scripts on fat linux" -- you will look through many replies that have no practical answer to the original problem. FWIW, you have to mount the filesystem with -o dmask=0222,fmask=0222 and then you can execute scripts and programs from the VFAT filesystem. I ran into this problem trying to build PropGCC on my phone.
BTW, does anyone need 500 Hitachi H8/3664 64QFP chips still in the vacuum pack, I'll discount them to see them go to a good use!
That wasn't my intent, I hope I've clarified. It was a rant, but meant to be producing and not insulting. I still think that if Parallax can give us a single resource as suggested earlier, the forum will do the rest. The simple IDE is the GCC?
turbo, it kinda looked like you were demanding by using bold font with a text size of +2, but maybe we all misinterpretted your rant. BTW, I don't think the Spin tool was written in python, unless delphi is some version of python. Also, the Spin compiler itself was written in x86 assembly. The Spin compiler has been rewritten in C, and the source is available online somewhere. I also think I read that SIDE will handle Spin files in the future. This should open up the door for enhancements to the compiler and the IDE.
I wasn't alive then and in reference to this particular instance I am happy about that. I wouldn't have been able to jump into using that without years and years of schooling and I wouldn't have had any interest in this as a hobby. I will give you that I have nothing to compare to, so I don't know how "bad" it could be, but I don't think that negates the desires for improvement expressed in this thread. There is obviously a lot of room for improvement, as stated by many people in this thread. Not everyone has or will ever have the experience and expertise that you have. I may have expectations that are too high, I'd like to hear Parallax's response to one of my earlier posts about if my expectations are false.
Imagine it's 1980 and you have on your desk a Motorola 6809 eight bit microprocessor chip. No documentation except the hardware technical reference and the instruction set description.
No assembler language and no high level language support.
Now your task is to build a board in which this chip can run. Plus you have to program some software environment, using HEX codes, that makes it useful.
That is the Prop chip, except Parallax has done a great job providing a dead easy programming language for it and a dead easy IDE in which to write that code.
I don't know what there is to complain about.
Imagine it's 1980 and you have on your desk a Motorola 6809 eight bit microprocessor chip. No documentation except the hardware technical reference and the instruction set description.
No assembler language and no high level language support.
Now your task is to build a board in which this chip can run. Plus you have to program some software environment, using HEX codes, that makes it useful.
That is the Prop chip, except Parallax has done a great job providing a dead easy programming language for it and a dead easy IDE in which to write that code.
I don't know what there is to complain about.
Been there, done that ...that was where I was in 1976 at the release of the Motorola D1 (6800) Evaluation board. I wrote a cross-assembler on a Singer/ICL SYstem Ten minicomputer. I owned my own System Ten (20 feet long) in 1977.
Hi Heater
I was in same place in 1976-77 but with one 8080 + its support iC and 2x2114 1024x4Bit RAMs and some switches and only instruction list + very simple SCH that showed what pins do what.
Imagine it's 1980 and you have on your desk a Motorola 6809 eight bit microprocessor chip. No documentation except the hardware technical reference and the instruction set description.
No assembler language and no high level language support.
Now your task is to build a board in which this chip can run. Plus you have to program some software environment, using HEX codes, that makes it useful.
That is the Prop chip, except Parallax has done a great job providing a dead easy programming language for it and a dead easy IDE in which to write that code.
I don't know what there is to complain about.
Right now, the synthesis guy is finishing the physical design of the main logic block, with current focus on the power grid. I'm just wrapping up testing of every instruction and functional block on the FPGA. If I find a bug and fix it, or make an enhancement, it just goes into the synthesis guy's flow without any significant disruption to his work. Today I am working on finishing the register remapping tests, then I must verify that the SETXFR-related block moves data correctly between pins and the CLUT/quadlongs. After that, I want to retest all the video shifter modes to make sure nothing got broken towards the end. Everything else that has to do with the main logic block is known to be working soundly. I've found and fixed a few bugs over the last few weeks, and also made a few minor tweaks. The window will be closing soon, though, as the synthesis work finishes. I'm maybe two days away from having my stuff done, and he's probably two weeks away. Meanwhile, Beau is making sure the padframe (with all the pins and memories) properly accommodates the logic block. There are 5,692 connections between the two, including the power taps. 3,752 of those are signal connections.
Good progress.
Are the timers in the Synthesis/FPGA, or in the padframe ?
Did the ability to capture an external edge, and/or clock from an external edge make it into the mix ?
I hope the feller who started this thread doesn't sound like Andy Rooney. I liked Andy, by the way.
Of course, most of us would like perfect documentation. And be able to just dive right in and write code without rtfm very much. But for someone/many to write what's been requested, well, that takes a very good writer. And mucho time.
For my money, and given Parallax's resources, I think they're doing an exemplary job. Documentation and support can never be all things to all people. That's just not possible for any company, and it would be wrong for Parallax to commit inordinate time and capital to such an impossible objective. In any business, there has to be some balance; and, for a small company, the name of balance is "triage." It's an imperfect world, and that being the reality here, I think the forum does a pretty good job of catching anyone who falls through the "official" cracks. Given such an array of safety nets under safety nets under safety nets (it's safety nets all the way down, guys), there hardly seems like much to complain about.
Yes, I'm sure everyone's listening here. We need to make better documentation. This is principally my fault, since I am the one who should have produced more bottom-level docs. I really wanted to make a short Spin manual, since there's actually not a whole lot anyone needs to know about it, but I never got to it because of other projects.
There is no reason for an apology here. I have found NO limitations using the available resources from Parallax, the forum and elsewhere. As long as this chip has been around, as much money, pleasure (hobbiest and pro), and education derived from its use, there should be much less griping than this thread. The only thing harder than technical training on _______ is actually documenting _______ and providing examples that are easily understood. With a few notable exceptions (Da Silva's and potatohead's tutorials, the kuroneko's, phipi's among them... the tool writers and object posters, jonnymac and the nuts and volts column) there does seemto be more sinks out there than sources. It would be nice to see more things being contributed, explained, etc. If you have gotten much from using this device, consider a little "pay it forward" for the noobs.
But the matrix is far into the future. No one can jack you into the net and pour "expert prop programmer" into your head. Even with whatever one would consider perfect documentation, there are things that you will only get your head around by doing and maybe letting out the magic grey mist on occasion. As Nike says, just do it. Chip, thanks for a great product, those i have learned from, thanks as well.
The ideas here are great...a community-based approach is perfect for supplementing the available information with useful code samples and structured information.
A great example of how this has been done can be found over at the Arduino pages--their "Playground" website ( http://arduino.cc/playground/ ) is a terrific source for getting code and good documentation, and their library pages are quite good (see http://arduino.cc/en/Reference/Libraries ). The Parallax obex is nice, but very limited as an information tool. I look forward to seeing something like a Parallax Playground that focuses on gcc C/C++ at some point...there's huge potential in that--and the beta appears to have fixed a LOT of issues - every demo I "make" works perfectly on a PPDB.
Personally, I wish there were more C++ examples...once you try OOP with classes, you won't go back. I'll work on contributing if we have the right place to put our stuff...forums clearly aren't the answer for that kind information presentation.
My programming experience seems to be the exact opposite of many around here. My first peek into programming was with MS BASIC around 14 years ago. Maybe I'm just a slow learner, or my brain is incompatible with BASIC, but I couldn't wrap my head around it. I then purchased C for Dummies, but felt that programming on the PC left too much magic going on in the background, and therefore I didn't get a feel for why so few lines of code were able to accomplish so many things. I wanted to have a better understanding, but then again, maybe I wasn't ready.
Then about 5 years ago or so, I found "What is a microcontroller?" on the shelf at a RadioShack. Having been interested in the nitty gritty of electronics, left me wondering "What is a microcontroller indeed?". So I purchased it and got started with the projects in the book, and while I was able to follow along, I still ran into the issue I had with BASIC all those years back. The abstraction between code and hardware left me feeling that I was missing out some very fundamental understanding. What did I do? I purchased an SX and started programming in assembly. It was tedious, but I felt like I was finally starting to get somewhere! I was able to finally get a small grip on the fundamentals of processor architecture, and for once, my understanding of programming had some meaning. The Propeller had already been released by then, but I kept away as Parallax themselves stated it was targeted towards more advanced users. I wish they hadn't, because when I finally decided to give it a shot, I found it to be perfectly compatible with the way I wanted to learn how to program. Simply put, SPIN made sense. The Fundamentals book got me started, and hooked. Sure, there was a lot that didn't get covered, especially since it was targeted at learning how to program with SPIN on the prop, and not general programming techniques, but I wasn't afraid to try figuring out concepts that were new to me. I was also excited that if I wanted, I could go low level and program in PASM in conjunction with SPIN. That's not to say I'm a master, or even intermediate in either, but it gave me a grip in coding I never had before. Everyone knows mastery of ANY art takes a lot of time, dedication and interest. I wouldn't expect anyone to pick up a guitar for the first time in their life and begin shredding right off the bat. No one would be upset at Fender or Gibson because of it, that would obviously be absurd.
I personally find there to be an EXTRAORDINARY amount of informational resources available for the prop. Granted, they're not in one specific location (this holds true for just about EVERYTHING), but they usually only require the most minute amount of searching. Yes, sometimes you have to do your own research, but what you get out of it is a million times more useful than a simple copy-and-paste. In my experience, when that fails, asking a question on the forum always helps. I have never received a rude response no matter how elementary or stupid my question may have been. In fact, these are the only forums I have ever been on where this is consistently the case. Maybe I'm just naive and stupid, but I couldn't ask for anything more. With that said, I'd like to give my most sincere thanks to Parallax and the excellent community around it! THANKS!
And to keep on topic:
What I find most frustrating about the Propeller is that its capabilities far exceed my own!
What I find most frustrating about the Propeller is that its capabilities far exceed my own!
Exactly how I feel.
Too many replies to answer individually so a big "Thank You" to everyone.
@chip, @ken - thanks for your comments and thanks to Chip for the status report.
@HShanko - #75 - I have *no* idea who you're on about. I'll have to Google him later.
A few general comments...
I have read the datasheet and manual many times and usually come away with more questions than I started with. I know documentation takes time and resources to write and that Parallax is a relatively small company HOWEVER if you want to see design wins against other larger companies you need to play on their terms. The chip I'm looking at as an alternative to the P1 has a 510 page datasheet to describe the silicon and a 460 page assembly programmer reference manual. Add a C language manual and the GCC manuals on top and your probably looking at 2,000 or more pages of documentation.
And that lot still haven't taught me how to program or write useful productive code or provided me with any code snippets.
I don't really care what the programming language is as long as it doesn't stop me from using the silicon in an efficient way and in a way that I know the chip can work.
What, to me, is obvious is that SPIN does not do this. Don't get me wrong, it's a great language and toolset for what I believe the target market is but it forces you to do things it's way and stops you getting close to the silicon.
Brian,
I'm curious. I really need to know what that other chip is that you considering as an alternative to the P1.
As far as I can tell there is only one other architecture generally available that compares with multiple cores, similar memory space, "soft" peripherals instead of dedicated silicon, similar price etc.
Now as mentioning any competeing mcu could cause another long and heated debate here perhaps you might let me know via a private message.
The chip I'm looking at as an alternative to the P1 has a 510 page datasheet to describe the silicon and a 460 page assembly programmer reference manual.
That is the beauty of the Propeller. It does NOT REQUIRE a huge datasheet and programmer reference manual. There are only 16 registers (duplicated in each cog). Not 100's. Therefore, you do not have to learn how to initialise all these registers, or what pins the internal peripherals use and share. You do not have to read 100 datasheets to find out which device in the family has an XYZ peripheral that can also be used at the same time as an ABC peripheral. The prop uses soft peripherals, and many of the standard peripherals have been done for you (serial, ps2, spi, i2c, etc). Not only that, but these soft peripherals are smarter and the protocols are implemented for various specific peripherals... 24C512 for instance, DS1307 RTC, SD card with FAT16/32, VGA, TV, and more.
... and stops you getting close to the silicon
I could not disagree more. If you want to do the bit-banging yourself, you can. Just write the pasm driver yourself. And you can even monitor what it is doing on another cog.
OK, here's an example of what I want to do. I can't see anything here that the silicon won't do.
main.spin is...
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
cog1 : "cog1"
cog2 : "cog2"
cog3 : "cog3"
cog4 : "cog4"
cog5 : "cog5"
cog6 : "cog6"
cog7 : "cog7"
VAR
'HUB is 32kbytes
'8kbytes of byte arrays
byte A[2048]
byte B[2048]
byte C[2048]
byte D[2048]
'16kbytes of word arrays
word E[2048]
word F[2048]
word G[2048]
word H[2048]
'4kbytes of long array
long I[1024]
'that leaves us 4kbytes for the SPIN code below and its stack
PUB Main
'start COGs
cog1.start(1)
cog2.start(2)
cog3.start(3)
cog4.start(4)
cog5.start(5)
cog6.start(6)
cog7.start(7)
repeat
'do stuff here involving all the arrays
I then have 7 files, one for each of the other COGs with the general structure...
CON
VAR
PUB start(a)
'now start it
cognew(@entry, $01)
DAT
'480 longs of executable PASM
'16 longs for intermediate calculations and address pointers into HUB RAM
'set origin
org
entry
pasm_code long $5500AA00[480]
acc1 long 1
acc2 long 2
acc3 long 3
acc4 long 4
acc5 long 5
acc6 long 6
acc7 long 7
acc8 long 8
acc9 long 9
acc10 long 10
acc11 long 11
acc12 long 12
acc13 long 13
acc14 long 14
acc15 long 15
acc16 long 16
...using the silicon in an efficient way... What, to me, is obvious is that SPIN does not do this.
This does not seem quite right to me. Spin includes PASM, you can't get much closer to the silicon than that. At least I don't want to go back to hand assembling into hexadecimal again:)
You are quite at liberty to write all your code in PASM if you wish, well with only a few lines of Spin to get things started.
Spin does of course have it's limitations but is by design I believe, it's kept simple for the intended audience of hobbyists and casual coders. It does also address the issue of how to get the most functionality into the limited memory space. Those byte codes are compact. As you will find if you look at the C compilers that compile to PASM instructions fetched and executed from HUB (Large Memory Model - LMM) the same functionality takes a lot more space than Spin.
It might be a good time to make a rigorous statement of the problem you are wanting to solve so that people can suggest how to go about it. A new thread for your project perhaps.
And don't get me started about why I can't use the addresses of the arrays directly within my PASM.
Okay I will not, but you can't
My solution:
The top object:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
arr : "arrays"
cog1 : "cog1"
cog2 : "cog2"
cog3 : "cog3"
cog4 : "cog4"
cog5 : "cog5"
cog6 : "cog6"
cog7 : "cog7"
VAR
long stack[50]
PUB Start
coginit(cogid, Main, @stack) 'move stack to var section
PUB Main
'start COGs
cog1.start(1)
cog2.start(2)
cog3.start(3)
cog4.start(4)
cog5.start(5)
cog6.start(6)
cog7.start(7)
repeat
'do stuff here involving all the arrays
byte[arr#A][99] := 0 'access arrays
result := long[arr#I][22]
The arrays object, which defines your arrays as constants
CON
'HUB is 32kbytes
'8kbytes of byte arrays
A = $1000 'byte A[2048] ($1000 reserves first 4k for Spin)
B = A+2048 'byte B[2048]
C = B+2048 'byte C[2048]
D = C+2048 'byte D[2048]
'16kbytes of word arrays
E = D+2048 'word E[2048]
F = E+4096 'word F[2048]
G = F+4096 'word G[2048]
H = G+4096 'word H[2048]
'4kbytes of long array
I = H+4096 'long I[1024]
'that leaves us 4kbytes for the SPIN code below and its stack
PUB dummy
And the COG objects
OBJ
arr : "arrays"
PUB start(a)
'now start it
cognew(@entry, $01)
DAT
'480 longs of executable PASM
'16 longs for intermediate calculations and address pointers into HUB RAM
'set origin
org
entry
pasm_code long $5500AA00[480]
acc1 long arr#A 'pointer to byte array A
acc2 long arr#B 'pointer to byte array B
acc3 long arr#H 'pointer to word array H
acc4 long 4
acc5 long 5
acc6 long 6
acc7 long 7
acc8 long 8
acc9 long 9
acc10 long 10
acc11 long 11
acc12 long 12
acc13 long 13
acc14 long 14
acc15 long 15
acc16 long 16
I'm not sure if the trick with restarting Spin to move the stackpointer works. If you not do that the stack will be at the end of all objects and overwrite one of your arrays.
Now I'm interested. I have been starting with PASM and sort of discovered by accident that SPIN arrays did not seem to be addressable from the PASM code. I thought it was my bad since I have only just started but is this indeed a limitation?
You have to remember that all of Spin's data is in one memory and the cog's data and instructions are in another memory and there's no connection between the two memories. There are special instructions (RD/WR BYTE/WORD/LONG) for accessing the memory (the HUB) where Spin's data resides and, as far as these instructions are concerned, the hub address is just another 32-bit value.
If you think of the RD/WR BYTE/WORD/LONG instructions as I/O instructions with the hub address just some I/O control information, it makes more sense than trying to think of hub memory as memory like that in the cog.
Comments
First, I'm pleasantly surprised that Chip and Ken replied and I understand that you may not have the staff to do what should have been done over the past 7 years as a cumulative project. I think you are overlooking your biggest resource though and that is that you have a lot of die hard supporters on this forum. Again, I don't know anything about the staff situation, but if you tasked someone to put serious time into heading up this effort, a lot of people would be willing to pitch in including myself as I indicated in my other thread. I am a technician, not a tech writer or organizational person, but I would like to pay forward what some of the very helpful forum members have taken their time to help me along the way with and I'm willing to work for free for you as long as I feel you have the same basic end goal as I do for this and have a vested interest in getting this done, as opposed to placation or only a slight interest. I believe many forum members feel this same way as I do, but I say this explicitly as I want to set proper expectations.
I know some of the things I listed are documented, that doesn't meant I didn't look for them or read them. I have probably read the manual more then most people on this forum because I have nothing else, this is my first and only uC and I can't rely on past experiences with previous uC's like some of the other forum members. I came to Parallax because I saw their product in Radio Shack marketed towards learners. I actually thought I was Parallax's target audience (new to uC's, new to programming, new to electronics) but I may be wrong about that and would like to know if I was mistaken in that. I take full responsibility for learning on my own (Cluso I'm not expecting too much and you've misunderstood me if you feel that) and do not think it is Parallax's responsibility, although I do think it is their responsibility to provide some of the basic tools such as what I listed above to help me help myself. I can teach myself given a decent set of tools and to be honest I don't want to have to rely on others, although sometimes this is inevitable. Thanks to MagIO2, I learned PASM in a month or two (with literally 0 prior ASM experience), this by no means is me saying I'm smart, but I think it shows that given the right tools, an average motivated person can learn things. I would have still been trying to figure out PAR without the help of MagIO2 and a few other forum members, but because I was able to build a good foundation before referring to the manual, the manual was reasonably useful and I actually think PASM is a little easier then SPIN. The risc/cisc thing helped me with knowing why there were not MUL and DIV commands and without 1 response from Kye posting a way that I could call the multiply and divide routines, I would really be hosed with PASM. Him posting the code from the SPIN interpreter for multiply and divide is the type of code examples I would like to see Parallax provide. I have it set up so that I can call it and return a value, it could be inserted into anyone's PASM code with very little interruption else wise.
I will help with code examples that should be in the manual (although there are many many better programmers on here compared to me), not just the OBEX which is kind of like the wild wild west, but in the manual. This is why the sanctioned oversight from Parallax is necessary. You know your product best and there are people here willing to do some of the leg work for you to help others in the future. I really don't think you could ask for more from your users, give us 1 good resource from Parallax, task them with this for the rest of 2012 as their primary task and I bet none of this is even an issue come 2013. The same with the prop tool/IDE ... I'm very hesitant to jump to the GCC and would like the small improvements done on the prop tool that I suggested, you can even make them so that they can be turned on or off which makes it a win win for everyone. I tried looking at the prop tools source code, but I don't know anything about Python unfortunately.
So what say you? Are you in?
First off,
Demanding the Propeller tool to be rewritten is asking a bit too much.
It is what it is - and it works well at what it does.
I just spend more time dealing with structural changes cause by indentation than I want to.
But that's a personal thing.
GCC is proving itself to be stable and useful.
I'm rewriting most of my earlier SPIN experiments to see how well that goes.
If it continues to please me the way it has so far I'll keep it as my main tool.
As for the "Are you in?" challenge, I'm way ahead of you.
And I suspect others are as well.
I wanted a QuickStart Manual for the QuickStart board hanging on the shelf at Radio Shack
(along side the DOZEN or so there for the Ardunio).
So I started writing my own.
I don't really expect it to be a commercial release, but who knows? Stranger things have happened!
Like the Forrest Mimm books (and in that same format), lots of examples and incremental development.
It's just a collection of experiments that I did to get going with the Propeller.
Scope -
First time user, or first time Propeller user...
Little or no programming experience needed, but experience always helps
things go faster and smoother.
NO extra hardware needed - just usi whats on-board.
So, no wiring, no soldering, nothing else to buy.
I'm 45 pages into now - but hung up on a few things that I don't yet know well, but feel like it should there to
complete the scope of the book.
Those things would be -
Bits, bytes and words - how to dig data from longs (doing it, but not happy with my examples)
Arrays
???
My table of contents - so far...
Propeller QuickStart Guide
Getting Started:
Installing software!
Editor screen:
A special note about indentation…
Top Object
Propeller Serial Terminal:
Projects:
Blinky1.spin Blinks an LED
Blinky2.spin Does it better?
Chase1.spin Chase light string
Cylon.spin Robotic cyborg eye display
Heartbeat.spin Pulse display
Tick.spin Accurate Timing Loops
Throb.spin Pulse Width Modulation
Tpad.spin Scan the touch pads
PWM.SPIN
Accurate Timing
Going Parallel
APPENDEX
Running the QuickStart board on battery power
Popular Propeller Expansion circuits
Propeller LED and Switch Interface
Propeller Composite Video (TV Out)
Propeller VGA Video
Propeller Audio Out (Stereo)
Propeller High Impedance Microphone
Propeller Secure Data Card Interface (S.P.I)
QuickStart board schematics
Web Addresses (LINKS)
Downloading Propeller Tool and related software
OBEX
Forum
Who has the PASM and advanced projects books???
At this point I've learned enough the hard way to where I don't struggle nearly as much as I did, although I still need help from the forum and am not experienced enough to be a very good teacher ... I'm interested in saving others from that struggle, who enter into the Propeller from a similar background as I did, so my motivation is more philanthropic than anything else.
Imagine it's 1980 and you have on your desk a Motorola 6809 eight bit microprocessor chip. No documentation except the hardware technical reference and the instruction set description.
No assembler language and no high level language support.
Now your task is to build a board in which this chip can run. Plus you have to program some software environment, using HEX codes, that makes it useful.
That is the Prop chip, except Parallax has done a great job providing a dead easy programming language for it and a dead easy IDE in which to write that code.
I don't know what there is to complain about.
Parallax has indeed provided us with much more than that. Still, I love the idea of a collection of coding examples of intermediate and advanced topics...along with helpful comments. I think Graham Stabler provided the perfect example of proper commenting here.
To get the mistakes out first: a) I chose a chip that had really bad documentation and closed development tools. b) I bought 500 of them at ~$5.10 each
If you go to www.dainst.com you will see a datalogging device I designed. I only made 2 of these, though the protos worked excellent at what I designed them to do.
I came across the Hitachi H8/3664 chip in some manner and decided I would use it as the center of my project. Mind you this was after doing much of the ground work with a BASIC stamp, but the $29 cost for a BASIC stamp was way too much for this product.
I wrote all of the firmware for the acquisition unit in C and had a program that ran on the PC, written in C++ using the Qt library. All of this worked very well and looked great. The primary target was the Sharp Zaurus PDA, but I could never get my program to run on it without core dumping. Further compounding the problem was debugging with the device.
Ultimately I had missed the target price (I aimed too low), my PDA uplink wasn't working, and the acquisition unit had no memory of it's own except on-chip flash.
I wanted to be able to execute field upgrades of the unit or use the flash for storing data, which turned out to be a HUGE freaking mess. Hitachi didn't put a proper flash controller on the chip, so the mCU had to be the flash controller. The process of writing to the flash wasn't well documented, there was no example code, and the flow charts omitted crucial elements that were necessary to make it work. In short, I wasn't prepared to write the necessary code to burn to flash, and they didn't provide a library or proper documentation to do it. But they didn't really care because 6 months later they had another part number and in a year that part was EOL and they didn't have to support it. Their attitude is to shovel Smile out to the customer and let them toy with it, but only to find out they need to buy the next best chip, then the next best chip, then the next best chip, etc.
If I was to take up this project again (which may happen), I would certainly target the whole kit and kaboodle at the Propeller. It would be almost trivial to reimplement it with the Propeller and have a load more features than I could originally implement.
For instance, I could have multi-GB SD card support for log data, I could have dashboard visualization with an LCD monitor, I could have more channels of timer data, and I could implement the output triggers I wanted to. One platform could be repurposed into several different products, from datalogging to traction control.
I still stand by my original statement, the Propeller is a great chip because it doesn't have a 300 page datasheet full of obtuse and erroneous information, it has a long term commitment from the manufacturer, the lifecycle is infinite in comparison to other chips, and the chip is very accessible with the tools and documentation provided. Furthermore, the community makes it very easy to ask questions and find answers. There isn't a lot of useless replies and banter to serious questions.
My case in point, search google for "executing scripts on fat linux" -- you will look through many replies that have no practical answer to the original problem. FWIW, you have to mount the filesystem with -o dmask=0222,fmask=0222 and then you can execute scripts and programs from the VFAT filesystem. I ran into this problem trying to build PropGCC on my phone.
BTW, does anyone need 500 Hitachi H8/3664 64QFP chips still in the vacuum pack, I'll discount them to see them go to a good use!
I wasn't alive then and in reference to this particular instance I am happy about that. I wouldn't have been able to jump into using that without years and years of schooling and I wouldn't have had any interest in this as a hobby. I will give you that I have nothing to compare to, so I don't know how "bad" it could be, but I don't think that negates the desires for improvement expressed in this thread. There is obviously a lot of room for improvement, as stated by many people in this thread. Not everyone has or will ever have the experience and expertise that you have. I may have expectations that are too high, I'd like to hear Parallax's response to one of my earlier posts about if my expectations are false.
Been there, done that
I was in same place in 1976-77 but with one 8080 + its support iC and 2x2114 1024x4Bit RAMs and some switches and only instruction list + very simple SCH that showed what pins do what.
Good progress.
Are the timers in the Synthesis/FPGA, or in the padframe ?
Did the ability to capture an external edge, and/or clock from an external edge make it into the mix ?
Of course, most of us would like perfect documentation. And be able to just dive right in and write code without rtfm very much. But for someone/many to write what's been requested, well, that takes a very good writer. And mucho time.
-Phil
But the matrix is far into the future. No one can jack you into the net and pour "expert prop programmer" into your head. Even with whatever one would consider perfect documentation, there are things that you will only get your head around by doing and maybe letting out the magic grey mist on occasion. As Nike says, just do it. Chip, thanks for a great product, those i have learned from, thanks as well.
Carp less, code more.........
Frank
Put perfectly.. Amen.
Thank you
OBC
A great example of how this has been done can be found over at the Arduino pages--their "Playground" website ( http://arduino.cc/playground/ ) is a terrific source for getting code and good documentation, and their library pages are quite good (see http://arduino.cc/en/Reference/Libraries ). The Parallax obex is nice, but very limited as an information tool. I look forward to seeing something like a Parallax Playground that focuses on gcc C/C++ at some point...there's huge potential in that--and the beta appears to have fixed a LOT of issues - every demo I "make" works perfectly on a PPDB.
Personally, I wish there were more C++ examples...once you try OOP with classes, you won't go back. I'll work on contributing if we have the right place to put our stuff...forums clearly aren't the answer for that kind information presentation.
Then about 5 years ago or so, I found "What is a microcontroller?" on the shelf at a RadioShack. Having been interested in the nitty gritty of electronics, left me wondering "What is a microcontroller indeed?". So I purchased it and got started with the projects in the book, and while I was able to follow along, I still ran into the issue I had with BASIC all those years back. The abstraction between code and hardware left me feeling that I was missing out some very fundamental understanding. What did I do? I purchased an SX and started programming in assembly. It was tedious, but I felt like I was finally starting to get somewhere! I was able to finally get a small grip on the fundamentals of processor architecture, and for once, my understanding of programming had some meaning. The Propeller had already been released by then, but I kept away as Parallax themselves stated it was targeted towards more advanced users. I wish they hadn't, because when I finally decided to give it a shot, I found it to be perfectly compatible with the way I wanted to learn how to program. Simply put, SPIN made sense. The Fundamentals book got me started, and hooked. Sure, there was a lot that didn't get covered, especially since it was targeted at learning how to program with SPIN on the prop, and not general programming techniques, but I wasn't afraid to try figuring out concepts that were new to me. I was also excited that if I wanted, I could go low level and program in PASM in conjunction with SPIN. That's not to say I'm a master, or even intermediate in either, but it gave me a grip in coding I never had before. Everyone knows mastery of ANY art takes a lot of time, dedication and interest. I wouldn't expect anyone to pick up a guitar for the first time in their life and begin shredding right off the bat. No one would be upset at Fender or Gibson because of it, that would obviously be absurd.
I personally find there to be an EXTRAORDINARY amount of informational resources available for the prop. Granted, they're not in one specific location (this holds true for just about EVERYTHING), but they usually only require the most minute amount of searching. Yes, sometimes you have to do your own research, but what you get out of it is a million times more useful than a simple copy-and-paste. In my experience, when that fails, asking a question on the forum always helps. I have never received a rude response no matter how elementary or stupid my question may have been. In fact, these are the only forums I have ever been on where this is consistently the case. Maybe I'm just naive and stupid, but I couldn't ask for anything more. With that said, I'd like to give my most sincere thanks to Parallax and the excellent community around it! THANKS!
And to keep on topic:
What I find most frustrating about the Propeller is that its capabilities far exceed my own!
Exactly how I feel.
Too many replies to answer individually so a big "Thank You" to everyone.
@chip, @ken - thanks for your comments and thanks to Chip for the status report.
@HShanko - #75 - I have *no* idea who you're on about. I'll have to Google him later.
A few general comments...
I have read the datasheet and manual many times and usually come away with more questions than I started with. I know documentation takes time and resources to write and that Parallax is a relatively small company HOWEVER if you want to see design wins against other larger companies you need to play on their terms. The chip I'm looking at as an alternative to the P1 has a 510 page datasheet to describe the silicon and a 460 page assembly programmer reference manual. Add a C language manual and the GCC manuals on top and your probably looking at 2,000 or more pages of documentation.
And that lot still haven't taught me how to program or write useful productive code or provided me with any code snippets.
I don't really care what the programming language is as long as it doesn't stop me from using the silicon in an efficient way and in a way that I know the chip can work.
What, to me, is obvious is that SPIN does not do this. Don't get me wrong, it's a great language and toolset for what I believe the target market is but it forces you to do things it's way and stops you getting close to the silicon.
I'm curious. I really need to know what that other chip is that you considering as an alternative to the P1.
As far as I can tell there is only one other architecture generally available that compares with multiple cores, similar memory space, "soft" peripherals instead of dedicated silicon, similar price etc.
Now as mentioning any competeing mcu could cause another long and heated debate here perhaps you might let me know via a private message.
main.spin is...
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ cog1 : "cog1" cog2 : "cog2" cog3 : "cog3" cog4 : "cog4" cog5 : "cog5" cog6 : "cog6" cog7 : "cog7" VAR 'HUB is 32kbytes '8kbytes of byte arrays byte A[2048] byte B[2048] byte C[2048] byte D[2048] '16kbytes of word arrays word E[2048] word F[2048] word G[2048] word H[2048] '4kbytes of long array long I[1024] 'that leaves us 4kbytes for the SPIN code below and its stack PUB Main 'start COGs cog1.start(1) cog2.start(2) cog3.start(3) cog4.start(4) cog5.start(5) cog6.start(6) cog7.start(7) repeat 'do stuff here involving all the arraysI then have 7 files, one for each of the other COGs with the general structure...
CON VAR PUB start(a) 'now start it cognew(@entry, $01) DAT '480 longs of executable PASM '16 longs for intermediate calculations and address pointers into HUB RAM 'set origin org entry pasm_code long $5500AA00[480] acc1 long 1 acc2 long 2 acc3 long 3 acc4 long 4 acc5 long 5 acc6 long 6 acc7 long 7 acc8 long 8 acc9 long 9 acc10 long 10 acc11 long 11 acc12 long 12 acc13 long 13 acc14 long 14 acc15 long 15 acc16 long 16If there's a solution I'd love some pointers.
This does not seem quite right to me. Spin includes PASM, you can't get much closer to the silicon than that. At least I don't want to go back to hand assembling into hexadecimal again:)
You are quite at liberty to write all your code in PASM if you wish, well with only a few lines of Spin to get things started.
Spin does of course have it's limitations but is by design I believe, it's kept simple for the intended audience of hobbyists and casual coders. It does also address the issue of how to get the most functionality into the limited memory space. Those byte codes are compact. As you will find if you look at the C compilers that compile to PASM instructions fetched and executed from HUB (Large Memory Model - LMM) the same functionality takes a lot more space than Spin.
It might be a good time to make a rigorous statement of the problem you are wanting to solve so that people can suggest how to go about it. A new thread for your project perhaps.
My solution:
The top object:
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ arr : "arrays" cog1 : "cog1" cog2 : "cog2" cog3 : "cog3" cog4 : "cog4" cog5 : "cog5" cog6 : "cog6" cog7 : "cog7" VAR long stack[50] PUB Start coginit(cogid, Main, @stack) 'move stack to var section PUB Main 'start COGs cog1.start(1) cog2.start(2) cog3.start(3) cog4.start(4) cog5.start(5) cog6.start(6) cog7.start(7) repeat 'do stuff here involving all the arrays byte[arr#A][99] := 0 'access arrays result := long[arr#I][22]The arrays object, which defines your arrays as constants
And the COG objects
OBJ arr : "arrays" PUB start(a) 'now start it cognew(@entry, $01) DAT '480 longs of executable PASM '16 longs for intermediate calculations and address pointers into HUB RAM 'set origin org entry pasm_code long $5500AA00[480] acc1 long arr#A 'pointer to byte array A acc2 long arr#B 'pointer to byte array B acc3 long arr#H 'pointer to word array H acc4 long 4 acc5 long 5 acc6 long 6 acc7 long 7 acc8 long 8 acc9 long 9 acc10 long 10 acc11 long 11 acc12 long 12 acc13 long 13 acc14 long 14 acc15 long 15 acc16 long 16I'm not sure if the trick with restarting Spin to move the stackpointer works. If you not do that the stack will be at the end of all objects and overwrite one of your arrays.Andy
Now I'm interested. I have been starting with PASM and sort of discovered by accident that SPIN arrays did not seem to be addressable from the PASM code. I thought it was my bad since I have only just started but is this indeed a limitation?
Cheers
Richard
If you think of the RD/WR BYTE/WORD/LONG instructions as I/O instructions with the hub address just some I/O control information, it makes more sense than trying to think of hub memory as memory like that in the cog.