[beagleboard] BBB, Debian, Chipsee display: Tkinter gives error

[Harke Smits]

Hello Learned Group,

I have a BBB running Debian (2015-11-03 version) with a Chipsee 4.3 
display. It works great, so far so good: both in graphic mode and text. I 
try to script an application requiring a GUI, so I loaded Tkinter and 
entered a test program.
This is the result:

Traceback (most recent call last):
  File "testtk.py", line 2, in 
root = Tkinter.Tk()
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1712, in __init__
self.tk = _tkinter.create(screenName, baseName, className, interactive, 
wantobjects, useTk, sync, use)
_tkinter.TclError: no display name and no $DISPLAY environment variable
root@beaglebone:/home/apptest# 

Its the same whether I run from BBB via bash or via another pc with Cloud9.

I googled a lot and the error is not uncommon, but could not find a clue 
for my case. 

Please advise, regards,
Harke

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Bug or error in the documentation of libpruio

[Davide Picchi]

I was reading carefully the following example taken from here 
:

file: button.c

define _GNU_SOURCE 1 
 #include "stdio.h" 
 #include  
 #include  
#include  
 #include  
#include  
 #include "../c_wrapper/pruio.h" 
 #include "../c_wrapper/pruio_pins.h" 
  
 #define PIN P8_07 
 
 int 
 isleep(unsigned int mseconds) 
 { 
 fd_set set; 
  struct timeval timeout; 
  
 /* Initialize the file descriptor set. */ 
  FD_ZERO(); 
  FD_SET(STDIN_FILENO, ); 
  
  /* Initialize the timeout data structure. */ 
 timeout.tv_sec = 0; 
  timeout.tv_usec = mseconds * 1000; 
  
 return TEMP_FAILURE_RETRY(select(FD_SETSIZE, 
 , NULL, NULL, 
 )); 
 } 
  
 int main(int argc, char **argv) 
 { 
 pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); // <= LOOK HERE
 
  do { 
  if (io->Errr) { 
  printf("initialisation failed (%s)\n", io->Errr); break;} 
  
  if (pruio_config(io, 1, 0x1FE, 0, 4)) { 
printf("config failed (%s)\n", io->Errr); break;} 
  
 struct termios oldt, newt; // make terminal non-blocking 
 tcgetattr( STDIN_FILENO,  ); 
 newt = oldt; 
 newt.c_lflag &= ~( ICANON | ECHO ); 
 newt.c_cc[VMIN] = 0; 
 newt.c_cc[VTIME] = 0; 
 tcsetattr(STDIN_FILENO, TCSANOW, ); 
  
 while(!isleep(1)) { // run loop until keystroke 
 printf("\r%1X", pruio_gpio_Value(io, PIN)); 
 fflush(STDIN_FILENO); 
 } 
 tcsetattr(STDIN_FILENO, TCSANOW, ); // reset terminal 
  
  printf("\n"); 
 } while (0); 
  
 pruio_destroy(io); /* destroy driver structure */ 
 return 0; 
 }


In the following line of code you can read that the value 0x98 is the 
*second* argument passed to the function.
*BUT* In the documentation I found that:

pruIo* pruio_new ( uint16  *Act*, 


uint8  *Av*, 


uint32  *OpD*, 


uint8  *SaD*  

) 

Wrapper function for the constructor PruIo::PruIo(). 
Parameters 
Act mask for active subsystems and PRU number 
Av avaraging for default steps (0 to 16, defaults to 0) 
OpD open delay for default steps (0 to 0x3, defaults to 0x98) 
SaD sample delay for default steps (0 to 255, defaults to 0) 
the second argument of that function should be the parameter Av, which 
ranges [0-16].
the OpD is passed lately to the function.

Is there a problem in the documentation or somewhere else??


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Bug or error in the documentation of libpruio

[Davide Picchi]

In the following line of code you can read that the value 0x98 is the 
*second* argument passed to the function:
 pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1);

I forgot to point to the function in the text.



