18F46K20 not fully supported

[camerart]

Hi,
I've just been in a tangle with Oshonsoft and MPLAB, mainly because of my misreading!

Out of habit while using surface mount low voltage PICs I've named them 18LF. I kept getting incorrect ID warning from MPLAB. Having taken a closer look at the PIC, I now remember I bought 18F46K20 PICs. These look the same as LF type, but now low voltage only needs F.

Oshonsoft doesn't support 18F46K20 PICs fully, and isn't happy with ALLDIGITAL and HSEROPEN. Previously I've programed these PICs using 18LF4620 quite happily. MPLAB is happy with 18F46K20 PICs. Will it be ok to program them as 18LF4620 in Oshonsoft, then 18F46K20 in MPLAB?

Camerart.

 

[Nigel Goodwin]

Yes, there's essentially no difference between the devices.

I must admit, I've occasionally selected the LF version in MPLABX by mistake, and then sat scratching my head wondering why it's not working and giving me a silly error message

 

[camerart]

Hi N,
I've set the OSH SIM as 18F4620 and MPLAB as 18F46K20 (both appear 'happy'

The PIC is programming, and I'm testing a simple LED routine first.

Symbol rled = PORTE.1
Symbol yled = PORTE.0

main:

rled = 1
WaitMs 1000
yled = 1
WaitMs 1000
rled = 0
WaitMs 1000
yled = 0
WaitMs 1000

goto main

Rled goes on then as Yled turns on Rled turns off, then both off. I can't get both LEDs to turn on at the same time, using SYMBOL.

If I use PORTE =%00000011 instead, both LEDs turn on.
C.

 

[sagor1]

In the OSH SIM, I notice that any "Alldigital" command does not in initialize PORTE's TRISE register (nor do you show those commands). When I put in TRISE = %00000000, then the sim seems to work with your code.
Without the TRISE command, the state of that register may be "undetermined", meaning anything random...

Even with your PORTE = %00000011 in the SIM I ran, it did not turn on the LED pins without that TRISE command....

Your code example does not show if you initialize the PORTE pins as output or not, so I may be wrong if you do...

 

[Ian Rogers]

Yes, there's essentially no difference between the devices.

Not quite true... Eric has posted a PDF over at AAC and there is quite a lot of software / hardware changes... The most important is the ram locations AND the block sizes...

I have ported several of my basic programs to Great Cow Basic... It seems to support a great deal more chips... BUT!!! no simulator... As I use Proteus, this isn't an issue to me..

 

[camerart]

In the OSH SIM, I notice that any "Alldigital" command does not in initialize PORTE's TRISE register (nor do you show those commands). When I put in TRISE = %00000000, then the sim seems to work with your code.
Without the TRISE command, the state of that register may be "undetermined", meaning anything random...

Even with your PORTE = %00000011 in the SIM I ran, it did not turn on the LED pins without that TRISE command....

Your code example does not show if you initialize the PORTE pins as output or not, so I may be wrong if you do...

Hi S,
A hopeful solution from AAC for SYMBOLs, is use LAT instead of PORT, which works for me.

Will you test it for me as before but with LAT, and if ok, correct it and post it, then I'll copy.
Thanks,
C.

 

[camerart]

Not quite true... Eric has posted a PDF over at AAC and there is quite a lot of software / hardware changes... The most important is the ram locations AND the block sizes...

I have ported several of my basic programs to Great Cow Basic... It seems to support a great deal more chips... BUT!!! no simulator... As I use Proteus, this isn't an issue to me..

Hi I,
I saw the PDF and spotted the different OSCCON setting, but couldn't see anything else that would affect my programming? Perhaps N was thinking on the same lines when he said 'essentially no differences'? The PDF is for 18F45K20, I'm using 18F4620, so there are even some more differences. If it doesn't effect my programs too much, I'll plod on, and hopefully be corrected when it does.

I looked a Great cow, but I rely on the simulator, so it's out I'm afraid.

Cheers, C.

 

[Ian Rogers]

I suspect Nigel is referring to LF vs F... The K series is quite different from the norm A pic18f4520 and the pic18f45k20 have diferent internal organisation and shouldn't work... The analogue selection is different, the ram is different, the interrupts are different, the comparator is different.

I wouldn't write code for the normal series then program the k with that code.

You can simulate all aspects via the ide, but not for real...

 

[camerart]

I suspect Nigel is referring to LF vs F... The K series is quite different from the norm A pic18f4520 and the pic18f45k20 have diferent internal organisation and shouldn't work... The analogue selection is different, the ram is different, the interrupts are different, the comparator is different.

I wouldn't write code for the normal series then program the k with that code.

You can simulate all aspects via the ide, but not for real...

