Bit Angle Modulation (BAM) in a PIC

[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]

sanch0

u r a very valuable programmer.

ur boss is so fortunate.

[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

[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))))