Re: [beagleboard] Re: serial terminal on HDMI Display in BBB

2017-05-06 Thread William Hermans 
Ah ok, yeah never used an NOOBs image I guess. Actually, someday I'll look
into creating my own images. Just need to work out what is needed from the
BSP for support files, kernel, and kernel modules etc. As I do not like all
this hand holding stuff, and quite honestly you never know what these
people put on your boards software wise.

As for the nagging about the default rpi user passwd. I think that a good
thing. One of the first things everyone should do once purchasing any of
these ARM based boards is:


   1. Change the default users passwd
   2. log in as root( not through su in an ssh session )
   3. Change the default user, and directory to a new suitable name for you.
   4. Give your new default user sudo access( visudo )
   5. Disable root login again, if that is your thing.

I am really glad that in general SBC makers are starting to take
responsibility for default security state of the board they're selling.
This will mean less problem on the internet over all. Which can be a huge
deal if you realize that a few hundred of these boards working in a zombie
team could by them self take down a very large corporate network.

-- 
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-C9UCx0ZWUgzqXQTVsov3Y4V0%2By-VYArDvgr%2BX_aFnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: serial terminal on HDMI Display in BBB

2017-05-06 Thread William Hermans 
Oh, by the way. One thing I have noticed about the default images I got at
least from the rpi foundation. I was going to show what version image I was
using, which I can still do because the *.img file is on my x86 Debian
server, But trying to log into my rpi failed. e.g. their network stack
seems buggy. It does this quite often. Even still, I'm able to connect to
the internet from my Android phones through the rpi acting as an AP. So . .
. like Widnows often does, it loses it's brains, or part of anyhow.

william@eee-pc:~$ ls backup/
2016-03-12-jessie-minibian.img
*2016-05-27-raspbian-jessie-lite.img*
BBB-blank-debian-8.5-console-armhf-2016-06-19-2gb.img.xz
BBB-blank-debian-8.5-console-armhf-2016-06-19-2gb.img.xz.1
bone-debian-8.5-console-armhf-2016-06-19-2gb.img.xz
bone-debian-8.6-console-armhf-2016-10-30-2gb.img.xz

The one highlighted  is what I'm using, The minibian image I was just
"reverse engineering", and have never used it yet.


On Sat, May 6, 2017 at 1:47 PM, William Hermans  wrote:

>
>
> On Sat, May 6, 2017 at 12:29 PM, Dennis Lee Bieber 
> wrote:
>
>>
>> Talking to myself in public again...
>>
>> On Sat, 06 May 2017 11:46:40 -0400, Dennis Lee Bieber
>>  declaimed the following:
>>
>> >
>> >   I'll admit, I'd prefer it if the default were not auto-login, and
>> >instead an X login dialog were presented, as found on most "big machine"
>> >Linux/X systems. If that were the norm, your problem would be rather
>> >simple, as starting your application would be something done via your
>> >account profile during login (somehow determine the login was into X,
>> start
>> >application -- otherwise [serial port console/SSH] ignore the
>> application.
>> >
>>
>> 
>>
>> >   Since the boot console uses the debug serial, I don't think there
>> is
>> >anything that can display on the HDMI until X is enabled. This is unlike
>> >the RaspberryPi, which does spew boot messages onto a text console on
>> HDMI
>> >-- before it starts X ( and it seems my current RPi card is giving a
>> >library error on the startx, so it is doing a log-on to the HDMI text
>> >console; time to reimage the SD card, the back-up card is doing auto
>> log-in
>> >to the X display).
>> >
>>
>> Turns out the RPi configuration program (which runs from the auto
>> login
>> X display) has options controlling both auto login, and GUI vs CLI (shell)
>> start-up. But take into account that even that CLI startup has to load
>> enough to render text to a framebuffer for the HDMI -- it is not a simple
>> pure text (ASCII/UTF-8/whatever) stream as with a true serial port.
>>
>>
>>
>>
>> NON-SEQUITUR RAMBLING:
>>
>> OTOH: The Raspberry foundation has gone too far with security.
>> 1)  using NOOBS installer one MUST have keyboard/mouse/HDMI to
>> respond to
>> prompts
>>
>
> This must be something new. I have an rPI here next to me right now acting
> as an access point for my Android phones, and I do not even own an HDMI
> cablem or even an HDMI capable monitor to plug it into.
>
>>
>> 2)  in my case, at least, after the OS installed and rebooted to the
>> logged
>> in X GUI, I had to edit /etc/wpa_supplicant/wpa_supplicant.conf to add my
>> WiFi credentials, then reboot
>> 2a) Strangely, the NOOBS installer allows for entering the
>> WiFi
>> passphrase, but NOT the subsequent Raspbian GUI; hence the need to do the
>> edit
>> 2b) The Ethernet port is also not enabled by default and
>> needs to be
>> enabled using the network connection icon config.
>>
>
> Again, as my first comment.
>
>>
>> 3)  SSH is DISABLED by default, so even if one has enabled WiFi and
>> hard
>> Ethernet, one still can not connect from outside without making more
>> configuration changes
>> 3a) One subsequently gets nagged about having a default
>> password on the
>> regular "pi" account
>>
>
> Same.
>
>>
>> In short: Every updated NOOBS SD card requires a session with
>> HDMI/keyboard/mouse just to get to the stage a BBB starts from...
>>
>
> There is an option of course. Well a couple at least if you own, and have
> a linux machine handy. You edit the sdcard before booting it on the rpi. Of
> course, you need to know the exact modifications you need to make.
> Otherwise it could get very tedious, very quickly changing the card between
> PC, and rpi.
>
> Additionally, if something like openssh-server is not installed by
> default. You can use chroot, plus QEMU to run the image emulated on an x86
> machine, usually well enough to install stock Debian packages. This
> requires a bit of knowledge of course, and a bit of thinking outside the
> box( sometimes ).
>

-- 
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

Re: [beagleboard] Re: serial terminal on HDMI Display in BBB

2017-05-06 Thread William Hermans 
On Sat, May 6, 2017 at 12:29 PM, Dennis Lee Bieber 
wrote:

>
> Talking to myself in public again...
>
> On Sat, 06 May 2017 11:46:40 -0400, Dennis Lee Bieber
>  declaimed the following:
>
> >
> >   I'll admit, I'd prefer it if the default were not auto-login, and
> >instead an X login dialog were presented, as found on most "big machine"
> >Linux/X systems. If that were the norm, your problem would be rather
> >simple, as starting your application would be something done via your
> >account profile during login (somehow determine the login was into X,
> start
> >application -- otherwise [serial port console/SSH] ignore the application.
> >
>
> 
>
> >   Since the boot console uses the debug serial, I don't think there
> is
> >anything that can display on the HDMI until X is enabled. This is unlike
> >the RaspberryPi, which does spew boot messages onto a text console on HDMI
> >-- before it starts X ( and it seems my current RPi card is giving a
> >library error on the startx, so it is doing a log-on to the HDMI text
> >console; time to reimage the SD card, the back-up card is doing auto
> log-in
> >to the X display).
> >
>
> Turns out the RPi configuration program (which runs from the auto
> login
> X display) has options controlling both auto login, and GUI vs CLI (shell)
> start-up. But take into account that even that CLI startup has to load
> enough to render text to a framebuffer for the HDMI -- it is not a simple
> pure text (ASCII/UTF-8/whatever) stream as with a true serial port.
>
>
>
>
> NON-SEQUITUR RAMBLING:
>
> OTOH: The Raspberry foundation has gone too far with security.
> 1)  using NOOBS installer one MUST have keyboard/mouse/HDMI to respond
> to
> prompts
>

This must be something new. I have an rPI here next to me right now acting
as an access point for my Android phones, and I do not even own an HDMI
cablem or even an HDMI capable monitor to plug it into.

>
> 2)  in my case, at least, after the OS installed and rebooted to the
> logged
> in X GUI, I had to edit /etc/wpa_supplicant/wpa_supplicant.conf to add my
> WiFi credentials, then reboot
> 2a) Strangely, the NOOBS installer allows for entering the WiFi
> passphrase, but NOT the subsequent Raspbian GUI; hence the need to do the
> edit
> 2b) The Ethernet port is also not enabled by default and needs
> to be
> enabled using the network connection icon config.
>

