Another dumb Spin question?
cavelamb Posts: 720
Been away from the Propellers for a while and trying to get my head straight.
Or properly twisted?
Multi-bit (range) I/O syntax
outa [23..16] := $00
IS there any clever way to take the magic numbers out of that statement?
OTHER than something like this???
Byte LED1, LED8
LED8 := 23
LED1 := 16
outa [LED8..LED1] := LED
I would suggest that you make your MSB and LSB values of the range constants, since those connections will not move during the operation of the program
To keep your code tidy you may want to write function like this:
I still like the ~~ notation:
Saves having to count 1's.
I've been trying to make that work as a constant for mumble something hours now.
I kept getting an error message (expected ":")
But since YOU said it, it now works.
That's some heavy juju you got there, JonnyMac.
I do not know what my problem was, but it works now, so back to work.
Thank you, Jon.
Yeah, that too!
Reading that old first-cut robot code from a few years ago...
Makes me wonder -
Who wrote this mess???
(high squeeky voice) "Nevermind"
I prefer the raw bits because it's verbose and is faster than ~~. If I don't want to be bothered counting bit I use -1, but this is rarely the case.
true(which evals to -1) could be argued is better or more "idiomatic". Using -1 instead of the actual bit mask will also save 1 byte of code (-1 constant is single byte code, bitmask constant is 2 bytes).
Also note that in flexspin, there's no codegen difference between a -1/0 assignment and a freestanding postset operator.
Indeed. Good point. Thank you.
all is -1.
If Shakespeare said it, it must be -1.
My ignorance is showing, but what is flexspin?
Flexspin is a compiler than understands Spin1, Spin2, C, and BASIC. I don't use it much (except for testing), but it has become quite popular with many forum members.
You can download from here:
And combinations thereof
Well, until then?
My project is a small table-top robot that I'd like to NOT fall off the table.
Robots don't bounce very well.
This is a kind of cleaned-up version of where I left it a couple of years ago.
It's baby-talk level Spin. I get that. I'm back to trying to learn...
Lab .01 code to exercise the circuitry and machinery to see if anything works right.
There are some fun things I'd like to try, but I don't know how to say it in Spin yet.
Like PWM control of the drive motors.
Like Bluetooth comms instead of the TV remote.
Like Line-following, mapping, tracking, etc?
But I gotta get Spun up first...
In this episode the big thing I'm tripped up over...
Printing text to the LCD display.
Printing "literals" is obviously no problem.
The Serial-LCD driver handles that nicely.
But sending a string variable?
I haven't quite got a handle on that one yet.
Pointer to a variable array, but not sure how to stuff the array.
Or get it shipped over to the LCD display.
In the code...
What I'd like to do...
Probably something like...
All files are in the zip.
I couldn't get the main program to format here...
Thank you for the Flexprop link, Jon.
had troubles formatting code!
I've attached a dual PWM driver that I've used in pan/tilt controllers for video cameras. You might need to make changes for your driver chip, but the code will show you how to run fixed-frequency. variable duty-cycle PWM in a secondary Spin cog. This code uses the cog counter to generate pulse outputs. It works well.
You can do this with a serial input. I've attached a big project (that has other goodies you may find useful); this was a mini "Stranger Things" wall that could accept commands and spell out other words using a string of WS2811 Christmas bulbs. Note that his project was coded for a P1-powered HC-8 controller from EFX-TEK (I designed it for them). I used an HC-06 Bluetooth (BT4) module.
There are no such things as string variables in Spin. As in C, a string is an array of characters terminated with 0 (null). You can build a string inline with the string() function, but if that string will be used more than once or needs to be referenced in code, it's best to define it in a DAT section. The Stranger Things example. For methods that require strings, you'll pass a pointer to that string. @ provides the run-time address of an object; we use this with specified strings.
I've already been studying the dual_motor_ez code.
Nice piece. Works well.
But I had some problems with it too.
Not with your code.
With my little toy motors.
I'm using the Tamiya double motor gearbox.
They use a pair of cheapie permanent magnet motors.
I tried characterizing a couple of them and found out that they don't run at the same speeds.
And the difference is different at different speeds.
Which makes going straight a problem!
The robot only needs four speeds to run well.
Stop, ahead 1/4, 1/2, 3/4, and flank (in naval terms)
That translates pretty close to 1,2,3, and 4 inches per second.
Table tops are not unlimited space!
And I want to use masking tape to draw off mazes.
I characterized each motors to see what it takes in the way of PWM ticks to achieve a given RPM.
Put those numbers in a dual array (left and right) and see if it can go straight.
Turn Rates, I think, would be controlled by a different paradigm - mule train.
Gee little bit, Haw little bit = increase outside motor speed or decrease inside motor speed.
For line following or edge following.
I know you guys have done a ton of work on small robot projects.
I should probably sit down and read through it.
Just opened Pandora's box of Stranger Things.
It may take a while!
I gotta get better at shifting...
That scan_ttl_ins for reading a 74165...
Speed shifting a 16 speed gearbox!
What did you use to **send **Bluetooth.
Not on the wall end, but the user end?
A phone would be ideal, but that would mean writing a phone app too?
Gee-yup(or hup): Hard right.
Haw-yup (or hup): Hard left.
Geep (jipp): Onward/faster.
Hald: stand still, head down (if human near).
On: pull fwd until there is no slack and stop.
Givit: pick foot up (pick feet)
Nawp: no/quit whatever you are doing/wrong/listen to me
Hawz (or Hawz-up): Rest after backing up a step to unload team from pulling the plow/wagon pull (unloaded rest position)
Whoops: Spilled my beer (ok, I made that one up)
We draft horse owners call these the “12 Commandments” of draft horse management. Just sayin’
That code is unrolled so that it can run as fast as possible (no loop overhead). It's running in a background cog that has a 1ms loop which is convenient for timing. I also do red-green color mixing for a 2-lead R/G LED which gives me off, red, green, and yellow, with solid and blinking states. Turns out you can do quite a lot of work in 1ms in an 80MHz P1.
No, you can use a simple terminal app since the input to the program is just text (which makes it easy to test through the PST window, too). This code lets me select how the program is going to take input. Once the command parser is tested and running through PST, I switch to BT. Easy-peasy.
For the trade show where that display was setup I wrote a little Android app for EFX-TEK using MIT App Inventor. It's kind of clunky (it's a "blocks" environment), but it's a tool that works and is free. My understanding is that it now supports iPhones so I may look at it again having moved from Android to iPhone late last year.
That navigation module is going to be a LOT more interesting now.
The day that I first used the Prop (late 2011), I also had a Bluetooth module and I immediately wanted to communicate with my Android phone and so I tried this:
One of the sample programs is for Bluetooth. I had the phone talking to the Prop in minutes
I selected the Android platform as the HMI for my machine control systems. I now have them all over the place in some pretty grimy environments. This has proven to be a great way to go
Yeah. I've played with RFO BASIC a bit.
Wrote a Retro Dialer.
I'll have to go back and look a that again.
Sure enough, they exist on Google Play. Just installed one and it's cool as heck
Okay, next dumb question please?
In the following I have commented where the difficulty lives.
Using IR remote control - the program needs to check for user input to turn the Power variable
on or off.
If Power is off, do not parse the remaining cases.
So, how to structure that - without the ugly mess in the listing -
i.e. having to test for Power on in each case?
It seems interrupting the Case structure is not allowed?
I fixed that problem right after posting the above...
Gilda Radner voice - "Nevermind"...
Just curious... Why are you restarting the ir code in a loop?
Shoudn't you just use something like:
to get the most recent IR code? Seems odd to create a new cog in each loop of your main code. Am I missing something?
You are missing the Sony IR driver that Tom Doyle wrote.
It's written to be restarted that way.
There is a "continuous" version somewhere.
But I haven't used it.