Hi I,
If it's true that the K won't work, in OSH and PMLAB, then I'm stuck

It's a costly business, choosing PICs! I've got a pile that have been superseded by some sort of upgrade I've had to do.
I'll carry on and see what happens?
C.

 

[Nigel Goodwin]

I suspect Nigel is referring to LF vs F... The K series is quite different from the norm A pic18f4520 and the pic18f45k20 have diferent internal organisation and shouldn't work...

Yes, sorry, I hadn't noticed the K

 

[Nigel Goodwin]

It's a costly business, choosing PICs! I've got a pile that have been superseded by some sort of upgrade I've had to do.
I'll carry on and see what happens?

Dump Oshonsoft and move to XC8 and MPLABX, you'll have to eventually as Oshonsoft becomes more and more obselete, so may as well do it sooner rather than later. I know C is more difficult, but you've probably got to do it some time.

 

[Ian Rogers]

If it's true that the K won't work, in OSH and PMLAB, then I'm stuck

No!! You are not stuck.... EVERYTHING can be written... If you need four or five functions that will give back support then thats easy to do.

BUT!!!! Why don't you port a small program to the free version of swordfish It has ICD debugging and has a mplab plugin for single stepping..

 

[camerart]

Dump Oshonsoft and move to XC8 and MPLABX, you'll have to eventually as Oshonsoft becomes more and more obselete, so may as well do it sooner rather than later. I know C is more difficult, but you've probably got to do it some time.

Hi N,
I've had this said many times, but unfortunately or fortunately, I am stuck with Oshonsoft and BASIC. I look at 'C' programs, and ASM, and can nearly follow, but soon realise, it's no good, although I can pick the bones out of those programs. Is there a simulator like Oshonsoft with XCB or MPLAB?
C.

 

[camerart]

No!! You are not stuck.... EVERYTHING can be written... If you need four or five functions that will give back support then thats easy to do.

BUT!!!! Why don't you port a small program to the free version of swordfish It has ICD debugging and has a mplab plugin for single stepping..

Hi I,
I'm sure Swordfish would be useful, but I'm at my limit all of the time keeping up with new acronyms (ICD for example), and DATA sheets. I'm looking at a Compass module DATA sheet at the moment, and it took me all morning to figure out, I had it upside down
C.

 

[JonSea]

Swordfish is a great language because the include modules are written in Swordfish Basic and there are tools for adding new parts. You're not stuck if the developer stops supporting the product. Plus, the free version has extremely generous limits to the point that many people never need the paid version.

 

[camerart]

Hi,
I'm getting an odd problem, regarding timing!

Here is the MAIN LOOP, with most lines commented out.
In the commented IN section there is a HSEROUT.

When this line in the main program:
'Define SIMULATION_WAITMS_VALUE = 1 'Comment in for SIM out for PIC
is commented IN, then It outputs the HSEROUT and LEDs (very fast), but when in normal mode, i,e, live on the PCB, the HSEROUT /LEDs don't work.

I'm programming with Oshonsoft set to 18F4620 and MPLAB set to both 18F4620 and 18F46K20.

EDIT: I've temporarily commented out the INTERRUPT in the program, it's working now.

C.

 

[JonSea]

...I'm programming with Oshonsoft set to 18F4620 and MPLAB set to both 18F4620 and 18F46K20....

C.

Aside from a similar part number, those two chips have nothing in common. You'd have as much luck using a 1963 VW service manual to overhaul a 2018 Ford Mustang.

 

[camerart]

Aside from a similar part number, those two chips have nothing in common. You'd have as much luck using a 1963 VW service manual to overhaul a 2018 Ford Mustang.

Hi J,
EDIT:
I don't have much choice other than to keep trying with the setup I've got. I am getting results.
C

 

[Pommie]

Your code isn't easy to understand but it appears that you stay in the interrupt until you receive a complete sentance and than echo it back. At 9600 baud this will take almost a quarter of a second. Interrupts need to be short. You should look into using a fifo buffer to hold the data. You could just use a straight buffer as you're detecting sentance end and setting a flag.

Mike.

 

[camerart]

Your code isn't easy to understand but it appears that you stay in the interrupt until you receive a complete sentance and than echo it back. At 9600 baud this will take almost a quarter of a second. Interrupts need to be short. You should look into using a fifo buffer to hold the data. You could just use a straight buffer as you're detecting sentance end and setting a flag.

Mike.

Hi M,
In the years, I've been working on this project, I think I recall that for some reason FIFO doesn't work in Oshonsfot, but I can't be certain.

Would you be good enough to jump to this thread please, as I've removed the SERVO sections and started again: https://www.electro-tech-online.com/threads/oshonsoft-serial-data.154782/page-2
C.