Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[William Hermans]

On Thu, May 4, 2017 at 5:42 PM, Graham Haddock  wrote:

> So, the COM port on Windows is talking to a virtual serial port in the BBB
> USB widget.
> There is no hardware UART involved, and no hardware clocks anywhere to
> throttle or pace anything.
> Then, you push this for transfer rate, while running it under a non
> realtime OS.
> I guess I am not surprised that you are having problems.
>

This is kind of what I'm thinking, but just sayin' Graham, "gadget" not
"widgit" :P But yeah I do not know this hardware at all, but the conversion
from USB to RS485, there can not be any flow control there. So the gadget
side of the hardware has no flow control, where the RS485 side *may*. I'd
actually speed up the transmission rate, and perhaps put in a usleep()
between each send to fine tune things, and call it quits.

>
> The USB widget is nice for doing simple things, with fast, simple set up
> for beginners.
> I suspect you are trying to run it in an application where it has not been
> well tested.
>
> For a stable system, I would recommend considering doing the data transfer
> over a real hardware serial port, or if that is not fast enough, do the
> transfer using Ethernet. (And I don't mean Ethernet over USB using the
> Widget.)
>
> I find the true hardware serial ports, and the genuine FTDI serial to USB
> converters to be stable well above 100,000 bits per second. Some report
> success in the megabits per second range, I have just not had to personally
> go there, yet.
>
> You never have been specific about how many bits per second of data that
> you have to move.
> I think that is an important place to start.
>
>
So *maybe* if UART4 on the beaglebone was used in full RS485 mode, talking
to the USB to RS485 converter connected to the Windows machine through USB.
*Maybe* that could, or would help solve these issues ? Just a guess but hey
probably worth looking into.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORoXByX_RLLcB-_SKTHYtuTfqiy05-EbsjcJaPTeivd29w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[William Hermans]

Dennis, keep your comments directed at helping the OP, and stop worrying
about what I'm saying.  We're obviously not talking about the same thing,
and your comments to me are not helping the OP solve his problem.

David,

As an example if I run the following program there is no data loss:
>
> import serial.tools.list_ports
>
> # connect to the BBB serial port on Windows
> x = serial.Serial('COM9')
> x.write(b'yes "123456"\n')
>
> while True:
>received = x.readline()
>if received != b'123456\r\n':
> print(received)
>
> But there is data loss if I run this:
>
> import serial.tools.list_ports
>
> # connect to the BBB serial port on Windows
> x = serial.Serial('COM9')
>
> x.write(b'yes "1234567"\n')
>
> while True:
> received = x.readline()
> if received != b'1234567\r\n':
> print(received)
>

This seems to me that you are indeed overflowing your buffer. How or why
I'm not sure, but if sending 6 characters all is fine, and 7 characters
does not transmit properly then obviously something is wrong. I'd look into
googling the driver name this device uses against any known reliability
issues in Linux. One odd thing I did notice about your output you've shown
us, is that everything in your received = x.readline() loop seems to be
working fine.But all the failures are related to this, or a similar line
you've not shown us yet: x.write(b'yes "1234567"\n')

I'm suspecting you're not showing us all your code however. Because the
output you've shown us does not necessarily "jibe" with the code I'm seeing
here.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqGCXZgqDeBwS09jc2gD9BUfC_wJZMYXs%3D37vSs60oWPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[Graham Haddock]

So, the COM port on Windows is talking to a virtual serial port in the BBB
USB widget.
There is no hardware UART involved, and no hardware clocks anywhere to
throttle or pace anything.
Then, you push this for transfer rate, while running it under a non
realtime OS.
I guess I am not surprised that you are having problems.

The USB widget is nice for doing simple things, with fast, simple set up
for beginners.
I suspect you are trying to run it in an application where it has not been
well tested.

For a stable system, I would recommend considering doing the data transfer
over a real hardware serial port, or if that is not fast enough, do the
transfer using Ethernet. (And I don't mean Ethernet over USB using the
Widget.)

I find the true hardware serial ports, and the genuine FTDI serial to USB
converters to be stable well above 100,000 bits per second. Some report
success in the megabits per second range, I have just not had to personally
go there, yet.

You never have been specific about how many bits per second of data that
you have to move.
I think that is an important place to start.

--- Graham

==

On Thu, May 4, 2017 at 6:53 PM, Dennis Lee Bieber 
wrote:

> On Thu, 4 May 2017 15:39:43 -0700 (PDT), David Howlett
>  declaimed the
> following:
>
>
> >I plugged the micro USB port on the BBB into my USB hub. The USB hub is
> >currently attached to a windows PC but the same fault happens when the USB
> >cable is plugged into my mac book running OSX.
> >
>
> Which, since there is no FTDI chip on the BBB, is effectively an
> emulated serial port... The USB-serial driver responds to I/O operations as
> if it were a serial port, but things like baud rate are mostly meaningless
> -- the driver moves bytes from the client buffer to the USB buffer, and USB
> transfers at (if USB2.0 full speed -- 480kbps; ignoring the breaks caused
> by USB packet size AND that the host computer has to poll the USB device to
> ask for each packet of data; effective throughput being closer to 250kbps).
>
> And, the Windows (or Mac) side is also an emulated serial, but as
> the
> host side, the USB driver controls the polling of the other end asking for
> data or to send packets.
>
>
> >I have also come to suspect that there are no hardware UARTS involved. I
> >believe that the serial line is being emulated.
> >
>
> Unless you use wires on the UART pins of the BBB, likely true.
> Those
> may be hardware UARTs, but as soon as something is connected that converts
> to USB, the actual data transfer is USB and the other end emulated.
>
> >
> >On the PC side I can set the baudrate to any number. The data rate and the
> >error rate appear to be unaffected. For example:
> >
> >x = serial.Serial('COM10', baudrate=10)
> >x = serial.Serial('COM10', baudrate=9600)
> >x = serial.Serial('COM10', baudrate=100_000_000_000)
> >
>
> As I suspect -- the baud rate is irrelevant when you get into the
> USB
> protocol. At most, it may control a "filter" as to how rapidly the drivers
> relay stuff to the USB protocol. That is -- at slow rates there may only be
> a few bytes of data per USB packet, whereas at really high rates each USB
> packet will contain more data (and hence be more efficient when taking the
> polling overhead into account).
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/beagleboard/1n0IkcmhEq8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/beagleboard/n0fngc1j3g8kfrh49uqngndtsj8b0ohjqi%404ax.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV4Z%3DnnsDDJK-br7yxVLc3XRA10z%2BM1Ys4WU8doRyr8UhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[William Hermans]

On Thu, May 4, 2017 at 3:32 PM, Dennis Lee Bieber 
wrote:

> On Thu, 4 May 2017 15:10:07 -0700, William Hermans
>  declaimed the following:
>
>
> >I think it's important to note that the OP is not sending data from the
> >beaglebone, but receiving it. At least looking at the last code he pasted.
> >Usually you wont see "COM9" on a Linux system ;)
> >
> The OP is running a program on Windows that is sending a command
> string
> TO the BBB, and that command at the shell generates output (on stdout,
> connected to the Windows COM port).
>

So, other than repeating exactly what I said, what's your point ? Also
newline eliminates the need for flush.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORo3gF4UJNcEmyuF-azGW3-zgKA-fqJ3AGn-3QXuYvY%3DGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[David Howlett]

>> I am confused as to what your actual hardware configuration is, with
respect to the "serial communications."
The actual hardware used in the final project with the i2c connectors
soldered on to a prototyping cape looks like this:


I have repeated the exact same fault on this:



>> Are you using a COM port in Windows to talk to a USB to serial cable,
which is talking to a hardware serial port in the BBB?
I plugged the micro USB port on the BBB into my USB hub. The USB hub is
currently attached to a windows PC but the same fault happens when the USB
cable is plugged into my mac book running OSX.

Within a minute of the BBB being plugged in an extra COM port is added in
windows. I connect to the com port with Termite (terminal program), ZOC7
(terminal program) or pyserial (the python serial library).
When I connect to the COM port I can login and get a shell. I ran some
relevant commands in the shell so you can see the results.

