Jump to content

Nav-Lights Variation Project Help


Recommended Posts

But the only problem with a stuck high pulse is that I'd be trying to measure a valid pulse, which what I do when I get an IOC (rising edge), is clear Timer 1 and start timing the pulse until I get a falling edge, which then I stop Timer 1 and store off the value. I could preload after a completed pulse and then if I got an overflow, that would indicate a missed pulse, or no pulse.

I guess what I could do, is preload a value on the rising edge (so that I could get the overflow time I wanted) but then remember that value when I actually got a valid pulse, and subtract it off. Something like this...

(Rising Edge) Timer 1 = 0x63C0 (on overflow, this would give me 40ms)

Case 1:

(Overflow) Timer 1 sets overflow interrupt. Reset Timer 1 to preset and start again.

Case 2:

(Falling Edge) Timer 1 = 0x699C (a 1.5ms pulse was received)

Any time I get an overflow or a completed pulse, I would then reset Timer 1 to the preset value to either wait for another pulse, or wait until another overflow... Cool.

So, is that kind of what you mean?

Link to post
Share on other sites
  • Replies 71
  • Created
  • Last Reply

Top Posters In This Topic

Yes, you would need to observe the loaded value later on. Subtract if necessary, or just compare the latched timer values to constants that are offset in size to include the preloaded value.

Again, there are several ways to accomplish the task. Just start coding and go from there. If something does not work out, solve it another way.

Link to post
Share on other sites

Great. I'll give that a shot and see what happens. Right now I have all this in my ISR, so I really need to take it out, and only leave just the basic stuff to handle interrups in there, and put the rest in the main routine. I think I'll use a flag register, that way, the ISR can kind of talk to the main routine.

BTW, what does BEC put out with a battery that is greater than 6V. I haven't measured it yet to check...

What the heck is a Gaffer anyway?

Edited by geogecko
Link to post
Share on other sites

>What the heck is a Gaffer anyway?

Mostly they hang around the catering table and hit on makeup artists.

;-)

Also ... they are in charge of anything electric on a movie set.

Chief Electrician if you prefer.

Edited by mikep
Link to post
Share on other sites

Okay, I was starting to think that it was 5V. I wonder why they spec servos with 6V (I guess if you have a glow plane, and use a 5 cell pack?).

Interesting. I went to see The Passion of the Christ last night with my wife, and as I was watching the trivia questions before the movie, there it was. What is a Gaffer?

"It said a person in charge of the lighting for a scene." Guess it depends on where you are coming from. What that has to do with R/C, I do not know, but okay.

Have you noticed how many posts this thread has gotten? Interesting, huh? I finally removed all the pulse checking (etc) from the ISR, and put it into the main routine (and yes, it still works!). I ordered the parts for the project this morning, so I hope to have a prototype up and working within a couple weeks. I feel like I've reached the point where I need to start actually using an Rx to further test the project. I've been using the strobe LED as an input for the pulse for the time being, and I realize that is probably too perfect of a pulse to expect. (Since I can control it exactly as I want it to be.)

Anyone have any experience with the buzzer used in the landing gear slower project? How loud is it? I was thinking of using it in another project (as just like a timer alarm), is it too loud for that?

Edited:

Oh, and one last thing. Why do I get the pop-up message box while programming the part that says, "Calibration Memory Already Programmed?"

Edited by geogecko
Link to post
Share on other sites
I guess if you have a glow plane, and use a 5 cell pack?

Certainly, and I know quite a few people who use that setup, especially for helis where it's good to have your servos going faster.

I finally removed all the pulse checking (etc) from the ISR, and put it into the main routine (and yes, it still works!)

Good thing! Sometimes you think everything is OK and then you spend hours debugging...

Link to post
Share on other sites
What that has to do with R/C, I do not know, but okay.

The RC-CAM site was formed to help promote R/C model based wireless video applications. So, members of the forum are given names that represent the sort of folks that would produce movies.

