Redefined procedures on Usart_c67 and c67g12

[MAN]

Hi Zoran;

After attempts for recompile some lib(done by me) used in the previous version, I am acquiring the following error:
Link error:Redefined: usart_write_text usart_c67g12.ppas
Link error:Redefined: usart_read_text usart_c67g12.ppas

do you already have some modification for those mcl's?


Thank's in advance;

[srdjan]

Hi,

Hi Zoran;

After attempts for recompile some lib(done by me) used in the previous version, I am acquiring the following error:
Link error:Redefined: usart_write_text usart_c67g12.ppas
Link error:Redefined: usart_read_text usart_c67g12.ppas

do you already have some modification for those mcl's?


Thank's in advance;

Do you have Usart_Write_Text routine defined somewhere in your library? If, yes, open your mcu definition file mcu_nameDEF.pbas and comment out the usart_c67_g12 library. Save the file, restart the compiler and recompile.

[MAN]

Hi srdjan;

thanks,

.

Do you have Usart_Write_Text routine defined somewhere in your library?

The problem is exactly this I don't have any procedure inside of my lib defined like Usart_Write_text and none a call for her. I just call from within my mcl for the native routine Usart_Write.
This problem seems to happen when I try to recompile a lib compiled with devices that just has one USART for a device that has two USART.

I forgot about another detail, when I compile the lib for a device that has two usart the problem appears in the lib Usart_c67.mcl :Redefined: Usart_write_text and Usart_Read_text.

[srdjan]

Hi,

Hi srdjan;

thanks,

.

Do you have Usart_Write_Text routine defined somewhere in your library?

The problem is exactly this I don't have any procedure inside of my lib defined like Usart_Write_text and none a call for her. I just call from within my mcl for the native routine Usart_Write.
This problem seems to happen when I try to recompile a lib compiled with devices that just has one USART for a device that has two USART.

I forgot about another detail, when I compile the lib for a device that has two usart the problem appears in the lib Usart_c67.mcl :Redefined: Usart_write_text and Usart_Read_text.

Well thats about it. Different mcus use different usart libraries.
Compiler, however, writes the name of the unit in which he found usart routines for appropriate MCU in the .mcl file.
So, when you build your library with the mcu that has one usart modue, Usart_c67 is linked and written into the library .mcl file. When you use this precompiled library file with the mcu that has two usart modules, compiler will link usart_c67 because it is written into your mcl, but it will also link usart_c67_g12, because it stands in library list for the specific mcu (located in appropriate *def.pbas file). So, now you have linked two units with usart definitions and there you have usart redefined messages.

Note that this will also happen if you use your library with the MCU that has one usart module, but on different pins.

The solution would be to make two libraries, one for mcus with one, and one for mcus with two usart modules.

Or you could have one library file, but you'll have to comment out usart library from MCU library list in def file. It should work because mcus with two usart modules you are talking about have usart1 module on the same pins as the mcus with one usart module. However, in this case you'll not be able to use usart2 routines. I would not recommend this approach.

[MAN]

Hi;

So, when you build your library with the mcu that has one usart modue, Usart_c67 is linked and written into the library .mcl file. When you use this precompiled library file with the mcu that has two usart modules, compiler will link usart_c67 because it is written into your mcl, but it will also link usart_c67_g12, because it stands in library list for the specific mcu (located in appropriate *def.pbas file). So, now you have linked two units with usart definitions and there you have usart redefined messages.

Thus, I see that you agree that the two lib, c_67 and c_67g12 has procedures with the same name. I would never write two lib's that could have the smallest possibility to share resources inside with the same name procedure. I know that difference also exists in the referring symbolic names to the registers that compose usart's in the mcu that has one and two usart however the addresses for the first usart it is the same for both. Perhaps it was then interesting to change this radically, thus, a lib for mcu that has 2 usart would use explicit reference to them
ex.: Usart_Write1, Usart_Write2, Usart_Write_Text1 and and so on, this way if usart_write1 were called for a mcu that just has 1 usart the linker says error of registers " TXREG1 not declared ". And for lib's with mcu that has 1 usart would just use USart_write and Usart_Write_text.
This way I would agree in having two lib's different from other form the more obvil it would be to maintain previous compatibility.

The solution would be to make two libraries, one for mcus with one, and one for mcus with two usart modules.

I had already thought of this, but, for some mcl's I don't have more the source, then I am with loss.

Or you could have one library file, but you'll have to comment out usart library from MCU library list in def file. It should work because mcus with two usart modules you are talking about have usart1 module on the same pins as the mcus with one usart module. However, in this case you'll not be able to use usart2 routines. I would not recommend this approach.

The fact to comment a lib or other I think to be not very elegant once the mcu's that has 2 usart has the first usart in the same pin's and same address to the that has 1 usart.

