ReadDataPic18() function missing from the 18F2XXX files

[manojmo]

When burning EEPROM for 4550, the ReadDataPic18() function seems to be missing. its defined in burn18.py, which is probbaly deprecated. i guess it should also be defined in CpuPIC18F.py or the 2XXX one ?

[danjperron]

Wow good catch!

It is more than a year that I made this. I will need to remember but I think the bug came from when I decide to create an universal method 'burnLVPx'.

The burnLVP.py and the burn18.py are old stuff please use burnLVPx.py.

It should be ReadData() and not ReadDataPic18(). and this will affect the files 'CpuPIC18F2XXX.py' and 'CpuPIC18FXX2.py'.

B.T.W. You could change the code, you are now a collaborator.

Thanks, Daniel

[manojmo]

did you go thru the refactored burnGPIO.py to see if its OK ? i have refactored the burnGPIO for Rpi too. maybe be can include the approproate file in burnGPIO.py, i.e. Rpi one or usb2Serial one. are getDataState() etc as per python naming convention ? ( i am a java guy ) these methods will need to be called from other files. i can check only the 18f related files at the moment.

the DataBlankCheck() and DataCheck() methods are repeated in 18f and 2xxx files. i think the one in 2xxx should be removed ? however the loadcode(0) is essential as per the spec, and that is in 2xxx. so that version should be used. Also, the DataBlankCheck() and DataCheck() can be made into one, since all but the value being compared is same.

On Mon, Dec 29, 2014 at 8:15 PM, danjperron notifications@github.com wrote:

Wow good catch!

It is more than a year that I made this. I will need to remember but I think the bug came from when I decide to create an universal method 'burnLVPx'.

The burnLVP.py and the burn18.py are old stuff please use burnLVPx.py.

It should be ReadData() and not ReadDataPic18(). and this will affect the files 'CpuPIC18F2XXX.py' and 'CpuPIC18FXX2.py'.

Daniel

— Reply to this email directly or view it on GitHub https://github.com/danjperron/burnLVP/issues/2#issuecomment-68262838.

[danjperron]

Next week I start a project using the pic16F1716. I will implement the code for it and check the code again. I knew that I had problem with the data eerom but I thought I fixed it . Looks like I didn't.

The burnGPIO.py was the way to make the system universal. just change burnGPIO.py to behave like the raspberry pi GPIO.

DataBlankCheck and DataCheck could be made into one but the better method will be to implement a subfunction since DataBlankcheck always compare to 0xff and DataCheck compare to what we have in pic_data.

Maybe change DataCheck to see if pic_data==None. If yes we have to check for 0xff.

And yes you are correct DataCheck and DataBlankCheck could be removed from CPUPIC18F2XXX.py since they are in CpuPIC18F.py

I'll see about it next week .

[manojmo]

the refactoring for burnGPIO is needed because other files reference Rpi GPIO directly, e.g. the setup,output and input functions along with the pins are called. hence i have encapsulated into burnGPIO.py as setDataState(), setDataModeRead() etc i changed and tested the common functon for DataCheck yesterday. have also changed burnLVPx to accept an argument for pic family, so that we do not have to check all. am attaching these changes. also the burnGPIO rpi version.

On Tue, Dec 30, 2014 at 10:23 PM, danjperron notifications@github.com wrote:

Next week I start a project using the pic16F1716. I will implement the code for it and check the code again. I knew that I had problem with the data eerom but I thought I fixed it . Looks like I didn't.

The burnGPIO.py was the way to make the system universal. just change burnGPIO.py to behave like the raspberry pi GPIO.

DataBlankCheck and DataCheck could be made into one but the better method will be to implement a subfunction since DataBlankcheck always compare to 0xff and DataCheck compare to what we have in pic_data.

Maybe change DataCheck to see if pic_data==None. If yes we have to check for 0xff.

ANd yes you are correct DataCheck and DataBlankCheck could be removed from CPUPIC18F2XXX.py since they are in CpuPIC18F.py

I'll see about it next week .

— Reply to this email directly or view it on GitHub https://github.com/danjperron/burnLVP/issues/2#issuecomment-68373404.

[manojmo]

left out the usb-serial version. attaching that.

On Wed, Dec 31, 2014 at 10:56 AM, Manoj Mokashi manojmokashi@gmail.com wrote:

the refactoring for burnGPIO is needed because other files reference Rpi GPIO directly, e.g. the setup,output and input functions along with the pins are called. hence i have encapsulated into burnGPIO.py as setDataState(), setDataModeRead() etc i changed and tested the common functon for DataCheck yesterday. have also changed burnLVPx to accept an argument for pic family, so that we do not have to check all. am attaching these changes. also the burnGPIO rpi version.

On Tue, Dec 30, 2014 at 10:23 PM, danjperron notifications@github.com wrote:

Next week I start a project using the pic16F1716. I will implement the code for it and check the code again. I knew that I had problem with the data eerom but I thought I fixed it . Looks like I didn't.

The burnGPIO.py was the way to make the system universal. just change burnGPIO.py to behave like the raspberry pi GPIO.

