indirect addressing (FSR and INDF) in MikroPascal

[joseLB]

Hi all of you!
In assembler 16F1788 we can use FSR registers using instructions such as MOVIW and MOVWI.
They take the contents of memory pointed by FSRxH/L and also increment/decrement the FSR.

Question: in mikroPascal is it possible to use indirect registers to read tables in flash memory and increment FSR?
Or at least use FSR /INDF to read the flash in an efficient way?

Thanks

Jose

[janni]

Yes, it is possible. Here's an example, though for one byte

Code: Select all

function readFLASH(address:word): byte;
 begin
  FSR0L:=Lo(address);
  FSR0H:=Hi(address);
  asm
         moviw    0[FSR0]
         movwf    R0
         return
  end;
  result:=result;
 End;{readFLASH}

I prefer use of NVMCON registers allowing to read full 14-bit words which, for example, allows to check whether the memory contents is indeed a table, but if speed is of the essence then using the two FSRs one may quickly copy constants from flash to RAM.

[joseLB]

Thank you very much Janni, as always your help is very accurate and valuable.
Jose

[joseLB]

and in fact what I need is based on your routine above, but using auto increment ++FSRx. And yes, speed in this project is important. is a spwm at 24 khz , where each pulse has 41 MS.

The sine values ​​come from a table with 100 positions in flash memory.

With pic 16 f 1788 at 24 MHz I have 250 instructions to generate each sine pulse.And perform other actions such as sampling the output and then choosing another curve in the flash.

I believe in 30 to 50 instructions to make the sine wave. The other 200 are for other activities.

[joseLB]

The pic16f 1788 has 12-bit ADC, plus a 32mhz clock, which makes it quite flexible beyond op amps etc.

[janni]

I recently needed a 12-bit ADC and 16-bit PWM so I used the Q41 series processor (PIC18F16Q41 - even cheaper than PIC16f 1788) but it was real pain to program it under mP PRO. I did it mostly to prove that it could be done but I don't think I'll repeat the experience. Pity what mE did to its compilers .

[joseLB]

HI Janni
Normaly I use PIC 16F, in special 1788. I think they are simpler to configurate. If they can ou do the job, ok.

If you can describe a bit your problems with this pic 18/your project would be great to us to know.

Jose

[janni]

Normaly I use PIC 16F, in special 1788. I think they are simpler to configurate. If they can ou do the job, ok.

That's as it should be . No need to look for trouble.

If you can describe a bit your problems with this pic 18/your project would be great to us to know.

Oh, that's simple - mP PRO is fundamentally not ready for new processor families. Assumptions were made that are no longer true, like position of Access Bank and registers used internally by the compiler. Even if one can trick the compiler then either linker or optimizer frequently gets lost. In other words the effort is not worth it (I succeeded only because I have rewritten all libraries and could recompile them - and even then I had to check whole resulting assembly code for linker and optimizer failures and find workarounds).