Bit Angle Modulation (BAM) in a PIC

[sanch0]

It's amazing how many people have come here to tell me that the Mirror Image won't fix BAM's blinking problem.

With the mirror image, there is absolutely NO blinking AT ALL. (Not even with a video camera).

Of course everyone admits that they've never even tried it.
But yet they still feel it's ok to tell the world that it won't work.

All I can do is return the favor ...
16 channel, 14-bit BAM, at 610hz, with a PIC, is IMPOSSIBLE.

It was bad enough when you said 13-bit. But now with 14-bits, the minimum period would be 0.1 µS. There's NO WAY you can set 16 outputs to the desired states with only one instruction, then set them all to new states on the very next instruction.

But then ... "I've never tried it".
<br>

Sorry for my poor english, maybe u hadn't understood me as it was supposed. I don't want to flame here... i feel a bit tired myself and i'm way too lazy now to start explanation again. I had thought to upload code here, but now i'm not sure of your reaction. Maybe even then u gonna blame me). Just read my previous posts again. But i don't want to disappoint u and u a free to think that i'm lousy liar))) Actually i started to code in ASM 17 years ago. And i don't have to prove nothing here. Yes, it works. Yes i didn't tried MIBAM yet with _MY_ 14 bit _BAM_ code (which was written about half year ago). I work periodically for local advertising companies and earn some $$$ from things i develop using my older 13 bit code for 18F, which actually isn't BAM nor "clear" PWM. (which, btw could also be upgraded to 14 bit 610Hz, but don't ask me how, as i had already described it). Sorry, do not have enough strength to continue that, i feel myself wasted a bit 8] best regards....

[sanch0]

example... sorry it's static...

[Darrel Taylor]

... Yes i didn't tried MIBAM yet with _MY_ 14 bit _BAM_ code (which was written about half year ago). ...

I'm sorry you're so tired, and I wouldn't want you to waist any more of your time.
I'm sure trying to explain something that's IMPOSSIBLE would really take a lot out of you.

But if it makes it any easier for you ... I don't need to see your whole code, or have a big explanation with pictures and billboards.

But I would like to know how you got past this one single problem.

... with 14-bits (BAM @ 610Hz), the minimum period would be 0.1 µS. There's NO WAY (a PIC) can set 16 outputs to the desired states with only one instruction, then set them all to new states on the very next instruction.

Since you do ASM, it's only 2 lines of code.

I would be apologizing profusely for weeks to come if you could.
<br>

[sanch0]

What exactly do you mean saying "single problem"? u have just described 2 problems) IMHO. of course u can't operate 2 ports at the same time, but u can make somekind of "interleaving" and operate them separately. Here comes out one problem we had spoke about it above - blanking interval. If only 16 channels (actually even more) needed, this could be solved in two ways - design more complex code avoid it (but it's very hard and non-effective combined with time-excessive code for maximum refresh rates and resolutions (more than 8 bits of output per channel); u can just increase LED current accordingly or u can just forget it, as human eyes (actully because of brain's perception algo, which integrates all incoming signals))) do not see much difference between duty cycles of 100% and 90%, or even less.
More serious problem is to make 1Tcy output discretization. But i described this trick before - this could be done using state prediction in code - u can _change_ (set or clear 8 bit of file register and set, reset or toggle single bits) for example using CLRF [filereg] command (or SETF, ANDWF, IORWF, ADDWF and all other byte-oriented commands) in proper place of execution stream. Of course u can't copy value from other location or modify port value in single 1Tcy instruction). It works, i didn't lie.

I didn't sayd that MIBAM doesn't work!!!

i said:
"I think that simple signal mirroring doesn't help to fully avoid flicker(s), it just makes it significantly lower, but maybe also affects visual perception of signal "decreasing" actual refresh rate."
as u can see, i didn't said that i'm sure MIBAM doesn't work (?), it was "suggestion", of course.

[btw, how can u measure flicker power or detect flicker existance when it appear at lower bit transition. This "flicker" effect depends on individul perception's sensetivity and many "watching" conditions. There is such science called psychophysiology, if i'm right).]
I still suppose that MIBAM DO have some minor disadvantages!

First - lower "refresh rate" (it's very important for most of my designs, as i like to get _PERFECT_ fadings, color slides or animations, as i'm very expirienced in this stuff, believe me. Most people accept much lower visual quality and even do not see any differences at all, where i see it) Maybe it could be also avoided forcing some blanking between two MIBAM parts? it should help...

Second - - floating period phase and frequency of signal. it's advantage too, as it decreases EMI amount generating in wider spectrum range without spikes on certain frequencies))). actually it's not realy important for most simple projects. situation changes when u work with huge led amounts, huge currents, long wires, when u must take into account effects of parasitic capasitances, inductivities, switching delays with specific LED drivers etc.

It's important to me to find compromises between time/memory-excessive code, it's complexity, resolution and speed, as i want to use LP INTs to
communicate at higher bitrates. Unfortunately, low-end PIC MCUs do not have larger FIFO buffers. With my present 13/610 PWM code only about 150 kbps speed could be achieved. And code itself uses significantly more RAM than my "flickering" 14/610 BAM, so i search for best suitable desicion for my designs and my aesthetic requirements (visual influence))).

