A Matter Of Perspective
K2
Posts: 693
I've been a pretty ardent supporter of the Propeller ever since some initial success I had writing SPIN apps that made use of the very nice canned objects available. SPIN seemed so natural that I hardly had to look at the manual. And the objects were so well-written that they were a pleasure to incorporate. Successes were many and grovelling was nonexistent.
Now, in the quest for speed, I've plunged headfirst into the PASM world and found it to be the absolute opposite experience. Constant roadblocks impede progress. Trying to get a relatively simple question answered has resulted in rebuffs from two individuals who don't do "Private Consultation." Blimey! Evidently a rose by another name reeks.
Nested vectored interrupt control doesn't seem so off-putting anymore.
Now, in the quest for speed, I've plunged headfirst into the PASM world and found it to be the absolute opposite experience. Constant roadblocks impede progress. Trying to get a relatively simple question answered has resulted in rebuffs from two individuals who don't do "Private Consultation." Blimey! Evidently a rose by another name reeks.
Nested vectored interrupt control doesn't seem so off-putting anymore.
Comments
If you sent a private message, then that explains it. Post your question so EVERYBODY can benefit from the answer. Not just you.
P.S. You might want to give PropBasic a try.
Bean
Haven't notice you asking any PASM questions recently.
Don't despair, ask away. No reason you would get less answers than anyone else.
I have never programmed in any other assembly language, but I have looked and them and they seem more picky and require more instructions to do the same thing. Almost all of them: you don't have optional C and Z flags. Instructions set them or they don't. Some 8-bit microcontrollers have other massive limitations when writing and reading just a byte. No need to mess with interupts, not knowing what the Z and C flags are can be a crazy pain. Being able to dedicate an entire cog to a single PASM routine is so much easier than trying to integrate one routine into another without shooting yourself in the foot with timing problems. Here is a big one: most other microcontrollers force you to use assembly, you don't have the option to use SPIN. Your only option is to pay for a C compiler which converts your code into assembly (and now we have this option, in many flavors, for free).
Anyway, everyone I have seen on here that have programmed in other assembly languages say PASM is so much easier than any other assembly language. Keep at it, you will learn it.
Heater, you're right. For personal reasons I was trying to get one particular question answered privately. Note to newbies: Don't do that. It won't end happy.
Bobb, maybe my problem is that I've programmed in assembly on too many processors. The quirks of the Prop that I once though were amusing and clever have turned into horrors now that I have to deal with the details. To be honest, 80% of it has gone reasonably well. The other 20% is queering the whole deal.
There is too big a gulf between the few snippets of sample code in the text (PM) and Chip's VGA objects. Meanwhile GEAR is giving me indecipherable nonsense. I don't recognize my variables _or_ my code in the jumble. It's not like any emulator I've ever used...and I don't mean that in a good way. No doubt I'm doing something wrong. Now if I could just find the GEAR manual...
Try this: http://forums.parallax.com/attachment.php?attachmentid=71834&d=1279324086
The BMADebugger_Demo.spin file has lots of docs.
It may also be indecipherable and quirky at times, but it's the best for me so far
It sure looks different from the assembly language I used for MSDOS 5.1!
Some tutorials would really be helpful...
To K2, and by extension "newbies" mentioned above:
If you think about it (I'm sure you have), asking for help via PM is against the culture of the forums (closed vs open).
It also implies that you are expecting "Private Consulting" from someone, as opposed to an open discussion of a problem. There can be a big difference in the amount of time or interest one has, based on if they feel they are being altruisitic to a community at large, or helping a single individual. Getting paid or not is not necessarily the driving force. Take a look at some of the threads here (and elsewhere) on open source vs. closed, "code protection", etc.
Also keep in mind that these forums are very "open" in nature, and attempts to make things work otherwise are often resented (sometimes deeply) by some members.
John R.
Ron, Amen! I had more fun programming in 286 machine code without the advantage of an assembler. Our professor thought that would promote character.
John R, it was obvious with the first rebuff that the discussion had already taken place, privately, among some of you. No doubt there were all sorts of wonderful rationalizations. I'm thinking "legal liability" was even uttered once or twice, with smug grimaces and knowing nods among participants. One runs into that a lot in life. In other venues, they go by the name of "statutes" - predetermined responses to variable inputs. I think they go away in the next life. Can't wait!
If you are trying to keep what you are doing a secret (plan to patent etc). Then yes it's hard to get help without actually paying someone to be a consultant.
If you don't need to keep it a secret, then by all means post what you have so far and how it is failing. I'll be glad to help.
PropBasic compiles to straight PASM so it's pretty fast. I wrote PropBasic, so if it is able to do what you want, I'll give you a PropBasic solution.
Bean
Hope something good comes out of your experiments with this. I use BMA constantly and add features every now & then. I don't mind feedback or requests for improvements. There is a thread for it although the forum transition clobbered the code block examples. http://forums.parallax.com/showthread.php?t=115068
Cheers.
--Steve
This forum's community atmosphere has a track record of being quite pleasant, welcoming and helpful. Best stay away from the PMing as all bets are off regarding responses or lack thereof...if you have PASM questions there are so many here that can help, so ask away.
I've read this thread a couple of times, and I can't figure out what your really asking. If you have specific questions you should ask them here. You'll get plenty of answers.
The Prop core is really quite easy to program in PASM. Of course, programming in assembly is alway very tedious. It doesn't matter which processor we're talking about. It would be nice to have a macro assembler for the Prop. That would remove some of the tedium from programming in assembly, and it would make the code more readable.
For the most part, the Prop core is quite capable. The only real drawback is the lack of indirect addressing of cog memory. Self-modifying code is not a very elegant way to handle to work around it, but it works.
Dave
I appreciate what you're saying. It's true - this is a outstanding forum. I'm floored by the productivity and genius of so many of the participants. It's probably an expectation collision I had. I was storing a flawed model of reality in my noggin. "Happy is the man that findeth wisdom, and the man that getteth understanding."
I'd be interested to know exactly what quirks you have in mind here. And then I'd like to know how they have turned into horrors.
I have programmed a lot in assembler over the years from 8085, Z80, 6800, 6809, 8086, 386, 68000 and more. This makes me think the Propeller has about the easiest to use assembly language I have ever come across.
Now of course the Prop has funky limitations like only 512 instructions in COG. I'd like to here what it is that you are stubbing your toe against.
Then again, the only time I had problems with ASM was when I was doing code for a 56K (source, destination) and a 80186 (destination, source) at the same time. That and trying to learn 6502 after getting used to 16 bit index registers on the 6809.
I wasn't so much asking. I was whining - whining mostly that the only way to obtain help with an obfuscated chip is by using a public forum wherein every detail of your project is on display. It's a personal thing. Sorry.
There were other things bugging me, but I'm going to give them a rest.
I'm familiar with that tedium. I accepted and embraced it many years ago. Thousands of vehicles are on the road running code I wrote. WRT the Prop, I'd be delighted if I could get to the point where all I had to deal with _was_ the tedium.
See my precious post. Everything you need to know to use the Prop is in the Propeller Manual, barring inadvertent omissions, errors and ambiguities that exist in all such documents. For those few things there is the forum here willing to clarify. I'm genuinely interested to know what the issues are.
I think we all know the aggravations associated with learning any new language. We always say, "why isn't this like that?" and "what were they thinking when they did this!" But once you learn it and move to some other language, you'll be saying the same thing with that language, comparing it to the one you are learning now.
It all comes down to working with what works, dealing with what we are dealt, and scratching and banging our heads for a while until it makes enough sense to make some dollars.
I'm sure you and Eric - and others - are right. It's about wrapping my head around certain things. It's not the self-modifying code issue - 6502 assembly was my intro to computerdom. (It would really bite to go from the 6809 to the 6502!)
One enormous help I wish Parallax would provide is a FAQ or APP NOTE that makes a bridge between Jeff Martin's PAR example of a single shared variable (which, believe it or not, I think I understand) and Chip's various VGA objects (which totally baffle me). It seems to me that Chip is invoking a whole lot of mojo that isn't explained anywhere in the PM - particularly wrt the sharing and transfer of data, and the complexities surrounding the launching of cogs.
There is the documenting of the chip. For PASM, I think that's actually very complete. --more than complete enough to make some great programs.
Documenting the use of those things is another matter. Because the chip is really different in some ways, like with the COGs, that documentation isn't as common as it could be, if the design were more aligned with the majority out there.
You made a very apt dichotomy. I have to agree that Parallax has ultimately done a thorough job of documenting the chip.
Unfortunately, plowing new ground unavoidably requires a greater effort. Either Parallax or its customers, or both, have to put in that extra effort. Who should be doing most of the pulling may be a more complex question than it first seems.
Parallax' approach at the moment seems to be that "Many hands make light work." They have a bunch of volunteers who, for their own varied reasons, are willing to do some pulling from time to time. Some are stronger than others. Some more willing than others. Some more altruistic than others. It's an interesting microcosm.
Edit: And some are just along for the ride.
I really like PASM. The Prop is very elegant, and well realized. The most interesting attribute to me is how things make sense in context. If one is used to other Harvard CPU's, it's a bit of a jump.
Once that initial memory to memory design idea hits your brain, and solidifies a bit, the doors open pretty wide PASM wise.
Programming on the Propeller evokes many of the same reactions I had on 6809, after working with 6502.
(I still really like 6809, and program it on occasion)
The Prop, built with such a clean, and uncluttered Von-Newmann design is beautiful to me.
IMHO, your comment is spot on, and I call that boot-strapping. Truth is, most other devices out there, share many attributes in common. The effort to learn the new bits is small, with most of the device being general.
The Propeller has some genuine, new ideas in it, and that raises that bar. This is, IMHO, why the scene surrounding it has that fun, exploratory feel. That is literally happening, because the device is actually different enough for that to occur.
In a very real sense then, it's hard to expect the level of documentation some people need to be realized right now, particularly given many best practices have yet to be sorted out.
I'm certain that there are aspects of the memory-to-memory idea that haven't solidified in my brain, at least with respect to the Propeller. But I have programmed on many von Neumann machines. In fact, until the 16C54 I'd never programmed anything that wasn't von Neumann.
Even on the Propeller I have several algorithms written, and thanks to jazzed, tested.
But my algorithms are still land-locked because they can't effectively communicate with others except through an ugly skinny pipe that involves an overused shared memory location and several pins.
Chip Gracey is the single most influential individual in this whole enterprise. Parallax wouldn't exist without his genius and protracted effort.
An oversimplified description of Chip is that he is a self-taught genius entrepreneur hobbiest. He has had to solve many _enormous_ puzzles to accomplish what he has. And he has had to do it largely on his own.
Some of us had it easy...there was a parent or teacher or professor to help help us practically every step of the way. We still had to read the book, do the homework, and take the tests, but, speaking personally, I'm 100% certain that I learned _much_ more that way than I ever would have on my own in the same amount of time. This is because I lack both Chip's genius and Chip's unrelenting drive. School is a huge blessing for lazy schlubs like me.
But, as a consequence of our disparate backgrounds, those of my ilk have one expectation and Chip and his company have a different. I believe that the chief product Parallax is peddling is 'discovery'. As potatohead has articulated, the discovery of the Propeller is a fantastic thing. Fantastic unless you expected results the same day you picked up deSilva and start reading. Fantastic unless you are accustomed to a professor or FAE to fall back on when you are confused and crunched for time.
Were Parallax to develop commercial aspirations, it seems axiomatic that they would have to launch a systematic effort to smooth the path to PASM development. To me, that means more extensive examples of specific solutions around the same cognitive hurdles that have been articulated on this forum, in one form or another, almost daily for years. But they may wish to remain in the hobby realm, instead, and continue to sell discovery and community. That's not a bad thing at all and Parallax does it very well.
One of those will trump the other. As of this moment, if you want it same day, perhaps using a rather ordinary, undifferentiated CPU makes the most sense, right?
On the other hand, if it needs to be specialized, then perhaps that differentiated CPU makes a lot more sense, but then it's not going to be the same day, the first time, like it would with mature technology, and implementation ideas.
Your comments on resources to tap are good ones. IMHO, those will happen, and as they do, some of this conversation will go away.
Again, if it's actually new, and the Propeller is, given how it's organized, and the rules by which it operates, then it by nature is discoverable. As it becomes less, new, it also by nature, then becomes "more mature".
eg: Pioneering effort on Prop I, leads to very solid base of core understanding and resources that will enable a quicker jump on Prop II.
There was too sharp of a focus on using any means possible to get the same cryptography applications running on Props that are currently running on an array of ARM Cortex chips. Somehow I figured it ought to take only a few days, tops.
For what it's worth, that's history. I may yet get the full-blown Prop implementation running, but there's no timetable for it. In the meantime ARM Cortex chips will continue their assigned roles. With PLCC chips sampling this quarter, I'll actually be able to assemble my own boards. And that will save a lot of money.
While that progresses, I'll have a chance to get a Prop'r education. (sorry)
Yeah, no worries. Good conversation.
All of this talk about pioneering effort and discovery is a bit silly. The fact is, there is a big lack of documentaion avaliable for the Propeller. Sure, you can't force people to write books, but there is a lack of baseline documentation available, which I personally believe is not the community's responsibility to provide. PASM is a good example. The Propeller has been on the market 4-5 years, which is plenty of time to hire a writer to write "PASM 101".
Sometimes it seems to me that there is too much reliance on the user community to provide the solutions to the problems.
Just now you can run the crypto algorithms xtea, xxtea, and RC4 on the Prop compiled from C source by the Catalina compiler. Or more slowly using GCC and Zog.
Those algorithms are small enough that I'm sure they could be implemented in PASM with in a single COG for the extra speed. Actually that is a little task I have set myself. Not that I have any use for it but just as a little challenge.
I don't know so much about cryto but I guess other algorithms will be too big to fit in COG in PASM.
Given that you mention using an array of ARM chips to do whatever it is, it sounds like you are after some serious performance. Perhaps the Prop is not avtually the most suitable device for what you want to do.
You were lucky to have professors explaining micro's to you. The first microprocessor I ever worked with seriously was the 6809. We had just the chips. No dev boards. No software. Not even an assembler. No one around who could explain anything. Who would know? Micros were pretty new stuff still at the time. We just had to build up a computer with it and start hacking out code to test it in hex with nothing but the data sheets to work from. Then create a debug monitor. Then think about what applications might work on it.
"And you try and tell the young people of today that ..... they won't believe you."
The stuff for beginners and people who are familiar with other processors, but not the Propeller rightly comes later and has been continuously under development, both by Parallax staff and other forum members. That there are not a series of books on this stuff is more a reflection of the limited resources at Parallax than anything else. Andy's PEK documentation is great. deSilva's intro to assembly is good, needs more work and polish.
Most of the baseline documentation appropriate for a microcontroller manufacturer is already done (except for the video generator). Documentation appropriate for an educational vendor of microcontrollers is partly done ... The Propeller Manual and PEK tutorials are quite good. More will come. Using experienced forum members just speeds the process up and brings in varied expertise.
Go through Microchip's documentation library sometime, look at the publication dates, and compare to the dates when the products involved were released. Given that Microchip is much larger, has a huge marketing department, Parallax isn't doing so badly.