Dimming while receiving serial

[Adam]

pic16f627 with internal osc, icprog, picbasic pro, jdm programmer

first of all without any serial stuff:

aval var byte
aval = 0
loop:
low portb.0
     for i = 255 to 0 step -1
     if aval = i then
        high portb.0
        endif
        pauseus 39
    
     next i
     pauseus 55
goto loop

This makes the led not full brightness, but I would say about theird to half on, why? it should be only 1/255th on, so hardly visible.

Then when I put a hserin command in between pauseus55 and goto loop, it makes it full brightness, almost like the command is waiting a long while, I thought hserin didn't do this, just passed the command to the hardware usart and carried on with the program pretty quickly?

 

[Exo]

Then when I put a hserin command in between pauseus55 and goto loop, it makes it full brightness, almost like the command is waiting a long while, I thought hserin didn't do this, just passed the command to the hardware usart and carried on with the program pretty quickly?

HSerIn uses the hardware usart but still uses polling to retrieve the data, not interrupts. So code execution will still wait until the data is received.

Why don't you use the 16f627 internal PWM to dim your led? would be a lot easyer and allows the pic to do other things.

 

[Adam]

Why don't you use the 16f627 internal PWM to dim your led? would be a lot easyer and allows the pic to do other things.

Sorry, didn't mention it in the first post, but I am planning on dimming 8 leds at at the same time, from 8 bytes received through serial, is there a flash pic which has 8 hpwm channels, works with picbasic, icprog and a jdm programmer, and is resonably priced (or available as a microchip sample :wink: )

 

[Exo]

No, there isn't any pic with 8 HPWM channel's.

Simplest would be to receive the bytes from the hardware usart using interrupts. check the datasheet for details.

 

[Adam]

Thanks for your help so far, but I have more problems:

@ device INTRC_OSC_NOCLKOUT
cmcon = 7
INTCON = %10010000

DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 20h
DEFINE HSER_BAUD 2400

Include "modedefs.bas"

On interrupt goto rec

i var byte
aval var byte
bval var byte
cval var byte
dval var byte
eval var byte
fval var byte
gval var byte
hval var byte

aval = 1
loop:
if aval > 0 then
  high portb.2
endif
for i = 1 to 255
pauseus 50
if i = aval then
   low portb.2
endif
next i

goto loop

rec:
disable
HSERIN [aval, bval, cval, dval, eval, fval, gval, hval]
enable
resume

END

The above code dimmed properly before the interupt code was added, according to the value specified in the basic program, but now the interrupt code has been added, it keeps the led on almost full brightness all the time, even when I disconnect the interupt pin (I haven't tried sending anything to it yet anyway)

 

[Exo]

You can configure the hardware usart to generate an interrupt when it has received something. This way, all the interrupt routine has to do is get the byte that was just received immidiately without havinfg to wait for something to come in...

Search the microchip website for application notes about serial using interrupts. They're in assembler, so I guess this is one of those cases you should know assembler, even if you use basic.

 

[Adam]

I think I had the register bits wrong, changed them to

PIE1=%00100000 
INTCON = %11000000

But it didn't make a blind bit of difference

 

[Adam]

What really puzzles me is why the led goes almost to full brightnes with the interrupt code in there, it must be going to the interrupt part of the code and waiting for hserin, but why?

 

[Exo]

You should only receive 1 byte in your interrupt routine, not 8...

An interrupt will be generated when 1 byte is received, so your pic will go to the interrupt routine and directly fetch the first byte, but then it has to wait again for the second...

You should receive 1 byte at a time, store it in memory, wait until all 8 are received and then use them.

 

[Adam]

I haven't even sent anything yet, there is nothing being sent to the usart, yet the pressence of the interrupt code prevnts the dimming from working

 

[Exo]

Have you tried clearing all interrupt flags before enabling interrupts?
And your interrupt routine should also clear RCIF after it has read the usart btw.

The fact that you use basic makes it more complicated (to me). because we don't know what actually happens in the background.

 

[Adam]

Have you tried clearing all interrupt flags before enabling interrupts?
And your interrupt routine should also clear RCIF after it has read the usart btw.

Do you know offhand how I could do this?

The fact that you use basic makes it more complicated (to me). because we don't know what actually happens in the background.

Looked at some assembler code a while back, and didn't like the look of it :lol:

 

[Adam]

I have added the following code, but again it has not made a difference

PIR1=%00000000

 

[Nigel Goodwin]

Looked at some assembler code a while back, and didn't like the look of it :lol:

This is a typical example of what I always say, "you can't use a BASIC compiler (or any other compiler) effectively without a reasonable knowledge of assembler".

A decent knowledge of assembler allows you to know what is happening, and why you do things a certain way, and (possibly more important) why you don't do things a certain way!.

As Exo and Adam have already mentioned, you shouldn't be reading your serial input from within the interrupt routine, the hardware USART should do this transparently and trigger an interrupt when data has been received.

It's also probably not a good idea to use software loops to generate your PWM, any extra cycles needed elsewhere (as for interrupts) will change the timing - as you've found. It's probably a better idea to use timer interrupts for the PWM instead.

 

[williB]

The PWM module has the following features:
• 8 PWM I/O pins with 4 duty cycle generators
• Up to 16-bit resolution
• ‘On-the-Fly’ PWM frequency changes
• Edge and Center Aligned Output modes

this is from the data sheet of the dsPIC30F
page 103.

**broken link removed**

 

[Exo]

The PWM module has the following features:
• 8 PWM I/O pins with 4 duty cycle generators
• Up to 16-bit resolution
• ‘On-the-Fly’ PWM frequency changes
• Edge and Center Aligned Output modes

this is from the data sheet of the dsPIC30F
page 103.

**broken link removed**

Its a bit overkill to use dsPIC to dim a few led's don't you think ?

 

[Exo]

It's also probably not a good idea to use software loops to generate your PWM, any extra cycles needed elsewhere (as for interrupts) will change the timing - as you've found. It's probably a better idea to use timer interrupts for the PWM instead.

I don't think the small overhead of retrieving a byte from the usart and storing it will make much of a visual diffirence in led intensisty...

 

[Nigel Goodwin]

I don't think the small overhead of retrieving a byte from the usart and storing it will make much of a visual diffirence in led intensisty...

Not for a correctly written routine, triggered by the USART interrupt.

 

[Adam]

I have now tried what I think you are telling me is a proper way, have the usart buffer the character, and generate an interrupt then read character out of buffer, but this line to enable the hardware usart causes the led to go on at full brigness (like before)

RCSTA=%10010000

 

[Nigel Goodwin]

I have now tried what I think you are telling me is a proper way, have the usart buffer the character, and generate an interrupt then read character out of buffer, but this line to enable the hardware usart causes the led to go on at full brigness (like before)

Have you changed your interrupt routine?.