HBUSIN as a legacy command

[SCV]

I get a hint after compilation about HBUSIN / HBUSOUT and related are legacy commands and will not be supported in future revisions.
What is the recommended command set to replace them?

Thanks,
Tim.

[evoortman]

I think that would be I2Cin / I2Cout ?

[Stephen Moss]

If you want to use the hardware as opposed to bit bashed software serial comms there is no alternate command, you have to write you own code to set up the registers, read/write the data buffer and handle any interrupts.

If you are using older devices the command may still work for you, it is just not guaranteed to work, particularly with newer devices that have a different set up to the way command expects, so it is best to write your own code when using the PIC hardware.

To quote Les "The HBusin and HBusout commands will not be removed from the compilers, but if the compiler senses the SFRs it requires for its existing library routines are not present on the device it will not be able to support them, and will give an error."

[Gamboa]

SCV,
You can use the BUSIN BUSOUT software commands. These work perfectly, but do not use the hardware resources of the microcontroller. I think they are a bit slower but they are more flexible than hardware commands.

Regards,
Gamboa

[keytapper]

Depending which MCU is used. If midrange family there's no harm. It will compile and run as expected.
I assume that the core compiler will keep working for old MCU.

[SCV]

Thanks for the responses.

[krizpin]

good evening ... I don't understand anything .... now we can't use the commands to handle i2c in the new compilers ... but we don't understand that each updated version should improve our lives ...if to handle i2c we have to work directly with the records of the pic ... we can eternalize in time and code

[John Drew]

You can use I2C with the new compiler. I do it all the time. It's just that some of the newer types might require a different approach. Just don't use the newer type PICs that have special requirements.
John

[krizpin]

good morning john.
I am currently with a project that uses pic 18f46k20, this pic if I program it with compiler version 3.7.5.5 gives me a warning hbusout is now a "legacy" command and it will not be supported by the next compiler versions, but if I program it with version 3.7.3.6 it doesn't give me problems.

[top204]

The message is to tell people that the newer devices that have a different way of using the I2C peripherals will not be supported by the compilers as a command. However, they will still remain for the devices that do support the way the compiler's library subroutines work.

Some of the newer devices have changed, dramatically, the way the I2C is setup and operate and they keep changing from family to family, so the logistics of buying devices, writing code, and testing is simply too much for a single person. i.e. Me!

Because the 8-bit compiler now has procedures, libraries could be created for specific devices that control the I2C peripheral.

Whenever possibe, I do not use the I2C peripheral on a device, and use the software I2C coms I created. i.e. I2CIn/I2COut, Busin/Busout, because the code is then fully transportable across the devices and they operate "exactly" the same way as the peripheral version.

[Stephen Moss]

good morning john.
I am currently with a project that uses pic 18f46k20, this pic if I program it with compiler version 3.7.5.5 gives me a warning hbusout is now a "legacy" command and it will not be supported by the next compiler versions, but if I program it with version 3.7.3.6 it doesn't give me problems.

The addition of the warning message is a recent change which it why it does not appear when using V3.7.3.6, it was added to alert those using the HBUS commands of their change in status and thereby indicate that you should not really be using it when writing new programs as they may not work.
Any command that has been downgraded to Legacy status is retained purely to maintain compatibility with older code that already uses it rather than taking the other option of removing the command completely (see the quote from Les in my earlier post).

Just because the warning is not issued in version 3.7.3.6 that does not mean you should assume the command will work for every device that version supports, only that the compiler does as not warn you about using the command with an unsupported device.
When the compiler V3.7.5.5 encounters a device that does not have the registers the compiler commands require it will generate an error like this...
Device not suitable for the HBUSin or HBUSout commands because no SSPCON2 register available!

If you still want to use compiler commands for I2C transactions you can use the I2Cin and I2Cout commands, but you need to be aware that they are software (bit bashed) I2C data transmissions and so the PIC cannot execute other code during I2C data transmission like it could when using the PIC hardware for I2C commands.

You seem disappointed at the news about the legacy status of the command and that is understandable, however when different devices have different ways of doing things it becomes extremely difficult to maintain compatibility. It is time consuming, constantly bolting bits of new code in to support all the different device methods can make the code more difficult to read and maintain, plus making such changes can sometime result in the introduction of unforeseen errors that could manifest themselves in other parts of the compiler.
Consequently, at some point it becomes too impractical to support and so the features/commands are removed or downgraded to Legacy status. The compiler is still supported by Les because he is passionate about his creation and we are grateful for this, but he is just one man, not a large team of developers and testers and there is only so much one man can do.

As useful and convenient as the as the compiler commands can be, particularly if you are in a hurry or just starting to program PICs, it is always wise when you have time to start reading the PIC data sheet and start experimenting working with the hardware directly by reading/writing the applicable registers because at some point you may want to use a device feature for which there is no compiler command and so knowing how to read/write registers directly it a useful thing learn.

[John Drew]