I see like this that in this new version some things were moved because in the previous version this didn't happen.
Please understand, your lib is great, I am just informing a fact and don't charge for this.

[srdjan]

Hi;

So, when you build your library with the mcu that has one usart modue, Usart_c67 is linked and written into the library .mcl file. When you use this precompiled library file with the mcu that has two usart modules, compiler will link usart_c67 because it is written into your mcl, but it will also link usart_c67_g12, because it stands in library list for the specific mcu (located in appropriate *def.pbas file). So, now you have linked two units with usart definitions and there you have usart redefined messages.

Thus, I see that you agree that the two lib, c_67 and c_67g12 has procedures with the same name. I would never write two lib's that could have the smallest possibility to share resources inside with the same name procedure. I know that difference also exists in the referring symbolic names to the registers that compose usart's in the mcu that has one and two usart however the addresses for the first usart it is the same for both. Perhaps it was then interesting to change this radically, thus, a lib for mcu that has 2 usart would use explicit reference to them
ex.: Usart_Write1, Usart_Write2, Usart_Write_Text1 and and so on, this way if usart_write1 were called for a mcu that just has 1 usart the linker says error of registers " TXREG1 not declared ". And for lib's with mcu that has 1 usart would just use USart_write and Usart_Write_text.
This way I would agree in having two lib's different from other form the more obvil it would be to maintain previous compatibility.

- And what about the mcus that have one usart modules but on different pin (not rc6 and rc7). How should we call these routines?

The solution would be to make two libraries, one for mcus with one, and one for mcus with two usart modules.

I had already thought of this, but, for some mcl's I don't have more the source, then I am with loss.

- I'm sorry to hear this. If you think of a way in which we could help you, contact me again.

Or you could have one library file, but you'll have to comment out usart library from MCU library list in def file. It should work because mcus with two usart modules you are talking about have usart1 module on the same pins as the mcus with one usart module. However, in this case you'll not be able to use usart2 routines. I would not recommend this approach.

The fact to comment a lib or other I think to be not very elegant once the mcu's that has 2 usart has the first usart in the same pin's and same address to the that has 1 usart.

I see like this that in this new version some things were moved because in the previous version this didn't happen.
Please understand, your lib is great, I am just informing a fact and don't charge for this.

- I do not really not how it could work in the previous versions. You should have got the same redefinition message.

[MAN]

Hi;

- And what about the mcus that have one usart modules but on different pin (not rc6 and rc7). How should we call these routines?

Well I think that who define this is the *def files and in this case it can point to other lib for this special case. Like this as, c_67 and c_67g12 was written for two mcu that have the first usart at same address, this two lib can be joined into one and the case above would give place to a new one.

- I'm sorry to hear this. If you think of a way in which we could help you, contact me again.

Don't worry about this, I will rewrite it when I need.

I do not really not how it could work in the previous versions. You should have got the same redefinition message.

For MCU that I do used at time, I never get this message in the previous version.

[srdjan]

Hi;

- And what about the mcus that have one usart modules but on different pin (not rc6 and rc7). How should we call these routines?

Well I think that who define this is the *def files and in this case it can point to other lib for this special case. Like this as, c_67 and c_67g12 was written for two mcu that have the first usart at same address, this two lib can be joined into one and the case above would give place to a new one.

- You have missed the point.
Lets say that we have two MCUs with usart modules. One MCU has usart module on rb2, rb1 and the other on rc6,rc7. We will make two libraries usart_b21 and usart_c67. One for each MCU. Which names shall we use for usart handling routines in these two files? If someone wants to use his libraries in the way you did (build library with one and then use it with the other MCU), we can not use i.e. Usart_write as a name in both of them. What should we use as procedure names in this case?
This is just a hypothetical case with two different usart modules. Now picture the real problem, we have 6 different usart libraries for pic16 family MCUs (one usart module).

[MAN]

Hi;

You have missed the point.

Perhaps not.

Lets say that we have two MCUs with usart modules. One MCU has usart module on rb2, rb1 and the other on rc6,rc7. We will make two libraries usart_b21 and usart_c67. One for each MCU. Which names shall we use for usart handling routines in these two files? If someone wants to use his libraries in the way you did (build library with one and then use it with the other MCU), we can not use i.e. Usart_write as a name in both of them. What should we use as procedure names in this case?

For the one that you wrote above, I understand that:
We have 2 MCU (MCU-A) and (MCU-B). MCU-A has usart in the pins rb2 and rb1 then we create the lib usart_b21, soon MCU-B has an usart in the pins rc6 and rc7, then we create the lib usart_c67.