Btw, if u didn't noticed, I thanked You for good work. And now I especially thank RadicalQ3, as his post helped me to select directions of my "engine" development. Somewhen later (got much other things to do, too) i could share some of my achievements with you, if you interested. But i'm not interested in disputes too much)))

[lanyong]

sanch0

i can understand u.

u r right.

u can do 14bit for 16 channel.

as some limlit precondition.

1:ur video don't be too high, such as 60Hz

2:ur 16 channels are not at the same phase position.

u r relly a genius.

[lanyong]

pls give us a code for generateing

the 14bit 610Hz such as 10 1010 1010 1010 a channel.

output_low(pin_a0);
output_toggle(pin_a0);
delay_cycles(2);
output_toggle(pin_a0);
delay_cycles(4);
output_toggle(pin_a0);
delay_cycles(8);
output_toggle(pin_a0);

.....

hahaha.

[lanyong]

pls give us a code for generateing

the 14bit 610Hz such as 10 1010 1010 1010 a channel.

output_low(pin_a0);
output_toggle(pin_a0);
delay_cycles(2);
output_toggle(pin_a0);
delay_cycles(4);
output_toggle(pin_a0);
delay_cycles(8);
output_toggle(pin_a0);

.....

hahaha.

movff two cycles.

so 13bit 610Hz is easy.
14bit 610Hz is hard

[lanyong]

sanch0

u r a very valuable programmer.

ur boss is so fortunate.

[Darrel Taylor]

movff two cycles.

so 13bit 610Hz is easy.
14bit 610Hz is hard

I agree, movff could set 8-outputs, using 2 cycles.
The other 8-outputs would take another 2 cycles, for a total of 4.

With a PICrunning at 40Mhz, that would take 0.4 µS.
At 14-bit resolution there are 16384 divisions of the period, so 0.4µS * 16384 = 0.0065536 Sec. for the entire BAM cycle.

Which means that the MAXIMUM refresh rate for 16 channels of 14-bit BAM is 152.5 HZ (1 / 0.0065536).
At 13-bit resolution, the MAX refresh is 305.1 Hz (1 / 0.0032768).

So I reiterate ....

16 channels of 14-bit BAM, at 610Hz ... IS IMPOSSIBLE.
<br>

[sanch0]

I agree, movff could set 8-outputs, using 2 cycles.
The other 8-outputs would take another 2 cycles, for a total of 4.

With a PICrunning at 40Mhz, that would take 0.4 µS.
At 14-bit resolution there are 16384 divisions of the period, so 0.4µS * 16384 = 0.0065536 Sec. for the entire BAM cycle.

Which means that the MAXIMUM refresh rate for 16 channels of 14-bit BAM is 152.5 HZ (1 / 0.0065536).
At 13-bit resolution, the MAX refresh is 305.1 Hz (1 / 0.0032768).

So I reiterate ....

16 channels of 14-bit BAM, at 610Hz ... IS IMPOSSIBLE.
<br>

Are u blind? What u just wanna prove iterating yer silly cycles, just try to return from yer subroutine, or generate some interrupt for yer brains. Try to think. I have these devices perfectly working and even more - they work pretty much time ago. I took much time to develop first working 13/610. 14bit isn't finished a bit, but i only need to delete flickers or improve BAM engine code + speed up comm bitrates + add more channels.


What do u see so impossible in my devices? Perhabs u think that if u can't do something, or u do not understand how it works, nobody could make it in whole Universe? U are such amazyng man, dude.... Stop smoking or eating much fastfood stuff) Just look for some "state-of-the-ART" code wroten for demoscene... U'll be surprised by the level of optimization and execution speed of some algos, just compare it with most of MS code - sometimes it very hard to understand way it works.

Ok, i would to share my secret ONLY WITH U!!! Actually 3 little green men from other galaxy just gave me much power to heal people, kill them also or make any Microchip MCU's work several times faster and presented me their magic LED-driver engines working far beyond the limits of physics laws (in your opinion))))

[lanyong]

haha, don't bicker.

16 channels of 14-bit BAM, at 610Hz ... IS POSSIBLE

i know the secret,haha.

in fact u have many time to handle the datas.

u only want to how to find a way to change the H/L in one cycles.

sanch0, u r right! where r u?

I am in Shanghai, China. Nice to meet u.


Darrel Taylor, everything is possible

the world is really magical

[lanyong]

which book?

i will read them.

[Darrel Taylor]

Whatever ....

My case has been made.
Anyone who knows anything will know the difference.

And apparently we will never see eye to eye.

Onward ... Through the fog ...
<br>

[lanyong]

Whatever ....

My case has been made.
Anyone who knows anything will know the difference.

And apparently we will never see eye to eye.

Onward ... Through the fog ...
<br>

we will learn from sanch0.

he is a program expert.

[sanch0]

haha, don't bicker.

16 channels of 14-bit BAM, at 610Hz ... IS POSSIBLE

i know the secret,haha.

in fact u have many time to handle the datas.

u only want to how to find a way to change the H/L in one cycles.

sanch0, u r right! where r u?

I am in Shanghai, China. Nice to meet u.


Darrel Taylor, everything is possible

the world is really magical

Hi there! I'm from Tallinn / ESTONIA / EU
Very nice to meet u too.