Am Samstag, 13. Februar 2016 13:01:04 UTC+1 schrieb Davide Picchi:
>
> I was reading carefully the following example taken from here:
>
> file: button.c
>
> define _GNU_SOURCE 1 
>  #include "stdio.h" 
>  #include  
>  #include  
> #include  
>  #include  
> #include  
>  #include "../c_wrapper/pruio.h" 
>  #include "../c_wrapper/pruio_pins.h" 
>   
>  #define PIN P8_07 
>  
>  int 
>  isleep(unsigned int mseconds) 
>  { 
>  fd_set set; 
>   struct timeval timeout; 
>   
>  /* Initialize the file descriptor set. */ 
>   FD_ZERO(); 
>   FD_SET(STDIN_FILENO, ); 
>   
>   /* Initialize the timeout data structure. */ 
>  timeout.tv_sec = 0; 
>   timeout.tv_usec = mseconds * 1000; 
>   
>  return TEMP_FAILURE_RETRY(select(FD_SETSIZE, 
>  , NULL, NULL, 
>  )); 
>  } 
>   
>  int main(int argc, char **argv) 
>  { 
>  pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); // <= LOOK HERE
>  
>   do { 
>   if (io->Errr) { 
>   printf("initialisation failed (%s)\n", io->Errr); break;} 
>   
>   if (pruio_config(io, 1, 0x1FE, 0, 4)) { 
> printf("config failed (%s)\n", io->Errr); break;} 
>   
>  struct termios oldt, newt; // make terminal non-blocking 
>  tcgetattr( STDIN_FILENO,  ); 
>  newt = oldt; 
>  newt.c_lflag &= ~( ICANON | ECHO ); 
>  newt.c_cc[VMIN] = 0; 
>  newt.c_cc[VTIME] = 0; 
>  tcsetattr(STDIN_FILENO, TCSANOW, ); 
>   
>  while(!isleep(1)) { // run loop until keystroke 
>  printf("\r%1X", pruio_gpio_Value(io, PIN)); 
>  fflush(STDIN_FILENO); 
>  } 
>  tcsetattr(STDIN_FILENO, TCSANOW, ); // reset terminal 
>   
>   printf("\n"); 
>  } while (0); 
>   
>  pruio_destroy(io); /* destroy driver structure */ 
>  return 0; 
>  }
>
>
> In the following line of code you can read that the value 0x98 is the 
> *second* argument passed to the function.
> *BUT* In the documentation I found that:
>
> pruIo* pruio_new ( uint16  *Act*, 
>
>
> uint8  *Av*, 
>
>
> uint32  *OpD*, 
>
>
> uint8  *SaD*  
>
> ) 
>
> Wrapper function for the constructor PruIo::PruIo(). 
> Parameters 
> Act mask for active subsystems and PRU number 
> Av avaraging for default steps (0 to 16, defaults to 0) 
> OpD open delay for default steps (0 to 0x3, defaults to 0x98) 
> SaD sample delay for default steps (0 to 255, defaults to 0) 
> the second argument of that function should be the parameter Av, which 
> ranges [0-16].
> the OpD is passed lately to the function.
>
> Is there a problem in the documentation or somewhere else??
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Bug or error in the documentation of libpruio

[TJF]

Hi Davide!

You're right, thanks for reporting that bug. It'll be fixed in next 
release. It's a copy / paste, you can find it in all C examples. The effect 
is that the ADC runs faster than expected (no delay).

BR

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BB-X15 and PCIe

[Jason Kridner]

https://groups.google.com/d/msgid/beagleboard-x15/CAALWOA-Oo27Pvr23r9wbXP%2BQXChi%3D%3DUyyKBsuJZ-FW70nbSY-w%40mail.gmail.com?utm_medium=email_source=footer
On Thu, Feb 11, 2016 at 6:42 AM Philippe  wrote:

> Hello,
>
> Does it will be possible to test PCIe on the BB-X15, may be by using
> mini-pcie interface boards such Ethernet or UART  ?
>
> Thanks
>
>
> Philippe
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Internal Pullup and Pulldown GPIO

[TJF]

Hi Bigowlrrww!

Do you mean Debian 7 (Wheezy) on a 3.8 Kernel?

You could use libpruio  to 
control the GPIOs. It can change the resistors configuration at run-time 
(slow via sysfs), but the program has to run under root privileges.

BR

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Read voltage from ADC using an external power supply

[TJF]

Hi Chelsea Orefice!

1V6 at an open pin looks good. AIN7 is connected to 1V65 at the board (half 
of power line) and that voltage pulls up the other pins, when open. When 
connecting P9_40 to ADC_GND you should see a values close to zero.

You could use the libpruio  
example oszi 

 
to study the ADC behaviour.

BR

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Can't connect to 192.168.7.2 on BBB via USB...What am I doing wrong? Help, please......

[bill . paige]

  Hi AllThanks in advance for any help here.  I am a new guy and just 
got the BBB.  I have gone through step 2 with no issues, but my PC will NOT 
get to 192.168.7.2 (step 3) via USB to BBB.  I have tried all 4 PC's that I 
own.  Three running Windows 10 and one running Vista.  The 32 bit drivers 
load fine (green check marks) on the Vista PC.  Tired Firefox and Chrome. 
  I have spent hours trying to figure this out and bought two books, so I 
want to get into this, but nothing works.  I have WiFi.  I have trued 
turning this off, but no luck.  The BBB does show up as a "gadget" but no 
connectivity.  
  I can connect a Ethernet cable to a repeater and see the internet when 
the BBB is hooked up to a monitor.  Thoughts?  Any help would be 
appreciated.  

  

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Codec drivers and alsa support for custom cape with sta321mp

[Pablo Fonovich]

Hi robin!

By this time, i was writting a guide to get a custom linux os to boot in
the beaglebone... and i was quite busy with that...