Thus, I can surely say that we can have the same name for procedures and functions in both lib because I understand that, if we set the MCU-A in the device panel, the compiler will seek and to just carry the files MCU-Adef.pbas and MCU-A.pbas regarding this chip(MCU-A) and inside of MCU-Adef.pbas usart_b21 would just be carried. For usart_c67 it would be hidden now, there would be like this never conflict among names of procedures. However, if the linker carries all the *def and *.pbas then oh a serious problem exists, there won't be enough, different names, for everybody.
Well, Maybe I'm wrong too, because I don't know the real scope, of which this platform is being developed.

This is just a hypothetical case with two different usart modules. Now picture the real problem, we have 6 different usart libraries for pic16 family MCUs (one usart module).

eah, I know that is not easy to control this. I respect the initiative and the team's courage in facing this challenge.

Please, now see this fragment of code generated by compiler for p18f8520 that have 2 usart's. Is for this point that I call the attention too.
All the source basic code of this example was duplicated but I only place reference for usart_Write.

Code: Select all

main:
Usart_Init1(9600)
Usart_Init(9600)

Usart_Write1(13)
Usart_Write(13)

Usart_Write_Text1("MyTest")
Usart_Write_Text("MyTest")

End.

Result;

Code: Select all

;  Assembly code generated by mikroVirtualMachine - V. 5.0.0.3
;  Date/Time: 8/11/2007 15:03:46
;  Info: http://www.mikroe.com


; ADDRESS	OPCODE	ASM
; ----------------------------------------------
$0000	$EF7A	F000			GOTO	_main
$0008	$	_usart_write1:
;USART_c67g12.ppas,131 :: 			
;USART_c67g12.ppas,132 :: 			
$0008	$	USART_c67g12_L_49:
$0008	$6A01	    			CLRF	STACK_1, 0
$000A	$B2AC	    			BTFSC	TXSTA1, 1, 0
$000C	$2A01	    			INCF	STACK_1, 1, 0
$000E	$5001	    			MOVF	STACK_1, 0, 0
$0010	$0A00	    			XORLW	0
$0012	$E102	    			BNZ	USART_c67g12_L_50
;USART_c67g12.ppas,133 :: 			
$0014	$0000	    			NOP
$0016	$D7F8	    			BRA	USART_c67g12_L_49
$0018	$	USART_c67g12_L_50:
;USART_c67g12.ppas,134 :: 			
$0018	$C021	FFAD			MOVFF	FARG_USART_Write1, TXREG1
$001C	$	USART_c67g12_L_47:
;USART_c67g12.ppas,135 :: 			
$001C	$0012	    			RETURN
$001E	$	_usart_write:
;USART_c67g12.ppas,33 :: 			
;USART_c67g12.ppas,34 :: 			
$001E	$	USART_c67g12_L_8:
$001E	$6A01	    			CLRF	STACK_1, 0
$0020	$B2AC	    			BTFSC	TXSTA1, 1, 0
$0022	$2A01	    			INCF	STACK_1, 1, 0
$0024	$5001	    			MOVF	STACK_1, 0, 0
$0026	$0A00	    			XORLW	0
$0028	$E102	    			BNZ	USART_c67g12_L_9
;USART_c67g12.ppas,35 :: 			
$002A	$0000	    			NOP
$002C	$D7F8	    			BRA	USART_c67g12_L_8
$002E	$	USART_c67g12_L_9:
;USART_c67g12.ppas,36 :: 			
$002E	$C021	FFAD			MOVFF	FARG_USART_Write, TXREG1
$0032	$	USART_c67g12_L_6:
;USART_c67g12.ppas,37 :: 			
$0032	$0012	    			RETURN

Then, if the compiler was duplicated the code assembler, why we don't try to share it with MCUs that have 2 usart with that have 1 usart at the same addres and pin's and get just one assembler code.

[srdjan]

Hi,

Then, if the compiler was duplicated the code assembler, why we don't try to share it with MCUs that have 2 usart with that have 1 usart at the same addres and pin's and get just one assembler code.

If i have understood you correctly this is my answer.
MCUs with two usart modules have 3 usart libraries defined for them: Usart, Usart1 and Usart2.
Usart library is identical to Usart1 library. This was done intentionally, so that user would not have to change the code when migration to "bigger" MCU which often has two usart modules. The code written for MCU with one usart module will be compatible and can be used without changes with MCU with two usart modules.

If I have misunderstood you, please, do correct me.

[MAN]

Hi;

If i have understood you correctly this is my answer.
MCUs with two usart modules have 3 usart libraries defined for them: Usart, Usart1 and Usart2.
Usart library is identical to Usart1 library. This was done intentionally, so that user would not have to change the code when migration to "bigger" MCU which often has two usart modules. The code written for MCU with one usart module will be compatible and can be used without changes with MCU with two usart modules.

That's good, like this we turn back the problem "back compatibility".

Now before I start this topic, for me I modified some *def and *.pbas file and I work with only usart_c67g12 lib for 18F4xx and 18F8xxx and I re-compile the same mcl that use only first usart for both. But certainly it just will work to me.