HSerReceive (or USART.h) versus Chipdata Definitions

[kent_twt4]

Been trying to use HSerReceive here lately and have run into compile error with the 16f1783, although I think this may be a wider problem? I am still using 0.94 but updated the. dat file and new usart.h from trunk.

I think it is possibly that OERR1 bit is checked in library, but it is not defined in the .dat file. Not sure what register or group of devices the OERR1 bit belongs to. So if anyone wants to try the simple program to verify. Also should CREN or CREN1 bit be set when USART_Blocking being defined?

errors:

usart.h (291): Error: Incorrect parameters in Set, expected: Set variable.bit status
usart.h (292): Error: Incorrect parameters in Set, expected: Set variable.bit status

'Chip model
#chip 16f1783, 8

'*****setup Hardware UART*****
#define USART_BAUD_RATE 115200
#define USART_Blocking
#define SerOutPort PortC.6
#define SerInPort PortC.7
dir SerOutPort Out
Dir SerInPort In
Dim RxByte(3)
'On Interrupt UsartRX1Ready Call ReceiveData
'test uart communication
For count = 0 to 10
  HSerPrint count
  HSerSend 10
  HSerSend 13
  wait 100 ms
Next
  HSerSend 10
  HSerSend 13
  HSerSend 10
  HSerSend 13
wait 1 s

Main:
  HSerReceive InData
  HSerPrint InData
  HSerSend 10'
  HSerSend 13
goto Main

[kent_twt4]

O.K. I got the old usart.h include file to work. Can't say I have the fix for it yet, as I just went the specific chip fix of #ifdef Var(RCREG) only, commented out #ifndef Var(RCREG1) and #ifdef Var(RCREG1) flow control for other chips.

I think it might also affect the new usart.h also. It has to do with the flow control in HSerReceive sub and the dat file definitions. Since the dat file definitions recognize RC1REG, RCREG, RCREG1, then the usart.h #ifndef Var(RCREG1) and #ifdef Var(RCREG1) are moot. That is, the compiled asm will show the last condition which is how the OERR1 bit problem comes up.

[Anobium]

I get no errors when compiling this code, ASM looks good also.

This is probably caused by using an older version of the compiler and the release package. We are maintaining the release to support a chips having different registers to the previous releases of Great Cow BASIC.

Just to share what we do:

When we find these types of differences of this type we address by updating the support files - we do not change the .dat file - I will explain.

The .dat file is generated from sources provided by Microchip, Atmel etc. We convert these to .dat format. Key to this is the sovereignty of these data sources - this means that we do not want to change the .dat but we want Microchip and Atmel to provide as a clean data source. We simply consume.

So, what happens when Microchip change registers to add functionality? We adapt the .h support files. We use scripts to minimise maintenance. Scripts are used to essentially map new registers and bit to the existing code.

If I take the 16f18855 (and the associated range of chips) as an example. This introduce a huge amount of new functionality. This took me about a month to understand the changes and to adapt the .h support files - we also had to change the compiler to support the new additional config statements.

If I take the 16f18326 (and the associated range of chips) as another example. This took a few minutes to add the new functionality. Note: The chip has other Microchip bugs that caused a lot more work. :-)

I am probably wrong about the root cause of your porblem but do try the latest release. I will publish v.0.95.008 when I get home to England today. v.0.95.008 contains the support for the 16f8326 range and it could easily address the issues you are encountering.

Anobium

[kent_twt4]

OK, I am now officially updated to 95.008!

Of course it works perfectly fine, no adjustments required to usart.h. Thanks Evan, and appreciate the explaination.

[roberto oscar]

¿Version 95.008 disponible?

[Anobium]

I am thinking you want to know about 008 ? If you wait tilltomorrow I will upload 009 - this includes a new GLCD driver.