I'll show u how to increase resolution to 1Tcy later, just do not have time now. I don't like to upload or post something unfinished. I don't use much comments in code and some of them are in russian. So when i finish my work on development, i should make code look better and more clear for anybody and for myself too)).

[Darrel Taylor]

I wait with baited breath for your code.

Just be aware ...
I'm going to tell you why it doesn't do what you think it does.
<br>

[sanch0]

And I use only pure ASM code for such relatively slow MCUs, of course...

p.s. please don't expect me to do it very soon, as i have to finish some other projects too. Firstly I must repair of girlfriend's apartment and after that I planned to develop some mechanics for other project. It could take 2 weeks, i hope. Sorry. Hope u'll be patient.
Darrel Taylor: )))))))))))))))))))))))))))))))))))))))))))))
It do what it supposed to do, not less not more.)) I've got enough measurement tools and other stuff to be 100% sure what i'm saying. And even i hadn't any of them... I don't just put MCU instructions into text file randomly. I know what i'm doing _exactly_, Darrel. I started studying electronics and ASM (for Z80 - first programming language i studied and used, M68K, PIC, AVR, x86 etc.) from my childrenhood, so i know what about i'm talking. U just have not any chanse, Darrel))))

[lanyong]

And I use only pure ASM code for such relatively slow MCUs, of course...

because u can share ur code.

so i say the secret,haha.

we can get A[0],A[1],,,A[13].

then

move A[1] to W.

then

movff A[0], PORTA
movwf PORTA

then we changer the H/L in a cycle.

have a good time.

haha.

[lanyong]

from ur childrenhood.

my god.

too young,haha.

i learn mcu in Unversity only.

[sanch0]

because u can share ur code.

so i say the secret,haha.

we can get A[0],A[1],,,A[13].

then

move A[1] to W.

then

movff A[0], PORTA
movwf PORTA

then we changer the H/L in a cycle.

have a good time.

haha.

Yep=)))
It's something like that.


btw, i had got my first shocks from electronics when i tryed to understand how my photoflash works. There was ~1000V on capacitor after trafo, but it didn't scare me) i was 5 years old then)

[lanyong]

Yep=)))
It's something like that.


btw, i had got my first shocks from electronics mosquitowhen i tryed to understand how my photoflash works. There was ~1000V on capacitor after trafo, but it didn't scare me) i was 5 years old then)

but it is a secret for me.

we can use the 1000v to electronic mosquito,

[Mike, K8LH]

Darrel,

I think these Gentlemen may be having a little fun at your expense as they try to get a rise out of you (LOL). That's the only reason I can think of for avoiding a simple question and for becoming a bit offensive when challenged.

My precalculated "output table" or "toggle table" MIBAM method should work fine with 13 or 14 bit duty cycle values but as you've already determined I can only get refresh rates of 610-Hz (8-chan, 13-bit, 200-nsec step) or 305-Hz (16-chan, 13-bit, 400-nsec step), etc., when using an 18F' device and 40-MHz clock (Tcy = 100-nsec). ISR "overhead" would be about 77% for the example below but could be improved with some structural changes.

Take care. Kind regards, Mike

;
;  8-chan (port b), 13-bit, 200-nsec (1638.4-usec period), 610-Hz
;
v_isr_h
        movff   bdat+12,LATB    ; b12 data        (2048T)
        inDlyCy(2048*tStep-2)   ; half 2^12
        movff   bdat+11,LATB    ; b11 data        (1024T)
        inDlyCy(1024*tStep-2)   ; half 2^11
        movff   bdat+10,LATB    ; b10 data        (512T)
        inDlyCy(512*tStep-2)    ; half 2^10
        movff   bdat+09,LATB    ; b9 data         (256T)
        inDlyCy(256*tStep-2)    ; half 2^9
        movff   bdat+08,LATB    ; b8 data         (128T)
        inDlyCy(128*tStep-2)    ; half 2^8
        movff   bdat+07,LATB    ; b7 data         (64T)
        inDlyCy(64*tStep-2)     ; half 2^7
        movff   bdat+06,LATB    ; b6 data         (32T)
        inDlyCy(32*tStep-2)     ; half 2^6
        movff   bdat+05,LATB    ; b5 data         (16T)
        inDlyCy(16*tStep-2)     ; half 2^5
        movff   bdat+04,LATB    ; b4 data         (8T)
        inDlyCy(8*tStep-2)      ; half 2^4
        movff   bdat+03,LATB    ; b3 data         (4T)
        inDlyCy(4*tStep-2)      ; half 2^3
        movff   bdat+02,LATB    ; b2 data         (2T)
        inDlyCy(2*tStep-2)      ; half 2^2
        movff   bdat+01,LATB    ; b1 data         (1T)
        inDlyCy(1*tStep-2)      ; half 2^1 (0 delay)
        movff   bdat+00,LATB    ; b0 data         (1T)
        inDlyCy(1*tStep-2)      ; full 2^0 (0 delay)
        movff   bdat+01,LATB    ; b1 data         (1T)
        inDlyCy(1*tStep-2)      ; half 2^1 (0 delay)
        movff   bdat+02,LATB    ; b2 data         (2T)
        inDlyCy(2*tStep-2)      ; half 2^2
        movff   bdat+03,LATB    ; b3 data         (4T)
        inDlyCy(4*tStep-2)      ; half 2^3
        movff   bdat+04,LATB    ; b4 data         (8T)
        inDlyCy(8*tStep-2)      ; half 2^4
        movff   bdat+05,LATB    ; b5 data         (16T)
        inDlyCy(16*tStep-2)     ; half 2^5
        movff   bdat+06,LATB    ; b6 data         (32T)
        inDlyCy(32*tStep-2)     ; half 2^6
        movff   bdat+07,LATB    ; b7 data         (64T)
        inDlyCy(64*tStep-2)     ; half 2^7
        movff   bdat+08,LATB    ; b8 data         (128T)
        inDlyCy(128*tStep-2)    ; half 2^8
        movff   bdat+09,LATB    ; b9 data         (256T)
        inDlyCy(256*tStep-2)    ; half 2^9
        movff   bdat+10,LATB    ; b10 data        (512T)
        inDlyCy(512*tStep-2)    ; half 2^10
        movff   bdat+11,LATB    ; b11 data        (1024T)
        inDlyCy(1024*tStep-802) ; half 2^11
        rcall   prep            ; rebuild bdat array
        movff   btmp,LATB       ; b12 data        (2048T)
        retfie  FAST            ;