root@beaglebone:/dev# w
 20:57:21 up  6:52,  1 user,  load average: 0.02, 0.06, 0.05
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root ttyGS014Nov15  1.00s  0.97s  0.02s w
root@beaglebone:/dev# who
root ttyGS0   2015-11-14 00:15
root@beaglebone:/dev# tty
/dev/ttyGS0
root@beaglebone:/dev# whoami
root
root@beaglebone:/dev# ls
alarmlog_system  ram11tty16  tty44   ubi_ctrl
ashmem   loop0   ram12tty17  tty45   uinput
audioloop1   ram13tty18  tty46   urandom
autofs   loop2   ram14tty19  tty47   usbmon0
binder   loop3   ram15tty2   tty48   usbmon1
blockloop4   ram2 tty20  tty49   usbmon2
btrfs-controlloop5   ram3 tty21  tty5vcs
bus  loop6   ram4 tty22  tty50   vcs1
char loop7   ram5 tty23  tty51   vcs2
console  loop-controlram6 tty24  tty52   vcs3
core mapper  ram7 tty25  tty53   vcs4
cpu_dma_latency  mem ram8 tty26  tty54   vcs5
disk mixer   ram9 tty27  tty55   vcs6
dri  mmcblk0 random   tty28  tty56   vcs7
dsp  mmcblk0boot0root tty29  tty57   vcsa
fb0  mmcblk0boot1rtc0 tty3   tty58   vcsa1
fd   mmcblk0p1   shm  tty30  tty59   vcsa2
full mmcblk0p2   snd  tty31  tty6vcsa3
fuse mqueue  sndstat  tty32  tty60   vcsa4
hwrngnet stderr   tty33  tty61   vcsa5
i2c-0network_latency stdintty34  tty62   vcsa6
i2c-1network_throughput  stdout   tty35  tty63   vcsa7
initctl  nulltty  tty36  tty7watchdog
inputppp tty0 tty37  tty8watchdog0
kmem psaux   tty1 tty38  tty9xconsole
kmsg ptmxtty10tty39  ttyGS0  zero
log  ptp0tty11tty4   ttyO0
log_events   pts tty12tty40  ttyS0
logibone_mem ram0tty13tty41  ttyS1
log_main ram1tty14tty42  ttyS2
log_radioram10   tty15tty43  ttyS3


>> So, you've actually delved further into using the UARTs on this platform
than I ever have.

I have also come to suspect that there are no hardware UARTS involved. I
believe that the serial line is being emulated.

>> Anyway, my first instinct wants to say baud rate is involved somehow.

On the PC side I can set the baudrate to any number. The data rate and the
error rate appear to be unaffected. For example:

x = serial.Serial('COM10', baudrate=10)
x = serial.Serial('COM10', baudrate=9600)
x = serial.Serial('COM10', baudrate=100_000_000_000)

I have also set the baud rate with Termite 3.1 to demonstrate that it is
not a bug in the python serial library.

On the BBB end the speed is always reported as 9600. Some commands to
change the speed succeed and others fail but the reported speed is
unchanged.

root@beaglebone:/dev# stty ispeed 7200
root@beaglebone:/dev# stty
speed 9600 baud; line = 0;
root@beaglebone:/dev# stty ispeed 14400
root@beaglebone:/dev# stty
speed 9600 baud; line = 0;
root@beaglebone:/dev# stty ispeed 2400
stty: standard input: unable to perform all requested operations
root@beaglebone:/dev# stty
speed 9600 baud; line = 0;

I will finish replying to everyone tomorrow. It is getting late where I am.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[William Hermans]

On Thu, May 4, 2017 at 3:10 PM, William Hermans  wrote:

>
>
> On Thu, May 4, 2017 at 3:02 PM, arsi  wrote:
>
>> Hi,
>>
>> call *flush* after write command!!!
>>
>> *flush**(**)*
>>
>> *Flush of file like objects. In this case, wait until all data is
>> written.*
>> Arsi
>>
>
> I think it's important to note that the OP is not sending data from the
> beaglebone, but receiving it. At least looking at the last code he pasted.
> Usually you wont see "COM9" on a Linux system ;)
>
> At any rate if receiving, you don't need to use flush at all. If it's
> anything like fflush() in C.
>

Additionally, the output had newline "\n" every time output was sent.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORorHBZ8m3uU-isbgbuXWKgiMSC4JF_U5VYmxwDMG9WUCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[William Hermans]

On Thu, May 4, 2017 at 3:02 PM, arsi  wrote:

> Hi,
>
> call *flush* after write command!!!
>
> *flush**(**)*
>
> *Flush of file like objects. In this case, wait until all data is written.*
> Arsi
>

I think it's important to note that the OP is not sending data from the
beaglebone, but receiving it. At least looking at the last code he pasted.
Usually you wont see "COM9" on a Linux system ;)

At any rate if receiving, you don't need to use flush at all. If it's
anything like fflush() in C.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpN4jWLhAs-GSZ5K1zTyNQ-d5FWp06cA1yCFfF1RVKW-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[arsi]

Hi,

call *flush* after write command!!!

