**** BEGIN LOGGING AT Tue Feb 14 03:00:03 2017 Feb 14 03:41:48 Hello all. I have been working with the BBB revC, Debian, and UART4 but can't get anything other than 115200 baud rate to work for transmitting thousands of bytes. Other baud rates work for small bursts of serial data but transmitting images all fail. The failure mode is just a boolean failure return from the _serialPort.Write(Buffer, NbBytes) where _serialPort is a SerialLib object. I Feb 14 03:41:49 also get some random corruption in the bytes at 115200 but the write commands don't fail. Feb 14 03:42:47 I'm a novice linux user so not sure where to go from here in troubleshooting. I see the drivers are the 8250 which seem to be the preferred but maybe changing that to OMAP_SERIAL could offer different results? I have rx, tx, gnd wired as the final application won't have any flow control wires available. Feb 14 03:43:35 I've also tried this on different BBB and BBG boards and computers and they all behave consistently in that 115200 is the only non failing writes for thousands of bytes but with some corruption. Feb 14 03:53:00 manntis: what i suspect is that the underlying OS call is return the number bytes written and EAGAIN return code. you are meant to advance your read pointer by the number of bytes and try writing from the new position Feb 14 03:53:10 repeat until you get to the end of the buffer Feb 14 03:53:42 if the library isn't returning both the number of bytes written and some representation of the underlying OS error, you might need to consider using a different library Feb 14 03:55:59 Thanks Jonseymour, I'm considering the boost serial library as it seems to be well received in StackExchange queries related to serial output. Feb 14 03:56:17 I can see inside SerialLib.cpp and it is hiding the number of bytes written, so I end up with a boolean result. Feb 14 03:56:19 #ifdef __linux__ Feb 14 03:56:19 if (write(fd, Buffer, NbBytes) != (ssize_t)NbBytes) // Write data Feb 14 03:56:19 return -1; // Error while writing Feb 14 03:56:19 return 1; // Write operation successfull Feb 14 03:56:19 #endif Feb 14 03:57:27 Do you think that if I advance by the returned number of bytes (instead of my requested number of bytes) and try writing again if I could get through the buffer? Currently if I get a -1 I quit as a fail. Feb 14 04:01:14 it is only safe to do that if you have checked the return code and confirmed that it is EAGAIN Feb 14 04:01:24 otherwise an uncorrectable error will put you into a loop Feb 14 04:03:09 is the .cpp public source ? if so, can you send me a link? Feb 14 04:03:41 Thanks, I'll scratch around inside this SerialLib to see if I can expose these other values. Feb 14 04:03:53 \file SerialLib.cpp Feb 14 04:03:53 \brief Class to manage the serial port Feb 14 04:03:54 \author Philippe Lucidarme (University of Angers) Feb 14 04:03:54 \version 1.2 Feb 14 04:03:54 \date 28 avril 2011 Feb 14 04:04:08 I'll look to see if there's a URL. It isn't in the source though. Feb 14 04:05:00 There's a version on this page http://5lair.free.fr/SourceCode/ find seriallib Feb 14 04:05:13 oh 1.0 thouhg Feb 14 04:05:37 https://github.com/Gregwar/AU324/blob/master/serialib.h Feb 14 04:05:40 Much better source Feb 14 04:10:49 The Lucidarne source code you linked to is Windows. Probably the port didn't take account that the unix write() syscall behaves differently to Windows WriteFile() Feb 14 04:11:13 particularly with regard to expectations about retry behaviour Feb 14 04:12:04 I am having trouble flashing emmc in beaglebone revC Feb 14 04:12:25 Can anyone spare some? Thanks Feb 14 04:13:23 Manntis - yeah, this has the unix source but it isn't sound - https://github.com/Gregwar/AU324/blob/master/serialib.cpp Feb 14 04:13:57 Manntis - better to start with a library that understands linux if you can Feb 14 04:14:11 jonseymour: Once I saw it gobbling the more informative results and returning boolean-ish behavior I've lost confidence as well. Feb 14 04:14:28 Humboldt421: what's happening when you try? Feb 14 04:14:37 jonseymour: would you recommend boost? If you have any recommendations? Feb 14 04:16:06 Manntis: I am not a C++ programmer. I'd be surprised if the Boost library was bad on the other hand I haven't had a chance to look at the code - there has to be some attempt to handle EAGAIN or it too is broken Feb 14 04:17:07 jonseymour: Thanks for your conversation, it helps to refine my thinking better than these figurines on the desk! Feb 14 04:17:20 :-) Feb 14 04:51:16 jonseyeymore: I have not been able to get the 2gb partion to fit in the emmc it fails to write Feb 14 04:51:20 fd Feb 14 04:52:54 I have attempted to burn the deb jessie image to the emmc 2gb version. it finished with the block of leds blinking on and off at once. Here is the emmc when I boot from Sd and mount it : /dev/mmcblk1p1 1809656 1793200 0 100% /media/rootfs Feb 14 04:53:40 its full but the total blocks is smaller than i figured it should be. do i need to repartition it? I cnat find the script to do that anywhere and dont know what to do Feb 14 05:13:46 Humboldt421: did you download a 2gb image? Feb 14 05:16:33 jonseymour: EAGAIN is only returned if the file descriptor is marked non-blocking, which is not the default Feb 14 05:17:02 on the other hand "write(fd, Buffer, NbBytes) != (ssize_t)NbBytes" is absolutely a bogus test Feb 14 05:34:13 wow that code is awful Feb 14 05:34:26 * zmatt made the mistake of clicking on the link Feb 14 06:09:12 zmatt: yes, you are correct about that but the code does open it with O_NDELAY, and yes, that code is awful. Feb 14 06:11:34 zmatt: regarding yesterday's problem, I realised that the default kernel doesn't even have omap-serial compiled so I am rebuilding it with omap-serial as a module. it is a very slow process. I probably should have used a multi-CPU amd64 server and cross-compiled (currently using a scaleway arm cloud server - it is very slow!) Feb 14 06:16:49 you can't really build it as a module anyway, if you want to use omap-serial instead of 8250-omap you need to rebuild the kernel... why do you think you need to switch which uart driver is used? Feb 14 06:17:22 (and yes you definitely want to use a cross-compiler for this sort of thing, which fortunately is pretty trivial) Feb 14 07:16:47 good morning ! Feb 14 10:53:54 Hi! Feb 14 10:54:11 Is mugunthan to working for TI anymore? Feb 14 10:54:35 I mean "not working" :-) Feb 14 11:32:25 https://www.theregister.co.uk/2017/02/07/intel_atom_failures_go_back_18_months/ Feb 14 11:33:37 https://www.theregister.co.uk/2017/02/06/cisco_intel_decline_to_link_product_warning_to_faulty_chip/ Feb 14 13:04:18 hello :) Feb 14 14:43:23 Hi, i just got a new beaglebone black. I follwed the instruction after lunching START.HTM. I install the drivers, at the end it say success!. I could see the beagle drive as usb. I then proceed to connect to http:\192.168.7.2. First, it didnt connect, second I can see the beagle drive anymore. Feb 14 16:17:03 bye bye ;) Feb 14 17:47:01 cutcha: stick around. :( Feb 14 18:09:49 jkridner: if only they did ... Feb 15 01:53:28 zmatt: the config tool allows me to build omap-serial as a module which I will use so I can easily experiment with variants of it I want to add debug outputs or whatever Feb 15 01:55:39 the reason I want to try it is that it appears to be the only driver that handles arbitrary GPIO pins to control the RS485 transceiver's transmit state (based on cursory inspection of the serial8250 driver's code) Feb 15 02:03:53 jkridner|pd: have ya seen this? Beagleboard X15 LVDS extension board https://github.com/julbouln/x15_ext1 X15 LVDS extension board https://oshpark.com/shared_projects/OXMxxWDw **** ENDING LOGGING AT Wed Feb 15 03:00:01 2017