Can you send me what you have so far, I just ordered a cnoverter rs485tors232 and wirless rs232.
Intelliflow pump RS485 protocol
- Thread starter miru
- Start date
Check the download area, I posted what I got.
I think it is here:
http://www.cocoontech.com/forums/index.php?app=downloads&showfile=173
Michael
nullglitch
New Member
I have been trying to experiment with my VS3050 and can't seem to get it to talk at all over RS-485.
The pump model I have doesn't have an LCD panel -- just the simple program number and speed up/down power on/off buttons.
I hooked the cable into the data port and plugged the other end into a RS485 to USB adapter (pl2303) using linux and the whole 9600 8N1 no hardware flow control and I tried a few of the commands for setting local/remote control and I get nothing from the pump --ever.
I have the supplied cable with a green and a yellow wire hooked up to the RS485 break out connector as:
T-/A connected to green
R+ connected to yellow
(I tried the other way around also with T+/B to yellow and R- to green)
I also tried talking from this RS485 to USB adapter to a arduino with an RS485 interface board and it seems to be able to talk both directions -- so I am pretty sure the RS485 adapter is working.
Is there something special I need to do to the enable the RS485 port on the pump? Is it possible the port is "broken"?
Any hints would be helpful.
The pump model I have doesn't have an LCD panel -- just the simple program number and speed up/down power on/off buttons.
I hooked the cable into the data port and plugged the other end into a RS485 to USB adapter (pl2303) using linux and the whole 9600 8N1 no hardware flow control and I tried a few of the commands for setting local/remote control and I get nothing from the pump --ever.
I have the supplied cable with a green and a yellow wire hooked up to the RS485 break out connector as:
T-/A connected to green
R+ connected to yellow
(I tried the other way around also with T+/B to yellow and R- to green)
I also tried talking from this RS485 to USB adapter to a arduino with an RS485 interface board and it seems to be able to talk both directions -- so I am pretty sure the RS485 adapter is working.
Is there something special I need to do to the enable the RS485 port on the pump? Is it possible the port is "broken"?
Any hints would be helpful.
myeager1967
New Member
Anyone still monitor this thread? I'm looking to communicate with an Intellichlor salt system using and Arduino controller. Will be snooping the data bus in a week or so.
Looking at tcpdump when my phone (Pentair Water) or laptop (ScreenLogic Connect) connects:
1) The client sends "CONNECTSERVERHOST" (with 0x0d0a0d0a termination) via http.
2) On iPhone clients, a description packet is then sent.
3) Finally, the server gives up the data.
Even sending this via nc doesn't seem to work properly ... I wish we just had a nice API! :-( Here's the full conversation:
00000000 43 4f 4e 4e 45 43 54 53 45 52 56 45 52 48 4f 53 CONNECTS ERVERHOS
00000010 54 0d 0a 0d 0a T....
00000015 02 00 0e 00 00 00 00 00 ........
00000000 02 00 0f 00 18 00 00 00 11 00 00 00 30 30 2d 31 ........ ....00-1
00000010 31 2d 36 38 2d 30 30 2d 36 31 2d 32 44 00 00 00 1-68-00- 61-2D...
0000001D 03 00 1b 00 4c 00 00 00 5c 01 00 00 00 00 00 00 ....L... \.......
0000002D 0c 00 00 00 4c 6f 63 61 6c 20 43 6f 6e 66 69 67 ....Loca l Config
0000003D 10 00 00 00 1c 06 c1 f7 de 77 ee bf de 80 48 cb ........ .w....H.
0000004D 5c eb 34 81 02 00 00 00 11 00 00 00 30 30 2d 30 \.4..... ....00-0
0000005D 30 2d 30 30 2d 30 30 2d 30 30 2d 30 30 00 00 00 0-00-00- 00-00...
0000006D 00 00 00 00 ....
00000020 03 00 1c 00 00 00 00 00 ........
00000071 04 00 b8 1f 00 00 00 00 ........
00000028 04 00 b9 1f 38 00 00 00 19 00 00 00 50 4f 4f 4c ....8... ....POOL
00000038 3a 20 35 2e 32 20 42 75 69 6c 64 20 36 33 35 2e : 5.2 Bu ild 635.
00000048 30 20 52 65 6c 00 00 00 02 00 00 00 05 00 00 00 0 Rel... ........
00000058 02 00 00 00 02 00 00 00 02 00 00 00 0c 00 00 00 ........ ........
00000079 05 00 f4 30 08 00 00 00 00 00 00 00 01 00 00 00 ...0.... ........
00000068 05 00 f5 30 68 03 00 00 64 00 00 00 28 68 28 68 ...0h... d...(h(h
00000078 00 02 00 20 18 00 00 00 0e 00 00 00 57 61 74 65 ... .... ....Wate
00000088 72 20 46 65 61 74 75 72 65 73 00 00 32 00 00 00 r Featur es..2...
00000098 f4 01 00 00 47 01 01 00 00 01 d0 02 f5 01 00 00 ....G... ........
000000A8 3e 10 03 00 05 02 d0 02 f6 01 00 00 49 10 03 00 >....... ....I...
000000B8 05 03 d0 02 f7 01 00 00 15 05 05 00 00 04 d0 02 ........ ........
000000C8 f8 01 00 00 2d 00 05 00 00 05 d0 02 f9 01 00 00 ....-... ........
1) The client sends "CONNECTSERVERHOST" (with 0x0d0a0d0a termination) via http.
2) On iPhone clients, a description packet is then sent.
3) Finally, the server gives up the data.
Even sending this via nc doesn't seem to work properly ... I wish we just had a nice API! :-( Here's the full conversation:
00000000 43 4f 4e 4e 45 43 54 53 45 52 56 45 52 48 4f 53 CONNECTS ERVERHOS
00000010 54 0d 0a 0d 0a T....
00000015 02 00 0e 00 00 00 00 00 ........
00000000 02 00 0f 00 18 00 00 00 11 00 00 00 30 30 2d 31 ........ ....00-1
00000010 31 2d 36 38 2d 30 30 2d 36 31 2d 32 44 00 00 00 1-68-00- 61-2D...
0000001D 03 00 1b 00 4c 00 00 00 5c 01 00 00 00 00 00 00 ....L... \.......
0000002D 0c 00 00 00 4c 6f 63 61 6c 20 43 6f 6e 66 69 67 ....Loca l Config
0000003D 10 00 00 00 1c 06 c1 f7 de 77 ee bf de 80 48 cb ........ .w....H.
0000004D 5c eb 34 81 02 00 00 00 11 00 00 00 30 30 2d 30 \.4..... ....00-0
0000005D 30 2d 30 30 2d 30 30 2d 30 30 2d 30 30 00 00 00 0-00-00- 00-00...
0000006D 00 00 00 00 ....
00000020 03 00 1c 00 00 00 00 00 ........
00000071 04 00 b8 1f 00 00 00 00 ........
00000028 04 00 b9 1f 38 00 00 00 19 00 00 00 50 4f 4f 4c ....8... ....POOL
00000038 3a 20 35 2e 32 20 42 75 69 6c 64 20 36 33 35 2e : 5.2 Bu ild 635.
00000048 30 20 52 65 6c 00 00 00 02 00 00 00 05 00 00 00 0 Rel... ........
00000058 02 00 00 00 02 00 00 00 02 00 00 00 0c 00 00 00 ........ ........
00000079 05 00 f4 30 08 00 00 00 00 00 00 00 01 00 00 00 ...0.... ........
00000068 05 00 f5 30 68 03 00 00 64 00 00 00 28 68 28 68 ...0h... d...(h(h
00000078 00 02 00 20 18 00 00 00 0e 00 00 00 57 61 74 65 ... .... ....Wate
00000088 72 20 46 65 61 74 75 72 65 73 00 00 32 00 00 00 r Featur es..2...
00000098 f4 01 00 00 47 01 01 00 00 01 d0 02 f5 01 00 00 ....G... ........
000000A8 3e 10 03 00 05 02 d0 02 f6 01 00 00 49 10 03 00 >....... ....I...
000000B8 05 03 d0 02 f7 01 00 00 15 05 05 00 00 04 d0 02 ........ ........
000000C8 f8 01 00 00 2d 00 05 00 00 05 d0 02 f9 01 00 00 ....-... ........
phandel said:
I setup a wireless RS485 link to my pump (using custom build PCBs for Synapse wireless modules) and got the posted software to work perfectly. I can tell the pump to run the 4 "external control" programs, or send me status. Despite having an Intelliflow VS pump (011018), I can't get any GPM data or set a GPM limit. The README with the code imply you can get that data. Maybe it was a different pump.
My next step is to use the provided protocol data to code up a python interface since those synapse wireless boards can run simply python code. Ultimately, the module will control my cleaner, waterfall, pump, solar heating, acid and chlorine injection systems. I may throw in control of my LED pool light just for the nerd factor of turing it on via my smartphone. Nothing like having a killer automation system for about $100. I cut myself a deal and provide labor for free
I'll document my progress on my blog
Has anyone successfully compiled and run the PAB014SHARE sources that are referenced on page 2? I can compile them, but when I try to start the server communication server aprs485 it crashes.
I tried it on both an Ubuntu Linux and Mac OS 10.10 using a CH341 USB-to-Serial adapter.
Thank you.
I tried it on both an Ubuntu Linux and Mac OS 10.10 using a CH341 USB-to-Serial adapter.
Thank you.
rocco
Active Member
Hi eriedl,
It's been a long time since I've been here - Luckily, I was subscribed to this thread.
I am currently working on a pool controller, using the BeagleBoneBlack as the Linux engine and a custom PCB to run the Pentair VF pump, a half-dozen valves, and some level, pressure and temperature sensors. Like you, I am using Michael's code as a base but I will be modifying it for different hardware. So I'm not sure if I can be much help.
Maybe I can help with debugging. Here are a few questions, if you won't mind:
Do You get any warning messages when compiling?
What kind of message do you get when aprs485 crashes? (if any at all).
Had aprs485 created its log file before crashing? Is there anything in it?
Have you tried running aprs485 with the "debug option" switch?
Are you using the CH341 driver? Or the generic USB-serial driver? (which I'm pretty sure won't work).
Have you tried to "cat" to the tty hardware? Can you "cat" without it throwing an error?
Can you run aprs485 under gdb?
That's all for now, i-gotta-go.
Mark
It's been a long time since I've been here - Luckily, I was subscribed to this thread.
I am currently working on a pool controller, using the BeagleBoneBlack as the Linux engine and a custom PCB to run the Pentair VF pump, a half-dozen valves, and some level, pressure and temperature sensors. Like you, I am using Michael's code as a base but I will be modifying it for different hardware. So I'm not sure if I can be much help.
Maybe I can help with debugging. Here are a few questions, if you won't mind:
Do You get any warning messages when compiling?
What kind of message do you get when aprs485 crashes? (if any at all).
Had aprs485 created its log file before crashing? Is there anything in it?
Have you tried running aprs485 with the "debug option" switch?
Are you using the CH341 driver? Or the generic USB-serial driver? (which I'm pretty sure won't work).
Have you tried to "cat" to the tty hardware? Can you "cat" without it throwing an error?
Can you run aprs485 under gdb?
That's all for now, i-gotta-go.
Mark
Thank you for your reply, Marc! I'll try to answer your questions the best I can:
Do You get any warning messages when compiling?
I do get a few warnings when compiling the sources, but I'm not sure if they are related to the segmentation faults I get when the app crashes. They refer to ignored return values and potential data type mismatch in printf format string.
eriedl@eriedl-ubuntuvm:~/pab014share$ make
gcc -O -Wall -I. -o padec padec.c -lm
gcc -O -Wall -I. -o iFlow iFlow.c -lm
In file included from iFlow.c:5:0:
aprs485.h: In function ‘hub_dt’:
aprs485.h:128:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(hd,buf,2);
^
gcc -O -Wall -I. -o iPump iPump.c -lm
In file included from iPump.c:5:0:
aprs485.h: In function ‘hub_dt’:
aprs485.h:128:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(hd,buf,2);
^
gcc -O -Wall -I. -o iComII iComII.c -lm
In file included from iComII.c:7:0:
aprs485.h: In function ‘hub_dt’:
aprs485.h:128:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(hd,buf,2);
^
gcc -O -Wall -I. -o iPmon iPmon.c -lm
In file included from iPmon.c:5:0:
aprs485.h: In function ‘hub_dt’:
aprs485.h:128:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(hd,buf,2);
^
gcc -O -Wall -I. -o aprs485 aprs485.c -lm
aprs485.c: In function ‘srv_client’:
aprs485.c:301:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ [-Wformat=]
a += sprintf(a,"\ntab[%d]",t-gl.tabs);
^
aprs485.c: In function ‘main’:
aprs485.c:635:3: warning: field precision specifier ‘.*’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=]
else sprintf(gl.bus,"%.*s",sizeof(gl.bus)-1,p);
^
aprs485.c: In function ‘slog_dump’:
aprs485.c:88:22: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
if (fd >= 0) write(fd,buf,p-buf);
^
aprs485.c:90:34: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
if (gl.dbug) *p++ = '\r', write(1,buf,p-buf);
What kind of message do you get when aprs485 crashes? (if any at all).
Have you tried running aprs485 with the "debug option" switch?
Yes, I did. Executing just aprs485 just prints the usage. So I'm guessing it is something when trying to access the serial port:
eriedl@eriedl-ubuntuvm:~/pab014share$ ./aprs485 -d /dev/ttyUSB0
hit <Escape> to exit...
Segmentation fault (core dumped)
Are you using the CH341 driver? Or the generic USB-serial driver? (which I'm pretty sure won't work).
Well, I tried to compile the sources from WCH, but they spew several errors. But then I found out that the H341 driver already comes with Ubuntu 14. I verified that the port is recognized and drivers are loaded when I plug it in:
eriedl@eriedl-ubuntuvm:~/pab014share$ lsusb
Bus 001 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
eriedl@eriedl-ubuntuvm:~/pab014share$ dmesg | grep USB
[ 0.293237] ACPI: bus type USB registered
[ 0.545457] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.546187] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.547518] ohci-pci 0000:00:06.0: new USB bus registered, assigned bus number 1
[ 0.603640] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.605335] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.607812] hub 1-0:1.0: USB hub found
[ 0.609514] uhci_hcd: USB Universal Host Controller Interface driver
[ 166.909930] usb 1-1: new full-speed USB device number 2 using ohci-pci
[ 167.213782] usb 1-1: New USB device found, idVendor=1a86, idProduct=7523
[ 167.213787] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 167.213789] usb 1-1: Product: USB2.0-Serial
[ 167.231294] usbserial: USB Serial support registered for generic
[ 167.232509] usbserial: USB Serial support registered for ch341-uart
[ 167.286873] usb 1-1: ch341-uart converter now attached to ttyUSB0
Have you tried to "cat" to the tty hardware? Can you "cat" without it throwing an error?
Yes, I did. Ubuntu has a bug that would not add the current user the dialout group so you couldn't access any serial port. I worked around that by doing to the following to be able to write and read to the USB/Serial port /dev/ttyUSB0:
eriedl@eriedl-ubuntuvm:~/pab014share$ groups ${USER}
eriedl : eriedl adm cdrom sudo dip plugdev lpadmin sambashare
eriedl@eriedl-ubuntuvm:~/pab014share$ sudo gpasswd --add ${USER} dialout
Adding user eriedl to group dialout
eriedl@eriedl-ubuntuvm:~/pab014share$ sudo chmod a+rw /dev/ttyUSB0
eriedl@eriedl-ubuntuvm:~/pab014share$ echo "Hello" > /dev/ttyUSB0
eriedl@eriedl-ubuntuvm:~/pab014share$ read X < /dev/ttyUSB0
eriedl@eriedl-ubuntuvm:~/pab014share$ echo $X
<this is just an empty line>
Can you run aprs485 under gdb?
I've never use gdb before, but I'm going to read up on it.
My next step would have been to try to get this working with the SoftwareSerial library from Arduino. That is, sending the "Talk over the COM port" command, which seems to be the sequence "A5 00 60 10 04 01 ff 02 19" or starting with "A5 01...". If I can get the pump to talk over the COM port that's already a big step.
Do You get any warning messages when compiling?
I do get a few warnings when compiling the sources, but I'm not sure if they are related to the segmentation faults I get when the app crashes. They refer to ignored return values and potential data type mismatch in printf format string.
eriedl@eriedl-ubuntuvm:~/pab014share$ make
gcc -O -Wall -I. -o padec padec.c -lm
gcc -O -Wall -I. -o iFlow iFlow.c -lm
In file included from iFlow.c:5:0:
aprs485.h: In function ‘hub_dt’:
aprs485.h:128:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(hd,buf,2);
^
gcc -O -Wall -I. -o iPump iPump.c -lm
In file included from iPump.c:5:0:
aprs485.h: In function ‘hub_dt’:
aprs485.h:128:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(hd,buf,2);
^
gcc -O -Wall -I. -o iComII iComII.c -lm
In file included from iComII.c:7:0:
aprs485.h: In function ‘hub_dt’:
aprs485.h:128:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(hd,buf,2);
^
gcc -O -Wall -I. -o iPmon iPmon.c -lm
In file included from iPmon.c:5:0:
aprs485.h: In function ‘hub_dt’:
aprs485.h:128:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(hd,buf,2);
^
gcc -O -Wall -I. -o aprs485 aprs485.c -lm
aprs485.c: In function ‘srv_client’:
aprs485.c:301:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ [-Wformat=]
a += sprintf(a,"\ntab[%d]",t-gl.tabs);
^
aprs485.c: In function ‘main’:
aprs485.c:635:3: warning: field precision specifier ‘.*’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=]
else sprintf(gl.bus,"%.*s",sizeof(gl.bus)-1,p);
^
aprs485.c: In function ‘slog_dump’:
aprs485.c:88:22: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
if (fd >= 0) write(fd,buf,p-buf);
^
aprs485.c:90:34: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
if (gl.dbug) *p++ = '\r', write(1,buf,p-buf);
What kind of message do you get when aprs485 crashes? (if any at all).
Have you tried running aprs485 with the "debug option" switch?
Yes, I did. Executing just aprs485 just prints the usage. So I'm guessing it is something when trying to access the serial port:
eriedl@eriedl-ubuntuvm:~/pab014share$ ./aprs485 -d /dev/ttyUSB0
hit <Escape> to exit...
Segmentation fault (core dumped)
Are you using the CH341 driver? Or the generic USB-serial driver? (which I'm pretty sure won't work).
Well, I tried to compile the sources from WCH, but they spew several errors. But then I found out that the H341 driver already comes with Ubuntu 14. I verified that the port is recognized and drivers are loaded when I plug it in:
eriedl@eriedl-ubuntuvm:~/pab014share$ lsusb
Bus 001 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
eriedl@eriedl-ubuntuvm:~/pab014share$ dmesg | grep USB
[ 0.293237] ACPI: bus type USB registered
[ 0.545457] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.546187] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.547518] ohci-pci 0000:00:06.0: new USB bus registered, assigned bus number 1
[ 0.603640] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.605335] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.607812] hub 1-0:1.0: USB hub found
[ 0.609514] uhci_hcd: USB Universal Host Controller Interface driver
[ 166.909930] usb 1-1: new full-speed USB device number 2 using ohci-pci
[ 167.213782] usb 1-1: New USB device found, idVendor=1a86, idProduct=7523
[ 167.213787] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 167.213789] usb 1-1: Product: USB2.0-Serial
[ 167.231294] usbserial: USB Serial support registered for generic
[ 167.232509] usbserial: USB Serial support registered for ch341-uart
[ 167.286873] usb 1-1: ch341-uart converter now attached to ttyUSB0
Have you tried to "cat" to the tty hardware? Can you "cat" without it throwing an error?
Yes, I did. Ubuntu has a bug that would not add the current user the dialout group so you couldn't access any serial port. I worked around that by doing to the following to be able to write and read to the USB/Serial port /dev/ttyUSB0:
eriedl@eriedl-ubuntuvm:~/pab014share$ groups ${USER}
eriedl : eriedl adm cdrom sudo dip plugdev lpadmin sambashare
eriedl@eriedl-ubuntuvm:~/pab014share$ sudo gpasswd --add ${USER} dialout
Adding user eriedl to group dialout
eriedl@eriedl-ubuntuvm:~/pab014share$ sudo chmod a+rw /dev/ttyUSB0
eriedl@eriedl-ubuntuvm:~/pab014share$ echo "Hello" > /dev/ttyUSB0
eriedl@eriedl-ubuntuvm:~/pab014share$ read X < /dev/ttyUSB0
eriedl@eriedl-ubuntuvm:~/pab014share$ echo $X
<this is just an empty line>
Can you run aprs485 under gdb?
I've never use gdb before, but I'm going to read up on it.
My next step would have been to try to get this working with the SoftwareSerial library from Arduino. That is, sending the "Talk over the COM port" command, which seems to be the sequence "A5 00 60 10 04 01 ff 02 19" or starting with "A5 01...". If I can get the pump to talk over the COM port that's already a big step.
rocco
Active Member
Hi eriedl,
Oh, God, do I hate segmentation faults! I've received more segmentation faults than I have hairs on my head (oh, wait, that isn't that many . . . ).
For me, they almost always turn out to be a bad memory access - a bad pointer or accessing hardware that doesn't exist or isn't enabled. The good news is that when you run under gdb, it shows you the line of code that caused the fault.
As far as those warnings, I'm sure that the unused return values from the 'write()' won't cause a problem (except for the fact that a write failure won't be detected). But the size mismatch between an 'int' and a 'long' could cause a problem. I'm not sure.
Are you compiling for 64-bits? Without examining the code (which I hope to do later) the only reason I could see for the size mismatch is if the original code made inadvertent assumptions about the default size of an 'int'. If so, than I expect that I will get similar errors when I try to compile for ARM (I'm running Debian in the BeagleBone).
It's good to hear that the CH341 driver is included in Ubuntu - one less issue to worry about. Getting a driver to work has always been a pain-in-the-neck for me.
I've heard about the dialout bug, but have never encountered it myself (I access the RS485 ports through the BeagleBone's real-time coprocessors). Could aprs485 be encountering the same bug when accessing the serial port?
mark
Oh, God, do I hate segmentation faults! I've received more segmentation faults than I have hairs on my head (oh, wait, that isn't that many . . . ).
For me, they almost always turn out to be a bad memory access - a bad pointer or accessing hardware that doesn't exist or isn't enabled. The good news is that when you run under gdb, it shows you the line of code that caused the fault.
As far as those warnings, I'm sure that the unused return values from the 'write()' won't cause a problem (except for the fact that a write failure won't be detected). But the size mismatch between an 'int' and a 'long' could cause a problem. I'm not sure.
Are you compiling for 64-bits? Without examining the code (which I hope to do later) the only reason I could see for the size mismatch is if the original code made inadvertent assumptions about the default size of an 'int'. If so, than I expect that I will get similar errors when I try to compile for ARM (I'm running Debian in the BeagleBone).
It's good to hear that the CH341 driver is included in Ubuntu - one less issue to worry about. Getting a driver to work has always been a pain-in-the-neck for me.
I've heard about the dialout bug, but have never encountered it myself (I access the RS485 ports through the BeagleBone's real-time coprocessors). Could aprs485 be encountering the same bug when accessing the serial port?
mark
Yes, I'm compiling on a 64-bit system. I make the educated guess that the dialout bug was fixed by explicitly adding my user to the dialout group. I also tried to run aprs485 as superuser with the same result. I'll let you know what I find when running it under gdb, but I have to read up on that first. C is not really my wheelhouse
Best,
Erie.
Best,
Erie.
rocco
Active Member
Hi Erie,
Just an update:
I compiled all of the code on the Beaglebone Black (32-bit ARM with Debian), and received no errors or warnings. I then ran aprs485 in debug mode, and it seemed to run fine. I don't have my pump hooked-up to it yet, so I can't transfer any data yet.
I looked at the code, and it appears that assumptions are made about the sizes of short, int and long. I'm sure that those assumptions will fail on a 64-bit system. In a few days, I will try the code on a 64-bit Ubuntu laptop, and make the necessary changes to get it to compile without warnings. It should be simply a matter of updating the size definitions.
I'll keep you posted.
Mark
Just an update:
I compiled all of the code on the Beaglebone Black (32-bit ARM with Debian), and received no errors or warnings. I then ran aprs485 in debug mode, and it seemed to run fine. I don't have my pump hooked-up to it yet, so I can't transfer any data yet.
I looked at the code, and it appears that assumptions are made about the sizes of short, int and long. I'm sure that those assumptions will fail on a 64-bit system. In a few days, I will try the code on a 64-bit Ubuntu laptop, and make the necessary changes to get it to compile without warnings. It should be simply a matter of updating the size definitions.
I'll keep you posted.
Mark
rocco
Active Member
Hi Erie,
Are you still here?
I compiled on both Ubuntu 32-bit and 64-bit (14.04.2). On the 64-bit system, I had the same eight warnings that you did. But on the 32-bit system I only had the six "return value" warnings and not the two int/long conflict warnings.
When I tried to run them, I received the same segmentation fault on the 64-bit system, but the program ran fine on the 32-bit system. So there is definitely a problem on 64-bit Ubuntu.
By running under gdb, I found that the segmentation fault occurs when the program attempts to initialize a socket for debug. If I run without the debug switch, I don't get the segmentation fault but the aprs485 terminates immediately (without an error). I haven't debugged beyond that.
I can see in the code how any 'int' can be mis-sized to a 'long' (their size is larger in 64-bit gcc then in 32-bit gcc). I can try to fix that when I have a chance, if you are still interested.
The "return value" warnings must be new in the latest version of gcc, as this code used to compile with no warnings on Ubuntu, and still compiles with no warnings on my Beaglebone Debian gcc.
mark
Are you still here?
I compiled on both Ubuntu 32-bit and 64-bit (14.04.2). On the 64-bit system, I had the same eight warnings that you did. But on the 32-bit system I only had the six "return value" warnings and not the two int/long conflict warnings.
When I tried to run them, I received the same segmentation fault on the 64-bit system, but the program ran fine on the 32-bit system. So there is definitely a problem on 64-bit Ubuntu.
By running under gdb, I found that the segmentation fault occurs when the program attempts to initialize a socket for debug. If I run without the debug switch, I don't get the segmentation fault but the aprs485 terminates immediately (without an error). I haven't debugged beyond that.
I can see in the code how any 'int' can be mis-sized to a 'long' (their size is larger in 64-bit gcc then in 32-bit gcc). I can try to fix that when I have a chance, if you are still interested.
The "return value" warnings must be new in the latest version of gcc, as this code used to compile with no warnings on Ubuntu, and still compiles with no warnings on my Beaglebone Debian gcc.
mark