*|flush|**(**)*

   *Flush of file like objects. In this case, wait until all data is
   written.*

Arsi

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/590BA513.2050307%40chello.sk.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Remote deploying a QT GUI application

[heathpritchett]

Hello,

I have been following the tutorials from "Exploring Beaglebone" on remote 
deploying a QT application to the beaglebone. So far I have set up the 
tool-chain and I can now remote deploy a console application to the 
beaglebone after setting up the kit in QT. The issue I am having is when I 
try to remote deploy a QT gui application I get the following error:

stdin: is not a tty

/home/root/qttest2: symbol lookup error: /home/root/qttest2: undefined 
symbol: _ZN7QWidget8qwsEventEP8QWSEvent

Application finished with exit code 127 


Here is my pc setup:

Qt qmake -v:

QMake version 2.01a Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu 
Qt Creator Ver:

qt-creator-opensource-linux-x86_64-4.3.0-rc1_1101

Qt lib:

qt-everywhere-opensource-src-4.8.2

Compiler:

/usr/bin/arm-linux-gnueabihf-g++

Debugger:

/usr/bin/gdb-multiarch

Qt Version:

/usr/local/qt4.8.2-armhf/bin/qmake


Here is my bbb setup:

qmake -v:

QMake version 2.01a Using Qt version 4.8.6 in /usr/lib/arm-linux-gnueabihf 

BBB version:

4.9.22-bone4


I also copied the qt library by the following cmd:

scp -r /usr/local/qt4.8.2-armhf/lib 
root@192.168.7.2:"/usr/local/qt4.8.2-armhf/"


Also, if i compile a QT GUI .cpp directly on the BBB there is no issue. Is 
there something that I am missing?

Thanks!


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c60b07b3-f320-4bae-80eb-4a4061159ab0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] automount sd-card on Beaglebone Black with Ubuntu 16.04 never worked

[michael c]

I'm surprised to not see this addressed adequately anywhere, maybe it's 
unique to me, but i have never seen my BBB (4.4.62-ti-r99) with Ubuntu 
16.04 automount my sd-card. it mounts fine on boot when i execute. 
mount -v /dev/mmcblk0p1 /media/sd-card
same FAT cards always work flawlessly on my notebook U16.04.
i'm using eMMC for booting.
and since this is a camera type product a UUID on the sd-card won't work. 
any card could be plugged, and un-plugged at any time.

im reading about fstab and autofs but don't see a clear path to dynamic 
plug and play sd-card mounting/unmounting.

thanks, i must be missing something, still looking.

michael

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d5d49b5a-31e9-4d10-b4a8-a98ebc8d0bf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[William Hermans]

On Thu, May 4, 2017 at 9:32 AM, David Howlett 
wrote:

> >> First, you're going to need to learn how to use systemd, and
> specifically, you're going to need to learn how to create, and use a
> startup service.
>
> I happen to have used systemd startup services in a previous project so I
> can see how it would be useful for setting settings on startup.
>

That good, something less to get in your way to fixing your problem.

> Conclusions
> ===
>
> - The virtual serial port provided is a poor imitation of a real serial
> port. Every command to change any property of either end of the connection
> either fails or is ignored.
>
> - There is undocumented flow control somewhere behind the scenes outside
> my control. It is probably in a driver.
>
> - The flow control mechanism loses data if the data is not a multiple of 4
> bytes long.
>

So, you've actually delved further into using the UARTs on this platform
than I ever have. Even with other( bare metal ) platforms, I only really
use UARTs for a printf() style serial debug output. With this platform, we
do not need it, unless you're troublshooting the boot process.

Anyway, my first instinct wants to say baud rate is involved somehow. It's
very unlikely a baud rate difference between systems, because usually when
this occurs, your transmission will be garbled. At least a few characters
here and there will be different between send, and receive. So this leads
me to speculate that you're somehow exceeding your maximum baud rate.

Another thing I'm noticing from what your code is outputting. is that your
"data loss" is not consistent. Which immediately makes me want to jump to
the conclusion that you code is somehow being preempted. Almost as if
you're data is on the stack, something preempts your code, and by the time
the part of your code is given control back, the data on the stack is no
longer there. This sort of situation is what I refer to as "stepping all
over the stack". e.g. some of those routines you're using could be stack
unfriendly. Granted, I know very little about Python, or the libraries
Python uses. But I've personally experienced this effect first hand, when
using a third party web server API, when dealing with a lot of data fast.
CANBUS at 1Mbit, while decoding PGNs in real time, and attempting to send
this data in real time using this third part web server API.

