LCD BARgraphs

[Darrel Taylor]

I am trying to make it as fast as possible in response. The program is doing other things too so cannot affort delays in tables to choose one of 60.

Ouch.

I think tying to calculate it is going to take a lot longer than a Table Lookup. (I do mean A LOT)

Maybe Alain's way might be better.

Up to you, if you want to try.
<br>

[Acetronics2]

Hi, Ioannis

Nothing Quicker than a lookup table ... ( PbP lookup not slower than ASM ... cause it's written quite the same !!! )

That's the way used for automobile ignitions ... where we count the µs ...

Alain

[Ioannis]

Thanks. I will see which way I am going to choose. After all precision is not important when displaying audio levels, isn't it? So a table might be better.

Ioannis

Edit: That post was meant as an answer to Darrel, but it came 1 min after yours Alain. But it fit both! Mysterious ways this forum works!

[Darrel Taylor]

Sorry, just another Shameless Plug.

Here's a way you might be able to implement the Lookup Table.
http://www.picbasic.co.uk/forum/show...php?t=3891#LAB

Quietly blushing,

[Ioannis]

Hmm, thats very clever. I think is faster too!

Hands on experiment!

Thanks Darrel.

Ioannis

[Acetronics2]

Hi, Ioannis

this will be smaller ... but not faster. ( operations are still the same ...)

Smaller ??? not sure ... still need 14 bits per value ...

BUT ...

as only 6 bits used per value, could try Value.Highbyte and Value.lowbyte to place 2 values in 1 location ...


just an idea ... but really fun a table loading !!!

mmmm, stupid idea: if you have 60 ( ? ) free locations in the RAM ( You did not tell us about the processor ...), you could download from the EEPROM to the RAM at each power-up ... and use a "simple" 60 values Array.

no faster way !!!

If you want to get a bit more precision ... you can linearize between two points ( "ax+b" line ) doesn't use much CPU ...

that will be "less false" ... LOL

Alain

[mister_e]

mmm, kinda mix with embedded strings in your code space and lookup table...
So the Excel sheet would have to pack it in 14Bit and later you use DA.

How's that sound? pretty bad to me as the unpacking method will certainely be slightly longer to execute than reading a single Byte for a DT, DW table ...

[Acetronics2]

Hi, Steve

Yess ... the packing method could work great if we had a 1 value to 1 Value "translation"

I think the problem is a bit more complicated than we think at first ...

we have to convert a 256 values log scale ( I do not want to think to 10 bits !!! ) to a 60 values lin scale ...

so, many input values have the same output result ...
Much,much room left !!!

What's the ADC resolution needed if we want a 1 dB precision output, even @ - 40 dB ???
Much,much,much,much,much,much room left !!! ... 255 values limit fully exploded !!!


Could we think to a BIG Select Case statement with 59 times " Case is < $xx or $xxxx" ... I do not know about the CPU time used ...

but it seems a lot easier to write and calculate.

Alain