;

[Darrel Taylor]

Thanks for the Backup Mike.
It's nice to see somebody else gets the same numbers.

I'm making some progress with the "full-port" modification to MIBAM.

Actually doing the outputs is easy, just like you showed previously.
But I'm still having problems letting the user assign pins at random.

It's getting there, although a bit slower than anticipated.
<br>

[sanch0]

Thanks for the Backup Mike.
It's nice to see somebody else gets the same numbers.

I'm making some progress with the "full-port" modification to MIBAM.

Actually doing the outputs is easy, just like you showed previously.
But I'm still having problems letting the user assign pins at random.

It's getting there, although a bit slower than anticipated.
<br>

that's nice, but not so effective at all. interleaving could be used to get more channels at the same freq. and something else to get 100ns discretization.)))

[boroko]

Hi all,
I had a question that seems to have gotten lost in the fray....

I'm trying to use other interrupts in hardware functions while using MIBAM.
Specifically, a CCP HI/LO capture or USUART. the stand alone MIBAM examples work wonderfully, but when I try and incorporate a lo priority pulse capture or do comm, I run into problems. Is there a way to use incorporate the other ints and still use MIBAM? I have resorted to using a second PIC, but that isn't very elegant.

Thanks for thinking about it.
Bo

[Darrel Taylor]

Hi Bo,

If you're using an 18F, then sure ... you can have Low Priority interrupts running too. But I don't think you need interrupts for that stuff.

With MIBAM ... <strike>99.4%</strike> 94% of the processor time is un-used. It's just sitting around twiddling it's thumbs. (if it has any)

And since "capture's" retain the captured value for a while, they can easily be handled in the main loop by polling the CCPIF flag.

I've also run the USART at 250kbaud for DMX reception, again strictly polled in the main loop, while MIBAM runs in the background.

So much time ... so few things to do ... if only life were like that.
<br>

[boroko]

Thanks Darrel for the timely reply.

Yes, I'm using an 18F1320.
I guess that I was still thinking in terms of SPWM_INT where your available processor time was limited. I didn't realize that MIBAM left so much to play with.

I have been trying to get them combined and I have it to the point that the only errors that I get are 3x "Symbol not previously defined (_doBam)". I haven't gotten it to compile, so I may be way off anyway. Don't know.

I might try to better understand the magic static later, but for now,with your enlightenment, I'm going to change directions and just poll the flag.

"Not as smart as tomorrow, but smarter than yesterday!"

Thanks
Bo

[sanch0]

Hi Bo,

If you're using an 18F, then sure ... you can have Low Priority interrupts running too. But I don't think you need interrupts for that stuff.

With MIBAM ... <strike>99.4%</strike> 94% of the processor time is un-used. It's just sitting around twiddling it's thumbs. (if it has any)

And since "capture's" retain the captured value for a while, they can easily be handled in the main loop by polling the CCPIF flag.

I've also run the USART at 250kbaud for DMX reception, again strictly polled in the main loop, while MIBAM runs in the background.

So much time ... so few things to do ... if only life were like that.
<br>

This stuff would work for low-current balanced circuits or if don't need much accuracy and precision in result. Background? hmm.... If want get better results u should use HP Interrupts to minimize jitter and other timing errors. For 18F U should T2 Ints (or check and update timers everytime in HP ISR to avoid jitter). In more complicated designs parameters of switching element (or specialised driver) should be taken in to account. Sorrry for repeating what i've said earlier. P.S. Hope u wount blame be again, as the truth is far outhere) Best REGARDzzz.

[boroko]

Thanks Darrel for the advise.... sadly, I'm still having problems....

To all that care to give me some advise:
I have tried cleaning up my code so that I can check flags often enough to avoid missing the comm coming in through the USART. The PWM is fairly dynamic and seems to blow up the comm (OERR) if I enable more than one of the LED subroutines. I have tried to use low priority INTS, and didn't get it sorted out, I have tried to use a pattern similar to Darrel's in http://www.picbasic.co.uk/forum/showthread.php?t=4972 #16, but I haven't managed that yet either. Any advise would be appreciated.

