RS485 protocol

[echase]

I am thinking of building a wired remote control device for a PA amplifier. The commands to set volume, etc. on its RS485 interface are published as below. How easy is it in Flowcode with its RS485 component to use this data to write the code for a PIC? I am not familiar with serial protocol so need Flowcode to take all the pain out my needing to programme the timings with e.g. C Code.

I’d use various buttons on digital inputs to send the demand to the PIC.

Baud rate: 19200
Bits: 8
Parity: No
Stop bits: 1

The protocol is an ASCII protocol – all characters in the string are ASCII chars.
A binary value ranging between hexadecimal 00 and FF is transmitted as two
ASCII chars. All command strings start with the % character and end with a
carriage return – shown as <CR> and equal to the single ASCII value of 13 (0x0D).

When a volume is adjusted send:

%PVAL:xxyy<CR> where “xx” is the sound channel number and “yy” is the
new volume level.

[LeighM]

This is easily done with the Flowcode UART (RS232) component, with which you can setup the rate and bit count and then just create your string and let the component take care of sending it (as ASCII characters).

The difference between RS232 and RS485 that you will need to take into consideration is that RS485 uses the same wires to transmit and receive, so you will just need one other output pin to control the RS485 line driver and put it into transmit mode whilst the component sends the string.

[echase]

Thank you. The protocol is 2 way. If I decide to use both directions, rather than just send, can Flowcode handle this?

E.g. Send the command
Amplifier processes it and sets registers to say it has responded
Read the registers back via RS485 to check it has been received and acted on.
Turn LEDs on to show current unmuted channels on amp.

[LeighM]

Yes, Flowcode can handle this.
When not sending, you would have the direction control set to receive, and call the UART ReceiveCharacter macro to listen for replies on the RS485

[echase]

I have found an off the shelf remote control with all the right physical interfaces, e.g. right buttons, LEDs and RS485 connectors. It uses a 40 pin PIC of unknown type, as label is obscured, but I suspect it’s a 16F877 as they were ubiquitous when this unit was made. 20 MHz xtal.

The 877 datasheet does not mention RS232/485 but it has 2 pins to connect to a USART. Is this enough to implement the Flowcode RS232/485 function?

If I draw out the circuit to understand what button/LED is connected to what PIC pin I then could reprogramme this 877 with totally new software with the right protocol to match my amplifier. Or replace it with a pin compatible more modern PIC with better USART if needed.

Thus the circuit changes needed would be zero or very minimal and as it’s all well spaced out and not surface mount it is not difficult to make changes.

Am I barking mad or is this not too difficult?

[Benj]

Hello,

The 877 datasheet does not mention RS232/485 but it has 2 pins to connect to a USART. Is this enough to implement the Flowcode RS232/485 function?

Yep this should be fine, the original 877 should have everything you need to be able to do the 9-bit data communication etc for RS232 or RS485 in Flowcode.

If I draw out the circuit to understand what button/LED is connected to what PIC pin I then could reprogramme this 877 with totally new software with the right protocol to match my amplifier. Or replace it with a pin compatible more modern PIC with better USART if needed.

The existing chip may have been locked so it cannot be reprogrammed. Worth a go though

Am I barking mad or is this not too difficult?

Sounds like it should be doable.

[echase]

The existing chip may have been locked so it cannot be reprogrammed. Worth a go though

Now see it is actually a 16C family device so can’t be reflashed. But is pin compatible with many like a 877 so not difficult to change it over. Might try a 18F4550 as more modern.

[Benj]

Hello,

The 16F1939 device may be a good option as it is low cost yet still pin compatible, very new and feature packed.

[echase]

Not a bad idea. I went on one of Microchip's courses and they gave us one of these http://www.microchip.com/pagehandler/en ... tools.html that uses a 16F1939.

Wish there was an easier way to select a PIC. I used their tool for selection of 877/4550 equivalents and don’t think that 1939 came up. They don't steer you away from old ones unless they are very old. 877 is one that they do not now recommend and point to 887 instead.

[echase]

Have finally got around to writing this programme. Their protocol is 8 bits, no parity and 1 stop bit. Flowcode says nothing about parity and stop bits. Do I have to add anything to Flowcode to add the stop bit?

Their manual says I need to send an ASCII string in form %PVAL:xxyy<CR>. All binary values from hexadecimal 00 to FF are sent as 2 ASCII characters

It says in its own words:

xx is 00 to 0C to set channel number
yy is 0x00 to 0xE1 to set volume
<CR> is single ASCII value 13(0x0D)

Problem to my mind is that these seem contradictory formats so should what I put into the Flowcode component box for the RS232 string to send be:

%PVAL:0C0xE113

%PVAL:0x0C0xE10x0D

%PVAL:0C0xE1<CR>

%PVAL:0CE100D

%PVAL:0CE113

Etc

