When you switch off the PWM module, the simple GPIO logic takes back control.
If PWM is on pin C2, and you set pin_c2=high, C2 will go high when you turn off
PWM. When the PIC is first started, the port pins are in undefined state.
"undefined" is usually always the same state on a certain chip, but it can be
different once in a while, and it can be very different on another chip, even
of the same type.
You can use a bit array, but it's quite a slow thing that uses a lot of code
space. You don't need an array, in which every bit can be randomly addressed.
You're reading the bits always in the same order, from right to left. So, a
shift register is the economic solution, and in JAL that means a simple integer
variable. JAL can happily handle integer variables of arbitrary length (up to
256 bytes, depending on the chip. For PIC16F, the limit can be 80 or 64 bytes).
I'm not sure how long access to a bit in a bit array takes, but I can estimate
that shifting a 19 byte variable by one bit at 4MHz takes about 25µs.
You already used the shift scheme for the bytes in the existing program. Just
enlarge the variable. It's no big deal, really.
Greets,Kiste
Am Mittwoch, 6. April 2022, 09:25:00 MESZ hat hans
<[email protected]> Folgendes geschrieben:
Thoughtful about this matter.
When turning off PWM1 by applying PWM1_off() the output goes low. When I did
the same with PMW2, the output turned out to stay high. Somewhere in the
datasheet I had read something that PWM2 is a mirror image of PWM1,
This difference is something to know.
Hence my first question in this series with the custom Sample 16F73_PWM2
This problem can therefore be solved by simply letting the PWM continue to work
and switching the ports to input or output.
To narrow things down a bit and then merge the series of bytes into one series
of bits, I now wonder if using Matthew's bit array library would be suitable
for this.
regards
Hans
Op dinsdag 5 april 2022 om 20:40:28 UTC+2 schreef Kiste:
Graag gedaan :-)
Do you know why I see that kind of errors? Because I had to find them a hundred
times in my own programs ;-)
Greets,Kiste
Am Dienstag, 5. April 2022, 19:29:10 MESZ hat hans <[email protected]>
Folgendes geschrieben:
Hi Kiste,
The case works !!!
What if I checked something hundreds of times and didn't see this miss?
“Thank you” is meager but sincere.
I'm going to look at the other clues at my leisure.
thanks again and regards
Hans
Op dinsdag 5 april 2022 om 18:44:46 UTC+2 schreef Kiste:
Here's how I would send the data. I didn't compile it, may have errors. Also,
I'm not sure if the protocol is right, just take it as an example:
var byte HALT_kamer_array[19] =
{17,218,39,0,0,64,40,0,160,0,0,0,0,0,0,197,66,0,33}
var byte HEAT_kamer_array[19] =
{17,218,39,0,0,65,40,0,160,0,0,0,0,0,0,197,2,0,226}
var byte*19 HALT_kamer_long at HALT_kamer_array --these variables are very
long and
var byte*19 HEAT_kamer_long at HEAT_kamer_array --cover the existing arrays
var byte HALT_hal_array[19] =
{17,218,39,0,0,64,40,0,160,0,0,0,0,0,0,197,66,0,33}
var byte HEAT_hal_array[19] =
{17,218,39,0,0,65,40,0,160,0,0,0,0,0,0,197,2,0,226}
var byte*19 HALT_kamer_long at HALT_hal_array
var byte*19 HEAT_kamer_long at HEAT_hal_array
var byte*19 send_buffer_long
var bit send_buffer_next_bit at send_buffer_long:0
-- choose what to send
send_buffer_long=HEAT_hal_long -- all the variable is copied to the output
buffer
-- now send all the bits
LED=on
_usec_delay(10000) -- send a long burst to calibrate the receiver
LED=off
_usec_delay(2000)
for (8*19) loop
LED=on
_usec_delay(450) -- send a burst
LED=off
if send_buffer_next_bit == 1 then -- wait additional time if sending a "1"
_usec_delay(840) -- the difference between 1190 and 350
end if
_usec_delay(350) --you can reduce this a bit to compensate for the
--time needed for the shifting
send_buffer_long=send_buffer_long >> 1 --takes a while to shift such a long
--variable, but it always takes the
--same amount of time
end loop
LED=on
_usec_delay(450) -- send a final burst to end the last bit
LED=off
Greets,Kiste
Am Dienstag, 5. April 2022, 16:13:19 MESZ hat hans <[email protected]>
Folgendes geschrieben:
Hello Kyle, Done but same result. PWM1 works and PWM2 not. Now tested on
16FHow can i combine 19 bytes in one big word
Op dinsdag 5 april 2022 om 13:30:54 UTC+2 schreef Kiste:
Hi hans,
now as I know what it is for, I can give some hints ;-)
I've done remote signals a lot, and I did it this way:
- I keep the PWM running all the time, at 50% duty.- I switch the LED on and
off by setting the port pin to input/output (Works if the LED is directly
connected or via bipolar transistor, not via FET)
If you're changing the duty cycle to switch the LED on or off, there can be a
significant delay before the action takes effect. Switching the pin to input or
output works instantaneous.
In the "procedure hal()" you're calling "command_send_kamer()", which is
probably wrong?
You've got procedures for sending a bit, a byte and a full command. That is
good for readability, but not so good for signal quality. You send a burst of
450µs, and the following pause codes the bit. If you're at the end of a byte,
the bit procedure is ended, then the byte procedure is ended, then the loop in
the command procedure is forwarding one step, the byte procedure is called,
then the bit procedure is called, and just then there's the next burst. That's
quite some time passing, which can make a "0" look like a "1". Better collect
all the bits in a single variable, and send all 152 bits in one loop in one
procedure.
And even if not, this is using time in bad places:
teller = 0 for 19 loop if x == high then
command_send_kamer(HEAT_kamer[teller]) else
command_send_kamer(HALT_kamer[teller]) end if teller = teller + 1
end loop
This would be better:
if x == high then for 19 using teller loop
command_send_kamer(HEAT_kamer[teller]) end loopelse for 19 using teller
loop command_send_kamer(HALT_kamer[teller]) end loopend if
That way there's no "if" between the bytes.
Greets,Kiste
Am Dienstag, 5. April 2022, 11:47:50 MESZ hat hans <[email protected]>
Folgendes geschrieben:
Everything has its limits. We have tried to make a remotecontrol for his two
DAIKIN ACs. With PWM1, the case responds just fine withPMW2 not responding. The
IR LEDs are controlled with an npn. (swapped) . Wealso tried the 16F877a, same
result. On an AUDICITY we compared the IR resultson a TSOP , the IR leds
(swapped!)… Both look the same. The frequencies of thePMW varied from 35 to 40.
No effect.
So that's the end of the story for us and then just fiddlingwith one PWM, which
we then switch via hardware. Unless ……. Any of you have adifferent idea.
Attached program and picture
Op maandag 4 april 2022 om 13:52:34 UTC+2 schreef hans:
Thank s Kiste. oops, I've now replaced all on/off's with
set_dutycycle_percent(..) the program that I use works fine with PWM1 but not
with PWM2. So there must be a difference. Where should I look now?
Op maandag 4 april 2022 om 12:04:31 UTC+2 schreef Kiste:
Sorry, no.
PWM2_off() does not set the LED off, it switches off the PWM module and passes
control of the output pin back to the simple digital output. The digital output
can be randomly set to "on", you did not set it to "off".
If you want to keep PWM running and switch off the LED, use
pwm2_set_dutycycle_percent(0)
pwm2_on() and pwm2_off() is not switching the *output* to on or off, it starts
or stops the PWM module. If you want to set LED brightness, you don't want to
ever stop the module. It's like waiting at the traffic lights: You're setting
the car speed to zero (=duty_cycle(0)), but you don't switch off the engine
(=pwm_off()). If the street's going downhill, a switched off engine will not
surely prevent the car from moving. You need to use the right means for the
purpose of stopping the car.
Greets,Kiste
Am Montag, 4. April 2022, 11:43:01 MESZ hat hans <[email protected]>
Folgendes geschrieben:
Hi Kiste,PWM2_off() sets the led ON and PMW2_on () sets the light off..
regards Hans
Op maandag 4 april 2022 om 09:21:03 UTC+2 schreef Kiste:
Hi hans,
this is what the program should do if the LED is connected to RC1 and GND (with
resistor):
The LED will slowly light up from off to 99% within one second,then it will
fade from 99% to 1% within another second.
The LED stays at 1% for half a second
PWM is disabled, so the LED will reflect the port pin, which is undefined by
default, for half a second
Then, PWM is reactivated and the LED will resume at 1% for 5 seconds, before
starting over again.
That is not what you're seeing?
Greets,Kiste
Am Sonntag, 3. April 2022, 16:10:38 MESZ hat hans <[email protected]>
Folgendes geschrieben:
A question from a friend. Attached is a test program for the use of the second
PWM port C1. The results are opposite to the assignment. On is off and off is
on. See the end of the file, the LED would go on for a long time but then it is
just off
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/0fc3bf61-ee5b-435f-a883-fbe7e1f9188fn%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/977fd495-4f9e-40f7-b9eb-caa72e361cd4n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/a5691502-ada9-4089-8666-3a0399756e44n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/c3f11c7f-47d8-4eaf-bf6d-34bd4761f886n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/62993504-3109-4598-8403-ec920d7d63e9n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/f1b63cef-cffd-4129-8704-6f35adcc0fbcn%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/878776458.1054347.1649234094034%40mail.yahoo.com.
