Adding native RS485 support to Arduino Serial Library

Development Libraries
#1

Dear Community,

I am working currently on a project where I need to use RS485. So far, I have not found any official solution, utilizing the HW USART(s).

Since the Arduino Serial library is the natural place to add this functionality I have modified it to add this functionality on my own. It eliminates the need to manually set the TX enable and wait until transmission is complete to clear it. The RS485 functionality can be simply invoked by adding a few control parameters to Serial.begin. Sending data in the usual manner is all that is required:

Serial.print("whatever..."); // DIR is automatically asserted.

The puffered sending is not affected in any way as the routine accomodates the data shifting out until the last character was sent to prevent cutting off the ongoing transmission.

Here is an example:

#define RS485_BAUD 9600
#define RS485_ENABLED 1
#define RS485_DISABLED 0
#define RS485_DIR_PIN 13 // standard Arduino pin numbering used here

#define RS485_POLARITY_ACTIVE_HIGH 0
#define RS485_POLARITY_ACTIVE_LOW 1

Serial.begin(RS485_BAUD, SERIAL_8N1, RS485_ENABLED, RS485_DIR_PIN, RS485_POLARITY );

where
RS485_ENABLED oder RS485_DISABLED, 1=ENABLED oder 0 (0=DISABLE)

RS485_POLARITY is only important for me due to hardware design reasons as ot allows to set the default level of the DIR pin.

I have tested it so far only on a ATMEGA328 but to plan to test it on chips with more then one USART. Once, testing has been satisfactory I would like to request if this modified library could become standard for the Arduino IDE package. Currently, I need to replace the two files HardwareSerial.cpp and the header file. This is clearly not ideal for the community.

Using Serial.begin in the normal short way, ignores the RS485 addition.

My question to you is, would you consider it beneficial to the wider community or should I just use it privately on my own? In the spirit of sharing I feel it is a worthwhile addition to the Arduino overall funtionality.

Anyways, I would appreciate to hear from you if you feel it deserves any interest and should be pursued further.

Best Regards,
Gerhard

#2

Is there any overhead for your added functionality when it's not being used (flash, SRAM, clock cycles)? If so, I don't think it's a good idea to add it to the HardwareSerial library because there are many more users who would be negatively affected than those who would benefit. In that case it would be better to publish it as a 3rd party library. Ideally this library could be installed normally, if it was necessary to replace files in the Arduino core library I'm sure those who need it would still be grateful to you for making it available.

If there's no overhead then the next question is why is it necessary to incorporate this into the HardwareSerial library? If there are no downsides to publishing it as a 3rd party library then it would be better because then you won't need to deal with trying to get it merged into the Arduino core library. If there is good reason for merging it then I think it's worth consideration.

#3

I need to get back to you and get the numbers. If the RS485 functionality is not used, the overhead is only 4 IF conditional tests to see if it is needed. The actual port assertion is done with a call to the standard pinwrite function. I estimate the overhead is under 100-200 bytes. I shall confirm that soon.

The serial library is really the best place where the Rs485 control is implemented. If there was a way to prevent ARDUINO from loading and claiming the USART interrupts then a third party solution would work. At this time, I don't know. It seems, even when Serial is not used, the interrupts are claimed and it is not possible to relplace the standard serial library.

If nothing else, the user just needs to save the two files and replace them with the modified ones. If not needed they could be removed. I could post the modified files soon for anybody interested testing them.

#4

I have done a quick test building the project with the original serial lib and the modified ones.

The difference is 184 bytes FLASH and 3 bytes RAM.

It might be possible to improve that.

#5

In the world of Arduino 184 bytes is a lot. It’s unfortunate that there isn’t an easy way for 3rd parties to override the core libraries, as you can do with other libraries by putting a modified version in your sketchbook. It would be nice if they had set it up so you just #include <HardwareSerial.h> in your sketch when you want to use it instead of the Arduino IDE assuming you always want it included. The only 3rd party installation alternative to replacing the HardwareSerial files I can think of is to create a whole hardware package that includes your modified HardwareSerial library in its core. This would allow the user to install it via Boards Manager without the need to reinstall after every IDE upgrade. Yeah, it seems a bit overboard for one library but I’m just brainstorming here.

#6

Yes. It is a bit of an inconvenient situation for now. Perhaps, a better way can be found in the future. Direct port access would save a bit. However, I wanted to allow the user to choose standard IO pins convention and used digital.write functions instead. Initially, I used direct port access and it saved quite bit of FLASH.

In any event, I do feel that the current updated libraries are a solution for some users, albeit somewhat inconvenient to setup. On the other hand, if the users had to add manual DIR control in front and after each serial write it would also take up memory and require the use of flush() to ensure completion of transmission.

Personally, I prefer to use the 1284 for most of my more involved projects and it doesn't matter very much there.

Anyways, perhaps together we can eventually create a better solution in the future together. I am still learning C++ and don't know all the subtle possibilities there. Right now, I probably implement things rather crudely.