Again, as my first comment.

>
> 3)  SSH is DISABLED by default, so even if one has enabled WiFi and
> hard
> Ethernet, one still can not connect from outside without making more
> configuration changes
> 3a) One subsequently gets nagged about having a default
> password on the
> regular "pi" account
>

Same.

>
> In short: Every updated NOOBS SD card requires a session with
> HDMI/keyboard/mouse just to get to the stage a BBB starts from...
>

There is an option of course. Well a couple at least if you own, and have a
linux machine handy. You edit the sdcard before booting it on the rpi. Of
course, you need to know the exact modifications you need to make.
Otherwise it could get very tedious, very quickly changing the card between
PC, and rpi.

Additionally, if something like openssh-server is not installed by default.
You can use chroot, plus QEMU to run the image emulated on an x86 machine,
usually well enough to install stock Debian packages. This requires a bit
of knowledge of course, and a bit of thinking outside the box( sometimes ).

-- 
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/CALHSORpOyP5f3wtH3RphDGe8PjeaDZNjdKka%2BrkUhVzvxypSsA%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.

2017-05-06 Thread arsi 



>> Why you want to use RS232, i would choose TCP ,UDP or WebServer

Personal preexisting skill set. I have been using serial connections 
for 4 years on multiple projects with multiple pieces of hardware. I 
wrongly believed that it would be easy to just use serial again.




And I will finally learn a python ;)


Test this: (on linux *telnet ip_of_python_host 5000* on windows with 
putty telnet to port 5000 )


|import  select
import  socket
from  timeimport  sleep
#telnet escape sequences
CLEAR_SCREEN = chr(27) +"[2J"
MOVE_TO_LINE_1 = chr(27) +"[1;1H"
MOVE_TO_LINE_2 = chr(27) +"[2;1H"
MOVE_TO_LINE_3 = chr(27) +"[3;1H"
MOVE_TO_LINE_4 = chr(27) +"[4;1H"
MOVE_TO_LINE_5 = chr(27) +"[5;1H"
MOVE_TO_LINE_6_ST = chr(27) +"[6;1H"
MOVE_TO_LINE_6 = chr(27) +"[6;15H"
CLEAR_LINE = chr(27) +"[2K"
CLEAR_LINE_TO_END = chr(27) +"[K"
SAVE_CURSOR = chr(27) +"7"
RESTORE_CURSOR = chr(27) +"8"
TXT_CMD ="Enter command:"
#
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.setblocking(0)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR,1)
server.bind(('0.0.0.0',5000))
server.listen(5)
inputs = [server]
counter1 =0
counter2 =0
counter3 =0
counter4 =0
counter5 =0
addrs = {}
terminalInitOk = []
data =None
while  inputs:
readable, writable, exceptional = select.select(inputs, inputs, inputs)
for  sin  readable:
if  sis  server:
connection, client_address = s.accept()
connection.setblocking(0)
inputs.append(connection)
print('Client connected...'  + str(client_address))
addrs[connection] = client_address
else:
try:
if  sin  inputs:
data = s.recv(1024)
if  data:
print('Client:'  + str(addrs[s]) +' Received command:'  
+ data +'\n')
if  sin  terminalInitOk:
   s.send(MOVE_TO_LINE_6_ST+ CLEAR_LINE+ TXT_CMD + 
MOVE_TO_LINE_6)
except:
inputs.remove(s)
terminalInitOk.remove(s)
c.close();
print('Client'  + str(addrs[s]) +' disconnected..')
if  len(inputs):
counter1 = counter1 +1  #At least one client is attached make the 
calculation
counter2 = counter2 +10
counter3 = counter3 +100
counter4 = counter4 +1000
counter5 = counter5 +1
for  sin  writable:
try:
if  sin  inputs:#send new value to client
if  sin  terminalInitOk:
s.send(SAVE_CURSOR + MOVE_TO_LINE_1 + CLEAR_LINE + 
str(counter1) \
+ MOVE_TO_LINE_2 + CLEAR_LINE + str(counter2) \
+ MOVE_TO_LINE_3 + CLEAR_LINE + str(counter3) \
+ MOVE_TO_LINE_4 + CLEAR_LINE + str(counter4)
+ MOVE_TO_LINE_5 + CLEAR_LINE + str(counter5) + 
RESTORE_CURSOR)
else:
 #init telnet terminal
