Programming the Parallax SX Microcontroller
microcontrolleruser
Posts: 1,194
Looks like there are three texts available
SX/B by Jon Williams
Programming the SX by Parallax.
Assembler Programming by Guenther.
Probably start out with the SX/B text.
Comments
Looks very good.
Still leaning towards Basic for SX.
Should be able to insert assembler code.
EDIT
It says manual but it's usually called a datasheet.
This SX is very worthwhile.Lot's of depth to it.
At first look the SX has a lot of horsepower, but a good microcontroller
doesn't need to be fast. I have seen your posts on SX books, and IMO
the Prop1 would be more worth while to learn.
If you like SXB, try Prop Basic instead. It was developed by the same
person that developed and updated SXB.
Bill M.
Captain Quirk
A couple things.
I guess I'm looking for the 'true path' to learn assembler.
Was learning PIC assembler.
That sort of blew up in my face. The tutorial I picked did not communicate in a way that made sense to me.
Guy that spent a lifetime with Texas Instruments said look at the MSP 430.
Looked at the Intel 8051. Unless I missed something, the instructions are one letter long. Don't like that.
Have a Z80 evaluation kit they sent us. Have to look at that some more.
Learning SX keeps me 'in the fold' Parallax wise.
Disadvantage is it is clone of PIC's with instruction set changed around a little.
Learning Propeller keeps me in the fold too.
Disadvantages are it adds 'multi processor' layer, no interrupts and the assembler looks a little 'candy coated'.
There is something to be said for just learning one and the rest are just like it.
Propeller sort of pushes the limit in that regard.
8051 instructions are between two and 5 letters.
http://www.keil.com/support/man/docs/is51/is51_instructions.htm
Barely. There is no support for the SX. If that irritates you, direct your angry letter to Ubicom -- they hosed up the works, not Parallax. Ken Gracey put forth a Hurculean effort to keep the SX going; Ubicom's repsonse was to spit on Parallax (my words, not theirs).
Oy vey. This from a guy who pontificates, posts Parallax training material as if it's his own, and has yet to show any actual embedded application created with anything. What makes the 'candy coated' comment especially silly is that PASM was created by Chip Gracey, a master PIC programmer (Parallax started as a provider of PIC programming tools).
As far as the Propeller is concerned, you don't have to use the extra processors although they're sure handy for implementing I/O devices like UARTs, PWMs, video output, floating point processors, WS2812b drivers, I2C and SPI drivers, whatever.
The assembler is 'candy coated'? No, it's just a straightforward assembler for a straightforward instruction set. If you want something more complex, there are some universal macro assembler languages that can handle multiple instruction sets by defining instructions as macros. You could also use the assembler built-into SimpleIDE if you want.
You can do Propeller Assembler (PASM) under Spin or C. C isn't really designed to have assembly in the same file (hence the ugly quoted __asm stuff, and the even worse hacks required to get GCC to support the Propeller), but Spin/PASM was designed from the beginning to support PASM. This is all you need to get started with PASM:
CON ' oscillator config _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 PUB start_pasm coginit(cogid, @entry, 0) ' restart current cog with PASM program @entry DAT ' assembly begins here org 0 entry jmp $ ' dummy program: infinite loopDon't use more than one cog until you're ready for it. Get as far as you can without doing things that need interrupts - this is probably a lot more than you think. When you finally reach the point where you do need interrupts, start a second cog to deal with what you would otherwise use an interrupt for. If you organize cog usage well, you won't have any problems with multiple cogs contending over the same resources - I almost never use locks. Until you learn how to organize cog usage to avoid locks, you can just use locks.
All good ideas.Thank you.
Mike Green and Electrodude's were most on the mark.Just going by the way I look at it.
Jon had a good take on Parallax and no more SX for them.
'Candy coated' meant you can't get at the registers.Maybe I haven't gotten that far yet.
Also it has a lot of commands. That reminds me of CCS PIC C Compiler with loads of extra commands. Commands/Macros?
Once I get a SX Blitz or Key I will probably use SX and not like it.
Just want to do it the 'Stupid Way' and move on.
After reading so many of your posts, and I am sure you will get along with it perfectly. I actually think you will become a great advocate of its design structure and simple to program features in weeks, if not days.
True, it has more horsepower than you need / want right now with the multiple cogs, but it doesn't penalize you for having that extra processing muscle in any way. You don't have to use them until you need one, otherwise they are "invisible".
You can program the Propeller so many ways, from dirt simple Blockly to Spin, to C in the IDE, etc., that one of them is bound to be your favorite before long! A guy like you could try them all and see what you like best, never know, it might surprise you!
Just had an idea to take all of the risk out of it for you, please check your PM. :cool:
Here's a real-world, beyond-the-theory code snippet that I wrote a couple weeks ago when stuck in a hotel without an oscilloscope. I needed to test my the actual pulse output time with versus the theory. This PASM segment does that and reports the pulse width to the hub. The difference between theory and empirical value was the overhead that my new driver now accounts for, giving better performance on systems with marginal output (this was for WS28xx pixels).
When starting a PASM cog you get to pass one long that is available to the cog in a register called par. The typical use of par is to define a starting point in the hub for a group of variables used by the cog, which may be shared by other cogs. In my little test program I pass the hub address of the variable I want to check and display. Note in the code that I am reading the phsa register from the local cog (result into t1), and then writing that to hub using the address in par. (There is a subtle issue here: the physical phsa register cannot be read from the destination field of the wrxxxx instructions, hence the use of t1.)
Once you actually start using the Propeller you may find -- as many of us do -- having multiple cogs is fantastic for testing and debugging. Again, I was on the road without a 'scope. No problem, I had spare cogs. In very short order I was able to test and refine my pixel driver.
dat org 0 entry rdlong ptix, par ' read adjusted pulse ticks mov dira, PIN_MASK ' make pin output mov ctra, POS_DETECT ' measure positive pulse or ctra, #15 ' use P15 mov frqa, #1 again mov phsa, #0 ' clear result pulse_out mov t1, ptix ' set pulse timing (ticks) or outa, PIN_MASK ' pin high add t1, cnt ' sync with system counter waitcnt t1, #0 ' hold andn outa, PIN_MASK ' pin low nop mov t1, phsa ' capture timing wrlong t1, par ' write to hub mov t1, QTR_SEC ' hold 250ms add t1, cnt waitcnt t1, #0 jmp #again ' ------------------------------------------------------------------------------------------------- PIN_MASK long 1 << 15 ' test pin P15 POS_DETECT long %01000 << 26 ' time high-going pulse QTR_SEC long CLK_FREQ >> 2 ' 250ms ptix res 1 t1 res 1 fit 496'Isn't the SX very PIC like? Why not just learn one of the smaller PIC chips since they are still in production? '
Just did not do well with it.
Okay. Prop it is.
Keep in mind I putter.
So get used to the snails pace.
It will be Spin and the PEKit.
That is what my co-conspirator (a relative) likes.
'Also, you don't have to find a place to buy the expensive SX-Key.'
Nope. Still want one.Don't panic.
We are committed to Prop.
Thanks for the help!