'*  Notes   : derived from Darrel Taylor & Mister E's work     
'*          : 18F1320a @ 8 mHz, PWM Freq = 95 Hz
clear
DEFINE OSC 8
OSCCON  = %01110001         ' INTOSC primary, 8MHz 
INCLUDE "AllDigital.pbp" 
include "EE_Vars.PBP"       ' manipulation of EEPROM
BAM_COUNT CON 8             ; BAM Pins are used?
INCLUDE "MIBAM.pbp"         ; 

;----[ MIBAM Setup ]-------------
BAM_DUTY  VAR BYTE[BAM_COUNT]
  LED1    VAR BAM_DUTY[0]           ; array for easy access
  LED2    VAR BAM_DUTY[1]           ; with FOR loops etc.
  LED3    VAR BAM_DUTY[2] 
  LED4    VAR BAM_DUTY[3] 
  LED5    VAR BAM_DUTY[4] 
  LED6    VAR BAM_DUTY[5] 
  LED7    VAR BAM_DUTY[6] 
  LED8    VAR BAM_DUTY[7] 

ASM
BAM_LIST  macro                     ; Define PIN's for BAM
     BAM_PIN (PORTB,5, LED1)        ;   and Duty variables
     BAM_PIN (PORTB,0, LED2)
     BAM_PIN (PORTA,3, LED3)
     BAM_PIN (PORTA,2, LED4)
     BAM_PIN (PORTA,1, LED5)
     BAM_PIN (PORTA,0, LED6)
     BAM_PIN (PORTA,7, LED7)
     BAM_PIN (PORTB,2, LED8)
  endm
  BAM_INIT  BAM_LIST                ; Init Pins
ENDASM

DEFINE HSER_RCSTA 90h ' En serial port & cont rx
DEFINE HSER_TXSTA 24h ' En transmit, BRGH = 1
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 160 ' 4800 Baud @ 8MHz, -0.08%
SPBRGH = 1
BAUDCTL.3 = 1         ' 

address      var byte
command      var byte        
charcnt      var byte        '
Cnt          var byte        ' counter for ramping the display brighter
Counter      var byte
CyLoop       var word        ' MAY be able to combine this later
Dly          var byte        ' used on delay loop sub
holdoff      var word
i            var byte
IDloop       var byte        ' loop cntr in ID Loop
Idx          VAR BYTE
loop         var byte
LoopCount    VAR WORD: LoopCount = 0        ' from Random Sub
ModeCnt      var byte: @ EE_var _ModeCnt, BYTE, 8 ' count flashes of 1&8 LEDs when Switch
NextLED      VAR BYTE: NextLED   = 1
PowerOn      VAR WORD: @ EE_var _PowerOn,  WORD, 0     '
RandVar      var word: RandVar  = 12345
RandVar8     var byte            '
SerialString var byte[40]         '
Speed        VAR BYTE: @ EE_var _Speed, BYTE, 50 ' delay length /control speed
state        var byte         ' condition bits
state2       var byte         ' condition bits
time         var WORD         ' delay loop sub
temp         var byte
value        var byte
Sync         VAR state.0        ' Sync byte rcvd
ForMe        VAR state.1        ' Packet is for this device
CmdRcvd      VAR state.2        ' flag for Command  rcvd
CntState     var state2.0       ' flag for counting pulse
ERROR        VAR state.3        ' Sync rcvd out of order
header       var state2.2
tlate        VAR state.4        ' command rcvd before last one done
ValRcvd      var state.5        ' flag: Value data rcvd 
Success      var state.6
idle         var state.7        ' flag: idle polarity  
TraceDIR     VAR state2.1       ' cyclon
CREN         var RCSTA.4        ' RX enable bit
OERR         var RCSTA.1        ' Overrun  error
RCIF         VAR PIR1.5         ' Receive  int flag (1=full , 0=empty)
TXIF         VAR PIR1.4         ' Transmit int flag (1=empty, 0=full 
Brightness   CON 100            ; Tracers DutyCycle
ID           CON 123            ' ID. unique to each, 255=all
SyncByte     CON 85             ' "U" for SYNC. constant on all 
TracerSpeed  CON 15             ; Smaller = Faster L-R
DrainSpeed   CON 30             ; Smaller = Shorter Trail       

'*************************
Main:
' once comm is figured out, Command will be used for selecting ModeCnt or speed 
' and value will be the rate that it flashes the LEDs  
     
'ManMod: 
'    branch ModeCnt,[fadem,smoothm,rampm,twinklem,cyclonm,dimm,RanMainm,IDm,autom]' 
'.....
      
'autom:
        gosub FadeUp
        gosub SmoothUp        ' as soon as I enable more than one-
'        gosub Fillup         ' comm starts to get erratic
'        gosub StrobeUp
'        gosub cyclon
'        gosub drvdim                
'        gosub RanSub
'        gosub shoid        
goto Main:
'**********Sub for polled comm *********
RX:
   IF OERR then
hserout ["OERR", 13,10]
      CREN=0
      CREN=1
      endif