Stephen, correct me if I'm wrong but I find using the hardware peripheral very useful to trigger an interrupt.
I appreciate the complexity caused by new devices and the difficulties this causes Les.
I hope that the legacy commands can remain with appropriate warnings.
John

[krizpin]

a very interesting and positive explanation to learn to better understand what happens when these changes occur in the compiler.
It is very true that writing / reading the registers is very useful to understand how the pic works but when the code is very large and you have to access the i2c many times, having to write all the read / write code becomes tedious.
John's comment is very interesting, it would be very good if the compiler keeps the appropriate warnings about these changes but maintaining the functionality. We programmers can already assume or not that possible loss of data.

[krizpin]

The message is to tell people that the newer devices that have a different way of using the I2C peripherals will not be supported by the compilers as a command. However, they will still remain for the devices that do support the way the compiler's library subroutines work.

Some of the newer devices have changed, dramatically, the way the I2C is setup and operate and they keep changing from family to family, so the logistics of buying devices, writing code, and testing is simply too much for a single person. i.e. Me!

Because the 8-bit compiler now has procedures, libraries could be created for specific devices that control the I2C peripheral.

Whenever possibe, I do not use the I2C peripheral on a device, and use the software I2C coms I created. i.e. I2CIn/I2COut, Busin/Busout, because the code is then fully transportable across the devices and they operate "exactly" the same way as the peripheral version.

I understood that the software commands did not work the same as acting directly on the peripheral. Especially when it comes to generating interruptions etc. In fact, in other posts I read that software commands could fail a lot when acting on a device that already has a specific peripheral for that function. Is this information not true? because if they really work the same it is much more comfortable to use software commands that will always work with all devices

[Stephen Moss]

Stephen, correct me if I'm wrong but I find using the hardware peripheral very useful to trigger an interrupt.

You are correct.
That should be the advantage of hardware based comms over bitbashed as it means the PIC can do other things while the hardware is taking care of the data transmission and can then jump back to read the incomming or write new outgoing data upon at suitable interrupt being triggered. This is enhanced even more on those devices (i.e. PIC24) where each peripheral has its own interrupt vector so you can essentially create an interrupt routine for each one, instead of a single "ON_Hardware_Interrupt" ISR which then has to waste time testing unrelated interrupt flags because all your IRS are placed in one big subroutine.

I have not looked at the code produced by the compilers hardware or software communication commands and so do not know which (if any) interrupts they use but when writing you own code you can use interrupts the compiler commands do not and so have a little more flexibility, if only because having had to read the datasheet you are more aware of the interrupts that are available to you.

It is very true that writing / reading the registers is very useful to understand how the pic works but when the code is very large and you have to access the i2c many times, having to write all the read / write code becomes tedious.

It sounds like you think you would need to write the same code multiple times when that is not necessary, normally you would write a subroutine or even better a procedure (maybe two, one receive and one transmit) and call them every time you wanted to read received data or write data to transmit as applicable. Writing the calling code then takes no more code space or time than writing the HBUSin or HBUSout commands every time you want to send/receive data.
1) You write the configuration code for the hardware (i.e. set Master or Slave, SPI or I2C, clock speed) - one time only
2) Enable the require interrupts for the hardware module - one time only
3) Write read and/or write Subroutines/Procedures - written once but called many times
4) Write interrupt handler (i.e. copy received data from buffer into variable or copy variable into buffer for transmission, & clear interrupt) - written once but called many times

John's comment is very interesting, it would be very good if the compiler keeps the appropriate warnings about these changes but maintaining the functionality. We programmers can already assume or not that possible loss of data.

The commands will remain but the appropriate warning will be issued by the compiler upon their use, I refer you again the quote I included form Les (TOP204) in my first post on this topic and the reply he made earlier which also states in the first line that commands will remain.   

[Fred Philpott]

Curses. I just spent a few days learning how to use the HBus commands to write to a Midas MCCOG21605D6W-BNMLWI display and now I find they are becoming legacy. I went over to an I2C display because they are easier to find than 6800 bus and I thought it might make life easier in the future. I understand the reasoning and I will continue to stay with it for the time being.

I would be interested in hearing any comments from other people about the advisability of switching to I2C for displays.

[John Drew]

Fred, on the old WIKI There were routines to drive the I2C displays. If they haven't found their way onto our new WIKI I'm sure there are people here who could find a copy.
Using I2C saves many pins.
Keep in mind Legacy doesn't mean lost. I believe there are other commands that are legacy and have been left there since the early days but just don't have a warning attached. I could be wrong, my wife tells me I often am.
John

[RayEllam]

Coincidence I guess. I just bumped into that issue today while trying to get an I2C driver for SSD1306 working. I do get the issue with microchip changing the way the parts work/register names. It must be a PITA for proton developers.

So it seems the upshot is, if you get compile warnings saying legacy command then the code should work? If you get a compile error then it won't? Please clarify?

Ray