I have 5 more prop chips on their way along with some eeproms, but I don't have an extra prop board since I only bought it to test to see if I could move the product from the SX to the Prop. Now that I am trying to go open source, I want to go bigger and better so I can have something to release that is better than the competition. With the power of the Prop, I am sure I can get there! I think I will use the board as a test board for now and when the chips come in, I can remove the chip on the prop board and replace it.
Can I run the 2x16 display without having perfect timing? I want to try and get the RPM signal working the best I can so when I can at least test it. I do have a 555 timer set up to replicate the engine RPM signal which works from 100 to 14,300 RPM. That is what I use for bench testing. Since I don't really understand how Johnny's code works, could someone help me understand how to call it properly and be able to pick up the RPM signal? I would like to have it run on it's own COG if at all possible. Does the command "cognew" call a function or object or does it just run 1 line of code? I don't quite understand the whole cog thing yet. I am an expert PHP programmer and I relate a lot of the code to how the spin code is written.
Out of curiosity, do heatsinks normally come with screws with them? I can't seem to find any information on it.
EDIT : I did not see anything on screws coming with them so I ordered some the same size as what is on the SX proto board Only $3 more for 100 screws and nuts... Can't lose there.
Typically I have only seen insulators supplied with parts such as those that you would get with an NTE that you have crossed from some original part. A little value added for the (primary market for NTE) electronic servicers. Sometimes when a Flame Emiting Transistor or Power bipolar has melted down in the Horizontal drive of a large older TV these things get damaged (fried), but not likely to have any issues with screws etc. So I have never seen screws in the kits, only mica insulators and plastic(?) donut insulators to isolate the tab from the mounting hardware.
Come to find out, the prop board is still ok. I just wrote a sample program to it and it is blinking the display like it should Now I have to figure out why it is not working anymore with my code. I am using the same code posted earlier. I don't think I made any changes to it before I locked it up over a year ago
Your heat problem may have come from the draw of the backlight for the LCD display. I used a 2*40 Hitatchi clone display, but check the jumpers on yours if they exist as they are used on some for enable of the backlight and / or control of same. Could be a jumper in place along with another one or an uncut configuration trace creating a short on the 5V reg circuit. The current rating of the backlight just may be enough to push a 7805 into a warmer place w/o the heatsink as the 1A max assumes heatsink is used.
Ok, i think I figured out what is going on... I nulled out the XIN and the CLKMODE lines and it started working. Could I have burnt out the crystal on the board?
Scope the pins and look to see if any osc present; should be around 3V or so and looking like a 5MHz sine wave at either crystal pin.
Maybe I am missing something.... The Prop development board has a 5Mhz crystal on it already. Is it connected to the Prop without having to solder anything?
Most are using machined pin sockets so that you can use different crystals. mainly 5.0 MHz and the 6.25 MHz values for 80MHz and 100 MHz respectively.
I have 5 more prop chips on their way along with some eeproms, but I don't have an extra prop board since I only bought it to test to see if I could move the product from the SX to the Prop. Now that I am trying to go open source, I want to go bigger and better so I can have something to release that is better than the competition. With the power of the Prop, I am sure I can get there! I think I will use the board as a test board for now and when the chips come in, I can remove the chip on the prop board and replace it.
Can I run the 2x16 display without having perfect timing? I want to try and get the RPM signal working the best I can so when I can at least test it. I do have a 555 timer set up to replicate the engine RPM signal which works from 100 to 14,300 RPM. That is what I use for bench testing. Since I don't really understand how Johnny's code works, could someone help me understand how to call it properly and be able to pick up the RPM signal? I would like to have it run on it's own COG if at all possible. Does the command "cognew" call a function or object or does it just run 1 line of code? I don't quite understand the whole cog thing yet. I am an expert PHP programmer and I relate a lot of the code to how the spin code is written.
I was fairly sloppy in my Hitatchi object and it did fine. Pick a refresh rate that will allow the user to see the display without it blurring all over the place with too many updates to se any values in the more rapidly changing digits. I like the 555 idea for testing 'cause it is easily replaced with a Hall ckt or similar for actual shaft rotations unless you are pulling a buffered pulse off the ignition ckt primary side and counting pulses there.
As for Johnny's code, go back through it and see if he put a driver/example of how to use the code. Most of the objects include at least one example of how to use the objects.
Now as to bigger and better. Good for goals, future plans etc. but don't let feature creep screw you up. Get a section at a time up and running of the base product and thoroughly unit test it. Once it all works at the base level, abuse it in the most creative ways you can think of because your users will certainly do so, generally in ways you can't even imagine. Then you can start adding the "extras" one at a time unit and integration testing all over again so that when a new feature crashes it (and it will, murphy was an engineer for sure) you will have a fallback to try again without trying to see which interaction among multiple changes actually caused the problems.
Yep, one thing at a time for sure. Right now, I am trying to get the LCD working with the Prop. It works fine with the SX, but I cannot get it to work with the Prop. Will it work with the internal clock?
EDIT : I got the display to show strange characters at 2400, but anything over that, the code hangs at the lcd.init(15, 9600, 2) I guess I will have to wait till I get the other chips
I have tried several different pins to see if I could get the display to act differently, but still nothing Guess I have to wait for the new chips. Does anyone have the ability to test the above code to see if it works for you?
I am planning on running the Prop with a crystal, but since the prop on the development board was burnt out and not able to run using the external crystal, I was trying to see if I could do any testing while I waited for the new chips to come in. Now that they are in, i will be replacing the one on the prop board now. I was also thinking of making my own prop PCB to be able to plug it into a bread board. Question is, can the radioshack etching kit do small traces like what i am needing to solder the prop to? My first project board i did, I ran into several problems trying to etch thin traces. Maybe I was doing something wrong...
You're attempting to measure engine RPM and use a serial (timing sensitive display) but you're not including a crystal? This is a clear case of stepping over dollars to pick up dimes. But hey, they're your dollars.
If you're going to use an RC mode then there is no way around it: you must tune the software for every chip. What this means is timing the chip when in RC mode to determine how fast it's actually running. You can then set this into a constant in your program to drive other features. Doable? Sure. Worth the trouble? No way in h*ll.
As you seem to be a gluten for punishment (wink) I will show you how. In the attached test program I am toggling an output such that if the timing was right I would get a 10ms high and low period in the wave. For RCFAST the initial setting of my CLK_FREQ constant is 12_000_000. Here's the output with that:
The measured pulse was 8.89ms. If we take 12_000_000 * 10 / 8.89 we get 13_498_313. If we plug that in and re-run the program we get this:
Bam, 10ms. We've fixed it, rigt? WRONG!!! This strategy only works for creating constants (as in the header of my program) that can be used with waitcnt. Most objects reference the [internal] clkfreq variable witch cannot be overridden in RC mode. So... all this is to say: just use a 5MHz crystal and save yourself a lot of programming troubles down the road.
Ok, something is really screwed up here. I have unsoldered the old Prop which I thought was burnt out since it was not able to run with an external crystal. I have now resoldered on a new one and it is doing the exact same thing and now my buttons are not working to adjust the display to the next number. All solder connections are good. My method of SM soldering is drag soldering using flux.
As a follow-up before I head off to acting class, and to prove that you can do really slow serial in Spin using RCFAST mode, I modified my program as attached. This illustrates the problem that I mention above: the system reports clkfreq as 12_000_000 when using RCFAST even though I empirically determined that the actual frequency is 13_498_313.
Edit: As ever, Marko is correct (which tends to help me remove my foot from my mouth) and you can in fact override clkfreq using the mechanism he suggests With that, you can actually use FullDuplexSerial once you've made the adjustment. See attached.
I've seen this problem a couple times: it resulted from water being trapped under the crystal after washing the board. As the Propeller is programmed using the internal RC clock all seems fine until you try to run in crystal mode. If you're washing your boards then this is something to check for. If not, you may need to check the specs on the crystal you're using (unless you bought it from Parallax, that is).
Ok, something is really screwed up here. I have unsoldered the old Prop which I thought was burnt out since it was not able to run with an external crystal. I have now resoldered on a new one and it is doing the exact same thing and now my buttons are not working to adjust the display to the next number. All solder connections are good. My method of SM soldering is drag soldering using flux.
I am planning on running the Prop with a crystal, but since the prop on the development board was burnt out and not able to run using the external crystal, I was trying to see if I could do any testing while I waited for the new chips to come in. Now that they are in, i will be replacing the one on the prop board now. I was also thinking of making my own prop PCB to be able to plug it into a bread board. Question is, can the radioshack etching kit do small traces like what i am needing to solder the prop to? My first project board i did, I ran into several problems trying to etch thin traces. Maybe I was doing something wrong...
I use a GG usb for the prop and wires over to the protoboard bank. One of the guys out there has built and I think sells a module that should from the look of it plug straight into a protoboard. If you worry about replacing fried/spun props, the forty can be breadboarded as in the online Prop Education manual. Fry's electronics (yeah I've ranted on this before) has the 40 pin dip version. and the prop ed kit. My rant has been why do they carry the schmart board for smd props but not the smd prop, and the 40dip. It occurs to me that they may be anticipating people frying the prop in the ed kit and here of course for a fee is a replacement 40dip prop.
You're attempting to measure engine RPM and use a serial (timing sensitive display) but you're not including a crystal? This is a clear case of stepping over dollars to pick up dimes. But hey, they're your dollars.
If you're going to use an RC mode then there is no way around it: you must tune the software for every chip. What this means is timing the chip when in RC mode to determine how fast it's actually running. You can then set this into a constant in your program to drive other features. Doable? Sure. Worth the trouble? No way in h*ll.
As you seem to be a gluten for punishment (wink) I will show you how. In the attached test program I am toggling an output such that if the timing was right I would get a 10ms high and low period in the wave. For RCFAST the initial setting of my CLK_FREQ constant is 12_000_000. Here's the output with that:
The measured pulse was 8.89ms. If we take 12_000_000 * 10 / 8.89 we get 13_498_313. If we plug that in and re-run the program we get this:
Bam, 10ms. We've fixed it, rigt? WRONG!!! This strategy only works for creating constants (as in the header of my program) that can be used with waitcnt. Most objects reference the [internal] clkfreq variable witch cannot be overridden in RC mode. So... all this is to say: just use a 5MHz crystal and save yourself a lot of programming troubles down the road.
Some things are better left under wraps unless no other way exists. Of course, he will learn the meaning of support nightmare............
Frank
I am to lazy to look it up in the docs, but does the prop internal clock have and drift with temp or supply variations??
I removed the crystal from the board when I resoldered the new chip on. Everything is clean but the chip will still not boot up if programmed to run with an external crystal
Here is my code. This the just the simple basics starting from ground 0 :
Not sure if you missed it in my other posts, but I am using a 5Mhz crystal with the prop. The only reason I asked if it would work without the crystal was so I could resume testing until the new prop chips came in. I now have a new chip soldered to the Prop development board and am back in testing. I reheated the solder joints with my hot air station and blew out any extra flux. That seem to do the trick and now I have the display, buttons, and crystal all working again
I have somewhat figured out how to use the code JM posted to get the RPM, but if I multiply the results by 60, the value is ~ 48900 which it should be somewhere close to 1,000 if I am not mistaken. I only have one display so I can't see what the SX is saying the RPM should be. I am running the Prop at 80Mhz using :
Then the Prop (Main part of Code only):
[PHP]pub period
'' Returns period of input waveform
return fccycles
pub freq | p, f
'' Converts input period to frequency
'' -- returns frequency in 0.1Hz units (1Hz = 10 units)
'' -- should not be called faster than expected minimum input frequency
p := period
if (p > 0)
f := clkfreq * 10 / p ' calculate frequency
fccycles := 0 ' clear for loss of input
else
f := 0
return f
dat
org 0
frcntr mov tmp1, par ' start of structure
rdlong tmp2, tmp1 ' get pin#
I have somewhat figured out how to use the code JM posted to get the RPM, but if I multiply the results by 60, the value is ~ 48900 which it should be somewhere close to 1,000 if I am not mistaken.
You didn't say which result you use and how you used the object. The example below will use Jon's object for measuring a 1000rpm signal (1000/60Hz). Said signal is generated by a counter (square wave). The returned frequency value (in 0.1Hz units) is then converted to rpm and displayed in hex with an additional reading counter. For the listed setup I get readings around $3E4 (996rpm) which is mainly due to rounding errors (integer arithmetic). Just run it and see what it gives you.
CON
_clkmode = XTAL1|PLL16X
_xinfreq = 5_000_000
CON
pin = 16
OBJ
helper: "jm_freqin"
serial: "FullDuplexSerial"
PUB null | rpm
serial.start(31, 30, %0000, 115200) ' debug output
waitcnt(clkfreq*3 + cnt) ' startup delay
serial.tx(0) ' clear screen
[COLOR="orange"]ctra := constant(%0_00100_000 << 23 | pin) ' |
frqa := 895 {2^32*(1000/60)/clkfreq)} ' |
dira[pin]~~ ' simulate 1000rpm[/COLOR]
helper.init(pin) ' start frequency reader
repeat ' display value
rpm := helper.freq{0.1Hz} * 60 / 10 ' 0.1Hz -> rpm
serial.hex(rpm, 8)
serial.tx(32)
serial.hex(result++, 8) ' increment for each reading (so we can observe change)
serial.tx(1)
waitcnt(clkfreq + cnt) ' allow for new measurement
DAT
Here is how I am calling it now. I am not sure how accurate it is since it is 20 degrees outside and I don't feel like trying to hook this up to my car to get a reading when it is so cold out
PUB saveval(tmp) | temp, startTime
temp := tmp
if temp <> lastWritten and temp <> 0
if i2c.WritePage(i2c#BootPin, i2c#EEPROM, @EVal1, @tmp, 4)
abort ' an error occured during the write
startTime := cnt ' prepare to check for a timeout
repeat while i2c.WriteWait(i2c#BootPin, i2c#EEPROM, @tmp)
if cnt - startTime > clkfreq / 10
abort ' waited more than a 1/10 second for the write to finish
lastWritten := temp
return
PUB getthrottle | thr
dira[5]~~ ' Set as output
outa[5]:=1 ' Set high
BS2.Pause(10) ' Allow to charge
'throttle := BS2.RCTime(5,1) ' Measure RCTime
lcd.gotoxy(13, 0)
lcd.str(string(" "))
lcd.gotoxy(13, 0)
lcd.str(num.dec(throttle)) ' Display
return throttle
DAT
numbers byte %0000_0000, %0101_0000, %1100_1110, %1101_1010, %0101_0011[/PHP]
I took the display off of the Prop development board and connected it to my SX chip which is also reading from the 555 output. I then adjusted the frequency, with the potentiometer I have connected to the 555 timer, to 3000 RPM according to the RPM function I am currently using on my SX circuit. It is accurate to within 100 RPM running at 5Mhz which is all I need. After getting the output frequency of the 555 timer to 3000 RPM, I put the display back on the Prop and tried different numbers to match the 3000 RPM. With dividing by 3, the Prop output was 2996 to 3005. That is pretty close to what I set it at. I am not sure if it helps any, but my vehicle is a 4 cylinder which has 2 ignition pulses per revolution. As you can see in my SX code, I have the variable "sparks" which refers to Engine Cylinders / 2. So for a 4 Cylinder, it will equal 2. Then a six cylinder will equal 3.
So the reading should be correct based on a bench test? I am almost ready to hook it to my car and see what kind of heat and all it generates. I did get the Mosfets and heatsinks in as well. the Mosfets have 8 pins and are half the size of the prop chip. I hope they can handle the temps! Right now, I am testing with the NPN to PNP circuit. Once I get comfortable with the power supply heat issue, I will change to the SM Mosfets. I asked this in a few posts back but don't think I got a response on it.... Will the RadioShack PCB etching kit do small traces like what I need for the Prop Pins and the Mosfet chips?
I was also thinking of trying to solder a single wire to each pin of the Mosfet and plug it into my breadboard for testing purposes if the etching will not do what I need.
Comments
Can I run the 2x16 display without having perfect timing? I want to try and get the RPM signal working the best I can so when I can at least test it. I do have a 555 timer set up to replicate the engine RPM signal which works from 100 to 14,300 RPM. That is what I use for bench testing. Since I don't really understand how Johnny's code works, could someone help me understand how to call it properly and be able to pick up the RPM signal? I would like to have it run on it's own COG if at all possible. Does the command "cognew" call a function or object or does it just run 1 line of code? I don't quite understand the whole cog thing yet. I am an expert PHP programmer and I relate a lot of the code to how the spin code is written.
Typically I have only seen insulators supplied with parts such as those that you would get with an NTE that you have crossed from some original part. A little value added for the (primary market for NTE) electronic servicers. Sometimes when a Flame Emiting Transistor or Power bipolar has melted down in the Horizontal drive of a large older TV these things get damaged (fried), but not likely to have any issues with screws etc. So I have never seen screws in the kits, only mica insulators and plastic(?) donut insulators to isolate the tab from the mounting hardware.
Frank
Your heat problem may have come from the draw of the backlight for the LCD display. I used a 2*40 Hitatchi clone display, but check the jumpers on yours if they exist as they are used on some for enable of the backlight and / or control of same. Could be a jumper in place along with another one or an uncut configuration trace creating a short on the 5V reg circuit. The current rating of the backlight just may be enough to push a 7805 into a warmer place w/o the heatsink as the 1A max assumes heatsink is used.
Frank
Scope the pins and look to see if any osc present; should be around 3V or so and looking like a 5MHz sine wave at either crystal pin.
Frank
Most are using machined pin sockets so that you can use different crystals. mainly 5.0 MHz and the 6.25 MHz values for 80MHz and 100 MHz respectively.
FF
I was fairly sloppy in my Hitatchi object and it did fine. Pick a refresh rate that will allow the user to see the display without it blurring all over the place with too many updates to se any values in the more rapidly changing digits. I like the 555 idea for testing 'cause it is easily replaced with a Hall ckt or similar for actual shaft rotations unless you are pulling a buffered pulse off the ignition ckt primary side and counting pulses there.
As for Johnny's code, go back through it and see if he put a driver/example of how to use the code. Most of the objects include at least one example of how to use the objects.
Now as to bigger and better. Good for goals, future plans etc. but don't let feature creep screw you up. Get a section at a time up and running of the base product and thoroughly unit test it. Once it all works at the base level, abuse it in the most creative ways you can think of because your users will certainly do so, generally in ways you can't even imagine. Then you can start adding the "extras" one at a time unit and integration testing all over again so that when a new feature crashes it (and it will, murphy was an engineer for sure) you will have a fallback to try again without trying to see which interaction among multiple changes actually caused the problems.
Frank
EDIT : I got the display to show strange characters at 2400, but anything over that, the code hangs at the lcd.init(15, 9600, 2) I guess I will have to wait till I get the other chips
[PHP]CON
_CLKMODE = RCFAST
OBJ
lcd : "Serial_Lcd"
PUB Main
lcd.init(8, 9600, 2)
lcd.displayOn
lcd.backLight(false)
lcd.gotoxy(0,0)
lcd.str(string("Testing 123456 "))
lcd.gotoxy(0,1)
lcd.str(string("This is Line 2 "))[/PHP]
If you're going to use an RC mode then there is no way around it: you must tune the software for every chip. What this means is timing the chip when in RC mode to determine how fast it's actually running. You can then set this into a constant in your program to drive other features. Doable? Sure. Worth the trouble? No way in h*ll.
As you seem to be a gluten for punishment (wink) I will show you how. In the attached test program I am toggling an output such that if the timing was right I would get a 10ms high and low period in the wave. For RCFAST the initial setting of my CLK_FREQ constant is 12_000_000. Here's the output with that:
The measured pulse was 8.89ms. If we take 12_000_000 * 10 / 8.89 we get 13_498_313. If we plug that in and re-run the program we get this:
Bam, 10ms. We've fixed it, rigt? WRONG!!! This strategy only works for creating constants (as in the header of my program) that can be used with waitcnt. Most objects reference the [internal] clkfreq variable witch cannot be overridden in RC mode. So... all this is to say: just use a 5MHz crystal and save yourself a lot of programming troubles down the road.
Edit: As ever, Marko is correct (which tends to help me remove my foot from my mouth) and you can in fact override clkfreq using the mechanism he suggests With that, you can actually use FullDuplexSerial once you've made the adjustment. See attached.
I use a GG usb for the prop and wires over to the protoboard bank. One of the guys out there has built and I think sells a module that should from the look of it plug straight into a protoboard. If you worry about replacing fried/spun props, the forty can be breadboarded as in the online Prop Education manual. Fry's electronics (yeah I've ranted on this before) has the 40 pin dip version. and the prop ed kit. My rant has been why do they carry the schmart board for smd props but not the smd prop, and the 40dip. It occurs to me that they may be anticipating people frying the prop in the ed kit and here of course for a fee is a replacement 40dip prop.
FF
Some things are better left under wraps unless no other way exists. Of course, he will learn the meaning of support nightmare............
Frank
I am to lazy to look it up in the docs, but does the prop internal clock have and drift with temp or supply variations??
Here is my code. This the just the simple basics starting from ground 0 :
[PHP]
CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
solenoida = 2
solenoidb = 3
upbutton = 0
downbutton = 1
VAR
OBJ
'num : "simple_numbers"
PUB Main | gear
gear := 1
gear := shiftgear(gear)
repeat
if ina[upbutton] == 1
gear++
gear := shiftgear(gear)
if ina[downbutton] == 1
gear--
gear := shiftgear(gear)
repeat while ina[downbutton] == 1 or ina[upbutton] == 1
waitcnt(30_000 + cnt)
waitcnt(1_000_000 + cnt)
PUB shiftgear(tmp)
if tmp > 4
tmp := 4
if tmp < 1
tmp := 1
dira[solenoida]~~
dira[solenoidb]~~
outa[16..23]~
dira[16..23]~~
if tmp == 1
outa[solenoida] := 1
outa[solenoidb] := 1
if tmp == 2
outa[solenoida] := 0
outa[solenoidb] := 1
if tmp == 3
outa[solenoida] := 0
outa[solenoidb] := 0
if tmp == 4
outa[solenoida] := 1
outa[solenoidb] := 0
outa[16..23] := numbers[tmp]
return tmp
DAT
numbers byte %0000_0000, %0101_0000, %1100_1110, %1101_1010, %0101_0011[/PHP]
[PHP] _CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000[/PHP]
Does the RPM code from the SX do something different than what the Freqin code does for the Prop?
Here are the 2 codes :
SX
[PHP]FUNC GET_RPM
PULSIN TachIn, 0, pWidth0
PULSIN TachIn, 1, pWidth1
pWidth0 = pWidth0 + pWidth1
pWidth0 = pWidth0 * sparks
dividendMSW = $005B
dividendLSW = $8D80
rpm = 1
overflow = 0
DO
doneBit = rpm.15
rpm = rpm << 1
IF overflow = 1 THEN
rpm.0 = 1
dividendMSW = dividendMSW - pWidth0
ELSE
IF dividendMSW >= pWidth0 THEN
rpm.0 = 1
dividendMSW = dividendMSW - pWidth0
ENDIF
ENDIF
overflow = dividendMSW.15
dividendMSW = dividendMSW << 1
dividendMSW.0 = dividendLSW.15
dividendLSW = dividendLSW << 1
LOOP UNTIL doneBit = 1
rpm = rpm << 1
rpm.0 = overflow
IF dividendMSW >= pWidth0 THEN
rpm.0 = 0
ENDIF
rpm = rpm / 100
RETURN rpm
ENDFUNC[/PHP]
Then the Prop (Main part of Code only):
[PHP]pub period
'' Returns period of input waveform
return fccycles
pub freq | p, f
'' Converts input period to frequency
'' -- returns frequency in 0.1Hz units (1Hz = 10 units)
'' -- should not be called faster than expected minimum input frequency
p := period
if (p > 0)
f := clkfreq * 10 / p ' calculate frequency
fccycles := 0 ' clear for loss of input
else
f := 0
return f
dat
org 0
frcntr mov tmp1, par ' start of structure
rdlong tmp2, tmp1 ' get pin#
mov ctra, POS_DETECT ' ctra measures high phase
add ctra, tmp2
mov frqa, #1
mov ctrb, NEG_DETECT ' ctrb measures low phase
add ctrb, tmp2
mov frqb, #1
mov mask, #1 ' create pin mask
shl mask, tmp2
andn dira, mask ' input in this cog
add tmp1, #4
mov cyclepntr, tmp1 ' save address of hub storage
restart waitpne mask, mask ' wait for 0 phase
mov phsa, #0 ' clear high phase counter
highphase waitpeq mask, mask ' wait for pin == 1
mov phsb, #0 ' clear low phase counter
lowphase waitpne mask, mask ' wait for pin == 0
mov cycles, phsa ' capture high phase cycles
endcycle waitpeq mask, mask ' let low phase finish
add cycles, phsb ' add low phase cycles
wrlong cycles, cyclepntr ' update hub
jmp #restart
'
POS_DETECT long %01000 << 26
NEG_DETECT long %01100 << 26
tmp1 res 1
tmp2 res 1
mask res 1 ' mask for frequency input pin
cyclepntr res 1 ' hub address of cycle count
cycles res 1 ' cycles in input period
fit 496[/PHP]
CON _clkmode = XTAL1|PLL16X _xinfreq = 5_000_000 CON pin = 16 OBJ helper: "jm_freqin" serial: "FullDuplexSerial" PUB null | rpm serial.start(31, 30, %0000, 115200) ' debug output waitcnt(clkfreq*3 + cnt) ' startup delay serial.tx(0) ' clear screen [COLOR="orange"]ctra := constant(%0_00100_000 << 23 | pin) ' | frqa := 895 {2^32*(1000/60)/clkfreq)} ' | dira[pin]~~ ' simulate 1000rpm[/COLOR] helper.init(pin) ' start frequency reader repeat ' display value rpm := helper.freq{0.1Hz} * 60 / 10 ' 0.1Hz -> rpm serial.hex(rpm, 8) serial.tx(32) serial.hex(result++, 8) ' increment for each reading (so we can observe change) serial.tx(1) waitcnt(clkfreq + cnt) ' allow for new measurement DAT[PHP]CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
solenoida = 2
solenoidb = 3
upbutton = 0
downbutton = 1
VAR
long lastWritten
BYTE EVal1
byte throttle
long rpm
OBJ
i2c : "Basic_I2C_Driver"
BS2 : "BS2_Functions"
'throt : "RCTIME"
lcd : "Serial_Lcd"
getrpm : "jm_freqin"
num : "simple_numbers"
PUB Main | gear
BS2.start (31,30)
EVal1 := 100
gear := i2c.ReadLong(i2c#BootPin, i2c#EEPROM, @EVal1)
if gear < 1 OR gear > 4
gear := 1
getrpm.init(15)
lcd.init(8, 9600, 2)
lcd.displayOn
lcd.backLight(false)
lcd.gotoxy(0,0)
lcd.str(string("Testing Version "))
lcd.gotoxy(0,1)
lcd.str(string("Tims shifter V1 "))
waitcnt(300_000_000 + cnt)
lcd.cls
lcd.str(string("Gear: "))
lcd.gotoxy(5,0)
lcd.str(num.dec(gear))
gear := shiftgear(gear)
repeat
rpm := getrpm.freq * 3
lcd.gotoxy(0,1)
lcd.str(string("RPM : "))
lcd.gotoxy(5,1)
lcd.str(num.dec(rpm))
'throttle := getthrottle
if ina[upbutton] == 1
gear++
gear := shiftgear(gear)
if ina[downbutton] == 1
gear--
gear := shiftgear(gear)
repeat while ina[downbutton] == 1 or ina[upbutton] == 1
waitcnt(3_000_000 + cnt)
waitcnt(10_000_000 + cnt)
PUB shiftgear(tmp)
if tmp > 4
tmp := 4
if tmp < 1
tmp := 1
'throttle := getthrottle(tmp)
dira[solenoida]~~
dira[solenoidb]~~
outa[16..23]~
dira[16..23]~~
if tmp == 1
outa[solenoida] := 1
outa[solenoidb] := 1
if tmp == 2
outa[solenoida] := 0
outa[solenoidb] := 1
if tmp == 3
outa[solenoida] := 0
outa[solenoidb] := 0
if tmp == 4
outa[solenoida] := 1
outa[solenoidb] := 0
outa[16..23] := numbers[tmp]
saveval(tmp)
lcd.gotoxy(5,0)
lcd.str(num.dec(tmp))
return tmp
PUB saveval(tmp) | temp, startTime
temp := tmp
if temp <> lastWritten and temp <> 0
if i2c.WritePage(i2c#BootPin, i2c#EEPROM, @EVal1, @tmp, 4)
abort ' an error occured during the write
startTime := cnt ' prepare to check for a timeout
repeat while i2c.WriteWait(i2c#BootPin, i2c#EEPROM, @tmp)
if cnt - startTime > clkfreq / 10
abort ' waited more than a 1/10 second for the write to finish
lastWritten := temp
return
PUB getthrottle | thr
dira[5]~~ ' Set as output
outa[5]:=1 ' Set high
BS2.Pause(10) ' Allow to charge
'throttle := BS2.RCTime(5,1) ' Measure RCTime
lcd.gotoxy(13, 0)
lcd.str(string(" "))
lcd.gotoxy(13, 0)
lcd.str(num.dec(throttle)) ' Display
return throttle
DAT
numbers byte %0000_0000, %0101_0000, %1100_1110, %1101_1010, %0101_0011[/PHP]
I was also thinking of trying to solder a single wire to each pin of the Mosfet and plug it into my breadboard for testing purposes if the etching will not do what I need.