getcomm:      
      i=RCREG                  ' take it        
      if header then
          if i ="#" then Discard  ' is it the end? "#" = yes   
        Serialstring[Counter]=i ' Store into the array
        Counter=Counter+1
        endif 
       if RCIF then getcomm     'try again of still data
      if i ="!" then header=1 ' header character? "!" = yes         
      Discard:
          while RCIF
                temp=RCREG
          wend
    
          if i="#" then       ' End of String character
             Success=1        ' Yeah i got a valid string
             header=0
          endif
  
   if Success then
      CREN=0                  ' Disable Receiver 
      address =  Serialstring[0]   'do deciphering here
      command =  Serialstring[1]
      value   =  Serialstring[2]
      
      hserout ["Str rx : ",str Serialstring\Counter," Ch : ", dec Counter,13,10]
      CREN=1                  ' Enable receiver
      Counter = 0
      Success = 0
      endif
return   

'***** Timing Sub:   *****
DlyTime3:                    ' longest delay loop
     for time = 0 to speed   
     next time
DlyTime2:                    ' mid delay loop
     for time = 0 to speed   
     PAUSE 2
     next time               
DlyTime1:                    ' smallest delay loop
     for Dly = speed to 0 step -1
     if RCIF then             ' check here for a comm flag r
        gosub RX              ' and get the character
        goto short            ' reduce delay, avoid blinking 
     endif
     PAUSEUS 180              ' times need to be refined
Short:
      'pauseus 5              ' times need to be refined
     next Dly
return 

'**********************      
' Subs for patterns
'
'***** Fade Sub: MODE 0  ******
FadeUp:
       hserout ["fadeUp",13,10]
   for  cnt = 0 to Brightness      ' fade up 
    gosub DlyTime1
    LED1 = Cnt: LED2 = Cnt: LED3 = Cnt: LED4 = Cnt
    LED5 = Cnt: LED6 = Cnt: LED7 = Cnt: LED8 = Cnt           '
   next Cnt                    ' 
hserout ["fadeDown",13,10]
FadeDown:        
   for  Cnt = Brightness to 0  step -1 ' fade down
    gosub DlyTime1
    LED1 = Cnt: LED2 = Cnt: LED3 = Cnt: LED4 = Cnt
    LED5 = Cnt: LED6 = Cnt: LED7 = Cnt: LED8 = Cnt           '
   next Cnt                     '
return                           'stay in fade loop 
'**** Smooth Sub: MODE 1 ******
SmoothUp: 
          hserout ["SmoothUp",13,10]  
   for loop = 0 to 7
   BAM_DUTY(loop) = Brightness           ' smooth up
   gosub DlyTime2
   BAM_DUTY(loop) = 0
   next loop
  
SmoothDown:
           hserout ["SmoothDown",13,10]
   for loop = 6 to 0 step -1
   BAM_DUTY(loop) = Brightness           ' smooth up
   gosub DlyTime2
   BAM_DUTY(loop) = 0
   next loop
   RETURN
'*****  Ramp Sub: MODE 2 ******
' .......
'
end

Thanks
Bo

[Darrel Taylor]

Hi Bo,

At 4800 baud, each byte takes about 2.1 mS.
The USART has a 2.8 byte buffer, so at around 6 mS the USART buffer will overflow.

In the DlyTime2 section, it will loop 50 times with a 2mS delay without checking the USART.
By the time it's finished, the buffer is very likely to have overflowed.

I think if you do the same thing you did in DlyTime1, and check the RCIF bit inside the loop, it will have a better chance.

And as you work on the rest of the program, look for any of those Evil PAUSE statements.
Anything more than 4ms will have to be broken in smaller loops with RCIF checks in the middle.

Added:
Another method might be to use ON DEBUG, with only the Delay routines ENABLEd.
Then it would be able to check RCIF in-between each and every statement in the delay routine without actually having to write the checks into the routine.

hth,

[sayzer]

It would be very handy if we could use a shift register with MIBAM to multiplex the outputs.

In that case, we could use a small PIC like 12F629 or 675, then use 74HC595 type of shift registers and get as many outputs as we want, with the possible limitations of course.

BTW; I am getting flickering at 4Mhz even with RGB routine only.

-------------

[ShortBus]

I'm having problems compiling the sample code. Would you have any suggestions?

;----[ MIBAM Setup ]--------------------------------------------------------
BAM_COUNT CON 3                     ; How many BAM Pins are used?
INCLUDE "MIBAM.pbp"                 ; Mirror Image BAM module

RED    VAR BYTE
GREEN  VAR BYTE
BLUE   VAR BYTE

ASM
BAM_LIST  macro                     ; Define PIN's to use for BAM
     BAM_PIN (PORTB,0, RED)         ;   and the associated Duty variables
     BAM_PIN (PORTB,1, GREEN)
     BAM_PIN (PORTB,2, BLUE)
  endm
  BAM_INIT  BAM_LIST                ; Initialize the Pins
ENDASM
;___________________________________________________________________________

Assembler output:

project.asm 257: Symbol not previously defined (wsave)
project.asm 260: Symbol not previously defined (ssave)
project.asm 262: Symbol not previously defined (psave)
project.asm 388: Symbol not previously defined (psave)
project.asm 390: Symbol not previously defined (ssave)
project.asm 392: Symbol not previously defined (wsave)
project.asm 393: Symbol not previously defined (wsave)

[Darrel Taylor]

In the MIBAM thread. The second post lists the typical Error/Warning messages you might encounter.

In your case, you need to add the wsave block shown in Post#1.
<br>

[boroko]

At 4800 baud, each byte takes about 2.1 mS.
The USART has a 2.8 byte buffer, so at around 6 mS the USART buffer will overflow.