s.send(CLEAR_SCREEN +MOVE_TO_LINE_1+ str(counter1) \
+ MOVE_TO_LINE_2 + str(counter2) \
+ MOVE_TO_LINE_3 + str(counter3) \
+ MOVE_TO_LINE_4 + str(counter4) \
+ MOVE_TO_LINE_5 + str(counter5) \
+ MOVE_TO_LINE_6_ST + TXT_CMD + MOVE_TO_LINE_6)
terminalInitOk.append(s)
except:
inputs.remove(s)
terminalInitOk.remove(s)
print('Client'  + str(addrs[s]) +' disconnected..')
s.close();
if  len(writable):
sleep(0.1)#Slow down writing
for  sin  exceptional:
if  sin  inputs:
inputs.remove(s)
terminalInitOk.remove(s)
print('Client'  + str(addrs[s]) +' disconnected..')
s.close();
|

​


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/590E1F46.20305%40chello.sk.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Elo touchscreen + BBB

2017-05-06 Thread Dario Guaman 

HI everyone, is posible to connect the BBB with the ELO touchscreen monitor 

https://www.elotouch.com/touchscreen-monitors.html

-- 
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/03bef710-0ac2-4471-b763-5be450ec0369%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.

2017-05-06 Thread William Hermans 
>
> $ python3.6 ~/reusable/BBB_pressure_streamer.py > some_log_file.txt
>
> When I view the log file I can't see any errors
>

So, actually, scripting languages in general can be far slower, that their
native code counterparts. Firstly, because there is an interpreter, and
secondly because of code bloat, through using libraries. Almost as a rule,
larger executables will lead to poorer performing code. Python in
particular is one of if not the slowest languages also when bench marked in
some tests. And I do not mean by a second or two. I mean by a huge margin
in seconds, for specific tests. Just as an example though, in a few tests I
remember reading, Compared to Nodejs, Python was behind by a minute or more.

My point here is not to say Nodejs is better or not though. Nodejs is
pretty terrible it's self. This is meant demonstrate in general that
scripting languages can be terrible when your app is I/O intensive. The
reason why I suggested piping the output of your script to a file was to
see if there was potentially any "normal" I/O bottlenecks involved. All
languages can suffer from this however, because printing to screen( stdout
) is, or can be very I/O intensive. In C, you're maybe going to max out
around a couple hundred "samples" to stdout a second, before your
application will noticeably slow down. With Nodejs, it's actually far less.
I do not know if Python is slower than Nodejs in this case. It's been a
while since I've read the benchmarks, but actually the benchmarks were not
testing this capability anyhow. Maybe they should have been ?

All in all, I'm still not convinced this is the problem in whole. But I do
feel that it could be a contributing factor. It still would not explain why
you seem to be getting your full amount of transmissions. Just that some of
those transmissions are "empty". Especially when those empty transmissions
are not consistent in timing / frequency. I would suggest that you do keep
this in mind, and perhaps at least consider testing output to a file
further. Instead of testing while output is to stdout. At minimum, this
will allow you to rule out, output to stdout as a contributing factor in
your code. With very little wasted time on your behalf.

On Sat, May 6, 2017 at 8:25 AM, David Howlett 
wrote:

> Sorry for double posting last time, this is my first time using google
> groups.
>
> >> 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 ?
>
> The data loss problem also happens when the yes command is just repeating
> a string over and over to stdout so I don't think the problem is python
> related.
>
> >> Why don't you humor me, and give that a try ?
>
> I tried:
> $ python3.6 ~/reusable/BBB_pressure_streamer.py > some_log_file.txt
>
> When I view the log file I can't see any errors
>
> >> Have you tried reducing the receive FIFO level?
>
> I had not thought of that. Today I tried setting the Tx and Rx buffers to
> 1, 8 and 14 bytes. Data continued to be lost on all settings.
>
> >> Suspect I'd start with
> >>  stty ixon ixoff -ixany
> >> and ensure the other end is set for equivalent.
>
> I tried:
>
> root@beaglebone:~# stty --file=/dev/ttyGS0 ixon ixoff -ixany
> root@beaglebone:~# 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
>
> and I also turned on flow control on the python side at the same time but
> I still got data loss.
>
> >> Recommend you specify /which/ serial port
>
> I was originally running stty while connected to the virtual serial port
> but I forgot to mention that detail.
>
> >> I can't duplicate your results as
> >> debian@beaglebone:~$ python3.6 -c "while True: print(sum(i for i in
> range(1)))"
>
> I previously installed python3.6 on all my boards. I should have given an
> example that only depended on base Debian.
>
> >> #flush input buffer (where did .read_all() come from?)
>
> It is from https://github.com/pyserial/pyserial/blob/master/serial/
> serialutil.py
> I was using it to clear the serial buffer of all data. Calling
> .reset_input_buffer() is better
>
> >> OKAY -- THIS PRODUCED a drop-out 2574..2659
>
> Thanks, it is nice to know that someone else can replicate the issue, it
> is not just me doing something stupid.
>
> >> For a stable system, I would recommend considering doing the data
>

[beagleboard] Re: can not able to ping from beagle bone black to PC

2017-05-06 Thread Stephane Charette 
On Friday, May 5, 2017 at 7:57:43 AM UTC-7, kiran nayak wrote:
>
> Hello, 
> Sorry if it is too basic, but i want a urgent help, i am stuck after 
> trying everything 
>
> I am not able to ping back from BBB to host ( host to BBB works ), using 
> Ethernet over usb
> host is windows-7 PC
>
> That is,  from BBB this wont work : ping 192.168.7.1 
> This works from BBB : ping www.google.com 
>

Wild idea -- firewall on the Windows PC side?

Stéphane

-- 
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/453ff296-6b08-43b2-b4df-24bcf4f7e277%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.

2017-05-06 Thread David Howlett 
Sorry for double posting last time, this is my first time using google 
groups.

>> 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 ?

The data loss problem also happens when the yes command is just repeating a 
string over and over to stdout so I don't think the problem is python 
related.

>> Why don't you humor me, and give that a try ?

I tried:
$ python3.6 ~/reusable/BBB_pressure_streamer.py > some_log_file.txt

When I view the log file I can't see any errors

>> Have you tried reducing the receive FIFO level?

I had not thought of that. Today I tried setting the Tx and Rx buffers to 
1, 8 and 14 bytes. Data continued to be lost on all settings.

>> Suspect I'd start with
>>  stty ixon ixoff -ixany
>> and ensure the other end is set for equivalent.

I tried:

root@beaglebone:~# stty --file=/dev/ttyGS0 ixon ixoff -ixany
root@beaglebone:~# 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

and I also turned on flow control on the python side at the same time but I 
still got data loss.

>> Recommend you specify /which/ serial port

I was originally running stty while connected to the virtual serial port 
but I forgot to mention that detail.

>> I can't duplicate your results as
>> debian@beaglebone:~$ python3.6 -c "while True: print(sum(i for i in 
range(1)))"

I previously installed python3.6 on all my boards. I should have given an 
example that only depended on base Debian.

>> #flush input buffer (where did .read_all() come from?)

It is from 
https://github.com/pyserial/pyserial/blob/master/serial/serialutil.py
I was using it to clear the serial buffer of all data. Calling 
.reset_input_buffer() is better

>> OKAY -- THIS PRODUCED a drop-out 2574..2659

Thanks, it is nice to know that someone else can replicate the issue, it is 
not just me doing something stupid.

>> For a stable system, I would recommend considering doing the data 
transfer over a real hardware serial port

