Internal Eeprom/flash , what are you doing ?

[ultiblade]

Thanks for your replies guys !

I could'nt get back to you any sooner, cause the forum was offline.

The reason i would like to use the 519 is because it's the cheapest and smallest
pic micro that has memory on it. I did some projects on the 12F635, and that works
like a charm, however, it's more expensive and isn't available in a MSOP package ...

OK, so read and write is not going to work then ?

Is there anyway i can make this work Darrel or Skimask ?

The project is very small step up dimmer for small led lights. It uses a i2c digital potentiometer to influence a sense resistor. Each time the pic get Vdd it reads the previous value and adds 1 to it and applies the setting to the digital pot. So, by switching the lights on and off a few times the dimmer state can be influenced ...

[skimask]

Is there anyway i can make this work Darrel or Skimask ?
The project is very small step up dimmer for small led lights. It uses a i2c digital potentiometer to influence a sense resistor. Each time the pic get Vdd it reads the previous value and adds 1 to it and applies the setting to the digital pot. So, by switching the lights on and off a few times the dimmer state can be influenced ...

Using a digital pot for LEDs (i.e. varying the current) isn't the way to go with LEDs. Sure, it'll work, but the results won't be very linear at the lower light levels. Best bet with an LED is to use PWM of some sort of another. If you look at the datasheet for whatever LED you've got, you'll notice that the color/intensity/etc are all referenced to a normalized current drive (or at least a range of current). Go outside of that range and the performance drops. If you use PWM, you drive the LED at an efficient level, with a varying duty cycle. And it saves power too...

As far as the FLASH in the 12F519? I didn't realize it was 64 bytes of FLASH either, I thought it was EEPROM. I don't have a 519 handy, and I haven't tried it either, so I don't know if PBP supports it in the same way it supports the other PICs with EEPROMs or not. You might end up writing an assembly subroutine to handle read, modifying, and re-writing the FLASH in 8 byte rows.

[Darrel Taylor]

Is there anyway i can make this work Darrel or Skimask ?

I think so.

Been looking through the 12F library, and it looks like the READ and WRITE commands still do the right thing. But there's no way (in PBP) to erase a block before writing.

This might work. It's a macro that will erase 1 block at a time using a Constant for the address.

To erase the first block (bytes 0-7), you can ...
@ EraseFlash 0

To erase the second block
@ EraseFlash 8

Put it right before the WRITE command.

And put this macro somewhere near the top of the program.

ASM
EraseFlash  macro Addr
  local EraseLoop
    MOVE?CB  (Addr & 0x38), EEADR
    BSF      EECON,FREE          ; SELECT ERASE
    BSF      EECON,WREN          ; ENABLE WRITES
    BSF      EECON,WR            ; INITITATE ERASE
EraseLoop 
    btfsc    EECON, WR           ; Wait for the erase to complete
    goto     EraseLoop
  endm
ENDASM

[ultiblade]

You're both absolutely right.

I forgot to mention I'm using Cree powerled's, that are driven by a supertex led driver. This driver uses a sense resistor to measure the current, if we influence the current ( by adding a resistor parallel to the sense resistor), we can influence the intensity of the powerled's.

Darrel, i'm going to try the erase macro immediately, will post my findings ....

Thanks Experts !

[ultiblade]

Hi Guys,

I have tried your code Darrel, and erasing the blocks before writing does the trick !!! Thank you !
Skimask, thank you for your quick replies and expert information !!



Best regards,

Ultiblade

[Darrel Taylor]

Woohoo!

Hope she's my prize.
<br>

[ultiblade]

[loud laughter]

I will ask her to contact you !

[/loud laughter]