Gaffers are the professional guys/gals that setup the scene lighting and manage the electrical distribution duties (I like mikep's description). http://www.newenglandfilm.com/news/archive...mber/gaffer.htm

Why do I get the pop-up message box while programming the part that says, "Calibration Memory Already Programmed?"

Because the Cal Osc value is already programmed by the factory.

Link to post
Share on other sites

I now see. So, would a "Stage Hand" also be considered a Grip? That's cool. I should have put 2 and 2 together (maybe for me, I should have put 1 and 1 together).

I was a little worried about moving the code to the main routine, but knew it had to be done, since it wasn't really part of the interrupt servicing. I'm glad it worked out so nicely. Just a couple more added instructions checking flags, and that was all that was needed.

So, basically, if I leave the code in that programs the OSCCAL value, then I will always get that message? I have noticed that on accident I programmed the wrong value in (after changing to a new PIC), but upon reading the program memory back, the value was still the original value. Is it write protected or something?

CALL CAL_INTOSC
CAL_INTOSC

BSF	BANK_SW;Switch to BANK 1

CALL	0x3FF;Get the Cal Value

MOVWF	OSCCAL;Calibrate

BCF	BANK_SW;Switch to BANK 0

RETURN
And then...
ORG	0x3FF

RETLW	0x60

That is the proper way to do it, is it not? <_<

Edited by geogecko
Link to post
Share on other sites
Is it write protected or something?

No it isn't. It can easily be erased if you do not manage your programmer. If you lose the value, and do not recall what it used to be, your chip will be in trouble.

Page 54 of the PIC12F629/675 data sheet has all the details to this, as well as how to code the calibration (your snippet is the same). However, the exampled value at 0x3FF's adress is determined by the silicon wafer lot and is assigned by the factory. You DO NOT put anything at this location -- the factory does this for you.

Link to post
Share on other sites

I've seen a lot of people out there with this retlw in their code, which is why I added it to mine.

From what I can gather from the data sheet, (and what you have said) the instruction/value already exists in memory when you get it from the factory.

The only reason I can think of is to why people are including this instruction in their code (as I have) is "just in case" their program filled up the entire amount of memory in the PIC, including 0x3FF. If you had this instruction at the end of your code, even if you had an instruction in your program that went into 0x3FF, the org 0x3FF and the instruction right after that, would overwrite any instruction in your program that may have made it into the last memory location.

With that being said, I have a thought. I am more likely to forget to change the calibration value when changing PICs than I am to actually have a program that takes up ALL the memory in the PIC. So, with that in mind, the logical thing for me to do would be to take the org and retlw instruction out of my code. Would you agree?

Edited by geogecko
Link to post
Share on other sites
So, with that in mind, the logical thing for me to do would be to take the org and retlw instruction out of my code. Would you agree?

If you are developing your code with an actual PIC (versus using an emulator), then every time you bulk erase the PIC you will lose the Osc Cal value. So, in this instance you must record the original factory value and then restore it with each burn attempt.

It is convenient to add the value to the source code. But be careful that the value used belongs to the target chip. Furthermore, once your code is debugged, REMOVE THE VALUE from your code. Otherwise, you can corrupt the production chips with alien calibration values.

The OSC Cal value is a great source of trouble for new PIC users and some hobby grade programming systems. I wish it was pseudo write protected since that would help keep some folks from accidently disturbing the factory assigned value. In applications like ours, where the oscillator's precision is REALLY important, a minor change to the cal data will cause endless grief when the finished code is released upon mankind.

Link to post
Share on other sites

I am using a PICSTART Plus programmer to program the chip directly. So every time I do an "Erase Device" I'm losing the OSCCAL value? It sounds like I should leave it in for now.

Hmm... You would think that Microchip would have write protected it. We shouldn't be changing it from the factory setting in the first place. Do some people change the value on purpose? It is new for me, because on the 16C73A, there was no such thing, when I was in school. Of course, neither was there FLASH devices.

Thanks for all your explainations. Hopefully someday, I can call myself a professional PIC programmer. I only wish that my job required me to use them.

Link to post
Share on other sites

I add the cal value in the code because I always use the same chip for my tests. I use IC-Prog, and as it has to erase the chip before programming it again, it must read the whole code before to store the cal value. Having it in the code allows me to skip that reading which saves me 10 seconds every time I burn the chip. Also, If the PIC gets erased and then programming fails (bad contact or what else), the value is lost. So that's why I always read and write down the value before doing anything else when I use another unit.

Link to post
Share on other sites

Kilrah.

I see about why you include it in the code now. I'm going to leave mine in for the time being, just need to remember to change it.

Jason.

Okay, so, what is a good number of pulses to average when checking pulses? I would prefer to use a 2^N number of pulses to average (as it makes the dividing easier), i.e., 2, 4, 8, 16, etc. I was thinking 4 would be good enough.

This project is coming along pretty well. I got the magnetic buzzer in the mail a few days ago, and it seems like it will be loud enough. I also have my EEPROM write/read routines written, now I just need to figure out the setup procedure routine. I assume I'm going to have to debounce the setup pin (I think I'll use the 20ms Timer 0 for this), since I'll be using it as a way to set a feature that requires the Rx to be powered before the jumper is installed.

