Re: [beagleboard] Test email to get Beaglebone software help

[David Good]

I'm here, but certainly not an expert. What are you trying to do?

--David

On Sun, Feb 10, 2019, 11:18 AM David Malawey  Hello,
>
> Please indicate if this email address is active.  I'm having issues with
> beaglebone blue for classroom use and I am in need of help.
>
> Cheers,
>
> David Malawey, MS ME
> ETID Technical Lab Coordinator
> mala...@tamu.edu
>
> --
> 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/CAFAki_0-mY8E7Yy93%2BvzXoEShEy6xUhL8N-z_Y%3D8BU6q26V1hA%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/CALMFhSzL_BGfdUHS313h%3D2ZvK9YSUdGws%2BqNk3oRHq%3DGCegTYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: What is the best free solution to develop a GUI application on a BB with LCD3 cape as of 2017?

[David Good]

I don't have any experience (yet) with using Tk specifically on the LCD3
cape, but it is something I'm going to experiment with.

Is Tk an option for you?

http://www.tkdocs.com/

It's usable from scripting languages such as Tcl, Python, Perl, and Ruby.

You can also use it with straight C via the API.

--David

On Mon, Jun 19, 2017 at 4:15 AM,  wrote:

> Not exactly a GUI, but if it doesn't have to be super pretty and
> fancy.. you can always make it a web page...fire up a browser when the gui
> boots up and redirect it to local webhost.
>  just remember you will have to remap left/right buttons to tab in the lcd
> overlay to make it useful.
>
> On Saturday, June 17, 2017 at 9:28:46 PM UTC-5, LV LV wrote:
>>
>>
>> I want to develop something for my home that has a GUI on the BB with
>> LCD3 cape.
>> At $1000/year Qt (one of my favorite dev environment) is no longer an
>> option.
>> I probably would have spent $29/Month to have access to it but at
>> $1000/Year that is just too much to bear for personal use.
>> For years I pushed students to use Qt so they would learn C++ in the
>> process, all with great success, unfortunately I have to turn them to Java
>> instead now.
>>
>>
>> *So what is the best solution available to develop a GUI application on a
>> BB with LCD3 cape as of 2017?*
>>
>>
>> --
> 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/4ebba887-4fca-4ef5-a815-60e970ff0cc2%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/CALMFhSzkt0vEUs2MCwXQUdasnN5rqgXFxv%3DX6fBbzvtGh5r9HA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBW fails to boot

[David Good]

I've been using the prebuilt debian 8 images on a BBW without problems, so
like you said, it must be something in the build process.

I have not tried this myself, but just thinking about it:
1> Bad "burn" to SD card?
2> /boot/uEnv.txt has some options that are trying making U-Boot try to
look for an image on a BBB eMMC rather than SD card.

--David

On Sun, Jun 26, 2016 at 7:56 AM, Hesham  wrote:

> Hi all,
>
> I have an old BBW that I wanted to revive. It boots fine with the SD card
> that came with it. It boots well with an old SD that I built following come
> old instructions, pre-dates DTS.
>
> Now, I've tried to build it following the instructions on:
> https://eewiki.net/display/linuxonarm/BeagleBone
> It fails to boot. I think something is wrong regarding the bootloader,
> either the way I built it or the instructions might be wrong for this old
> platform.
>
> Anyways, here is what I get on minicom before it dies:
>
> U-Boot SPL 2016.07-rc2-dirty (Jun 26 2016 - 03:11:33)
> No AC power, disabling frequency switch
> Trying to boot from MMC1
> Expected Linux image is not found. Trying to start U-boot
>
>
> U-Boot 2016.07-rc2-dirty (Jun 26 2016 - 03:11:33 -0400)
>
>Watchdog enabled
> I2C:   ready
> DRAM:  256 MiB
>
> The symptoms of its death, it disconnects the /dev/ttyUSB0 and the LED is
> off.
>
> Any idea where what I might be doing wrong? I build on Ubuntu 16.04
>
> Thanks,
> -Hesham
>
> --
> 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/11f427aa-46e8-43b3-83b8-759c8cd3e580%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/CALMFhSx9h%3DmwygeeZMCABz8zRWe9ge4c7QJdLj%2BhgdM10QsXbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Best way to get data into PRU

[David Good]

Hi All,

I'm a little confused as to how to get data into the PRU using
remoteproc/vrings.

Background:
I have successfully adapted the remoteproc examples to get an LED matrix
scrolling message board working with an initial test image.  I can also
send data to /dev/rpmsg_pru30 to turn the display on and off (echo B >>
/dev/rpmsg_pru30).

Now, I want to send the display new display data, which is approximately
1152 bytes (144 pixels by 8 rows).  Trying to follow the pru_rpmsg.h/.c
code, I see a constant called RPMSG_BUF_SIZE 512 with note that this size
includes the header overhead (pru_rpmsg_hdr looks like 17 bytes).

So, if I want to use virtqueues, it looks like I will have to invent some
kind of protocol to transmit chunks of data at a time until I get the whole
image transferred.

Is this correct?

Can I use the /dev/rpmsg_pru30 device for this purpose?

Is this the standard way to get this kind of data into the PRU, or am I
thinking about this incorrectly.

Thanks!

--David

-- 
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/CALMFhSyqP5Z6BeKM6e8qiZWP6MxPJx4UGHrxFw0-kWNV05ihDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru remoteproc development examples for debian?

[David Good]

Great! Thanks for the info, All.  I'm getting somewhere now :)

I've got more PRU questions, but will start a new thread since it's not
exactly related.

@ZeekHuge: Nice info on your website!  It's the website I wish I would have
made after all of my stumbling around with PRUs.

--David

On Sat, Jun 25, 2016 at 10:46 AM, ZeekHuge  wrote:

>
>
> Hi Greg,
>
> Yes, virtual file entries mounted at debugfs can be used to debug pru
> codes.
>
>
> https://github.com/ZeekHuge/BeagleScope/blob/master/docs/current_remoteproc_drivers.notes#L212
>
>
> root@beaglebone:~# tree /sys/kernel/debug/remoteproc/remoteproc*
> /sys/kernel/debug/remoteproc/remoteproc0
> |-- name
> |-- recovery
> |-- state
> |-- trace0
> `-- version
> /sys/kernel/debug/remoteproc/remoteproc1
> |-- name
> |-- recovery
> |-- regs
> |-- single_step
> |-- state
> `-- version
> /sys/kernel/debug/remoteproc/remoteproc2
> |-- name
> |-- recovery
> |-- regs
> |-- single_step
> |-- state
> `-- version
>
> Though I haven't tried it yet, will get into it soon :)
>
> - ZeekHuge
>
> --
> 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/1236ef86-9242-4b8d-b0bb-47488a5fec3b%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/CALMFhSxPfDXMQM9bURevCSjfDHNpUiKvZi5K_XAwzKBq4pgdSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru remoteproc development examples for debian?

[David Good]

To clarify question 1 of my original post, I'm checking the pin mode
settings with 'cat $PINS' and the PRU pins always show 0x27.  I'm asking
whether there are any other PRUSS specific requirements in the device tree
itself or if the load order of the device tree overlay and firmware matter
in order for the '$PINS' file to show that the mode was changed to
pru_r30_blah_blah.

Thanks!

On Wed, Jun 8, 2016 at 12:07 PM, David Good  wrote:

> Good suggestions Greg!  I didn't know about rmmod -f.  You learn something
> new every day!
>
> I didn't even know about config-pin until yesterday, since I've only ever
> used device trees in the past.  I guess config-pin might actually be the
> best option for my stage of development, but I would like to get the PRU
> pins configured with device trees eventually, since that feels more like
> the right "embedded" thing to do ;)
>
> --David
>
> On Wed, Jun 8, 2016 at 9:18 AM, Greg  wrote:
>
>> Regarding the device tree, I'm using the "Universal IO" and the
>> accompanying shell script config-pin and I haven't had any configuration
>> problems with the PRU pins.
>> There is an option for config-pin which reads a file and sets all of the
>> pins per a list of the pins in the file.  It works very well.  You can put
>> this command in your .profile or
>> whatever you do at boot time to set up the pins.  I've found this system
>> works flawlessly and saves a lot of time and confusion.
>>
>> I have had to tweak the device tree source if a different pull-up/down
>> resistor is required on a PRU input pin.
>>
>> Regarding the rmmod problem, use the "force" option -f.  This is actually
>> recommended by TI.
>>
>> I highly recommend creating simple bash scripts or aliases called
>> "prumodout" and "prumodin" which execute the rmmod and insmod commands to
>> remove
>> and insert your PRU firmwares.  Taking it to the next step, you can use
>> your prumod and prumodin commands in your build script so that the firmwares
>> are copied to the /lib/firmware directory, old firmwares removed and new
>> firmwares loaded and started all in a single command.
>>
>> You should be able to go through a modify-build cycle without reboot, and
>> very quickly.
>>
>> Regards,
>> Greg
>>
>>
>> On Wednesday, June 8, 2016 at 1:25:20 AM UTC-4, David Good wrote:
>>
>>> Alright, I'm making some progress, but am having some issues:
>>>
>>> 1. I can't seem to get my device tree to change the mode of pins
>>> associated with the pruss, but other pins are configured correctly.  Is
>>> there some kind of order that the PRU firmware and device tree has to load
>>> in?
>>>
>>> /* Start EBB-PRU-Example.dts */
>>> /dts-v1/;
>>> /plugin/;
>>>
>>> / {
>>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>>
>>>part-number = "EBB-PRU-Example";
>>>version = "00A0";
>>>
>>>/* This overlay uses the following resources */
>>>exclusive-use =
>>>  "P9.11", "P9.13", "P9.27", "P9.28", "pru0";
>>>
>>>fragment@0 {
>>>   target = <&am33xx_pinmux>;
>>>   __overlay__ {
>>>
>>>  gpio_pins: pinmux_gpio_pins { // The GPIO pins
>>> pinctrl-single,pins = <
>>>0x070 0x07  // P9_11 MODE7 | OUTPUT | GPIO pull-down
>>>0x074 0x27  // P9_13 MODE7 | INPUT | GPIO pull-down
>>> >;
>>>  };
>>>
>>>  pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
>>> pinctrl-single,pins = <
>>>0x1a4 0x05  // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT |
>>> PRU
>>>0x19c 0x26  // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT |
>>> PRU
>>> >;
>>>  };
>>>   };
>>>};
>>>
>>>fragment@1 { // Enable the PRUSS
>>>   target = <&pruss>;
>>>   __overlay__ {
>>>  status = "okay";
>>>  pinctrl-names = "default";
>>>  pinctrl-0 = <&pru_pru_pins>;
>>>   };
>>>};
>>>
>>>fragment@2 { // Enable the GPIOs
>>>   target = <&ocp>;
>&

Re: [beagleboard] Re: pru remoteproc development examples for debian?

[David Good]

Good suggestions Greg!  I didn't know about rmmod -f.  You learn something
new every day!

I didn't even know about config-pin until yesterday, since I've only ever
used device trees in the past.  I guess config-pin might actually be the
best option for my stage of development, but I would like to get the PRU
pins configured with device trees eventually, since that feels more like
the right "embedded" thing to do ;)

--David

On Wed, Jun 8, 2016 at 9:18 AM, Greg  wrote:

> Regarding the device tree, I'm using the "Universal IO" and the
> accompanying shell script config-pin and I haven't had any configuration
> problems with the PRU pins.
> There is an option for config-pin which reads a file and sets all of the
> pins per a list of the pins in the file.  It works very well.  You can put
> this command in your .profile or
> whatever you do at boot time to set up the pins.  I've found this system
> works flawlessly and saves a lot of time and confusion.
>
> I have had to tweak the device tree source if a different pull-up/down
> resistor is required on a PRU input pin.
>
> Regarding the rmmod problem, use the "force" option -f.  This is actually
> recommended by TI.
>
> I highly recommend creating simple bash scripts or aliases called
> "prumodout" and "prumodin" which execute the rmmod and insmod commands to
> remove
> and insert your PRU firmwares.  Taking it to the next step, you can use
> your prumod and prumodin commands in your build script so that the firmwares
> are copied to the /lib/firmware directory, old firmwares removed and new
> firmwares loaded and started all in a single command.
>
> You should be able to go through a modify-build cycle without reboot, and
> very quickly.
>
> Regards,
> Greg
>
>
> On Wednesday, June 8, 2016 at 1:25:20 AM UTC-4, David Good wrote:
>
>> Alright, I'm making some progress, but am having some issues:
>>
>> 1. I can't seem to get my device tree to change the mode of pins
>> associated with the pruss, but other pins are configured correctly.  Is
>> there some kind of order that the PRU firmware and device tree has to load
>> in?
>>
>> /* Start EBB-PRU-Example.dts */
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>
>>part-number = "EBB-PRU-Example";
>>version = "00A0";
>>
>>/* This overlay uses the following resources */
>>exclusive-use =
>>  "P9.11", "P9.13", "P9.27", "P9.28", "pru0";
>>
>>fragment@0 {
>>   target = <&am33xx_pinmux>;
>>   __overlay__ {
>>
>>  gpio_pins: pinmux_gpio_pins { // The GPIO pins
>> pinctrl-single,pins = <
>>0x070 0x07  // P9_11 MODE7 | OUTPUT | GPIO pull-down
>>0x074 0x27  // P9_13 MODE7 | INPUT | GPIO pull-down
>> >;
>>  };
>>
>>  pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
>> pinctrl-single,pins = <
>>0x1a4 0x05  // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT |
>> PRU
>>0x19c 0x26  // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT |
>> PRU
>> >;
>>  };
>>   };
>>};
>>
>>fragment@1 { // Enable the PRUSS
>>   target = <&pruss>;
>>   __overlay__ {
>>  status = "okay";
>>  pinctrl-names = "default";
>>  pinctrl-0 = <&pru_pru_pins>;
>>   };
>>};
>>
>>fragment@2 { // Enable the GPIOs
>>   target = <&ocp>;
>>   __overlay__ {
>>  gpio_helper {
>> compatible = "gpio-of-helper";
>> status = "okay";
>> pinctrl-names = "default";
>> pinctrl-0 = <&gpio_pins>;
>>  };
>>   };
>>};
>> };
>> /* End EBB-PRU-Example.dts */
>>
>>
>> 2. I've got one of the TI examples compiled running as
>> /lib/firmware/am335x-pru0-fw
>> dmesg seems to show that it loads successfully, without errors.
>>
>> #include 
>> #include 
>> #include "resource_table_empty.h"
>>
>> volatile register uint32_t __R30;
>> volatile register uint32_t __R31;
>>
>> void main(void)
>> {
>>
>> uint32_t gpio;
>>
>

Re: [beagleboard] Re: pru remoteproc development examples for debian?

[David Good]

Alright, I'm making some progress, but am having some issues:

1. I can't seem to get my device tree to change the mode of pins associated
with the pruss, but other pins are configured correctly.  Is there some
kind of order that the PRU firmware and device tree has to load in?

/* Start EBB-PRU-Example.dts */
/dts-v1/;
/plugin/;

/ {
   compatible = "ti,beaglebone", "ti,beaglebone-black";

   part-number = "EBB-PRU-Example";
   version = "00A0";

   /* This overlay uses the following resources */
   exclusive-use =
 "P9.11", "P9.13", "P9.27", "P9.28", "pru0";

   fragment@0 {
  target = <&am33xx_pinmux>;
  __overlay__ {

 gpio_pins: pinmux_gpio_pins { // The GPIO pins
pinctrl-single,pins = <
   0x070 0x07  // P9_11 MODE7 | OUTPUT | GPIO pull-down
   0x074 0x27  // P9_13 MODE7 | INPUT | GPIO pull-down
>;
 };

 pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
pinctrl-single,pins = <
   0x1a4 0x05  // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT | PRU
   0x19c 0x26  // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT | PRU
>;
 };
  };
   };

   fragment@1 { // Enable the PRUSS
  target = <&pruss>;
  __overlay__ {
 status = "okay";
 pinctrl-names = "default";
 pinctrl-0 = <&pru_pru_pins>;
  };
   };

   fragment@2 { // Enable the GPIOs
  target = <&ocp>;
  __overlay__ {
 gpio_helper {
compatible = "gpio-of-helper";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&gpio_pins>;
 };
  };
   };
};
/* End EBB-PRU-Example.dts */


2. I've got one of the TI examples compiled running as
/lib/firmware/am335x-pru0-fw
dmesg seems to show that it loads successfully, without errors.

#include 
#include 
#include "resource_table_empty.h"

volatile register uint32_t __R30;
volatile register uint32_t __R31;

void main(void)
{

uint32_t gpio;

/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

/* gpio = 0x000F; */
/* gpio = (1 << 5); */
gpio = 0x0010;

__R30 = 0x0;

/* Toggle the LEDs */
/* TODO: Create stop condition, else it will toggle indefinitely */
while (1) {
__R30 ^= gpio;

__delay_cycles(1);

}
}

As you can see, main is an infinite loop.  This means that if I try to
rmmod pru-rproc, I get the following error:
rmmod: ERROR: Module pru_rproc is in use

This means that I have to reboot in order to update the code.  How do I
either force the pru to unload or send it signals to stop so I don't have
to reboot everytime?

Thanks again!

--David


On Wed, May 11, 2016 at 5:57 PM, Greg  wrote:

> Ok, thanks-- no insurmountable legal issues for sharing your own PRU
> code.  Beagleboard PRU fans, please start your code sharing engines!
>
> Greg
>
>
> --
> 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/566d5ab7-7b0d-4445-8c2c-0ed6004d1242%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/CALMFhSznstanAr2gspTRdqkX-NkT5xkmZuGTR-jn9Ch5QU4ovw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru remoteproc development examples for debian?

[David Good]

Thanks Greg!

I did get the file at:
http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#PRU

but got a little weirded out with the HUGE, legally binding contract that
seems to say that you can't distribute your source code, only executables
when using that package.

I'll definitely look over the other links you provided very carefully.

Many thanks for the direction!

--David

On Tue, May 10, 2016 at 8:18 AM, Greg  wrote:

> https://github.com/dinuxbg/gnupru
>
> Also almost forgot about the above, however, I have not tried using it.
>
> Greg
>
> --
> 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/8e712c3c-13bf-4087-9869-3969ffc039a6%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/CALMFhSwyg%3DGNT0n1faAJkj2dk_irj-JFvrPN-WTWPAD%3DqmQ2aw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] pru remoteproc development examples for debian?

[David Good]

Hi All,

Is there a good example of developing using remoteproc on the beaglebone
using only open source/free software?  The docs at TI are really good, but
rely on Code Composer Studio or PRU code generation tools etc.

I was hoping for something like this:
https://github.com/beagleboard/am335x_pru_package

Thanks!

--David

-- 
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/CALMFhSwEFR2Wbrk1djZ3HFMW%3DGrcD_nz32sjbbwO6eFout2CRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Good]

Hi Harke,

X11 is the X window system rev 11.  It's the most basic graphics layer on a
desktop system.  By itself, it just allows you to create graphical windows,
but doesn't manage them in any way.  That's where LXDE comes in.  LXDE sits
on top of X11 and provides useful "desktop user" type features like window
management, a clipboard for copy and paste between applications, a program
menu launcher, etc...

About starting your program, you really shouldn't need to have LXDE.  You
should be able to to add your "python my_program.py" to a .xinitrc file and
get what you are looking for.  This uses X11 at its most basic level,
without providing "start menu" etc.

https://wiki.debian.org/Xinitrc
http://blog.falconindy.com/articles/back-to-basics-with-x-and-systemd.html
https://wiki.gentoo.org/wiki/X_without_Display_Manager

After poking around a bit, I found that you might like a package called
nodm.
https://github.com/spanezz/nodm
https://packages.debian.org/jessie/nodm
http://jeffhoogland.blogspot.com/2011/12/howto-get-right-to-x-with-no-display.html

I've not used it, but now that I've seen this, I will give it a try myself!

I hope this helps!

--David


On Mon, Apr 4, 2016 at 1:53 PM, Harke Smits  wrote:

> Hello David and John,
>
> Thanks for your reactions. Sorry for the delay, was occupied with some
> other duties like skiing
> echo $DISPLAY from the debian command line returns nothing (a blank line).
> The same command form the debian command line coming from the LXDE
> interface gives: :0. So I issue the sudo python myprog.py command after the
> LXDE shell has been loaded: that works for me.I need sudo because of the
> Adafruit library, but I suppose that is another story.
> Would be great to run the program without LXDE but I guess that will not
> work.
> The next problem is: how to run the program automatically upon start-up. I
> prefer without LXDE but I am afraid that is not possible. So I need to
> start myprog.py form a kind of start-up script
> Btw: what is X11? The link is not terribly clear for me as a novice...
>
> Best regards,
> Harke
>
>
> On Sat, Mar 26, 2016 at 10:01 PM, David Good 
> wrote:
>
>> It looks like you need to set the DISPLAY environment variable so that
>> tkinter knows which display to use.
>>
>> Is X11 installed on the BBB?
>>
>> On my linux machine, when I try echo $DISPLAY, I get ":0.0" without the
>> quotes.
>>
>> What happens if you run that command?
>>
>> You might check out some of the info on this page as well.
>>
>>
>> http://unix.stackexchange.com/questions/17255/is-there-a-command-to-list-all-open-displays-on-a-machine
>>
>> --David
>>
>> On Sat, Mar 26, 2016 at 1:59 PM, John Baker > > wrote:
>>
>>> Harke:
>>> Another in the Learned Group, I think it was Steve Plant but I can't
>>> find the post, suggested connecting a keyboard and mouse to the BBB and
>>> running the Python program with 'sudo python your_python_program'. That
>>> worked great for me. I never would have thought of it. My code is a GUI
>>> with buttons, text boxes and an animation graph running Tkinter and also
>>> running PyBBIO for PWM output and ADC inputs.
>>> John
>>> johnbakeree.blogspot.com
>>>
>>> On Saturday, February 13, 2016 at 3:07:04 AM UTC-8, Harke Smits wrote:
>>>>
>>>> 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, 

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

[David Good]

It looks like you need to set the DISPLAY environment variable so that
tkinter knows which display to use.

Is X11 installed on the BBB?

On my linux machine, when I try echo $DISPLAY, I get ":0.0" without the
quotes.

What happens if you run that command?

You might check out some of the info on this page as well.

http://unix.stackexchange.com/questions/17255/is-there-a-command-to-list-all-open-displays-on-a-machine

--David

On Sat, Mar 26, 2016 at 1:59 PM, John Baker 
wrote:

> Harke:
> Another in the Learned Group, I think it was Steve Plant but I can't find
> the post, suggested connecting a keyboard and mouse to the BBB and running
> the Python program with 'sudo python your_python_program'. That worked
> great for me. I never would have thought of it. My code is a GUI with
> buttons, text boxes and an animation graph running Tkinter and also running
> PyBBIO for PWM output and ADC inputs.
> John
> johnbakeree.blogspot.com
>
> On Saturday, February 13, 2016 at 3:07:04 AM UTC-8, Harke Smits wrote:
>>
>> 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.
>

-- 
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] Arch linux and issues loading device tree overlay at boot via uEnv.txt

[David Good]

Or does it have something to do with the external RTC specifically?  I made
a cape that had an RTC which loads correctly at boot time using kernel 3.8
something, so maybe it's a kernel problem.  Can you check if another cape
loads automatically on boot correctly?

--David


On Fri, Mar 25, 2016 at 4:42 PM, Axe  wrote:

>
> Like many, I'm having issues with loading device tree overlays at boot.
>
> # uname -a
> Linux spa.turrim 4.4.4-1-ARCH #1 Sat Mar 5 18:30:09 MST 2016 armv7l
> GNU/Linux
> #
>
> I have DS3231.dts:
>
> /dts-v1/;
> /plugin/;
>
> /{
>
>   compatible = "ti,beaglebone", "ti,beaglebone-black";
>   part-number = "BBB-DS3231";
>   version = "00A0";
>
>   fragment@0 {
> target = <&i2c2>;
>
> __overlay__ {
>   pinctrl-0 = <&i2c2_pins>;
>
>   clock-frequency = <10>;
>   status = "okay";
>
>   rtc: rtc@68 {
> compatible = "dallas,ds1307";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x68>;
>   };
> };
>   };
> };
>
> I have compiled it and put the .dtbo in /lib/firmware:
>
> # ls -l /lib/firmware/DS3231-00A0.dtbo
> -rw-r--r-- 1 root root 699 Feb 22 21:35 /lib/firmware/DS3231-00A0.dtbo
> #
>
> Interactively it works:
>
> # echo DS3231 > /sys/devices/platform/bone_capemgr/slots
>
> produces:
>
> [ 4082.171481] bone_capemgr bone_capemgr: part_number 'DS3231', version
> 'N/A'
> [ 4082.178999] bone_capemgr bone_capemgr: slot #4: override
> [ 4082.184502] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 4
> [ 4082.191512] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,DS3231'
> [ 4082.216295] rtc-ds1307 2-0068: rtc core: registered ds1307 as rtc1
> [ 4082.222530] rtc-ds1307 2-0068: 56 bytes nvram
> [ 4082.237260] bone_capemgr bone_capemgr: slot #4: dtbo 'DS3231-00A0.dtbo'
> loaded; overlay id #0
>
> and
>
> # cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,DS3231
> #
>
> So I ask to have it enabled at boot:
>
> # cat /boot/uEnv.txt
> optargs=coherent_pool=1M bone_capemgr.enable_partno=BBB-DS3231
> #
>
> and I get this in dmesg:
>
> # dmesg | grep bone
> [0.00] Kernel command line: console=ttyO0,115200n8
> coherent_pool=1M bone_capemgr.enable_partno=BBB-DS3231
> root=PARTUUID=0e4f7ccd-01 rw rootwait fixrtc
> [4.950284] bone_capemgr bone_capemgr: Baseboard:
> 'A335BNLT,00C0,3214BBBK9247'
> [4.957585] bone_capemgr bone_capemgr:
> compatible-baseboard=ti,beaglebone-black - #slots=4
> [5.023585] bone_capemgr bone_capemgr: slot #0: No cape found
> [5.083600] bone_capemgr bone_capemgr: slot #1: No cape found
> [5.143596] bone_capemgr bone_capemgr: slot #2: No cape found
> [5.203580] bone_capemgr bone_capemgr: slot #3: No cape found
> [5.209370] bone_capemgr bone_capemgr: enabled_partno PARTNO
> 'BBB-DS3231' VER 'N/A' PR '0'
> [5.217685] bone_capemgr bone_capemgr: slot #4: override
> [5.223023] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 4
> [5.230034] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,BBB-DS3231'
> [5.239545] bone_capemgr bone_capemgr: initialized OK.
> [6.259420] bone_capemgr bone_capemgr: loader: failed to load slot-4
> BBB-DS3231:00A0 (prio 0)
> #
>
> Is this a case of /lib/firmware not being available yet?  I see people
> with Debian fiddling with initramfs in similar situations...?
>
>
> --
> 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.

Re: [beagleboard] REMOTE DEBUGGING/RUNNING WITH PYCHARM

[David Good]

If your question is about PyCharm setup, I can't really help you there as I
don't use it, but if your question is about scp, I can help you there.

>From windows, you can run the command:
scp myFileOnWindows.py user@bbbIpAddress:/home/user/projDir/

substituting your info for the various place holder names.  This will place
your local files to the directory of your choice on the Beaglebone.

Hopefully this can help you setup your environment!

--David

On Thu, Mar 24, 2016 at 3:40 AM,  wrote:

> Hello everyone!
>
> I recently purchased a new beaglebone black and I'm starting to playing
> around with it. I'm trying to run my programs remotely from my Pycharm IDE
> to the beaglebone. I have tried with the ssh command scp, but I'm always
> getting an error "not such file or directory", which makes me wonder: what
> path should I specify in Pycharm and where, to say "read the file from the
> directoy in my computer (windows) but use the beaglebone interpreter to run
> it on the beaglebone". I have already configured the beaglebone interpreter
> in Pycharm, so that one is settled. The rest I cannot find any reliable or
> clear source. Can someone attempted this? I need some help. The reason
> behind this is because I'm building a complex application and it's just
> easier to maintain order with Pycharm. 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.
> 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.

Re: [beagleboard] Re: 16 bit SPI transfer possible with Python?

[David Good]

The problem is in the adafruit code itself, specifically lines 122 and 144:

https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/spimodule.c#L122

https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/spimodule.c#L144

The buffer they are using is an array of bytes (uint8_t) and then they
blindly cast each list object in the spi.xfer call to u8 (i.e. one byte).

In order to fix this, you would have to change this function to store both
the low byte and the high byte in the buf variable, probably depending on
the value of self->bpw.

If you did that, you would also have to figure out how to read 16bit values
as well.

Most likely, Your best option is to manually treat 16-bit values as two 8
bit values in your code and split or combine them as makes sense in your
application.

--David

On Thu, Mar 24, 2016 at 4:26 AM,  wrote:

> Hi,
> I encounter the same problem as you and i would like know if you had
> returns or if you had to find the solution to send more than 8 bits with
> this library ?
>
> thank you and good day
> Clément
>
>
> Le lundi 4 août 2014 00:36:16 UTC+2, bumin.h...@googlemail.com a écrit :
>>
>> Hello everybody,
>>
>> I am not sure if this is the correct place to post my problem. I am very
>> new to the
>> Beaglebone and embedded systems under Linux.
>>
>> I am currently trying to get a 16bit ADC running via SPI1 on my
>> Beaglebone Black.
>> My OS is Debian Wheezy with the  3.8.13 kernel. So far I have disabled
>> the HDMI
>> interface and got the spidev1.0 and spidev1.1 running. (Aside from my
>> actual
>> problem I am not sure what the last number represents.)
>>
>> I have shot wired the P9_29 and P9_30 pins to test the communication. My
>> program is written
>> in Python 2.7 and I am using the Adafruit_BBIO modul to control the  SPI
>>  (https://github.com/adafruit/adafruit-beaglebone-io-python). The SPI
>>  part of this module
>> seems to derive from the spidev module (
>> http://tightdev.net/SpiDev_Doc.pdf).
>>
>> When trying to send and receive one 16-bit word with the following code:
>>
>> import Adafruit_BBIO.SPI as SPI
>> print "Testing SPI: P9_29 and P9_30 need to be short wired"
>> spi = SPI.SPI()
>> spi.open(1,0)
>> spi.bpw = 16
>> print "Word length is : " + str(spi.bpw)
>> resp = spi.xfer([0x1234]) # transfer one word of two bytes length
>> print "Sending 0x1234 via xfer - receiving: " + str(resp)
>> spi.close() #close the port before exit
>>
>> I only receive 8 bit, being the 8 LBS "34". The same goes for the xfer2
>> method.
>>
>> Does somebody have any experience with this type of problem, or am I
>> missing something obvious?
>> Any help would be appreciated!
>>
>> Best Regards,
>> Bumin
>>
> --
> 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.

Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

[David Good]

Yes, I would love for someone to give me tips on setting up a periodic
timer interrupt.  What I have might be the only way to really do it, but I
would assume not.

Thanks for your tips on ghosting.  I will use it when I start to see real
data in the buffers rather than my simple test patterns.

About using SPI.  Yes, this is what I was doing on the Raspberry Pi, but
haven't done it on the Beaglebone yet.  I will definitely give it a shot.
Bit banging the clock and data looks like it's costing me ~1ms per row as
currently implemented.

On the topic of dedicated hardware offloading the workload, I suppose that
this is exactly what the PRUs are designed for.  Perhaps it's time to say
Hello World to one of them.  Since this is a personal project, there aren't
any real design requirements, so any option is open to me right now.  I was
planning to layout a PCB to clean things up a bit because right now I have
a hand soldered perf board with ribbon cables :)

Thanks for the suggestions!  Let's see if someone can answer about a kernel
timer interrupt.

--David

On Mon, Mar 21, 2016 at 6:07 PM, CEinTX  wrote:

> David,
>
> Without seeing your circuit of how you are setting up your rows & columns
> to be driven, I'll take a blind stab at your issue.
> To get rid of artifacts / ghosting / etc...
> 1) Shift out all your data
> 2) Turn off your drivers and row power if that is available
> 3) Delay ~20us
> 4) Latch the data into your drivers
> 5) Delay ~20us or more
> 6) Change your row address
> 7) Enable your outputs and/or row power
>
> You must have some dead time between rows or you will get artifacts /
> ghosting / whatever you choose to call it.
> You might get away with less than 20us but also you might need more
> depending on your circuit.
> Too much dead time and you will get flicker - not enough and you guessed
> it - artifacts/ghosting.
>
> For what it seems like you are doing, I'd use the SPI interface to shift
> out your data in blocks of 16-bits  - 9 xfers gets you 144 bits out.
> You obviously could bit bang this but why when you have built-in hardware
> that will do it for you. I'd think it would be fast enough in an ISR. I
> should think less than 250 us.
> Use the gpio for toggling your latch and output enable and addr/row select
> - these are low speed signals - so no problem
> There are definitely easier ways to do this with external hardware, but
> for this size matrix it would be a waste of $. Yes, a $1-2 cpld will do the
> trick - but then you need a pcb etc...
> Setup a periodic timer interrupt to sync your shifts / rows of data - take
> your refresh rate (suggest 55-80Hz to avoid flicker) & divide by # of rows
> (timer => 440 to 640 Hz / row)
> Use the time between interrupts to setup your next buffer for display
>
> Get someone here to help you with the timer/interrupt under Linux - I have
> no idea on that one. Would like to though - so maybe someone will respond
> with how to do that.
>
> Hope that helps.
>
> Good Luck,
> Matt
>
>>
>> --
> 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.

Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

[David Good]

Now here's where kernel space gets really weird.  I did actually mean
20milliseconds.  My first version of the LKM tried to use msleep(2), but
only got 6Hz total image refresh rate.  I measured the signals with a logic
analyzer and found that I was waking up every ~20ms. Totally confused, I
searched and found the answer here:

https://www.kernel.org/doc/Documentation/timers/timers-howto.txt

It turns out that msleep doesn't work for very low values of 'm' because
they use legacy timers rather than the new high resolution ones.

The GPIO can be toggled through back to back function calls at about 2us.

About waiting on "the buffer".  There are two buffers:
1> active row data
2> temporary buffer that is filled by dev_write calls from user-space.

The active row data buffer is never touched by user space, so no one ever
waits for it.  The temp buffer is only used to get new image data from user
space and once filled, is consumed by the update_row task.  Again, unless I
missed something, the update_row task is not affected.  My driver should be
getting multiple time slices of the CPU asynchronously during the time that
the dev_write routine is waiting.  But in actual use, I've never seen that
this wait ever happens since it is only triggered if user-space is somehow
able to write faster than my kernel thread can update the active row data.
My test pattern application only writes a new pattern every 1 second, so I
have been treating the LKM gently :)

I definitely will check out flattening the two dimensional array.  I didn't
think that it would really impact performance since I'm not dereferencing
it with multiple subscripts, but rather just passing buf[row] as a pointer
into the serializer function.  It probably would be easier to do effects
and transitions on a linear array, but I probably won't do too much of that
in the kernel module itself.  If the performance of writing to a character
device is good, I would prefer to do all image processing and buffer
manipulation in user space.  But, experimentation will have to guide me
there!

--David

On Mon, Mar 21, 2016 at 4:08 PM, William Hermans  wrote:

>
>>
>> *Hi William!*
>>
>>
>> *Good eyes, but I don't know if that will affect the row updates.  This
>> will affect user space programs trying to write to the character device and
>> introduce a delay returning from write request, but since the row updates
>> themselves are happening on a separate kthread, it shouldn't be possible to
>> disturb the critical timing.*
>> *I think that the delay actually produced by this call will be 1 "jiffy"
>> which I think is ~20ms or more, but I didn't think it mattered to make
>> user-space wait this amount of time.*
>>
>
> Hi David,
>
> About the only way I can think of to "accurately" test this. Would be to
> write a similar LKM that toggles a single GPIO, and watch the results with
> a scope or logic analyzer. So when you say ~20ms" be wary that "ms"
> typically means milliseconds, which you probably meant to mean microseconds.
>
> Again, I'm not sure of msleep() but it seems to be called every time the
> driver is waiting on the buffer. And I do not know how often this method in
> your  module is called, but that potential for latency from the sleep() and
> the big O nested loop situation . . . is your buffer really a two
> dimensional array ? I'd definitely look into changing that into possibly a
> linear field that can have bit ops done on it effectively.
>
>
>
> On Mon, Mar 21, 2016 at 1:55 PM, David Good  wrote:
>
>> Hi William!
>>
>> Good eyes, but I don't know if that will affect the row updates.  This
>> will affect user space programs trying to write to the character device and
>> introduce a delay returning from write request, but since the row updates
>> themselves are happening on a separate kthread, it shouldn't be possible to
>> disturb the critical timing.
>>
>> I think that the delay actually produced by this call will be 1 "jiffy"
>> which I think is ~20ms or more, but I didn't think it mattered to make
>> user-space wait this amount of time.
>>
>> --David
>>
>> On Mon, Mar 21, 2016 at 3:44 PM, William Hermans 
>> wrote:
>>
>>> So, I'm just now getting back to you, and I see you all have been
>>> discussing things I have not fully read about yet. Anyway I will say that I
>>> have zero hands on with LKM's, but I do have a decent amount of hands on
>>> with C in userspace. One thing that sticks out to me . . .
>>> https://github.com/davidgood1/ledmsgchar/blob/master/ledmsgchar.c#L359
>>>
>>> msleep(n) where 

Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

[David Good]

ramebuffer devices and see if I can learn
>> >> >anything there, but kernel programming is very new to me.
>> >>
>> >> Kernel programming (for microprocessors) is not all that bad, but
>> >> there are things you probably don't think of when writing kernel level
>> >> drivers and code.
>> >>
>> >> 1) everything is asynchronous
>> >> 2) this can be inconvenient
>> >> 3) lots of mechanisms exist to keep this from happening
>> >>
>> >> I'd be tempted to do the following approach:  Divide the scan time
>> >> into one slot per digit plus one.  Use that time to allow synchronized
>> >> refresh to the display itself.  You may need to limit the on time
>> >> depending on your sink current (per driver's data sheet).
>> >>
>> >> Assuming you use a semaphore, then while actively scanning digits, the
>> >> scanning process "owns" it.  During the update time, the scanning
>> >> process gives it back.  The update process can grab that, then can
>> >> update all the ram buffers that the scanning process uses.  The update
>> >> process then gives back the semaphore and the scanning process can
>> >> grab it again during the next scan time.  Result: display does all RAM
>> >> updates while blanked.
>> >>
>> >> Now for the scan itself.  Assuming the scan time has just happened,
>> >> you may want to disable task switching.  shift in the new data, switch
>> >> the row drivers off, then latch the column data, then enable the new
>> >> row drivers.  Since darlingtons are slow, I'd be looking at the
>> >> driving waveforms for the darlington outputs to the display for any
>> >> overlap.  Shouldn't be much, though, if any.  Some software delays of
>> >> a few microseconds may be needed.  At this point, enable task
>> >> switching for the OS and you're in good shape.
>> >>
>> >> The problem with multiplexed displays run directly by a microprocessor
>> >> is debugging during the scan cycle, where the average display current
>> >> can exceed the steady state limits for the display.  I'd have been
>> >> tempted to put in a small CPLD which appears as external registers to
>> >> the processor, and then allow the hardware to do all the work.  Xilinx
>> >> coolrunner II 32 or 64 cell chips are cheap, 3.3 volt I/O, and need
>> >> (IIRC) 1.5 volts.  Not too bad and the display stays happy.
>> >>
>> >> Harvey
>> >>
>> >> >
>> >> >Thanks for your feedback!
>> >> >
>> >> >--David
>> >> >
>> >> >
>> >> >On Mon, Mar 21, 2016 at 9:40 AM, Harvey White > >
>> >> >wrote:
>> >> >
>> >> >> On Mon, 21 Mar 2016 01:20:34 -0500, you wrote:
>> >> >>
>> >> >> I've often seen artifacts in LED displays where the write to the
>> >> >> display process (which should be amazingly short for each digit) is
>> >> >> interrupted.  You might be seeing some differences in digit
>> brightness
>> >> >> as well.
>> >> >>
>> >> >> Once you have the pattern in Ram, ready to be written, you would
>> >> >> ideally update right at the beginning of each scan for each digit.
>> You
>> >> >> want to make sure that the pattern is not updated during the active
>> >> >> strobe to display process as well.  (I'm assuming that there's a
>> >> >> hardware latch in there that you write, and you're not depending on
>> >> >> the output pins to be constant, that strobe to activate the display
>> is
>> >> >> also a latch).  This approach would minimize the critical time where
>> >> >> the display data cannot be interfered with.  This would ideally be
>> in
>> >> >> the microsecond range (i.e. turn off previous strobe, load next
>> data,
>> >> >> turn on this strobe).  That part of the code cannot be interrupted
>> and
>> >> >> should ideally protected by turning interrupts off during those few
>> >> >> instructions.
>> >> >>
>> >> >> So the first question to ask is "what's going on with the strobes
>> and
>> >> >> data?"
>> >> >>
>

[beagleboard] Remove graphical desktop packages from Debian image

[David Good]

I'm totally out of space (100%) disk usage on my Debian image flashed to a
4GB SD card for a Beaglebone White.  Is there an easy way to remove all of
the desktop oriented packages for users who are using these in a headless
maner?

I started to poke around the installed packages with various dpkg -l
scripts, but was wondering if such a collection already existed (on a wiki
somewhere?).

Thanks!

--David

-- 
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] Driving a Multiplexed LED matrix directly from gpio

[David Good]

es
> its
> >> >timing by calling usleep_range() which is supposed to be backed by high
> >> >resolution timers.  I am using the same number on the upper and lower
> >> >bounds to try and force stricter timing and because when I did +/- 10%
> you
> >> >could definitely see more visual artifacts.
> >> >
> >> >Also, you will notice that the strobe pin is toggled high and then
> >> >immediately low, which I've measured to be about 2us.  So, that seems
> to
> >> be
> >> >the best the gpio interface can do.
> >> >
> >> >Thanks!
> >> >
> >> >--David
> >> >
> >> >On Sun, Mar 20, 2016 at 11:03 PM, William Hermans 
> >> wrote:
> >> >
> >> >> OK so yes, seeing your code would help us understand what you're
> >> >> bottleneck but I've a pretty good idea why you're LCD matrix refresh
> is
> >> so
> >> >> slow. It has to do with userspace communicating with kernel space,
> and
> >> >> you're either invoking some system API calls ( which are notoriously
> >> slow
> >> >> ), or you're copying data from userspace to kernel space, which
> again is
> >> >> slow.
> >> >>
> >> >> The reason I said to show us some code above however is that I think
> it
> >> >> *should* be possible to use /dev/mem/ + mmap() to access whatever
> you're
> >> >> controlling. Using mmap() in this manner gives you no userspace to
> >> kernel
> >> >> overheard . . . but again I need to see some relevant code to give
> you a
> >> >> better idea how that might work.
> >> >>
> >> >> On Sun, Mar 20, 2016 at 8:58 PM, William Hermans 
> >> >> wrote:
> >> >>
> >> >>> Show us some code.
> >> >>>
> >> >>> On Sun, Mar 20, 2016 at 6:28 PM, David Good 
> >> >>> wrote:
> >> >>>
> >> >>>> Hi All,
> >> >>>>
> >> >>>> I've been experimenting with embedded linux and matrixed LED
> displays.
> >> >>>> I started on a Raspberry pi user space program, but could see
> visual
> >> >>>> artifacts on the display due to inconsistent timing of my sleep
> >> command.
> >> >>>> So, I figured that moving the basic row scanning into the kernel
> >> would help
> >> >>>> out.  After failing to get the right kernel headers for the pi, I
> >> switched
> >> >>>> to a BeagleBone White.  I've now got a working character device LKM
> >> which
> >> >>>> takes new images by writing ASCII formatted hex strings to the
> device
> >> in
> >> >>>> /dev.  The performance is pretty good, but not great.  I still see
> >> visible
> >> >>>> artifacts, but am playing with things.
> >> >>>>
> >> >>>> My basic question is this: I know that Linux is not a RTOS, so
> timing
> >> >>>> will never be guaranteed, yet linux does a lot of things very
> quickly
> >> >>>> (video, audio, i2c, etc).  My driver is bit-banging a spi like
> stream
> >> over
> >> >>>> 8 rows at a rate of ~3ms per row (333Hz row scanning or ~41Hz per
> >> complete
> >> >>>> frame) and is really struggling.  How does linux usually get large
> >> smooth
> >> >>>> video at over 60FPS while doing other things???  Is it simply
> taking
> >> >>>> advantage of special hardware resources?
> >> >>>>
> >> >>>> The obvious solution for this display is to use a little 8051 or M0
> >> >>>> microcontroller (or PRU!) and let the Bone feed it over uart or
> >> something,
> >> >>>> but I really thought I could do better with the LKM.
> >> >>>>
> >> >>>> Am I just doing something totally wrong?  Any other ideas?
> >> >>>>
> >> >>>> Thanks!
> >> >>>>
> >> >>>> --David
> >> >>>>
> >> >>>> --
> >> >>>> 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.
> >> >>
> >>
> >> --
> >> 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.
>

-- 
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] Terminal Block Wiring Options

[David Good]

It sounds like a good idea!  At a minimum you should add some kind of
buffering to the signals as Jacek suggested.  This can be opto-isolators,
signal buffers, or logic-level converters.  It really depends on how
"industrial" you are trying to be.  Is this a one-off, or are you trying to
make several?

I have made a cape before, and I found that the bone fits best "upside
down".  If you think about it that way,  the "cape" can be a much larger
rectangle with all kinds of things broken out, power jacks added, XBEE
footprint for RF, etc.  Plus, you can probably fit something like that into
a project box much easier.

Look at this one:
http://elinux.org/Beagleboard:BeBoPr-Plus

Alternately, you could get into the "Grove" ecosystem over at Seeed Studios
if you are wanting to cobble together a more modular solution rather than
designing your own PCB.

http://www.seeedstudio.com/depot/Grove-Cape-for-BeagleBone-Series-p-1718.html

--David


On Thu, Mar 17, 2016 at 7:44 PM, Jacek Radzikowski <
jacek.radzikow...@gmail.com> wrote:

> It looks like the terminal blocks should be the least of your worries
> at the moment. To have "industrial strength" system, you should never,
> ever connect wires directly to the pins of the processor. For each
> digital input and output you should add at least transistor driver
> separating the outside circuit from the board, with optoisolation if
> possible. Analog inputs and outputs should also be buffered. It would
> be good to add voltage spike protections (diodes, transils) on each of
> the lines.
> Optoisolation and spike protection will add ruggedness to your system,
> however without proper buffering of the signals, most likely you will
> fry the board in no time.
>
> Regards,
> Jacek.
>
>
> On Thu, Mar 17, 2016 at 8:07 PM,   wrote:
> > Hey guys,
> >
> > I'm currently designing a greenhouse automation control unit utilizing
> the
> > BBB as the brain.  In order to create industrial strength wiring I'd
> like to
> > use terminal block connections to each connector on the P8 and P9
> headers.
> >
> > To give you a visual of what I'd like to do check out a picture of the
> > terminal block shield for the Arduino Mega.  It plugs into the board
> nicely
> > and the terminal blocks lay along perimeter of the shield giving the user
> > access to each input.
> >
> > I'm also open to other ideas regarding how to wire up a BBB in a reliable
> > way suitable for industrial purposes.
> >
> > What do you think?
> >
> >
> > The information contained in this transmission contains potentially
> > privileged, export controlled and/or confidential information of
> Imageware
> > Systems, Inc. or its customers or partners.  It is intended only to be
> read
> > by the person(s) named above and for no other purpose.  You are hereby
> > notified that any dissemination, distribution, duplication of this
> > communication or use of its contents for any purpose not authorized
> > expressly by Imageware Systems, Inc. is strictly prohibited and could
> lead
> > to both civil and/or criminal penalties.  If you are not the intended
> > recipient, you are prohibited to review the contents herein and please
> > contact the sender by reply e-mail and destroy all copies of the original
> > message.  To reply to our e-mail administrator directly, please send an
> > e-mail to emailad...@iwsinc.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.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Given a choice between two theories, take the one which is funnier
>
> --
> 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.

Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

[David Good]

6 at 11:03 PM, William Hermans 
> wrote:
> >
> >> OK so yes, seeing your code would help us understand what you're
> >> bottleneck but I've a pretty good idea why you're LCD matrix refresh is
> so
> >> slow. It has to do with userspace communicating with kernel space, and
> >> you're either invoking some system API calls ( which are notoriously
> slow
> >> ), or you're copying data from userspace to kernel space, which again is
> >> slow.
> >>
> >> The reason I said to show us some code above however is that I think it
> >> *should* be possible to use /dev/mem/ + mmap() to access whatever you're
> >> controlling. Using mmap() in this manner gives you no userspace to
> kernel
> >> overheard . . . but again I need to see some relevant code to give you a
> >> better idea how that might work.
> >>
> >> On Sun, Mar 20, 2016 at 8:58 PM, William Hermans 
> >> wrote:
> >>
> >>> Show us some code.
> >>>
> >>> On Sun, Mar 20, 2016 at 6:28 PM, David Good 
> >>> wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> I've been experimenting with embedded linux and matrixed LED displays.
> >>>> I started on a Raspberry pi user space program, but could see visual
> >>>> artifacts on the display due to inconsistent timing of my sleep
> command.
> >>>> So, I figured that moving the basic row scanning into the kernel
> would help
> >>>> out.  After failing to get the right kernel headers for the pi, I
> switched
> >>>> to a BeagleBone White.  I've now got a working character device LKM
> which
> >>>> takes new images by writing ASCII formatted hex strings to the device
> in
> >>>> /dev.  The performance is pretty good, but not great.  I still see
> visible
> >>>> artifacts, but am playing with things.
> >>>>
> >>>> My basic question is this: I know that Linux is not a RTOS, so timing
> >>>> will never be guaranteed, yet linux does a lot of things very quickly
> >>>> (video, audio, i2c, etc).  My driver is bit-banging a spi like stream
> over
> >>>> 8 rows at a rate of ~3ms per row (333Hz row scanning or ~41Hz per
> complete
> >>>> frame) and is really struggling.  How does linux usually get large
> smooth
> >>>> video at over 60FPS while doing other things???  Is it simply taking
> >>>> advantage of special hardware resources?
> >>>>
> >>>> The obvious solution for this display is to use a little 8051 or M0
> >>>> microcontroller (or PRU!) and let the Bone feed it over uart or
> something,
> >>>> but I really thought I could do better with the LKM.
> >>>>
> >>>> Am I just doing something totally wrong?  Any other ideas?
> >>>>
> >>>> Thanks!
> >>>>
> >>>> --David
> >>>>
> >>>> --
> >>>> 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.
> >>
>
> --
> 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.

Re: [beagleboard] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

[David Good]

I'm sorry to hear the frustration Karl, but actually I'm on the other arc:
Pi to BeagleBone.  The Pi has a lot going for it, but I get the feeling
it's trying to craft an Arduion-like experience.  That's great for messing
around, but my experience was that as soon as you leave the well worn path,
you realize that the edges are a bit guarded.  That might be putting it a
little strongly, but I couldn't figure out how to get the correct kernel
headers for the stock image to try and create LKMs.

--David

On Sun, Mar 20, 2016 at 10:32 PM, evilwulfie  wrote:

> Reading this made me laugh.
>
>
>
>
> On 3/20/2016 3:49 PM, William Hermans wrote:
>
> *Trying to update the flash to Debian 8.3 and initially I get the back and
>> forth Knight Rider pattern. Then, after a bit I get just 4 double blink
>> leds every half second or so. Looks like a few others have seen this, but
>> no conversation around the issue or possible solutions.*
>>
>> *My raspberry pi's work just fine, and when I do have a problem I can
>> find answers fairly quickly.*
>>
>> *It's clear that the BBB is a dead product. There is no meaningful
>> resources for issues, and when the system simply won't 'reset from a new
>> image from their site'... that's the last straw.*
>>
>> *Mine are going in the trash and I will advise anyone everywhere to do
>> the same.*
>>
>
> If that's the mentality you're going to take, then I say don't let the
> door hit you in the ass on your way out . . .But it is in no way the fault
> or responsibility of anyone in this community that *you* have problems with
> customizing your software. You had a working image on it when it shipped to
> you, you take responsibility when you attempt to customize the software.
>
> On Sun, Mar 20, 2016 at 1:34 PM, Peter Lawler 
> wrote:
>
>>
>> On 21 Mar 2016 06:28, "Karl Easterly" < 
>> k.s.easte...@gmail.com> wrote:
>>
>> > Mine are going in the trash
>>
>> Seriously?
>>
>> Don't trash em. Send em to me. Email me your details and I'll pay for
>> shipping if you like.
>>
>> PO Box 195
>> Lindisfarne
>> Tasmania
>> AUSTRALIA 7015
>>
>> P.
>> --
>> 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.
>
>
> --
> 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.

Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

[David Good]

Ok, I posted the full source code here:
https://github.com/davidgood1/ledmsgchar

I'm not sure that userspace has much to do with what I'm seeing right now.
I'm using a kthread that runs until a flag is set indicating that there is
a new buffer of data ready from user space and my task (update_row) copies
the buffer, so no one should be waiting on slow user space operations, but
maybe there's something I don't see.

I didn't know if I was getting interrupted in the memcpy call in
update_row, so I am going to try to copy the buffer by rows one call at a
time rather than copy the whole buffer at once.

Also, I notice that I see visual artifacts whenever anything else is going
on, such as ssh, typing on the terminal, etc.  The CPU usage is ~3% using
the timing in the file right now.  BTW, the update_row task regulates its
timing by calling usleep_range() which is supposed to be backed by high
resolution timers.  I am using the same number on the upper and lower
bounds to try and force stricter timing and because when I did +/- 10% you
could definitely see more visual artifacts.

Also, you will notice that the strobe pin is toggled high and then
immediately low, which I've measured to be about 2us.  So, that seems to be
the best the gpio interface can do.

Thanks!

--David

On Sun, Mar 20, 2016 at 11:03 PM, William Hermans  wrote:

> OK so yes, seeing your code would help us understand what you're
> bottleneck but I've a pretty good idea why you're LCD matrix refresh is so
> slow. It has to do with userspace communicating with kernel space, and
> you're either invoking some system API calls ( which are notoriously slow
> ), or you're copying data from userspace to kernel space, which again is
> slow.
>
> The reason I said to show us some code above however is that I think it
> *should* be possible to use /dev/mem/ + mmap() to access whatever you're
> controlling. Using mmap() in this manner gives you no userspace to kernel
> overheard . . . but again I need to see some relevant code to give you a
> better idea how that might work.
>
> On Sun, Mar 20, 2016 at 8:58 PM, William Hermans 
> wrote:
>
>> Show us some code.
>>
>> On Sun, Mar 20, 2016 at 6:28 PM, David Good 
>> wrote:
>>
>>> Hi All,
>>>
>>> I've been experimenting with embedded linux and matrixed LED displays.
>>> I started on a Raspberry pi user space program, but could see visual
>>> artifacts on the display due to inconsistent timing of my sleep command.
>>> So, I figured that moving the basic row scanning into the kernel would help
>>> out.  After failing to get the right kernel headers for the pi, I switched
>>> to a BeagleBone White.  I've now got a working character device LKM which
>>> takes new images by writing ASCII formatted hex strings to the device in
>>> /dev.  The performance is pretty good, but not great.  I still see visible
>>> artifacts, but am playing with things.
>>>
>>> My basic question is this: I know that Linux is not a RTOS, so timing
>>> will never be guaranteed, yet linux does a lot of things very quickly
>>> (video, audio, i2c, etc).  My driver is bit-banging a spi like stream over
>>> 8 rows at a rate of ~3ms per row (333Hz row scanning or ~41Hz per complete
>>> frame) and is really struggling.  How does linux usually get large smooth
>>> video at over 60FPS while doing other things???  Is it simply taking
>>> advantage of special hardware resources?
>>>
>>> The obvious solution for this display is to use a little 8051 or M0
>>> microcontroller (or PRU!) and let the Bone feed it over uart or something,
>>> but I really thought I could do better with the LKM.
>>>
>>> Am I just doing something totally wrong?  Any other ideas?
>>>
>>> Thanks!
>>>
>>> --David
>>>
>>> --
>>> 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.
>

-- 
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] Driving a Multiplexed LED matrix directly from gpio

[David Good]

Hi All,

I've been experimenting with embedded linux and matrixed LED displays.  I
started on a Raspberry pi user space program, but could see visual
artifacts on the display due to inconsistent timing of my sleep command.
So, I figured that moving the basic row scanning into the kernel would help
out.  After failing to get the right kernel headers for the pi, I switched
to a BeagleBone White.  I've now got a working character device LKM which
takes new images by writing ASCII formatted hex strings to the device in
/dev.  The performance is pretty good, but not great.  I still see visible
artifacts, but am playing with things.

My basic question is this: I know that Linux is not a RTOS, so timing will
never be guaranteed, yet linux does a lot of things very quickly (video,
audio, i2c, etc).  My driver is bit-banging a spi like stream over 8 rows
at a rate of ~3ms per row (333Hz row scanning or ~41Hz per complete frame)
and is really struggling.  How does linux usually get large smooth video at
over 60FPS while doing other things???  Is it simply taking advantage of
special hardware resources?

The obvious solution for this display is to use a little 8051 or M0
microcontroller (or PRU!) and let the Bone feed it over uart or something,
but I really thought I could do better with the LKM.

Am I just doing something totally wrong?  Any other ideas?

Thanks!

--David

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