programming in spin
capnruss
Posts: 17
in Propeller 1
The new nuts volts mag, April issue 2017.. There is an article on a garage or parking sentinel using the Propeller Project Board USB. Now, I'm totally new the propeller world but I did get the program to compile but when I tried to run it nothing happened. I looked at the the signal pin on the 3 terminal ultrasonic unit and there are no pulses. Looking at the compiled program I noticed that the I2C portion of the code is red and pink. The I2C title is red and everything below it is pink. I don't know if that is normal or not. the rest of the code is blue. Is that where the problem is? If so how do I fix the problem? if not, what could it be?
Comments
Thanks for the quick response
I notice in the article the author said he powered the Ping with 3.3V. I don't think the Ping is reliable at 3.3V.
I suggest powering the Ping with 5V and use a 4.7k ohm resistor in series on the signal line.
There are other things you can do test each component but I suggest trying the above with the Ping sensor.
The colors of the sections of code you described are normal.
A 2k resistor is out of specs for the Propeller. The current on an input pin needs to be limited to 500uA. This requires about are resistor value of at least 3k. You don't want to use too high of a value or the Ping might now see the 3.3V signal. I've used 4.7k myself many times.
You 2k resistor will probably be okay but you're putting the I/O pin at risk.
My standard procedure of debugging a program is to add debug statements.
I haven't tested the code below but hopefully it will give you a clue of what the program is doing.
I left out the "Calmode" method for now.
Give the code below a try and let us know what you see in the terminal window. The program requires input from the terminal to start so it won't work without being connected to a computer.
I couldn't find a Ping handy, else I would have created a new version of this project using my objects.
I'll post it in a few minutes.
The I/O pins controlling the lights can now be on any I/O pins. They don't need to be next to each other as they were in the original program.
I used inches as the unit of distance since you mentioned feet in an earlier post.
To change the thresholds of when the various lights will turn on and off you just need to edit these constants.
As the code is now, it has four distance zones. It wouldn't be hard to add a fifth zone had have the amber light blink as one of the zones.
I haven't tested this code. If it doesn't work as expected, let me know and I'll dig out a PING sensor and test it myself.
Does the distance display correctly?
Does it repeatedly output "Too close!"?
I figured there was a good chance I did something wrong but once in a while I get lucky with an untested program.
I'll wire up a sensor and try the program myself.
The code below works for me.
Make sure and change the distance values to fit your need.
Many of my programs run a generic background cog; I use this to keep a running timer and process specialty IO so that the foreground doesn't have to be bothered. In some of my Escape Room apps, I even have a monotonic music player that can play notes and simple musical runs while the foreground code happily does its thing.
If I were building this project I would monitor the Ping in a background cog so the foreground simple had a value to deal with. In this case, the value is distance to target in microseconds which is easily converted to cm or inches.
This also shows how to measure a pulse with a counter module so that you don't get trapped by waitpeq/waitpne if there is a sensor problem. The counter is put into POS Detect mode which counts the number of ticks the input line is high. Note that the Ping measurement is broken into discrete states so that it can be folded into the background process. At the moment, there is just the timer and the Ping, but you can do other things.
Here's the background code -- very typical of many of my projects.
www.jonmcphalen.com