I wish that Microchip made some 10 pin devices, so I could have a couple extra pins. I'd really like to have the battery monitor, but that requires two pins, if I use a reference, which I would have to, in order to monitor voltage that I'm also using to power the PIC. I could get rid of the glitch LED, however, I can't seem to think of a way to get rid of another pin, without losing something that I want. I guess I could do double duty with the strobe output, since it's only on for about 40ms, I could connect the buzzer to the same output, and then if I had a lost model, I just turn the strobe on without flashing. Oh, well, I really need to get the basics working before I get that far along.

Thanks,

Jason.

Link to post
Share on other sites
I assume I'm going to have to debounce the setup pin (I think I'll use the 20ms Timer 0 for this)

To debounce setup buttons I generally use a simple delay loop, as it is much simpler and time is not critical at that moment.

I wish that Microchip made some 10 pin devices

Get a 16F676! It's exactly the same unit as the 12F675 but with 14 pins! To port the code you just have to change your GPIO accesses as there are 2 registers instead of one. All the rest is similar. I've bought a couple of them for when I need more I/O.

Link to post
Share on other sites

Kilrah.

Hey, thanks for the information about the 16F676. I didn't know it existed until now.

As far as the debounce thing goes, I too used to use a delay loop, however, a good debounce is about 3ms long or so, if I remember correctly, and I'm not sure I want to wait that long in a delay routine. Actually, I guess it wouldn't be that bad, I'm not timing anything that is real critical right now (besides what is taken care of with an interrupt). I'll start with that, since it's the easiest thing to do, and if that doesn't work out for me, I'll go another route.

I've just spent the last few days trying to debug a problem, and now think I have the answer. I declared a variable 'A' and wanted to store it into another variable 'B', so what was I doing? A "MOVLW A" and then a "MOVWF B". Those are always the hard ones to catch for me, using the MOVF instead of the MOVLW...

So you have any input into the pulse averaging? I notice that when I'm right at the edge of where the landing lights come on, I can get it to flicker pretty good. I think averaging would solve this, but I'm not sure. It actually may require some hysteresis (spelling?), but I don't think I'm willing to incorporate that at this time...

I hooked up the prototype to a receiver last week, and everything seems to be working as expected. (Got to fix that last problem that I described earlier for the Glitch counter to work...) After that, it's on with the setup pin and EEPROM code. I've already got a couple routines written for the write/read, now I just need the logic for the setup pin.

Jason.

Link to post
Share on other sites

Next issue:

I'm working on the EEPROM code that will allow a similar type setup used in the Landtastic project. Question is, I have a value, the rate at which the strobe flashes (or cycle time, rather), which is currently set as a constant in my code, then stored in a RAM variable when needed. I want to change this to pull the value out of EEPROM memory, but had a few questions on doing so.

1. Should I just read the value in EEPROM memory once when the PIC initializes, and store that value in RAM, or

2. Should I not even use a RAM variable, and always read the value from EEPROM when needed in the program?

The reason I ask, is that I wasn't sure if reading the EEPROM memory affects it's memory life, or how long it takes to read from EEPROM memory.

The other concern that I have, is that if I went into setup mode to change this value, I could allow the user to use a variable stick on the transmitter to store a new value of the strobe rate in RAM, and then when exiting the setup mode, I would then write the value to EEPROM. This would allow the user to update the value real-time, while not continually writing to EEPROM memory in the setup mode.

Hmm...Have I answered my own question...maybe I need to quit this thinking (typing) out loud? I had to move on to another task, because I'm not sure how to tackle the pulse averaging technique yet. It seems like that might get hairy considering that I am using 16 bit pulse width values...

Jason.

Hmm...Code reuseability. How I can't wait until this project is over, and I can just cut and paste code for my next project! What a learning experience this has been, wow. :lol:

Edited by geogecko
Link to post
Share on other sites

1. Yes.

2. No.

You can read directly from the EEprom as often as you want. Usually you are penalized by low access speed. Do not create code that continuously writes to the EEProm. That is considered a no-no.

It is also a good idea to add a checksum to the EEProm data tables to detect corruption. However, I suggest you do this after you gain more programming experience. It is not a critical requirement.