Sorry I didn't get back. Thank you, that was where I missed it.

Bit of a lull as I wait for a new meLabs serial programmer. For some reason the 18F2550 decided to become a heating element instead of a processor. Alas, it lived a good life.... Couldn't be EOC, could it? (Excessive Operator Carelessness). Had to dig out an old laptop that still had a parallel port to run the EPIC programmer.

Bo

[talatsahim]

Hallo
will work mibam with hserin on 16F828?

[Darrel Taylor]

will work mibam with hserin on 16F828?

Yes it will.

[talatsahim]

Yes it will.

Sorry, my very poor english.
Im new pbp user.
can you help me why not work my code?
Device 16F628

DEFINE OSC 20
CLEAR

;_________________________Interrupt Context save locations]_________________

wsave       var byte    $20     SYSTEM      ' location for W if in bank0
wsave1      VAR BYTE    $A0     SYSTEM      ' location for W if in bank1
wsave2      VAR BYTE    $120    SYSTEM      ' location for W if in bank2
ssave       VAR BYTE    BANK0   SYSTEM      ' location for STATUS register
psave       VAR BYTE    BANK0   SYSTEM      ' location for PCLATH register
;----[ MIBAM Setup ]--------------------------------------------------------
BAM_COUNT CON 3                     ; How many BAM Pins are used?
INCLUDE "MIBAM.pbp"                 ; Mirror Image BAM module

BAM_FREQ    CON 100
DEFINE BAM_INFO 1  
DEFINE HSER_BAUD 250000
DEFINE HSER_CLROERR 1
DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 20h 



KANAL       CON 3   
BREAKTIME   VAR BYTE
DMXFLAG     VAR BIT
STARTBYTE   VAR BYTE
ADR         VAR BYTE
RVAL        VAR BYTE
GVAL        VAR BYTE
BVAL        VAR BYTE
YVAL        VAR BYTE
X           VAR BYTE
DUMMY       VAR BYTE
i           VAR BYTE

'*****************  MIBAM  ***************************************************
RED         VAR BYTE
GREEN       VAR BYTE
BLUE        VAR BYTE

ASM
BAM_LIST  macro                     ; Define PIN's to use for BAM
     BAM_PIN (PORTB,5, RED)         ;   and the associated Duty variables
     BAM_PIN (PORTB,6, GREEN)
     BAM_PIN (PORTB,7, BLUE)
  endm
  BAM_INIT  BAM_LIST                ; Initialize the Pins
ENDASM
'*****************************************************************************
TRISA=%00111001
TRISB=%00000010 

ScopeSync   VAR     PORTB.2   
RXT         VAR     PORTB.1
ERR         VAR     PORTB.4

CMCON=7        
VRCON=0 
OPTION_REG.7 =0
INTCON =%11000000  



START:
PAUSE 100
DUMMY=0
ADR = KANAL-1
RED=50
GREEN=100
BLUE=180
ERR=0
GOTO LOOP
'--------->>>>>>>>

DMXBAK:
i=i+1
IF i> 200 THEN RETURN
BREAKTIME =1:DMXFLAG = 0
pulsin  RXT,0,BREAKTIME 

if BREAKTIME = 0 then return  
if BREAKTIME < 30 then DMXBAK 

PIE1.5=1 
RCREG = dummy 
RCREG = dummy '
SPBRG = 0 
TXSTA.2 = 0 
TXSTA.4 = 0 
RCSTA.7 = 1 
RCSTA.6 = 0  
RCSTA.4 = 0 
RCSTA.4 = 1 

while RCIF = 0:wend 
STARTBYTE = RCREG
if STARTBYTE = 0 then 
     
    for x = 1 to ADR
    while RCIF = 0:WEND 
    dummy = RCREG 
    next x
    
    DATAAL:
    RVAL= RCREG 
    RCREG = 0 
    RCREG = 0 
    GVAL= RCREG 
    RCREG = 0 
    RCREG = 0 
    BVAL= RCREG 
ENDIF
RCSTA.7 = 0 
DMXFLAG=1
return


LOOP:
    IF DMXFLAG=1 THEN
        RED= RVAL
        GREEN=GVAL
        BLUE=BVAL
    ENDIF
GOSUB DMXBAK
    IF i>200 THEN 
        ERR=0
        ELSE
        ERR=1
    ENDIF
i=0
DUMMY=0

GOTO LOOP

END

[Darrel Taylor]

can you help me why not work my code?

Yes I can ...

1. HSER defines only work with HSERIN/HSEROUT. If you are reading RCREG manually, the baud rate will not have been set by PBP and you will have to do that manually as well.<br><br>
2. pulsin RXT,0,BREAKTIME, PULSIN does not work with interrupts. The timing will be wrong and you'll almost never see a Break pulse that way. Fortunately, the USART does it for you. Look for an FERR flag (framing error) which happens on every Break.<br><br>
3. INTCON =%11000000, interrupts are controlled by the MIBAM routines. Don't change any interrupt registers.<br><br>
4. PIE1.5=1, you've enabled the USART receive Interrupt ... don't do that.<br><br>
5. RCREG = dummy, RCREG is a Read-Only register. Don't know what you were trying to do there.<br><br>
6. SPBRG = 0, it's unlikely that you would want to put SPBRG (Baud Rate Generator Register) to 0 for any reason.<br><br>
7. TXSTA.2 = 0, It's unlikely that you would want to put the USART in Low Speed mode when running at 250Kbaud.<br><br>
8. TXSTA.4 = 0, OK, it's not synchronous mode .... but what is it?<br><br>
9. I have no idea what you are trying to do here. RCREG is read-only, and you're reading 3-bytes from a maximum 2-byte buffer, without checking to see if anything is there.

   DATAAL:
   RVAL= RCREG 
   RCREG = 0 
   RCREG = 0 
   GVAL= RCREG 
   RCREG = 0 
   RCREG = 0 
   BVAL= RCREG 
   ENDIF
   RCSTA.7 = 0 
   DMXFLAG=1
   return