In my project, the drivers seems to be working properly, although i can't
use regmap_update_bits function... i'm not sure, but i think it has
something to do with the i2c communications that seems not to be working...
If it has to update registers through i2c and this is not working, it makes
sense that that functions returns error... i think that for that same
reazon, alsamixer is not working... i've made the structures you told me,
but i keep getting "input output error" when i try to "alsamixer"

Anyway, the university is closed till march here (we are on holydays) so i
can't get the equipmet to test the hardware, and i don't own any right now
(too expensive for me).

One main issue i'm having and that i can't solve is that i can record only
4 channels with arecord...
I configured 2 serializers as input, and 4 tdm slots on each in the device
tree... but if i "arecord -c 6" it says "no channel count avaliable"... i'm
starting to think that arecord recors from only one serializer... i would
need to record an arbitrary channel if it's possible, and i think i should
write an alsa application for this...

But more important right now seems to be this: Do you think is possible
that alsamixer and  regmap_update_bits are not working cause of i2c problem?

Thanks for everything
Pablo



2016-02-12 12:17 GMT-03:00 Robin Scheibler :

> Hi Pablo,
>
> Any progress with your board ?
>
> Also, to answer your question, I got the alsamixer working. You have to
> add a number of macros for predefined controls corresponding to register to
> update in the codec. You can see it directly in my code:
>
>
> https://github.com/fakufaku/linux/blob/66e5bfa74df723ff64b48d2ae14f3543d6c47861/sound/soc/codecs/sta321mp.c#L74
>
>
> static const DECLARE_TLV_DB_SCALE(mvol_tlv, -12700, 50, 1);
> static const DECLARE_TLV_DB_SCALE(chvol_tlv, -7950, 50, 1);
> static const struct snd_kcontrol_new sta321mp_snd_controls[] = {
> SOC_SINGLE("Master Switch", STA321MP_MMUTE, 0, 1, 1),
> SOC_SINGLE_TLV("Master Volume", STA321MP_MVOL, 0, 0xff, 1, mvol_tlv),
> SOC_DOUBLE_R("Ch1 Capture Switch", STA321MP_C1VTMB,
> STA321MP_C2VTMB, 7, 1, 1),
> SOC_DOUBLE_R("Ch2 Capture Switch", STA321MP_C3VTMB,
> STA321MP_C4VTMB, 7, 1, 1),
> SOC_DOUBLE_R("Ch3 Capture Switch", STA321MP_C5VTMB,
> STA321MP_C6VTMB, 7, 1, 1),
> SOC_DOUBLE_R_TLV("Ch1 Capture Volume", STA321MP_C1VOL, STA321MP_C2VOL, 0,
> 0xff, 1, chvol_tlv),
> SOC_DOUBLE_R_TLV("Ch2 Capture Volume", STA321MP_C3VOL, STA321MP_C4VOL, 0,
> 0xff, 1, chvol_tlv),
> SOC_DOUBLE_R_TLV("Ch3 Capture Volume", STA321MP_C5VOL, STA321MP_C6VOL, 0,
> 0xff, 1, chvol_tlv),
> };
>
> This implements volume control for all six capture channels, as well as
> mute switches.
>
> Best,
> Robin
>
>
>
> On 12 janv. 2016, at 21:50, Pablo Fonovich 
> wrote:
>
> Hi Robin:
>
> I realized that although i was commenting the line you said, i was using
> and old image of the compiled kernel, and that was why i kept getting the
> same error! My bad... Now that is working, but i have an error in the line:
>
> ret = regmap_update_bits(priv->regmap, PCM3168_DAC_FMT_CONTROL, 0x0f, val);
>
> on my pcm3168.c file... ret gets the value -128 (error code). I use this
> function to update some register on the codec... i suspected that my i2c
> connection is not working properly, so i commented this line (althoug i'm
> not sure if an error in i2c causes this function to crash) and finally the
> arecord command works gives no error, but records nothing :(
>
> That was somehow expected, as my codec is not geting it's regmap
> updated... One of this days i will use an ozscope to see if the signals out
> of the i2c of the beaglebone are right... If you came up with some idea
> please tell me... you've been of great help...
>
> P.D: have you got alsamixer working in your project?
>
> 2016-01-11 17:06 GMT-03:00 Pablo Fonovich :
>
>> Hi:
>> Thanks for your suggestions!
>> i've already commented that line, as i said in the mail when i isolated
>> the problem to that function... the error persist but now in:
>>
>> ret = snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_OUT);
>> if (ret < 0)
>> return ret;
>>
>> I'm using the linux-cross-reference, that's how i find out what each
>> parameter means, but perhaps i still dont quite understand what the
>> function really does.
>>
>> I've also read the mcasp section of the am335x datasheet when i was doing
>> the PCB for the codec, but i should re-read it, as many things where not
>> clear for me at that moment, and perhaps now they make a little more sense.
>> Anyway, the problem and same error code persists, now in that other line...
>>
>> Thanks for your help! i'll post any progress i make
>>
>>
>> 2016-01-11 5:12 GMT-03:00 Robin Scheibler :
>>
>>> Hi Pablo,
>>>
>>> I took a look at your