DataBlankCheck and DataCheck could be made into one but the better method will be to implement a subfunction since DataBlankcheck always compare to 0xff and DataCheck compare to what we have in pic_data.

Maybe change DataCheck to see if pic_data==None. If yes we have to check for 0xff.

ANd yes you are correct DataCheck and DataBlankCheck could be removed from CPUPIC18F2XXX.py since they are in CpuPIC18F.py

I'll see about it next week .

— Reply to this email directly or view it on GitHub https://github.com/danjperron/burnLVP/issues/2#issuecomment-68373404.

[danjperron]

Thank's manojo,

I gave you have access to the repository. Could you create a branch and push your code in.

Whish you happy new year,

Daniel

[manojmo]

ok. thanks, and wish you a happy new year too. :)

On Wed, Dec 31, 2014 at 5:25 PM, danjperron notifications@github.com wrote:

Thank's manojo,

I gave you have access to the repository. Could you create a branch and push your code in.

Whish you happy new year,

Daniel

— Reply to this email directly or view it on GitHub https://github.com/danjperron/burnLVP/issues/2#issuecomment-68437920.

[manojmo]

hi dan,

i have created the usb2ser branch for my changes. by mistake i had checked in the cpu18f file in master, i have reverted it back.i mean to use the code for burning the small pic16f675 in HVP mode. will keep you posted.

regards, manoj

On Wed, Dec 31, 2014 at 5:30 PM, Manoj Mokashi manojmokashi@gmail.com wrote:

ok. thanks, and wish you a happy new year too. :)

On Wed, Dec 31, 2014 at 5:25 PM, danjperron notifications@github.com wrote:

Thank's manojo,

I gave you have access to the repository. Could you create a branch and push your code in.

Whish you happy new year,

Daniel

— Reply to this email directly or view it on GitHub https://github.com/danjperron/burnLVP/issues/2#issuecomment-68437920.

[manojmo]

hi,

as i had mentioned before, the data eeprom read issue was only for the usb-serial interface, not for Rpi. Darron Broad from kewl.org, who has a nice open source software for PICs as well, pointed out that i was missing a resistor to protect the PGD->DTR path. Here, as DTR is low, when PGD goes high, DTR will be like a short, and CTS will be near to bypassed. once i added a 1K resistor there, the EEPROM read error went away :)

by modifying Darron's software for my case, i was also able to burn a 12F675 using HVP. btw, why does our CpuPIC12 file use MCLR instead of PGM in set_LVP ? Also, shouldn't SendMagic() be part of set_lvp ?

regards, manoj

On Thu, Jan 1, 2015 at 4:34 PM, Manoj Mokashi manojmokashi@gmail.com wrote:

hi dan,

i have created the usb2ser branch for my changes. by mistake i had checked in the cpu18f file in master, i have reverted it back.i mean to use the code for burning the small pic16f675 in HVP mode. will keep you posted.

regards, manoj

On Wed, Dec 31, 2014 at 5:30 PM, Manoj Mokashi manojmokashi@gmail.com wrote:

ok. thanks, and wish you a happy new year too. :)

On Wed, Dec 31, 2014 at 5:25 PM, danjperron notifications@github.com wrote:

Thank's manojo,

I gave you have access to the repository. Could you create a branch and push your code in.

Whish you happy new year,

Daniel

— Reply to this email directly or view it on GitHub https://github.com/danjperron/burnLVP/issues/2#issuecomment-68437920.

[danjperron]

Hi,

Good! you are making progress

I started all that with the PIC12F1840. Most of the PIC12/16 cpu don’t have PGM pin, you need to hold MCLR low and send MAGIC . In HVP mode you have to use VPP which is MCLR for the PIC12F1840.

I know my code works well in HVP mode because Valter Fukuoka use this mode. But my primary intention was to burn in LVP mode using the raspberry PI with less parts possible.

regards,

Daniel

[manojmo]

ok.it would be more generic if we can introduce a burn_mode object with HVP, LVP_PGM and LVP_KEY modes. we could specify mode as command line argument, and then use mode.set() and mode.release()

will the pic12 code for read/write data work for all pic12, or are there differences ?

btw, did you check out the ensure lib, which allows some static typing and checks in python 3+ ? coming from java,i find the weak typing a source of errors. e.g. when i started usb2ser, i was reading zeroes because i had forgotten a "return" in the getDataState() method, and the compiler did not complain.

an example :

from ensure import ensure_annotations

@ensure_annotations

The return type will be checked only when the function is used

def ff(x: int, y: float) -> float: return x+y

in python3, print needs brackets

print( ff(1,1.2) )

regards, manoj

On Wed, Jan 14, 2015 at 5:37 PM, danjperron notifications@github.com wrote:

Hi,

Good! you are making progress

I start all that with the PIC12F1840. Most of the PIC12/16 cpu don’t have PGM pin, you need to hold MCLR low and send MAGIC .

I know my code works well in HVP mode because Valter Fukuoka use this mode. But my primary intention was to burn in LVP mode using the raspberry PI with less parts possible.

regards,

Daniel

— Reply to this email directly or view it on GitHub https://github.com/danjperron/burnLVP/issues/2#issuecomment-69907194.