Back to the Drawing Board.

[talatsahim]

"RCREG=DUMMY" was copy-paste from a sample code
how can I set receive port with correct commands?
and how sense break signal with FERR ?


[QUOTE=Darrel Taylor;80570]Yes I can ...

1. DEFINE OSC 20
   CLEAR
   ;_________________________Interrupt Context save locations]_________________
   
   wsave var byte $20 SYSTEM ' location for W if in bank0
   wsave1 VAR BYTE $A0 SYSTEM ' location for W if in bank1
   wsave2 VAR BYTE $120 SYSTEM ' location for W if in bank2
   ssave VAR BYTE BANK0 SYSTEM ' location for STATUS register
   psave VAR BYTE BANK0 SYSTEM ' location for PCLATH register
   ;----[ MIBAM Setup ]--------------------------------------------------------
   BAM_COUNT CON 3 ; How many BAM Pins are used?
   INCLUDE "MIBAM.pbp" ; Mirror Image BAM module
   
   BAM_FREQ CON 100
   DEFINE BAM_INFO 1
   ' MUST BE HERE DEFINE USART PARAMETER?
   
   KANAL CON 3 'my dmx adress, 3.byte red, 4. byte green, 5. byte blue
   BREAKTIME VAR BYTE
   DMXFLAG VAR BIT
   STARTBYTE VAR BYTE
   ADR VAR BYTE
   RVAL VAR BYTE
   GVAL VAR BYTE
   BVAL VAR BYTE
   YVAL VAR BYTE
   X VAR BYTE
   DUMMY VAR BYTE
   i VAR BYTE
   
   '***************** MIBAM ************************************************** *
   RED VAR BYTE
   GREEN VAR BYTE
   BLUE VAR BYTE
   
   ASM
   BAM_LIST macro ; Define PIN's to use for BAM
   BAM_PIN (PORTB,5, RED) ; and the associated Duty variables
   BAM_PIN (PORTB,6, GREEN)
   BAM_PIN (PORTB,7, BLUE)
   endm
   BAM_INIT BAM_LIST ; Initialize the Pins
   ENDASM
   '************************************************* ****************************
   TRISA=%00111001
   TRISB=%00000010
   
   ScopeSync VAR PORTB.2
   RXT VAR PORTB.1
   ERR VAR PORTB.4
   
   CMCON=7
   VRCON=0
   OPTION_REG.7 =0
   
   
   START:
   PAUSE 100
   DUMMY=0
   ADR = KANAL-1
   RED=50
   GREEN=100
   BLUE=180
   ERR=0
   GOTO LOOP
   '--------->>>>>>>>
   
   DMXBAK:
   i=i+1
   IF i> 200 THEN RETURN
   BREAKTIME =1MXFLAG = 0
   pulsin RXT,0,BREAKTIME ' I DONT KNOW HOW USE FERR THIS POINT
   
   if BREAKTIME = 0 then return
   if BREAKTIME < 30 then DMXBAK
   
   BRGH=1 ' 250000 BAUD ?
   SPBRG = 4 ' 250000 BAUD ?
   'AND HOW CAN I "DEFINE HSER_CLROERR 1" WITHOUT DEFINE?
   
   
   RCSTA.7 = 1
   RCSTA.6 = 0
   RCSTA.4 = 0
   RCSTA.4 = 1
   
   while RCIF = 0:wend
   STARTBYTE = RCREG
   if STARTBYTE = 0 then
   
   for x = 1 to ADR 'MY ADRESS 3, SKIP 2 BYTE
   while RCIF = 0:WEND
   dummy = RCREG
   next x
   
   DATAAL:
   RVAL= RCREG ' 3.BYTE, START OF MY DATA STREAM, RED VALUE
   GVAL= RCREG '4 BYTE.. GREEN VALUE
   BVAL= RCREG '5. BYTA BLUE VALUE
   ENDIF
   RCSTA.7 = 0
   DMXFLAG=1
   return
   
   LOOP:
   IF DMXFLAG=1 THEN
   RED= RVAL
   GREEN=GVAL
   BLUE=BVAL
   ENDIF
   GOSUB DMXBAK
   IF i>200 THEN
   ERR=0
   ELSE
   ERR=1
   ENDIF
   i=0
   GOTO LOOP
   
   END

[Darrel Taylor]

Sorry talatsahim,

This little bit of code I made, has already turned into several commercial products.
I have no problem with that, and everyone is free to do so if they wish.

But, some things you just have to do on your own.
If you can come up with the rest, that's great.

Best regards,