I wonder if you run the application that failing for you there is you pipe
that data to a file, instead of to stdout, if you would be experiencing the
same problem ? Why don't you humor me, and give that a try ? e.g. run your
application as such:

$ myapp > some_log_file.txt

Run it for a few hundred iterations and see if you get any blank
transmission, and if you do, if they are fewer. If this stops your blank
tramissions, or lessens them a fair bit. Then your problem could either be
python not being able to keep up( I'm kind of doubting that ), or Windows
for whatever reason is preempting your code mid transmission. Or even
something else not yet considered.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrMbrWmS22aaJbObbhbp-PXx3h04bfEvNkS_aj1zxwmaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[Graham]

David:

I am confused as to what your actual hardware configuration is, with 
respect to the "serial communications."

Are you using a COM port in Windows to talk to a USB to serial cable, which 
is talking to a hardware serial port in the BBB?

Or, are you doing something else?

If so, please describe.

I have never seen these kinds of problems when dealing with hardware serial 
ports.

--- Graham

==

On Thursday, May 4, 2017 at 11:32:04 AM UTC-5, David Howlett wrote:
>
> >> First, you're going to need to learn how to use systemd, and 
> specifically, you're going to need to learn how to create, and use a 
> startup service.
>
> I happen to have used systemd startup services in a previous project so I 
> can see how it would be useful for setting settings on startup.
>
> >> Second, you need a tool that is capable of working with serial devices 
> at a "low level".  Such as: 
> https://manpages.debian.org/jessie/coreutils/stty.1.en.html and 
> specifically this setting:
>
> This is the tool I was looking for and could not find, thank you. The 
> default settings for the serial connection I am using are:
>
> root@beaglebone:~/reusable# stty --all
> speed 9600 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
> eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = 
> ^R;
> werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
> -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon 
> -ixoff
> -iuclc -ixany imaxbel -iutf8
> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 
> vt0 ff0
> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
> echoctl echoke
>
> I can now use the stty command to set ixon on or off.
>
> root@beaglebone:~/reusable# stty -ixon
> root@beaglebone:~/reusable# stty --all
> speed 9600 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
> eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = 
> ^R;
> werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
> -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon 
> -ixoff
> -iuclc -ixany imaxbel -iutf8
> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 
> vt0 ff0
> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
> echoctl echoke
>
> Unfortunately the data loss is the same regardless of whether ixon is 
> enabled or disabled. Changing ixoff does not affect the data loss either.
> I tried setting crtscts and cdtrdsr but this is not permitted.
>
> root@beaglebone:~/reusable# stty crtscts
> stty: standard input: unable to perform all requested operations
> root@beaglebone:~/reusable# stty cdtrdsr
> stty: invalid argument `cdtrdsr'
>
> There is flow control regardless of what I do
> =
>
> There does appear to be flow control of some sort. I realised I can get 
> debug information with the CPU LED. I can make the CPU light on the BBB 
> light up for 2.4 seconds by running the following program on the PC. The 
> fact that the CPU light turns off again indicates that there is some kind 
> of flow control that pauses the computation when the buffer fills up.
>
> import time
> import serial.tools.list_ports
>
> # connect to the BBB serial port on Windows
> x = serial.Serial('COM9')
> x.read_all()
> x.write(b'python3.6 -c "while True: print(sum(i for i in range(1000)))"\n')
> # pause forever
> time.sleep(1_000_000)
>
> If I slow down the CPU wasting command like this:
>
> import time
> import serial.tools.list_ports
>
> # connect to the BBB serial port on Windows
> x = serial.Serial('COM9')
> x.read_all()
> x.write(b'python3.6 -c "while True: print(sum(i for i in 
> range(10_000)))"\n')
> # pause forever
> time.sleep(1_000_000)
>
> Then the CPU LED stays lit for about 10x as long. This demonstrates that 
> streaming on the beagle bone is stopped by a buffer filling up rather than 
> a timer.
>
> Data loss only happens when the length of the data being written is not a 
> multiple of 4 bytes
>
> =
>
> As an example if I run the following program there is no data loss:
>
> import serial.tools.list_ports
>
> # connect to the BBB serial port on Windows
> x = serial.Serial('COM9')
> x.write(b'yes "123456"\n')
>
> while True:
>received = x.readline()
>if received != b'123456\r\n':
> print(received)
>
> But there is data loss if I run this:
>
> import serial.tools.list_ports
>
> # connect to the BBB serial port on Windows
> x = serial.Serial('COM9')
>
> x.write(b'yes "1234567"\n')
>
> while True:
> received = x.readline()
> if received != b'1234567\r\n':
> print(received)
>
> It prints:
>
> 

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[David Howlett]

>> First, you're going to need to learn how to use systemd, and 
specifically, you're going to need to learn how to create, and use a 
startup service.

I happen to have used systemd startup services in a previous project so I 
can see how it would be useful for setting settings on startup.

>> Second, you need a tool that is capable of working with serial devices 
at a "low level".  Such as: 
https://manpages.debian.org/jessie/coreutils/stty.1.en.html and 
specifically this setting:

This is the tool I was looking for and could not find, thank you. The 
default settings for the serial connection I am using are:

root@beaglebone:~/reusable# stty --all
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = 
^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon 
-ixoff
-iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 
ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

I can now use the stty command to set ixon on or off.

root@beaglebone:~/reusable# stty -ixon
root@beaglebone:~/reusable# stty --all
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = 
^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon 
-ixoff
-iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 
ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Unfortunately the data loss is the same regardless of whether ixon is 
enabled or disabled. Changing ixoff does not affect the data loss either.
I tried setting crtscts and cdtrdsr but this is not permitted.

root@beaglebone:~/reusable# stty crtscts
stty: standard input: unable to perform all requested operations
root@beaglebone:~/reusable# stty cdtrdsr
stty: invalid argument `cdtrdsr'

There is flow control regardless of what I do
=

There does appear to be flow control of some sort. I realised I can get 
debug information with the CPU LED. I can make the CPU light on the BBB 
light up for 2.4 seconds by running the following program on the PC. The 
fact that the CPU light turns off again indicates that there is some kind 
of flow control that pauses the computation when the buffer fills up.

import time
import serial.tools.list_ports

# connect to the BBB serial port on Windows
x = serial.Serial('COM9')
x.read_all()
x.write(b'python3.6 -c "while True: print(sum(i for i in range(1000)))"\n')
# pause forever
time.sleep(1_000_000)

If I slow down the CPU wasting command like this:

import time
import serial.tools.list_ports

# connect to the BBB serial port on Windows
x = serial.Serial('COM9')
x.read_all()
x.write(b'python3.6 -c "while True: print(sum(i for i in 
range(10_000)))"\n')
# pause forever
time.sleep(1_000_000)