The way they have written the manual makes it very unclear.

One of the other available commands is %PVAL:xx??<CR> where the ?? is definitely the two ACII characters ?? so makes me suspect that the hexadecimal numbers should be sent as E1 and not 0xE1 or else this second style of command string would be shorter than %PVAL:xxyy<CR>.

I could just try them all to see what works but unfortunately do not have the hardware that receives these commands yet so can’t yet do it.

[LeighM]

Yes you are right, looks like you need %PVAL:0000<CR> to %PVAL:0CE1<CR> (without the 0x)
or as string "%PVAL:0CE1\r"

Just configure the component for 8 data bits, the stop bit will be appended automatically.

[echase]

Many thanks. So is \r the ASCII 2 character string for <CR> then? Their manual is thus rather unhelpful in steering me to 13 or 0x0D instead!

[LeighM]

The byte that is actually sent can be represented in quite a variety of different ways.
The \r in a string gets converted to a single byte carriage return character that can be represented as 0x0d (hexadecimal) or 13 (decimal)
If you put 13 in the string it would get sent as two characters ‘1’ and ‘3’
This might help…
http://www.asciitable.com/

[echase]

I see my Picoscope has a facility for reading the RS485 port and converting the data to ASCII so I can do some checks with that. At least it can read RS232 so I assume it can also read 485 although I think 485 uses different voltages.

Flowcode is suggesting a crystal of 19.66 MHz whereas 20Mhz is currently fitted. Do you think 20Mhz will work? The device does not send a fast continuous steam of data, only one %PVAL=xxyy<CR> type command every 1/10 second. So I hope that any slight timing mismatch will be ironed out in the pauses between sends.

[LeighM]

The pauses between sends will not help as it is the baud rate that will be in error, but I think it should be small enough to not cause you any problems.

[echase]

Apologies for reposting here after a whole year but have finally got around to finishing off this project. The C code generated by Flowcode for my string manipulation ended up like below where Slider is a 0-255 Byte variable containing the position of the volume slider and Volume_as_string is it converted to hex and then 2 digit ASCII and sent by RS232/485 in form %PVAL:01yy<CR> for slider 01 with yy a 2 digit ASCII version of the Slider byte.

//Volume as 2 digit ASCII
//Calculation:
// Volume_as_string = NumberToHex$ (Slider)
FCI_NUMBER_TO_HEX(FCV_SLIDER, FCV_VOLUME_AS_STRING,FCSZ_VOLUME_AS_STRING);

//Calculation
//Calculation:
// Complete_string = "%PVAL:01" + Volume_as_string + "0D"
FCI_SHEAD("%PVAL:01",8, FCV_VOLUME_AS_STRING,FCSZ_VOLUME_AS_STRING, FCI_TMP_STR,20);
FCI_SHEAD(FCI_TMP_STR,20, "0D",2, FCV_COMPLETE_STRING,FCSZ_ COMPLETE _STRING);

//Send volume
//Call Component Macro: SendRS232String(Volume_string)
FCD_RS2320_SendRS232String(FCV_VOLUME_STRING, FCSZ_VOLUME_STRING);

Have I correctly converted the byte to 2 digit ASCII and correctly put the whole string together as FCV_VOLUME_AS_STRING? Bit worried about the 8 and 20 numbers in the C code as I did not put them into Flowcode. Volume_as_string I set to 2 long and Volume_string as 12 long.

Don't think it is right because under simulation the yy value for VOLUME_AS_STRING comes out as 0x so it is truncating a number in 0xyy format such as 0xFF to just 0x and leaving off the essential FF. So looks like convert to hex generates a string 4 long from a byte as the 0x is always added. Your help file text below for this is not very instructive as it lacks an example that might give a clue to what happens to the 0x.

NumberToHex$( number )

Converts a byte or int number into a hexadecimal string.

number = byte or integer number to convert.

string = String variable to hold the conversion data.

string = FloatToString( INT )


What is FCSZ_ xxxxxx above?

[echase]

I had forgotten how useful the simulation is as I can’t normally use it due to too much C Code hand added in to my programmes.

By experimentation and simulation I see that by using the Right$(string, 2) function I can truncate 0xFF to just FF and then it appears to send the correct ASCII characters, such as %PVAL:01FF13. Yet to try it on hardware and only then may be able to work out if %PVAL:01FF13 or %PVAL:01FF0D gives the correct carriage return command.

[LeighM]

Hi

Looks like you are getting there.
The FCSZ_xxx is a value created by Flowcode that represents the maximum string length, so as to avoid buffer overruns in the called macro.
Just remember, from notes earlier, how character bytes are coded. For a carriage return character, when in a string is represented by \r e.g. SendString(“%PAL:01FF\r”), when sent as a single byte you can also use 0x0d or 13 e.g. SendChar(0x0d) or SendChar(13)

Leigh