It does, however work properly and a oszilloscope observation confirms perfect timing.

#7

Yeah, I love the ATmega1284P. I've made some small efforts to make that chip more accessible to the Arduino community.

My advice is to make your work publicly available and see what happens. It may benefit some people, some people may contribute to the project and benefit you in return. I think a GitHub repository is the best way to do this and will make it easy for people to contribute to the project.

I'm skeptical about the prospects of the Arduino developers merging something with so much overhead but I certainly don't have an official voice in the matter. I just did a search of the Arduino IDE repository to see what had been said on the subject and there are some things you might find of interest in the results:

#8

Thanks for your suggestions and comments. I will check out the github link. Perhaps, the work is already superbly done and my efforts come way too late. Unfortunately, I was not aware of his work.

I will put the modified libs on Github once I know how to publish them there and perhaps they will be useful to someone too. I certainly will use them myself;-)

Anyways, I apreciate all the feedback. I am a late comer to the Arduino world, but I realized soon what gift to the world to interested people this monumental effort is and certainly deserves all the support it can get.

I have designed new 1284P and 328PB miniature boards somewhat similar to Pro-Mini but with emphasis for lowest possible current drain and other features that make it more useful for low power battery or solar powered data logging applications. They will be eventually published on Github when I had a chance testing them. The 1284P should really become the standard Arduino platform chip as it offers so much more. It certainly makes a FAT file system far less FLASH consuming. The much increased RAM size is also a bonus.

Cheers,
Gerhard

#9

pert:
...I just did a search of the Arduino IDE repository to see what had been said on the subject and there are some things you might find of interest in the results:
Issues · arduino/Arduino · GitHub

Some clarification seems in order:
I had a look at Michael's library and it is a much more comprehensive implementation than mine. My adaptation of the Serial core library simply asserts a chosen pin automatically whenever the USART is sending out data and returning the pin to the non-active state once all bits have been shifted out from the send shift register. The rest depends on the user application. With my Serial library modification you can simply connect two uC together via RS485 transceivers such as MAX483/5/SN75167 and they will be able to simply communicate with each other using half-duplex 2-wire connection, the same way as if RS232 was used.

#10

If you have any questions on using GitHub I'm happy to help. There's a little bit of learning curve but I think you'll find it worthwhile in the long term. It's by far the most popular site for hosting code now and they really do a great job of making it easy to collaborate on open source projects. If you're already familiar with Git version control then you already know most of what you need to use GitHub. If you aren't familiar with Git then the basic concepts you need to learn to be able to use GitHub will be a useful introduction. I started with GitHub because I had a couple bugfixes I wanted to submit to some Arduino library repositories. That eventually got me started on using Git version control on my own projects and it has made a huge difference in the quality and efficiency of my programming. I'm sure it's not for everyone but definitely at least worth giving some consideration.

There was also some issues or pull requests in those search results regarding modifying HardwareSerial for use with RS485. I didn't read them very thoroughly but thought they might be relevant.

I think it's good for people to have multiple choices. Every user has different needs so it's difficult for one one library to work for everyone. There's certainly no need for there to only be one Arduino project for each application.

Did you get any insights on how that library had dealt with the issue of HardwareSerial and the interrupts?

#11

pert:
If you have any questions on using GitHub I'm happy to help. There's a little bit of learning curve but I think you'll find it worthwhile in the long term. It's by far the most popular site for hosting code now and they really do a great job of making it easy to collaborate on open source projects. If you're already familiar with Git version control then you already know most of what you need to use GitHub. If you aren't familiar with Git then the basic concepts you need to learn to be able to use GitHub will be a useful introduction. I started with GitHub because I had a couple bugfixes I wanted to submit to some Arduino library repositories. That eventually got me started on using Git version control on my own projects and it has made a huge difference in the quality and efficiency of my programming. I'm sure it's not for everyone but definitely at least worth giving some consideration.

I am still learning on how to use Github. Thanks for your comments, though and your offer to assist.

There was also some issues or pull requests in those search results regarding modifying HardwareSerial for use with RS485. I didn't read them very thoroughly but thought they might be relevant.

I think it's good for people to have multiple choices. Every user has different needs so it's difficult for one one library to work for everyone. There's certainly no need for there to only be one Arduino project for each application.

Did you get any insights on how that library had dealt with the issue of HardwareSerial and the interrupts?

I still want to do that. But I wanted to first get my libraries on to Github. Please see link.

I have included a tested and working example program and instructions to alow verification of the whole setup. I still need to test the libraries with multiple USARTs chips such as the 1284P, 328PB, 2560 and some others. I suspect it should work as I did not touch the other USARTs setup in the existing libraries code set. (I could be wrong;-) )

I would be interested to hear from anyone who has tried the RS485 example and let me know of any problems. I only tested a Pro-Mini clone so far.

#12