Then the CPU LED stays lit for about 10x as long. This demonstrates that 
streaming on the beagle bone is stopped by a buffer filling up rather than 
a timer.

Data loss only happens when the length of the data being written is not a 
multiple of 4 bytes
=

As an example if I run the following program there is no data loss:

import serial.tools.list_ports

# connect to the BBB serial port on Windows
x = serial.Serial('COM9')
x.write(b'yes "123456"\n')

while True:
   received = x.readline()
   if received != b'123456\r\n':
print(received)

But there is data loss if I run this:

import serial.tools.list_ports

# connect to the BBB serial port on Windows
x = serial.Serial('COM9')

x.write(b'yes "1234567"\n')

while True:
received = x.readline()
if received != b'1234567\r\n':
print(received)

It prints:

b'yes "1234567"\r\n'
b'11234567\r\n'
b'11234567\r\n'
b'12234567\r\n'
b'12334567\r\n'
b'12345677\r\n'
b'\n'
b'\n'
b'\n'
b'\n'
b'\n'
b'\n'
b'12345567\r\n'
b'\n'
b'12234567\r\n'
b'\n'
b'12334567\r\n'
b'12344567\r\n'
b'12344567\r\n'
b'\n'
b'\n'
b'12344567\r\n'
b'12234567\r\n'
b'12345567\r\n'
b'12345667\r\n'
b'\n'
b'\n'
b'12234567\r\n'
b'12334567\r\n'
b'12234567\r\n'
b'12345677\r\n'
b'12334567\r\n'
b'\n'
b'12345677\r\n'
b'1234567\r\r\n'
b'\n'
b'11234567\r\n'
b'12234567\r\n'
b'123234567\r\n'
b'12234567\r\n'
b'12334567\r\n'
b'\n'

Re: [beagleboard] I can not get the 'BBB-blank' Debian flasher image from 3-7-2017 from the User Manual web page.

[Robert Nelson]

On Wed, May 3, 2017 at 9:09 PM,  wrote:

>
> 
>
>
> 
> I can not get  the 'BBB-blank' Debian flasher image from 3-7-2017 from the
> User Manual web page. this is the web page.could i must  use this image
> file? I would like to ask how can we control this two-wheeled balance car,
> thank you
>

Which "manual" is referencing 3-7-2017?  I don't have unlimited space, so I
tend to keep links from "official manual's" links available, but the
other's only stay till space is needed.

You could just grab the latest:

https://rcn-ee.net/rootfs/bb.org/testing/

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYgEj-o6BgcgfXZjv5XR2qu0tespwz3bsKyMKfmhcz48_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] I can not get the 'BBB-blank' Debian flasher image from 3-7-2017 from the User Manual web page.

[leehua19930912]

I can not get  the 'BBB-blank' Debian flasher image from 3-7-2017 from the 
User Manual web page. this is the web page.could i must  use this image 
file? I would like to ask how can we control this two-wheeled balance car, 
thank you

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4a204224-fc83-46b7-8d89-fa8941be67d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Flashing eMMC memory from SD card with Chipsee Debian Jessie

[Radovan Chovan]

Dňa utorok, 2. mája 2017 16:52:46 UTC+2 RobertCNelson napísal(-a):
>
> On Tue, May 2, 2017 at 9:46 AM, Radovan Chovan  > wrote: 
>

> > you'll need to update the UUID variable in /boot/uEnv.txt along with 
> > the parameters in /etc/fstab 
>

Note: I have access to SD card versions of these files, so I edited files 
on SD card (not on eMMC internal memory)
*/etc/fstab - before changes:*

# /etc/fstab: static file system information.
#
# Auto generated by RootStock-NG: setup_sdcard.sh
#
/dev/mmcblk0p1  /  ext4  noatime,errors=remount-ro  0  1
debugfs  /sys/kernel/debug  debugfs  defaults  0  0

*/etc/fstab - after changes:*

# /etc/fstab: static file system information.
#
# Auto generated by: beaglebone-black-eMMC-flasher.sh
#
UUID=50d572df-6313-4600-844c-5da83e43e5b5  /  ext4  noatime,errors=remount-ro 
 0  1
UUID=E302-7CCA  /boot/uboot  auto  defaults  0  0
debugfs  /sys/kernel/debug  debugfs  defaults  0  0

I used UUID values from my two BeagleBoneBlack Debian Wheezy(2014-05-14) 
boards (they have same UUID values, because they were flashed from same SD 
card I think) which runs on eMMC.





*/boot/uEnv.txt - before changes:*
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

#uname_r=4.4.9-ti-r25
uname_r=4.4.9+
#uuid=
#dtb=

##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)

##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb

##BeagleBone Black: eMMC disabled:
#dtb=am335x-boneblack-hdmi-overlay.dtb

##BeagleBone Black: HDMI Audio/eMMC disabled:
#dtb=am335x-boneblack-nhdmi-overlay.dtb

##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
#dtb=am335x-boneblack-overlay.dtb

##BeagleBone Black: wl1835
#dtb=am335x-boneblack-wl1835mod.dtb

##BeagleBone Green: eMMC disabled
#dtb=am335x-bonegreen-overlay.dtb

cmdline=coherent_pool=1M quiet cape_universal=enable

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M quiet cape_universal=enable 
video=HDMI-A-1:1024x768@60e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh



*/boot/uEnv.txt - after changes*
...


*##note: the eMMC flasher script relies on the next 
linemmcroot=UUID=50d572df-6313-4600-844c-5da83e43e5b5 rommcrootfstype=ext4 
rootwait fixrtc*

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
*cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh*

Then I rebooted board via "sudo reboot". Switch SW8 on Chipsee board was 
still "uSD".

After reboot there is white background and Debian logo on it for one 
second, immediately after that there is black screen with "linux penguin" 
in left upper corner for cca 10 minutes and then only black screen.
USER LEDs state:
[x] [] [] []
USERLED0 is still blinking (2times quickly, then short pause and this is 
repeating).

When I removed SD card, switched SW8 to "eMMC", only Debian logo appeared 
for one second and then nothing happened.
USER LEDs state:
[] [] [] []
 
Is now my only solution flash SD card again? Fortunately I made backup 
(*.img) via Win32DiskImager.
And what could I do wrong with editing two mentioned files?



> > Plug in a usb-serial adapter, you should see that eMMC flasher logging 
> > the process over serial 
>