Today I purchased two connectors for the hardware serial pins from:
https://www.dfrobot.com/product-147.html
I will see if that helps.

>> You never have been specific about how many bits per second of data that 
you have to move.

Today I measured the average data rate of my application to be 69,218 
bytes/second.

>> 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.

When I send:
x.write(b'yes "123456"\n')
I receive 8 bytes per line not 6 due to the addition of /r/n. I don't think 
this is terribly important though

>> I'm suspecting you're not showing us all your code

My working repository is here:
https://github.com/DavidHowlett/BBB_fault_demo
A permanent link to the relevant commit is here:

https://github.com/DavidHowlett/BBB_fault_demo/blob/389785ec4e50af35fd78673d338063458da6be04/on_PC.py

There is not much to see in the repository but you are welcome to have a 
look.
The only thing worth noting is I use python 3.6 on the PC side too.

>> Here you can see the source code of USB serial gadged driver

Thankyou

>> The easiest solution is to do a simple handshake

That is a good idea for avoiding data loss, the troublesome buffer would 
never fill so there would be no data loss.

>> Why you want to use RS232, i would choose TCP ,UDP or WebServer

Personal preexisting skill set. I have been using serial connections for 4 
years on multiple projects with multiple pieces of hardware. I wrongly 
believed that it would be easy to just use serial again.

In the future I plan to use the hardware serial connection.

>

-- 
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/d14843cc-8eb0-4fbb-bec1-3e9052c272ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] serial terminal on HDMI Display in BBB

2017-05-06 Thread sajeevan k 


Hi all,

Basically I want to run my Qt application(A particular window on HDMI 
Display) at login in Beaglebone Black.

For that I have written necessary scripts in .xinitrc, and then proceeding 
as per wiki page  

*http://forums.debian.net/viewtopic.php?f=16=123694=0,* 

I am adding the line  

*[ "$(tty)" = "/dev/ttyS0**" ] && exec startx * 

in ~/.profile, where ttyS0 is FTDI serial terminal(connector J1) in BBB.

Startx at login is finely working for FTDI serial terminal.

When I boot the system, the FTDI serial terminal asking for login id and 
password, when I entered it correctly, my Qt application and other 
application will be run as specified in .xinitrc.

But what is my requirement is, a serial terminal should appear in HDMI 
display itself. When User ID and password is entered there, my application 
should run.

But I am not able to run a serial terminal on HDMI display. 

Since I run the command 

systemctl set-default multi-user.target

the HDMI Display shows a blank display, with the cursor blinking 

How can I enable a serial terminal on HDMI display?


And what will be the terminal name (like /dev/ttyS0), for such a terminal?  
  

Thanks in advance for the advice.


Thanks & Regards,
Sajeevan.K

-- 
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/6233d1ea-1c0e-4d2f-bfa6-126c2a891ad1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Octalbonescript serial port Read

2017-05-06 Thread Michael Dalby 
Hi All,

I'm using Node-Red on a BBB and want to do some serial messaging. I am 
using a  node-red function block calling Octalbonescript ( 
https://github.com/theoctal/octalbonescript/wiki/Serial-Port)  to do a 
serial write function this works okay (i.e. sends data out of the serial 
port)


*var b = context.global.octalbonescript;*

*b.serial.open('/dev/ttyO2', {baudRate: 115200}, function(data){*
*  console.log(data);*
*}, function(err){*
*  if(err){*
*console.error(err.message);*
*  }*
*});*

*var path='/dev/ttyO2';*

*//msg.payload is passed from the previous block as "hello World"*
*var buffer = msg.payload +'\r';*

*b.serial.write(path, buffer);*

*return msg;*

Now, I want to try and get the serial read working, but I don't fully 
understand the operation and wondered if anyone can help (an example would 
be tops).  The documentation defines the serial.open as:
serial.open(path, options, handler[data], callback[err|null, serialPort])
 so I take it that the incoming serial data is passed into the 
handler[data]. Do I need to keep calling this function to check for any 
data or do I just do it once and it gets handled in the background??

Best regards 

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/d7292d61-e9cb-4a37-b7db-3dba553e708c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.