Newbie goes from BS2 to SX
Ugha
Posts: 543
Hi all,
I recently was given an SX kit and I have found that I'm quite addicted to the power the SX chips have
over the BS2... but I've hit a wall.
I'm attempting to convert a BS2 program (to receive a simple RF signal using a cheap receiver) to SX/B
and I'm having absolutely no luck at all.
I must be missing some simple concept of SX/B or the SX chip so I'd appreciate any enlightenment
you could offer.
I've attached both the original source code and my attempt at translating it for SX/B.
Thanks in advance for any advice you can share.
I recently was given an SX kit and I have found that I'm quite addicted to the power the SX chips have
over the BS2... but I've hit a wall.
I'm attempting to convert a BS2 program (to receive a simple RF signal using a cheap receiver) to SX/B
and I'm having absolutely no luck at all.
I must be missing some simple concept of SX/B or the SX chip so I'd appreciate any enlightenment
you could offer.
I've attached both the original source code and my attempt at translating it for SX/B.
Thanks in advance for any advice you can share.
Comments
First, the Start and Main labels are more strict in their use with SX/B -- "Start" is run once upon reset -- there is other code as part of "Start" generated by SX/B that sets up the registers of the SX.
Second, it might help to define pins as outputs, inputs, etc. I don't have my SX/B manual in front of me, so I can't remember if HIGH and LOW will make a pin an output (like on the Stamp) then set the state of the pin. In general on the SX I would take "more control".
Third, if you are running this without the SX-Key generated clock, and you are NOT using a resonator, I do not think the internal RC clock of the SX will be stable enough for serial comm, even at 2400.
Fourth, in theory your program could wait at SERIN *forever* until any byte comes. What is sending to your SX?
Lastly, you might want a longer pause after the receipt of the byte before the LEDs turn off to make sure you can see what's going on...
DEVICE SX28, OSC4MHZ, TURBO, STACKX, OPTIONX ' change OSC4MHZ to use an external resonator/crystal FREQ 4_000_000 led pin ra.0 OUTPUT ' LED pin led2 pin ra.2 OUTPUT ' No signal LED receive pin ra.1 INPUT ' Receiver Pin baud con "T2400" ' 2400 baud, non-inverted... What's True? string var byte ' variable to store received data PROGRAM Start Start: ' upon reset Main: ' main program low led ' Reset LED low led2 ' Reset LED2 pause 200 ' Delay LED off states string = "B" ' Set string to something other than A serin receive, baud, string ' Get data if string = "A" then ' Check if string is A HIGH led ' Turn the LED on else high led2 ' If no data, then blink the no signal LED endif pause 1000 ' Wait a bit goto Main ' Loop▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Post Edited (Zoot) : 4/16/2008 1:37:26 AM GMT
Baud Modes T (true), N (inverted), OT (open, true), ON (open, inverted)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
I too am not at my computer (and won't be til tomorrow) so I can't test your modified version of my code... but I do have a couple questions about what you said.
First... According to the SX-Key software helpfile, High and Low automatically set a pin as output.
I don't fully understand the clocks and how they work. I know I should most likely try to learn more about them before I work on something like this but I learn better when I'm actually working on a project.
Can you explain what you meant about the SX clock and being able to hit 2400 baud?
As far as Serin waiting forever, that's fine. The project is very simple. Wait til an A is received serially from a RF receiver (From sparkfun, it's a really cheap and simple RF receiver/transmitter pair that I've used in many BS2 projects in the past) then light up an LED. I just put in the second LED as part of a debugging process cause I couldn't figure out what the heck was wrong.
Do you have any more suggestions? I'd appreciate anything you can offer.
The SX can run off of an external clock source attached to OSC1 and OSC2. There are a variety of components for clocks, the easiest to use being the resonators sold by Parallax.
Now, with an SX-Key connected, the Key itself can be the clock source (pull your resonator/crystal/oscillator when doing this).
The "internal" 4MHZ clock is dandy for a lower component count and for applications that don't need higher speeds BUT (and this is a big but) the ACCURACY of the internal clock is not that great (I believe around +/- 8%, but Bean can probably correct me on this). For many applications this not necessarily a problem, but for any truly time-sensitive operations (like serial communication) it may not provide accurate enough clocking.
Short version for your code -- EITHER use an external resonator (say 20MHZ) and change your freq directives accordingly, OR use the SX-Key generated clock (in other words, leave the Key connected when running your app). It's not so much a questions of SPEED (see the SX/B file for allowable bauds at different clock frequencies) as much as the accuracy of the clock -- if the clock is off a bit there is no way that commands like SERIN/SEROUT will catch bit states at the right time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Asynchronous serial communications (what you're using with SEROUT ans SERIN) requires an accurate clock source, and the internal clock is not that accurate. Using an external clock (e.g., a resonator) will allow serial comms to work properly, which will allow you to connect your SX to other devices with a serial link.
I updated your program in my (anal retentive) programming style using a template, like the one in the help file -- you might find it useful. I created a function for SERIN that has a 250 ms timeout, so you should be able to get the LED to blink. Don't be worried that the subroutines/functions look a little complicated; they're really not -- it's just that SX/B is closer to assembly than PBASIC is. The upside is that they're re-usable and will ultimately save you programming code space and time.
I had heard that the Key's clock was a little flakey, but I thought it would be enough for Serin cause its supposed to be async.
I'll toy with the two resonators that came with my SX tech tool kit. Besides unplugging them before hooking the key up,
is there anything I should be aware of when using them? If I can even see them... the numbers on these things are so
small its almost impossible to read them.
Which would be better for serial communication at 2400... the 4Mhz or the 50Mhz? Is there any harm in having the clock
too fast?
And my question about True on serial communication is because I've never heard of the terms True and Open... Inverted
and non-inverted I get but not True and Open.
> I think they are having some production problems with the next-gen of Keys but I have never had problems with SX-Key generated clock source (well, to clarify -- make sure your header pins are clean and your wiring relatively short so that debugging can happen while the clock is being generated).
I'll toy with the two resonators that came with my SX tech tool kit. Besides unplugging them before hooking the key up,
is there anything I should be aware of when using them? If I can even see them... the numbers on these things are so
small its almost impossible to read them.
> Nope. Although you can PROGRAM a chip with resonator installed; but you won't be able to use SX-Key as clock source nor debug with resonator installed. In the interest of debugging your program, you could just yank the resonator and use the Key -- this will let you experiment with different freq. settings without swapping resonators. Plus being able to debug.
Which would be better for serial communication at 2400... the 4Mhz or the 50Mhz? Is there any harm in having the clock
too fast?
> You should be able to use either. See the SX/B docs for maximum serial rates at different frequencies. The only "problem" -- or feature -- with using faster clocks is that a) your settings and any external components must be correct so the resonator starts up, and b) the faster the chip is clocked the more power-hungery it is. See the SX data sheet, but the amount of extra current consumption between 4MHZ and 50MHZ is not insignificant.
And my question about True on serial communication is because I've never heard of the terms True and Open... Inverted
and non-inverted I get but not True and Open.
> true = non-inverted (i.e. 1 = high = yes = true)
> open = serial line is "pulled" high and driven low. In other words, any device that uses the serial line "releases" it to let it get pulled high (usually by making the serial pin an input) and drives it low. This allows multiple devices to share the same serial line without risk of short-circuit (if one device drives the line high while another drives it low, smoke ensues).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
I tried your version of the program using a 4mhz res with little result... at least the no-signal LED flashes now.
I changed the OSC4MHZ to OSCXT2.
JonnyMac: I attempted your program too, again, with a 4Mhz res with no luck. The no-signal LED doesn't even flash.
I tripple checked my wiring and again hooked it up exactly the same to a BS2 on a BOE with the previously attached program
and it works fine.
The only thing I haven't mentioned so far is that I am running the SX tech board off 4 AAs... although I strongly doubt that
matters.
Anyone have any ideas?
I'm attaching the program I use on a second BOE to generate the RF signal that I'm trying to get the SX to receive... just in
case the problem might be there.
In any case:
- if using external 4mhz resonator, is Key disconnected when you test?
- if using Key for clock with resonator removed, you may need more than 4AA -- the key uses a bit of juice, esp if it's programming/debugging/generated clock
It also sounds like your bs2 program works to receive the serial byte? What device is sending the byte?
[noparse][[/noparse]edit] -- whoops you're using a Stamp and you posted the code. Hold on a minute...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
I can't test it with a wall wart because I don't have a regulated one handy... since the SX tech board has a voltage regulator
built-in, will an unregulated wall wart cause problems?
The RF pair I'm using is available here:
http://www.sparkfun.com/commerce/product_info.php?products_id=7813
I just tested my version of the program on a PDB using HyperTerminal as the input and it works fine; one LED blinks with no input, the other comes on (briefly) when the correct letter is received.
What I did do, though, is add an extra delay after receiving the "A" character so that I could more easily differentiate between the LEDs.
IF cmd = "A" THEN Led1 = IsOn DELAY_MS 1000 ELSE Led2 = IsOn ENDIFKeep in mind that when using SERIN the serial data isn't buffered, so if your character comes in the middle of a delay it will be lost. You can write code to buffer serial, but it's advanced and you may not be ready for that now.
In this program the serial data is buffered, and each time an "a" or "A" is received the Led1 output is turned on and a timer [noparse][[/noparse]re]set to one second. Note that if the one-second timer is about half-way done and you send another "a" the timer will be reset to one second; if you want to stack the output such that the LED stays on for one second for every "a" or "A" received you'll need to adjust the code.
If you call RX_BYTE when there is nothing in the serial buffer it will "block" just like SERIN, so be careful with this; the reason for the rxReady flag is to let you know if something is there or not.
> Don't be so sure... I'm just naming things that could be suspect. I also would look to JonnyMac's comments -- given possible pauses between TX and RX from each device, it might be possible that a full byte is never sent while the SX is ready -- but since you don't have a long pause in the TX loop, I would think eventually it would send a byte while the RX is ready. I use both single-byte and the multi-byte buffered version of Jon's ISR serial code myself -- but that can look more complex than it is. As Jonny mentioned SERIN *waits* for the start bit of a byte (and could wait forever, hanging the program); the ISR version just receives the byte whenever it comes and stores it until the main program loop goes and checks to see if anything came in. In any case, it still seems like your setup should work, barring wiring/flashing/clock errors. If you keep having problems with this code, you could think about doing a small test/debug program that counts out milliseconds in a debug WATCH window -- that would at least tell you if you are downloading/running/clocking/debugging correctly with the SX-Key (if your clock speed is screwy you won't get an accurate count after a large number of milliseconds, and if the Key isn't communicating properly and you have bad power you prob. won't get debug info).
I can't test it with a wall wart because I don't have a regulated one handy... since the SX tech board has a voltage regulator
built-in, will an unregulated wall wart cause problems?
> Check what it's rated for .. if <= 9v you will prob. be OK. Remember that an unreg. wall wart will deliver much more voltage when NOT under load, i.e., if you check a 9v wall wart with a voltmeter you may see 12-15v as the meter is not (supposed to be) a load per se. Make sure the power plug is center positive. Plug the wall wart in and if power comes on, check the voltage out of the regulator on the board (measure Vdd) and check to see if the regulator is getting hot. The regulator on the Parallax boards is pretty tough -- just pull the power ASAP if *anything* seems amiss. Never hurts to disconnect power from your circuitry and pull the SX to keep 'em safe when you try it out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Mostly anyways... It seems there was some kind of problem with the power supply.
I hooked up an unregulated wall wart and tweaked the program a little, and it works perfectly.
I've uploaded the new program... its basicly the same thing as before cept the LEDs stay on
instead of blink.
I've got another puzzle...
I sometimes get false positives when using the 4 AA battery pack, but no false positives with the
unregulated wall wart.
The wall wart has a much longer wire than the battery pack, so I don't think its acting like an
antenna... so I'm stumped.
I also, very, very rarely, get false negatives. I'm assuming this is due to either the slow speed of the BS2
transmitting the signal or the low clock on the SX receiving it, or a combo of both.
I plan to eventually use SX chips to both send and receive, so the BS2 isn't as much of an issue, and I
can tweak it with different speed settings to see if I can get them to work properly.
Now that this task is over... my next step is figuring out how to run everything off a 12 volt tractor battery.
Anyone want to hold my hand and guide me through that? [noparse];)[/noparse]
Thanks to everyone who helped,
- Ugha
the answer).
I have a couple newbie questions about the mods you made...
First, I haven't had a chance to try it out... I'm not at that computer so please excuse my lack of insight on that front.
It seems that the program will only detect the signal once... then be stuck "on" until reset. Am I reading this right?
My second question is... at the moment I'm using a BS2 on a BOE to broadcast the signal. I didn't see anything that said if
the signal its broadcasting is idle high (true) or idle low. Do you happen to know which it is?
Or does True refer to the undetected (no signal at all) state?
Sorry for the stupid newbie questions and thanks for all the help guys.
A hint: the transmitter's baudmode.