Do you have some "manual" for me, how can I see these logging messages on 
my PC(OS Windows8.1)?
But there is better option for me (which I used with Debian Wheezy and 4D 
Systems Touchscreen) : Flashing eMMC via "dd" command (OS runs on SD card 
via this process), then removing SD card and start OS from eMMC without 
inserted SD card. 

>
> Regards, 
>
> -- 
> Radovan 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0f6ee6a4-0264-4270-8b3d-3433b3d929a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GPIO based LEDs with USR LED functions

[William Hermans]

OK so assuming you have everything loaded as per the normal Debian image .
. .
root@wgd:~# ls /sys/class/leds/
beaglebone:green:usr0  beaglebone:green:usr1  beaglebone:green:usr2
beaglebone:green:usr3

This is the path you're looking for then:
root@wgd:~# ls /sys/class/leds/beaglebone:green:usr0
brightness  device  invert  max_brightness  power  subsystem  trigger
uevent

You can work with individual led files from there. Which I do not remember
how closely this matched to earlier kernels . . . It's been a long time for
me since I've worked with anything but kernel 4.x . . .


On Thu, May 4, 2017 at 12:53 AM, abraxas1  wrote:

> excellent, thanks.
> this is my first exposure to overlays etc... now i see about sysfs.
> i'll just blink leds in my code. using threads won't suck up hardly any
> processor time.
> ciao,
>
>
> On Thu, May 4, 2017 at 12:07 AM William Hermans  wrote:
>
>> Can you ask a more specific question ? It seems as though as you;re
>> asking if you can use the sysfs file system to control USR0-USR3 ?
>>  The answer is yes, you can, but it largely depends on which drivers
>> you're loading with your hardware. Using /dev/mem/ + mmap all you need to
>> know if the memory map for the GPIO pins. But for sysfs access, you need to
>> load certain drivers at boot.
>>
>> On Wed, May 3, 2017 at 11:19 PM, michael c  wrote:
>>
>>> i really thought i would find this online someplace but,
>>> can i use the trigger and heartbeat type functions on a LED connected to
>>> GPIO on my custom board based on the BBB design?
>>> this would save me time in my code that is already quite busy.
>>> i noticed some example from 3.14 kernel days
>>> i'm 4.4.62 and ubuntu 16.04
>>> and controlling them from c code.
>>>
>>> thanks so much,
>>> Michael
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>>
>> You received this message because you are subscribed to the Google Groups
>>> "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/beagleboard/2cd59eb1-ec6f-4c29-a548-072ba0633aee%
>>> 40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/beagleboard/V_xNqTVXtbU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/beagleboard/CALHSORq-qjC62rrD6yoo-W5twFWsdGN%
>> 2BrhXDPNSxDduPTEiayw%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CAHSSfWPZ%3D6%2BDOENYgi%2Bmw3ghad-
> STYHL5CdyJN3XWQyzgtGn7Q%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORosO025C3%3DD%3DNFhA-aJXEqtFFCC4c8yc9esUB91SD_gLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GPIO based LEDs with USR LED functions

[William Hermans]

Can you ask a more specific question ? It seems as though as you;re asking
if you can use the sysfs file system to control USR0-USR3 ?
 The answer is yes, you can, but it largely depends on which drivers you're
loading with your hardware. Using /dev/mem/ + mmap all you need to know if
the memory map for the GPIO pins. But for sysfs access, you need to load
certain drivers at boot.

On Wed, May 3, 2017 at 11:19 PM, michael c  wrote:

> i really thought i would find this online someplace but,
> can i use the trigger and heartbeat type functions on a LED connected to
> GPIO on my custom board based on the BBB design?
> this would save me time in my code that is already quite busy.
> i noticed some example from 3.14 kernel days
> i'm 4.4.62 and ubuntu 16.04
> and controlling them from c code.
>
> thanks so much,
> Michael
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/2cd59eb1-ec6f-4c29-a548-072ba0633aee%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORq-qjC62rrD6yoo-W5twFWsdGN%2BrhXDPNSxDduPTEiayw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] GPIO based LEDs with USR LED functions

[michael c]

i really thought i would find this online someplace but,
can i use the trigger and heartbeat type functions on a LED connected to 
GPIO on my custom board based on the BBB design?
this would save me time in my code that is already quite busy.
i noticed some example from 3.14 kernel days
i'm 4.4.62 and ubuntu 16.04
and controlling them from c code.

thanks so much, 
Michael

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2cd59eb1-ec6f-4c29-a548-072ba0633aee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.