I've developed a program based on 16F1618 ,but i found 16F1579 with double ram (1024byte instead of 512bytes) and also a bit cheaper,so i bought some 16F1579 to try them too.
The program is an implementation of a serial interface for amstrad cpc through cpu's expansion port, and uses only the hardware EUSART module .
Now, from the datasheets, these two PIC, seem to be exact pin compatible. So, i assume that changing the initial option for chip selection, from:
chip 16F1618, 32
to:
chip 16F1579, 32
It will do the job. Unfortunately, although hex file and flashing pic went well, when the adapter is pluged on amstrad, it didn't work at all, geting a completely erratic respond from pic resulting even in reseting or crashing amstrad!
So, my question is, since these two pics are pin compatible (so no alteration ,on the board using them, is needed) the changing of chip selection in the start of code shouldn't do the job? Is there anything else that might need changing in the code, or maybe 16F1618 and 16F1579 aren't so compatible after all?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
first line of asm:
Program compiled by Great Cow BASIC (0.98.01 2017-10-27)
For the testing, the usart module is not used at all,i only send input and output commands to a specific port (from amstrad cpc), where pic should respond. Using 16F1618 works perfect, but switching to 16F1579.... nothing :-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IT WORKED!
Turns out exactly as you said it, "something very simple"... :-)
Although i knew the configuration command OSC, i never thought to use it, because i thought that compiler use internal clock by default, if the choosen speed is supported by internal clock of course. I've used many different pics in the past (from small 12F629,12F683,16F684,16F688 up to 20pin 16F1618 and 28pin 18F2550) for my projects, always use the internal clock but never set the config command OSC=INTOSC, as always worked without it.
Anyway, again, many thanks!
Forum's help support is really something else! ;-)
Last edit: ikonsgr74 2018-05-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately i think i discover another possible bug regarding 16F1579 asm code produced.
Transmit through hardware EUSART port, doesn't seem to work (receive works fine though).
I checked the INIT PPS section on both 16F1618 and 16F1579 asm codes (where the TX pin is assigned), and they are exactly the same. However, checking on datasheets of both pics, the USART transmit block diagrams seem to have major differences, although receive block diagrams look the same. I also tried to remove the init pps section from 16F1579 code (as i note on TX block diagram there is no refference to PPS at all) and assign directly the TX pin but still didn't work.
Could you please take a look at this?
Last edit: ikonsgr74 2018-05-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that's what i did. Anything is sent from pc to amstrad cpc is received fine, so most probable pic and code functions ok.The problem is that nothing transmitted from amstrad (e.g. pic's usart) to pc seem to work , nothing is received to pc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you connect an serial analyser? Can you determine anything?
The results were?
Can you connect the PIC to a PC? Start serial Terminal - try changing the Baud Rate. Is the part therefore clocked at the correct frequency?
Are things operatings at the correct baud rate?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, any command for changing baud rate works ok (i have the proper respond from pic).
I'm using a pair of bleutooth modules and a terminal on pc to check comunications. Receiving characters from pc to amstrad works fine, but when i send something from amstrad, i dont get anything on pc terminal receive window.
I have an 8channel salae logic analyzer somewhere, but i have to find it first to get any serial anlysis :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that the same code works perfect on both directions with 16F1618, that's why i said something might be wrong with correct setting of TX pin (which is set using PPS) with 16f1579
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Use the PPSTOOL to recreate the PPS setting. I see that the PPSTOOL headings are missing so - my guess. You have not recreated for this part.
'Generated by PIC PPS Tool for Great Cow Basic'PPS Tool version: 0.0.5.16'PinManager data: v1.65.2''Template comment at the start of the config file' #startup InitPPS, 85 Sub InitPPS'Module: EUSARTRB7PPS=0x0009'TX > RB7RXPPS=0x000D'RB5 > RX End Sub'Template comment at the end of the config file
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Use the PPSTOOL to recreate the PPS setting. I see that the PPSTOOL headings are missing so - my guess. You have not recreated for this part.
'Generated by PIC PPS Tool for Great Cow Basic'PPS Tool version: 0.0.5.16'PinManager data: v1.65.2''Template comment at the start of the config file' #startup InitPPS, 85 Sub InitPPS'Module: EUSARTRB7PPS=0x0009'TX > RB7RXPPS=0x000D'RB5 > RX End Sub'Template comment at the end of the config file
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found this: Enhanced Universal Synchronous Receiver Transmitter (EUSART) Transmit Mode
Under certain conditions, a byte written to the TXREG register can be transmitted twice.
This new byte is immediately transferred to the TSR register, but also remains in the TXREG register until the completion of the current instruction cycle.
f the new byte in the TSR register is transmitted before this instruction cycle has completed, the duplicate in the TXREG register will subsequently be transferred to the TSR register on the following instruction clock cycle and transmitted. Work around
Monitor the Transmit Interrupt Flag bit (TXIF).
Writes to the TXREG register can be performed once the TXIF bit is set, indicating that the TXREG register is empty."
So a slight delay befor sendind a second byte may solve the proiblem.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My PPS tool for 16F1579 created same code with one difference in the "crucial" line of setting the TX pin:
RB7PPS = 0x0006 'TX > RB7
instead of 0x0009 you mentioned.
Anyway, i changed the value to 0x0009 and again... it worked!
So, why this happened? Is it a bug with pps tool, not setting the correct value?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not a bug in the tool, a bug in the copy/paste method.
PPS is device specific.
There may be core similarities but PPS is hardware level so the Die of the Chip may be routed differently between members of the same family, leading to core differences.
For this reason it is important that you actually run the PPS tool, rather than copy and paste, when moving code between devices, even in the same family.
Cheers
Chris
Last edit: Chris Roper 2018-05-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After a quick check on pps tool, it seems that although i've changed pic to 16F1579 (from previous 16F1618 ) for some reason, it didn't load the correct xml file, and used the "old" of 16F1618. So,i close PPS tool program, re-open it, select 16F1579, set PPS output to RB7 pin ,TX peripheral, and the code produced was correct!
Anyway, thanks for your help and advices, guys!
COWBASIC RULES! ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've developed a program based on 16F1618 ,but i found 16F1579 with double ram (1024byte instead of 512bytes) and also a bit cheaper,so i bought some 16F1579 to try them too.
The program is an implementation of a serial interface for amstrad cpc through cpu's expansion port, and uses only the hardware EUSART module .
Now, from the datasheets, these two PIC, seem to be exact pin compatible. So, i assume that changing the initial option for chip selection, from:
chip 16F1618, 32
to:
chip 16F1579, 32
It will do the job. Unfortunately, although hex file and flashing pic went well, when the adapter is pluged on amstrad, it didn't work at all, geting a completely erratic respond from pic resulting even in reseting or crashing amstrad!
So, my question is, since these two pics are pin compatible (so no alteration ,on the board using them, is needed) the changing of chip selection in the start of code shouldn't do the job? Is there anything else that might need changing in the code, or maybe 16F1618 and 16F1579 aren't so compatible after all?
Can you share your version of Great Cow BASIC? An easy way to tell is to look post the top line of the ASM file generated.
We do support EUSART - the version number is needed.
first line of asm:
Program compiled by Great Cow BASIC (0.98.01 2017-10-27)
For the testing, the usart module is not used at all,i only send input and output commands to a specific port (from amstrad cpc), where pic should respond. Using 16F1618 works perfect, but switching to 16F1579.... nothing :-(
Please post the source code and you asm as a ZIP.
May be something simple - you have a good version so it is not that.... need your code and asm please.
Here are two zips, one for 16F1618 and one for 16F1579, source code is exactly the same, only the chip selection is different.
Btw Anobium, thanks for your quick respond and concern!
These are different chip architectures but with essentially the big difference in the registers to drive the USART.
But, I see nothing incorrect with the asm.
I am concerned regarding the OSC - please try.
IT WORKED!
Turns out exactly as you said it, "something very simple"... :-)
Although i knew the configuration command OSC, i never thought to use it, because i thought that compiler use internal clock by default, if the choosen speed is supported by internal clock of course. I've used many different pics in the past (from small 12F629,12F683,16F684,16F688 up to 20pin 16F1618 and 28pin 18F2550) for my projects, always use the internal clock but never set the config command OSC=INTOSC, as always worked without it.
Anyway, again, many thanks!
Forum's help support is really something else! ;-)
Last edit: ikonsgr74 2018-05-11
Great! !! I am not sure why we are not setting. So , added to the list to sort.
Use the config for now.
Pleasure
Unfortunately i think i discover another possible bug regarding 16F1579 asm code produced.
Transmit through hardware EUSART port, doesn't seem to work (receive works fine though).
I checked the INIT PPS section on both 16F1618 and 16F1579 asm codes (where the TX pin is assigned), and they are exactly the same. However, checking on datasheets of both pics, the USART transmit block diagrams seem to have major differences, although receive block diagrams look the same. I also tried to remove the init pps section from 16F1579 code (as i note on TX block diagram there is no refference to PPS at all) and assign directly the TX pin but still didn't work.
Could you please take a look at this?
Last edit: ikonsgr74 2018-05-12
Transmit on the 16F1579. Correct?
Can you connect an serial analyser? Can you determine anything?
Can you connect the PIC to a PC? Start serial Terminal - try changing the Baud Rate. Is the part therefore clocked at the correct frequency?
Yes, that's what i did. Anything is sent from pc to amstrad cpc is received fine, so most probable pic and code functions ok.The problem is that nothing transmitted from amstrad (e.g. pic's usart) to pc seem to work , nothing is received to pc.
I just checked same code for 16F1618 and worked perfect, so something must be wrong in setting the TX pin on 16F1579
Not sure this is the case. I dont know how you know this.
Have you checked the basics as I asked?
What did you find?
Yes, any command for changing baud rate works ok (i have the proper respond from pic).
I'm using a pair of bleutooth modules and a terminal on pc to check comunications. Receiving characters from pc to amstrad works fine, but when i send something from amstrad, i dont get anything on pc terminal receive window.
I have an 8channel salae logic analyzer somewhere, but i have to find it first to get any serial anlysis :-)
Note that the same code works perfect on both directions with 16F1618, that's why i said something might be wrong with correct setting of TX pin (which is set using PPS) with 16f1579
Let us analyse please.
Use the PPSTOOL to recreate the PPS setting. I see that the PPSTOOL headings are missing so - my guess. You have not recreated for this part.
Let us analyse please.
Use the PPSTOOL to recreate the PPS setting. I see that the PPSTOOL headings are missing so - my guess. You have not recreated for this part.
Hi John,
This may help - PIC16(L)F1574/5/8/9 Family Silicon Errata
I found this:
Enhanced Universal Synchronous Receiver Transmitter (EUSART) Transmit Mode
Under certain conditions, a byte written to the TXREG register can be transmitted twice.
This new byte is immediately transferred to the TSR register, but also remains in the TXREG register until the completion of the current instruction cycle.
f the new byte in the TSR register is transmitted before this instruction cycle has completed, the duplicate in the TXREG register will subsequently be transferred to the TSR register on the following instruction clock cycle and transmitted.
Work around
Monitor the Transmit Interrupt Flag bit (TXIF).
Writes to the TXREG register can be performed once the TXIF bit is set, indicating that the TXREG register is empty."
So a slight delay befor sendind a second byte may solve the proiblem.
Cheers
Chris
We do monitor the TXIF and where appropiate the TX1IF regisgter bits.
My PPS tool for 16F1579 created same code with one difference in the "crucial" line of setting the TX pin:
RB7PPS = 0x0006 'TX > RB7
instead of 0x0009 you mentioned.
Anyway, i changed the value to 0x0009 and again... it worked!
So, why this happened? Is it a bug with pps tool, not setting the correct value?
No idea.
Unless you keep the PPSTool information in your code - the fulll header - you would be guessing.
Your original code had no PPSTool information in the code (I am looking at it) so, I would be guessing.
I simply would ALWAYS ALWAYS recreate for a new part and post (and retain) the complete PPSTool insertion.
Good luck. Case closed.
Not a bug in the tool, a bug in the copy/paste method.
PPS is device specific.
There may be core similarities but PPS is hardware level so the Die of the Chip may be routed differently between members of the same family, leading to core differences.
For this reason it is important that you actually run the PPS tool, rather than copy and paste, when moving code between devices, even in the same family.
Cheers
Chris
Last edit: Chris Roper 2018-05-12
After a quick check on pps tool, it seems that although i've changed pic to 16F1579 (from previous 16F1618 ) for some reason, it didn't load the correct xml file, and used the "old" of 16F1618. So,i close PPS tool program, re-open it, select 16F1579, set PPS output to RB7 pin ,TX peripheral, and the code produced was correct!
Anyway, thanks for your help and advices, guys!
COWBASIC RULES! ;-)