Link to post
Share on other sites

I now have the EEPROM part of the program working properly. Thanks for the tips there.

Now. Here is where I've run into an issue with how to do something. I currently have code now that checks for the trip point of the landing lights, a too short pulse, and a too long pulse. I need to add some points (a center stick check point, and full up stick check point, and a full down check point) for the setup routine, however, I am unsure how to go about this. If you look at the code, once it finds a match, I exit out of the checking part of the routine, and do whatever needs to be done. I guess, I just need to not get out of the code in some cases, but I'm not sure. Here is the pulse checking routine. (The pulse is actually measured in the ISR.) Any ideas?

CHECK_PULSE

;When A Subtract Is Performed, The Carry Bit In The Status Register Will Be Cleared On A Borrow

  	BTFSS	PULSE_RX;Has A Valid Pulse Been Received?

  	RETURN

  	BCF  PULSE_RX;Reset Flag For Next Pulse

SHORT_PL	MOVLW	MIN_PULSE_H

  	SUBWF	T1H_SAVE,W;W=MIN_PULSE_H  F=T1H_SAVE

  	BTFSS	STATUS,C;Is Pulse H >= Minimum Pulse Width H?

  	GOTO	GLITCHED;F < W (C = 0)

  	BTFSS	STATUS,Z;F >= W

  	GOTO	LONG_PL

  	MOVLW	MIN_PULSE_L

  	SUBWF	T1L_SAVE,W;W=MIN_PULSE_L  F=T1L_SAVE

  	BTFSS	STATUS,C;Is Pulse L >= Minimum Pulse Width L?

  	GOTO	GLITCHED;F < W (C = 0)


LONG_PL  MOVLW	MAX_PULSE_H

  	SUBWF	T1H_SAVE,W;W=MAX_PULSE_H  F=T1H_SAVE

  	BTFSS	STATUS,C;Is Pulse H >= Maximum Pulse Width H?

  	GOTO	GOOD_PL  ;F < W (C = 0)

  	BTFSS	STATUS,Z;F >= W

  	GOTO	LOST_MODEL

  	MOVLW	MAX_PULSE_L

  	SUBWF	T1L_SAVE,W;W=MAX_PULSE_L  F=T1L_SAVE

  	BTFSS	STATUS,C;Is Pulse L >= Maximum Pulse Width L?

  	GOTO	GOOD_PL  ;F < W (C = 0)

  	GOTO	LOST_MODEL;F >= W


GOOD_PL  BCF  LMA_FLAG;Turn Off Lost Model Alarm

  	MOVF	LAND_POINT_H,W

  	SUBWF	T1H_SAVE,W;W=LAND_POINT_H  F=T1H_SAVE

  	BTFSS	STATUS,C;Is Pulse H >= Landing Point Pulse Width H?

  	GOTO	LAND_ON  ;F < W (C = 0)

  	BTFSS	STATUS,Z;F >= W

  	GOTO	LAND_OFF

  	MOVF	LAND_POINT_L,W

  	SUBWF	T1L_SAVE,W;W=LAND_POINT_L  F=T1L_SAVE

  	BTFSS	STATUS,C;Is Pulse L >= Landing Point Pulse Width L?

  	GOTO	LAND_ON  ;F < W (C = 0)

  	GOTO	LAND_OFF;F >= W


GLITCHED

  	MOVLW	MAX_GLITCHES

  	SUBWF	GLITCH_CT,W;W=MAX_GLITCHES  F=GLITCH_CT

  	BTFSS	STATUS,C;Is Glitch Count >= Maximum Glitch Count?

  	INCF	GLITCH_CT,F;F < W (C = 0) -- Increase Glitch Counter

  	GOTO	DONE_CHECK;F >= W

LOST_MODEL	BSF  LMA_FLAG;Turn On Lost Model Alarm

  	GOTO	DONE_CHECK

LAND_ON  BSF  LANDING  ;Turn Landing Lights On

  	GOTO	DONE_CHECK

LAND_OFF	BCF  LANDING  ;Turn Landing Lights Off


DONE_CHECK	RETURN

Thanks, Jason.

P.S. Sorry for the bad formatting, it didn't copy and paste very well...

P.S.2. I attached the code section to a text file for easier reading. (Tabstop=4) :ph34r:

check_pulse.asm

Edited by geogecko
Link to post
Share on other sites
  • 6 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...