Professional DEV board. SxKey COM port error? newbie
elliott
Posts: 14
Hello-
I get an error message that states that the SXkey could not be found on the COM port 1 when I run a program. I have tried comport 2 as well.
I'm trying to run a program for the first time. I'm using the Professional development board.
I get an error message that states that the SXkey could not be found on the COM port 1 when I run a program. I have tried comport 2 as well.
I'm trying to run a program for the first time. I'm using the Professional development board.
-
I'm using the Professional development board.
- I have the sxKey plugged into the cable and the com port 1
- I have the sxKey plugged into the Board with the vss, vdd markings corectly aligned.
- I have the power on (bluw LEDs by both the power switch and the pulse area.
- I have the correct port selected in the software "device" dialog.
WHAT GIVES??? any help would be greatly appreciated... (this is the firstthing that I have done with stamps)
Comments
pda's ,cell phones, ect
The will usually hog the comm port and you will have to stop their program in order to let another program use the comm port
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
DTQ
You cannot program the SX chips from the serial connector on the PDB.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
·
yes I have the SXkey. After a long discussion with tech support (VERY HELPFUL). we determined that it was not the com port or the SXKEY.
HERE's the story. I'm trying to do the MIDI Receiver that is the Nuts and volts Project[noparse]:http:[/noparse]//www.parallax.com/dl/docs/cols/nv/vol6/col/nv122.pdf
and I'm using the professional development board. I've prototyped the circuit on the board. THE PROBLEM IS whenver I jumper(power up) the circuit that is on the bread board, the blue power led dims by about 10%. Tech support said this indicates that somewhere in my circuit I'm drawing too much current. THIS DOESN'T sound right. THE ALTERATION that I've made to the project is to simply use the DIP switches that are already on the Professional DEV board. I've gone back over my circuit 3 times with the schematic...
any words of wisdom?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
The way you solve these problems is to strip the problem down and eliminate variables. I'm referring here to physical variables, not the software variety.
If you really want to know whether or not your breadboarded circuit is causing the problem, then you need to remove ALL power and ground connections to your circuit (not the dev board or SxKey) and then try running the SXKey. Really, the best way to start is to pull all the components off the board and just see what happens when you run the SX chip and the SxKey. You don't need the MIDI circuitry to program the SX chip and see if it will enter debug mode. After you know that the board and the key are working, you need to start adding components (or power connections) back one at a time until the key no longer communicates with the board.
The key here is that you're starting from an assumption that the breadboarded circuit you built by hand is less likely to fail than the PCB and the SXKey from Parallax which are used across the world by tens of thousands of users. Here's what you said in one of your posts:
THIS DOESN'T sound right. THE ALTERATION that I've made to the project is to simply use the DIP switches that are already on the Professional DEV board. I've gone back over my circuit 3 times with the schematic...
Given that you have the physical evidence (the LED dims when you apply power to your circuit), you need to start assuming that the problem lies with your circuit instead of the opposite. There are few bigger roadblocks to problem solving than starting with the assumption that your work must be correct. Guenther Daubach just related a story the other day where he made a circuit and forget to pull MCLR on the SX chip up. He went round and round trying to figure out what was wrong until he discovered his simple mistake. I once spent 30 minutes trying to fix a circuit that went dead only to discover that a power cable had slipped and the "bad signal" I was getting on my oscilloscope was simply noise being picked up by the unpowered circuit.
So, approach this methodically. Take all the power/ground connections off the board (or better yet, all the components) and test the SxKey to Sx chip communications. Once you know that works, start adding power/ground back one at a time (or component sections) and test at each step. Eventually you'll find the power hog and have a great insight into problem solving, or you'l get everything hooked back up without errors and the circuit will just work. Either way you'll have a working circuit.
Thanks, PeterM
no (sorry) I absolutely assume that my work is the problem. I have very little experience with electronics. AND I HAVE BEEN really impressed with tech support at Parallax.
My work is definitely the problem. apologies If i offended anyone
No, not offended at all. I was just trying to help steer you into a solid path of bug fixing and trouble shooting based on what you wrote in your posts - I guess I misunderstood your intent.
So, have you taken my advice, pulled all the power and ground connections to your circuit, and started bringing them back one at a time while testing? If you do, it won't take long to find where the problem lies.
hanks, PeterM
What power supply are you using?
I ask this because I has a simliar problem with the PDB and SX-key, and it turned out to be a power supply problem. The PDB needs a higher input voltage than the SX-Tech board. I was using a 7.5 V supply, which worked fine with Stamps, but the SX-key would not work. Now I am using a 12 V supply (as recommend by Parallax).
William
Post Edited (William) : 8/17/2005 8:30:50 PM GMT
I did a lot of breadboarding when preparing the application sample chapters for my book. Due to the new professional development board, I tend to do even more breadboarding than before, because it is so much fun with such an ample breadboarding area, and many useful components on board, just a wire jumper away - THANK YOU, Parallax"!
When starting a new SX project, you should first just insert the SX28, hook up the SX-Key, and see if you can send the basic part of your planned application to the SX, and test if you can debug it, for example, the code to clear the RAM and to initialize the port configuration registers.
When this works, you can add more components (in hardware on the breadboard, and in software to the application). For example, you could attach components to the planned SX output lines, like LEDs, Relays, etc. Even if your code does not yet contain the logic to control such components, you can use the debugger, set a breakpoint on some instruction following the initialization. Clicking on the bits in the port register's binary representation, you can toggle the output lines to verify if the connected components are driven by the output lines as expected.
Next, you can do the same with the input lines, i.e. connect them to pushbuttons, DIP switches, or any other components driving SX inputs. Again, you can run the basic program to a breakpoint located at some meaningful location, and then actuate the input components, watching if the associated port bits are changing as expected.
When you have mastered this, you can be pretty sure that the hardware part of your project is free of bugs. Next, you will have to dive into the "mysterious adventure" of adding more and more components to your software part of the project. I can promise you - the probability to run into errors here, is much higher than before when you have set up the hardware. Nevertheless, you should be able to master this part as well. Again, think of modules, or components. Don't try to enter code for the complete project at once. Add routines to handle certain tasks first, and - if necessary - write a "wrapper" (to be removed again later) in your main program to call and test these routines.
Design the software part of your project as modular as possible. It is better to spend some more instruction words and execution cycles for subroutine calls and returns (with the right pages selected before), even if a soubroutine might be called only once in a program than trying to write "tricky" code in the beginning. You may optimize your code later, when it turns out that this is really required to reduce code size, or to gain execution speed. If this is not the case, just don't do it - this keeps your code well-structured making it a lot easier to add enhancements later when neccessary.
Following these rules, you (and not only you
BTW: Two bugs meet in a program. Says the first one: "My programmer is trying to fix me since a week!" Says the other one: "Well, my programmer does not even know about me".
Bugfree programming!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I found one problem. I had assumed that the pin layout on my Optoisolator was 1 through 8 top to bottom. looking at the data sheet , it's 1 through 8 clockwise!!! DOOOOOOHHHHH..