yona-appletree / ledscape Goto Github PK

Hi there! First of all, thanks so much for supporting this project.

I'm trying to compile and install the LEDscape project as per instructions. I have a Beaglebone Green running the latest Wheezy 7.11 Debian build. I've checked out the LEDscape project, set the executable bit on the install-software.sh script, and attempted to run the script. It gets the following failure when running the make command:

debian@beaglebone:~/LEDscape$ sudo ./install-software.sh
Making ledscape...
gcc -std=c99 -W -Wall -D_DEFAULT_SOURCE -Wp,-MMD,./.opc-server.o.d -Wp,-MT,opc-server.o -I. -O2  -g -lm -mtune=cortex-a8 -march=armv7-a -Wunused-parameter -DNS_ENABLE_IPV6 -Wsign-compare -Werror -Wno-unknown-pragmas -I./am335x/app_loader/include -c -o opc-server.o opc-server.c
In file included from opc-server.c:27:0:
lib/cesanta/frozen.h:38:3: error: unknown type name 'uint'
opc-server.c: In function 'demo_mode_from_string':
opc-server.c:146:2: error: implicit declaration of function 'strcasecmp' [-Werror=implicit-function-declaration]
opc-server.c: In function 'main':
opc-server.c:719:2: error: implicit declaration of function 'bzero' [-Werror=implicit-function-declaration]
opc-server.c: In function 'server_config_from_json':
opc-server.c:1018:59: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1018:59: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1022:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1022:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1027:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1027:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1032:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1032:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1037:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1037:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1042:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1042:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1047:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1047:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1052:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1052:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1057:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1057:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1062:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1062:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1067:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1067:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1072:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1072:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1077:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1077:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1082:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1082:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c: In function 'rotate_frames':
opc-server.c:1286:3: error: implicit declaration of function 'timersub' [-Werror=implicit-function-declaration]
opc-server.c: In function 'render_thread':
opc-server.c:1334:4: error: implicit declaration of function 'usleep' [-Werror=implicit-function-declaration]
opc-server.c: In function 'join_multicast_group_on_all_ifaces':
opc-server.c:1782:29: error: 'IFF_LOOPBACK' undeclared (first use in this function)
opc-server.c:1782:29: note: each undeclared identifier is reported only once for each function it appears in
opc-server.c:1783:29: error: 'IFF_POINTOPOINT' undeclared (first use in this function)
opc-server.c:1784:28: error: 'IFF_MULTICAST' undeclared (first use in this function)
opc-server.c:1787:19: error: storage size of 'multicast_req' isn't known
opc-server.c:1787:19: error: unused variable 'multicast_req' [-Werror=unused-variable]
opc-server.c: In function 'e131_server_thread':
opc-server.c:1905:7: error: 'uint' undeclared (first use in this function)
cc1: all warnings being treated as errors
make: *** [opc-server.o] Error 1
Making backups of old device tree files...
mkdir: cannot create directory `/boot/dtbs/3.8.13-bone80/ledscape.bak': File exists
Copying new device tree files...
Copying config file to /etc
Leaving existing /etc/ledscape-config.json intact.
Enabling kernel module...
Done. Please enter reboot to reboot the machine and enable changes.
debian@beaglebone:~/LEDscape$

Any idea what's going on? Should I not be relying on the stock compiler packaged with the BBB Debian images?

Would appreciate any advice. Thanks!

Apologies if this isn't the best place for this question; I can't find anywhere else...
Does LEDScape use both PRUs or is it possible to select one or the other? I'm trying to use this code along with the Bela audio hood which uses one of the PRUs itself.

I'm using LEDscape to drive just a handful of ws281x LEDs and I'm seeing a CPU usage of about 40%. Is it possible to limit the fps? I don't really need 3k updates per second :)

[render] fps_info={frame_avg_usec: 301, possible_fps: 3322.26, actual_fps: 3185.30, sample_frames: 31853}

Hey I found a patch in the osresearch issues:

osresearch#6
mikelikespie@64311c1

I'm going to test later ... but I thought I'd share now.

Hi. Thanks for all the hard work on this!

I'm trying to understand how to connect a single NeoPixel string. Mostly at this moment I'm trying to figure out which pins to reserve in my cape design. But reading the readme, it's not at all obvious. It says if I'm not using the LEDscape cape to refer to the Pin Mapping section below (btw, it's above), but that doesn't really help at all.

Also, it seems like node.js is required to use it? Is that true? I'm only interested in calling it from C (C++), but it seems that I have to use node.js to configure it. Hard to tell for sure.

I'd really appreciate some guidance. I'm just using a NeoPixel 24 ring as a backlight in a box.

Thanks!

Upon further testing of the APA102 support I'm getting a problem with this template on the last pixel of each strip.

When set to black the last pixel of each strip will glow dimly red. I've tried a whole bunch of various potential fixes and cannot get this to stop happening. I'm not sure if its just my setup or my LEDs or something, can someone else confirm?

There is no license listed for the codebase. Under which license(s) is this project released? Could a 'COPYING' file be added for clarity? Thanks in advance

While the vast, vast majority of 0 bits coming out of the PRU are 300ns-370ns wide, I am seeing a very rare case where a 0 bit can be as wide as 540ns, which is wide enough to be seen as a 1 by some WS2812B chips.

When the problem happens, it seems to stretch all output bits being transmitted at that moment, although there is only material impact on 0 bits since 1 bits just become slightly longer 1 bits.

Outwardly, this appears as a row of pixels flashing for a single frame. It is especially noticeable when running strings in demo mode "black" when all bits should be 0. It is possible this is only visible on WS2812B chips with a shorter-than-spec T1H minimum time.

I verified the problem by attaching a scope to an output and setting to trigger on minimum pulse width of 450ns. Then I ran the "black" demo mode. In this mode, all bits should be 0 so I should never see a pulse wider than 450ns. Yet I was (rarely) able to capture pulses as wide as 540ns.

The stretched bits seem to happen more frequently when the ARM is under heavy memory stress so I think this might be caused by a worst-case series of cache misses when the PRU accesses the data in ARM RAM.

The current approach of timing the bit phases uses the cycle counter. Is it possible that the cycle counter does not not count cycle where the PRU is stalled because it is waiting for a cache miss when reading external RAM? The STALL COUNT register possibly indicates this...

STALLCOUNT
This value is incremented by 1 for every cycle during which the PRU
is enabled and the counter is enabled (both bits ENABLE and
COUNTENABLE set in the PRU control register), and the PRU was
unable to fetch a new instruction for any reason.

Possible solutions might include...

1. Rearrange current code so that all of the accesses to external RAM occur between bits rather than during the T0H phase of the bits. This would still add jitter to the time between bits when cache misses occur, but as long as this time is less than RESET, then the only impact should be (very) slightly diminished performance rather than bad data.
2. Rewrite PRU code to copy pixel data into PRU RAM first and then transmit the bits directly from local PRU RAM during the timing sensitive frame.
3. Rewrite the PRU code to use the IEP_TIMER to time the signal phases rather than the cycle counter. The IEP_COUNTER seems to be able to run deterministicly at 200MHz no matter what is happening with PRU accesses.

I can try to tackle either of these approaches, but just want a sanity check before doing the work. Has anyone else ever seen these wide bits (or the flashes they produce)?

I've been trying to get ledscape to work on the Beaglebone green wireless.
(It's a BB with 2 seeed connectors plus wifi/Bluetooth - minus the Ethernet and HDMI)
I used the lts kernel and debian jessie (since the BBG-W isn't supported on earlier builds)
update_kernel.sh --bone-rt-kernel --lts-4_4
I also used
bash patch_dts.sh /boot/dtbs/$(uname -r)/am335x-bonegreen-wireless.dtb
to generate a suitable dtb
This nearly works - but I get the following error message :
pru_gpio:173: /sys/class/gpio/gpio26/value: Unable to open? No such file or directory

As far as I can tell this is because the BBG-W steals 2 gpios to enable/disable the Bluetooth and wifi chips - the schematic seems to indicate they are: GPIO0_26 (WIFI) and GPIO1_28 (BT)

I don't need 48 lines - is there an easy way to reduce the GPIO needs and exclude these 2
from LEDScape's use? (Say disabling a PRU?)

Aim: Control WS2812B Led Strip with BeagleBone Black.

I find a number of resources that link to your repo and your contribution are the main part to direct me to fill with me to aim.

thank you.

Why do I see a lot of flickering when I activate dithering with 8 string * 100 pixels and it becomes much better when I change it to 48 strings * 100 pixels?

I'm working on a large POV display that currently uses LEDscape with a bunch of ws2812 led strips (http://beagleboard.org/blog/2013-12-17-project-spotlight-orbital-rendersphere/). I'm trying to increase the resolution of the display, which also means considerably increasing the frame rate. I was hoping to use LEDscape in conjunction with some apa102 strip to be able to refresh all of the pixels in my display at the higher rates I need, but it looks like LEDscape is actually driving the apa102 strips slower than ws281x strip of the same length. Here is representative output from running opc-server with a ws281x config and an apa102 config using the same number of pixels:

ws281x, 17 pixels, no interpolation, dithering:
[render] fps_info={frame_avg_usec: 745, possible_fps: 1342.28, actual_fps: 1335.50, sample_frames: 13355}

apa102, 17 pixels, no interpolation, no dithering:
[render] fps_info={frame_avg_usec: 792, possible_fps: 1262.63, actual_fps: 1256.60, sample_frames: 12566}

However I actually want to have longer runs of apa102 leds than I had of ws2812s. But then performance gets even worse:

apa102, 41 pixels, no interpolation, no dithering:
[render] fps_info={frame_avg_usec: 1836, possible_fps: 544.66, actual_fps: 543.40, sample_frames: 5434}

The comment at the top of apa102.p says that it is pushing data to the strips as fast as it can, which it indicates is about 1.6mhz. I've seen numerous other references from people who are able to run apa102 strip at much higher rates however. Is there something that can be done to increase the frame rate for apa102? Or is there some limitation with LEDscape at work here?

I am getting this error when doing a clean make after checking out this branch. Maybe some files are missing?

  - Building permutation for mapping original-ledscape
    - Generating mapping headers...

module.js:340
    throw err;
          ^
Error: Cannot find module 'strip-json-comments'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/root/LEDscape/pru/pinmap.js:1:87)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
make: *** [pru/generated/apa102.template] Error 255

This results in this error when trying to run opc-server

root@beaglebone:~/LEDscape# ./opc-server --mapping rgb-123-v4
main:706: ERROR: Configuration failed validation:
{
        "errors": [
                "Invalid mapping and/or mode name; cannot access PRU 0 program 'pru/bin/ws281x-rgb-123-v4-pru0.bin'",
                "Invalid mapping and/or mode name; cannot access PRU 1 program 'pru/bin/ws281x-rgb-123-v4-pru1.bin'"
        ],
        "valid": false

First off, thank you for this project! It has been incredibly useful for a project I'm working on.

I just updated to the latest commit (from a version in September).

I was a bit dismayed I had to pass a pixel ordering on every call to ledscape_pixel_set_color(). Is there a good reason to add this flexibility? Shouldn't any code that calls it just pass the colors in the predetermined order? And if it is necessary, then why not just make it a macro #define, does it really need to be set at runtime? And even if it is set at runtime, why not just pass it once on init?

That being said, perhaps it is something I changed, but for some reason my color order for COLOR_ORDER_RGB is GRB (IIRC), while setting COLOR_ORDER_GBR worked just fine. What is very odd is that I don't see any issues with the case statement that sets the color order in ledscape.c. Can you confirm that you do not have this issue?

Hi,
I've tried the defaul config "ws281x" with a strip of 5vdc WS2812B and everything was fine.
Then I've replaced the strip with a 12Vdc WS2811 with one chip driving 3 led and the strip turns on but doesn't respond correctly to signals.

this is how I've wired the WS2811:

12vdc power supply( + ) ---------------- STRIP (+)
12vdc power supply( - ) -----------------STRIP (-)
STRIP( DI ) ---------------- level shifter (H1)

5vdc power supply( + ) ---------------- level shifter (H)
5vdc power supply( - ) ----------------- com (-)

3V3 BEAGLEBONE ---------- level shifter (L)
CHANNEL0 PIN ---------------level shifter (L1)

every help is really appreciated, BR

I've got a Beaglebone Black running Debian 10.3. When I run 'make' to build the opc-server, it's failing thusly:

opc-server.c: In function ‘opc_server_set_error.part.1’:
opc-server.c:211:3: error: invalid use of ‘__builtin_va_arg_pack ()’
snprintf(
^~~~~~~~~
extra_info_out,
~~~~~~~~~~~~~~~
sizeof(extra_info_out),
~~~~~~~~~~~~~~~~~~~~~~~
extra_info,
~~~~~~~~~~~
__builtin_va_arg_pack()
~~~~~~~~~~~~~~~~~~~~~~~
);

I'm running the stock kernel 4.19.94. GCC is version 8.3.0-6.

There are also a bunch of warnings beforehand. Any suggestions on how to fix this?

Hi,

I want to use the BBB for powering in total 50Meters of LED stripes, seperatated in 10 parts with different lenghts which are not arragend in a Matrix. The longest has a total amount of 720 single LEDs.

I've worked with Processing and figured out, that there is a 64 LED limitation, which comes from the fadecandy implemtation. Is there any way, to use all capabilities (more than 64 LEDs per Channel) of the BBB with Processing?

Furthermore i made some experiments with shell comands to the opc - server and i could not get it to work. It shows always the demo pattern which i can not change.

You mentioned that there is a documentation available. Do you mean your readme.md in github? Unfortunatly i could only get the BBB to work with the demo pattern, and with your readme.md i could not find the failure i made.

Regards
Andreas

hi,

i got things working nicely on the BeagleBone Black Rev C. i tested the opc-server and it works as well. now i face a little confusion: i want to scale this massively, so tried to run

./opc-server -p 7890 -c 512
main:279: [main] 512 pixels cannot fit in a UDP packet.

looking at that code, 512_48_3 indeed is more than the 65k max size of UDP. what are the options? could i disable UDP and use TCP only? is the OPC protocol using TCP and could do without UDP? if so, i can do a PR to have an option to disable UDP and hint that if the check fails.

another question: can i disable opc-server going into demo mode with a configuration option or do i need to change the source code to achieve that?

I've been working with macetech's octobar's for a couple years and have been searching for a replacement for my software bitbanging for a while. Would adding support for the A6281 be a good fit for the project?

I'd love to get some of my lantern displays using LEDscape

Hi, I'm trying to control a 4x4 RGB LED Matrix WS2812 through beaglebone black and I'm able to run the opc server in demo mode i.e., all 16 LEDs fade with changing colour.

Now I'm finding it hard to go forward i.e., to control individual LEDs:
How does one control a single LED (the LED matrix that I'm using just uses 1 BB pin PWM/P9.14 and all LEDs are in a series so I assume it's just one strip).

I am trying to use the fadecandy python library to connect to the opc server. Although the connectino is successful, the pixels that I send to the server are not showcased on the LEDs.

TL;DR: I'm trying to send pixels to the opc server but despite having connection, the pixels aren't put on the LEDs (all LEDs shutdown and I see one LED flicker once in a while).

Any example code of sending pixels to opc-server would be appreciated

When running install_software.sh, I receive this fatal error:

opc-server.c: In function ‘opc_server_set_error.part.1’:
opc-server.c:211:3: error: invalid use of ‘__builtin_va_arg_pack ()’
   snprintf(
    extra_info_out,
    sizeof(extra_info_out),
    extra_info,
    __builtin_va_arg_pack()
   );
make: *** [Makefile:93: opc-server.o] Error 1

BeagleBone Black
Debian 10.3

https://groups.google.com/d/msg/beagleboard/GANFPr7BtVo/ubCbAW2cSysJ

Hi, thought I'd cross post here as I imagine some of you have the same issue. Anyone here found a slim console only image with Debian (or Ubuntu) that plays well with LEDscape?

The latest installation docs don't work for new installations of Debian Jessy(tested with the 2016-01-24 image). Not only is the dtbs location different(which the docs do cover), but TI introduced a new version of the 4.1 kernel(see this) which changes the API for accessing the PRUSS. This causes the modprobe uio_pruss step to fail.

The solution is to execute the following before copying the modified am335x-boneblack.dtb file:

cd /opt/scripts/tools
./update_kernel.sh --bone-rt-kernel --lts-4_1
reboot

However, from this point on, I receive segmentation faults when running LEDscape.

root@ledscape:~/LEDscape# ./run-ledscape 
tokens: 381: {
    "outputMode": "ws281x",
    "outputMapping": "rgb-123-v2",
    "demoMode": "power",
    "ledsPerStrip": 30,
    "usedStripCount": 23,
    "colorChannelOrder": "BRG",
    "opcTcpPort": 7890,
    "opcUdpPort": 7890,
    "enableInterpolation": true,
    "enableDithering": true,
    "enableLookupTable": true,
    "lumCurvePower": 2.0000,
    "whitePoint": {
        "red": 0.9000,
        "green": 1.0000,
        "blue": 1.0000
    }
}

Loaded config file from ws281x-config.json.
Config file written to ws281x-config.json
[main] Starting server on ports (tcp=7890, udp=7890) for 30 pixels on 48 strips
[main] Demo Mode Enabled
Starting demo data thread
[e131] Starting UDP server on port 5568
[udp] Starting UDP server on port 7890
Segmentation fault

Do you have any plans to support websockets as a control protocol the way that Fadecandy boards do?

The 2014-11-11 image has moved the dtbs directory. Here's how I install

echo -----COPYING DTB FILES -----
DTBS=/boot/dtbs/uname -r
cp $DTBS/am335x-boneblack.dtb{,.preledscape_bk}
cp am335x-boneblack.dtb $DTBS

--Mark

Hi-
Are there any tricks to using e131 input vs OPC? I thought I had it working once before but now the only LED output I see is all off. The demo mode stops so I do think it is receiving some kind of data.

I see where you mentioned before that this was an 'experimental' feature - so maybe my issue is not something you've run across yet.

I'm using Lightjams, which outputs e131 & Artnet but not OPC. I've had some success with using OLA on the Beaglebone to bridge Artnet->OPC but I've been running into some addressing limitations (and some inconsistent startup states) there, so that's not been a great total solution either.

Here's the log from ./opc-server:

[main] Demo Mode Enabled
[e131] Starting UDP server on port 5568
[udp] OPC command for 28800 LEDs cannot fit in UDP packet. Use --count or --strip-count to reduce the number of required LEDs, or disable UDP server with --udp-port 0
Starting demo data thread
[render] Starting render thread for 28800 total pixels
[main] Initializing / Updating server...[tcp] Starting TCP server on 7890
Allocating buffers for 28800 pixels (691200 bytes)
frame_size1=28800
[render] Awaiting server initialization...
[demo] Starting Demo: fade
[main] Starting LEDscape...[e131] Joined multicast group 239.255.0.0 on 192.168.1.174
[e131] Joined multicast group 239.255.0.0 on 192.168.7.2
pru_init: PRU 0: data 0xb4564000 @ 8192 bytes,  DMA 0xb44e4000 / 9f700000 @ 262144 bytes
pru_init: PRU 1: data 0xa4466000 @ 8192 bytes,  DMA 0xa43e4000 / 9f700000 @ 262144 bytes
String PRU0 with pru/bin/ws281x-original-ledscape-pru0.bin... OK
String PRU1 with pru/bin/ws281x-original-ledscape-pru1.bin... OK
{
        "outputMode": "ws281x",
        "outputMapping": "original-ledscape",
        "demoMode": "fade",
        "ledsPerStrip": 600,
        "usedStripCount": 48,
        "colorChannelOrder": "BRG",
        "opcTcpPort": 7890,
        "opcUdpPort": 7890,
        "enableInterpolation": true,
        "enableDithering": true,
        "enableLookupTable": true,
        "lumCurvePower": 2.0000,
        "whitePoint": {
                "red": 0.9000,
                "green": 1.0000,
                "blue": 1.0000
        }
}
[demo] Stopping Demo: fade
[render] fps_info={frame_avg_usec: 21223, possible_fps: 47.12, actual_fps: 0.10, sample_frames: 1}
[render] fps_info={frame_avg_usec: 24425, possible_fps: 40.94, actual_fps: 40.70, sample_frames: 407}
[render] fps_info={frame_avg_usec: 24401, possible_fps: 40.98, actual_fps: 40.90, sample_frames: 409}
[render] fps_info={frame_avg_usec: 24526, possible_fps: 40.77, actual_fps: 40.80, sample_frames: 408}
[render] fps_info={frame_avg_usec: 24434, possible_fps: 40.93, actual_fps: 40.80, sample_frames: 408}
[render] fps_info={frame_avg_usec: 24431, possible_fps: 40.93, actual_fps: 40.90, sample_frames: 409}

I noticed running as a service would cause random freezes in output. I tracked down the issue to logging. Adding:

StandardOutput=null
StandardError=null

To the [Service] section of ledscape.service.in fixed the issue.

I wrote a program which uses the ledscape interface directly for custom lighting and effects. I noticed some frame skipping and isolated the issue to the ledscape_wait() function returning almost immediately sometimes (despite the remaining loop time being the same). This often happens in bursts which causes a large number of frames to be skipped.

I'm not sure if it is related, but I also noticed my FPS dropped ~15% since upgrading to the latest code (vs. a version from around September).

Hello, sorry if this is a dumb question, but they are in beta on a new board http://www.elinux.org/Beagleboard:BeagleBoard-X15 that is just a bit like BBB. I think the microcontroller is a bit different than the PRU so I am doubtful but.. what are the chances there could be a ledscape that is compatible with that new board?

Hi,

I just did a clean build of Debian 7.11 2015-06-15 4GB SD LXDE

First I install

sudo apt-get update
sudo apt-get install usbmount -y
sudo apt-get install git build-essential python -y

I then follow the read.me instructions

git clone git://github.com/Yona-Appletree/LEDscape
cd LEDscape
chmod +x install-software.sh
./install-software.sh
reboot

The output of install-software.sh is as below;

Making ledscape...
gcc -std=c99 -W -Wall -D_DEFAULT_SOURCE -Wp,-MMD,./.opc-server.o.d -Wp,-MT,opc-server.o -I. -O2  -g -lm -mtune=cortex-a8 -march=armv7-a -Wunused-parameter -DNS_ENABLE_IPV6 -Wsign-compare -Werror -Wno-unknown-pragmas -I./am335x/app_loader/include -c -o opc-server.o opc-server.c
In file included from opc-server.c:27:0:
lib/cesanta/frozen.h:38:3: error: unknown type name ‘uint’
opc-server.c: In function ‘demo_mode_from_string’:
opc-server.c:146:2: error: implicit declaration of function ‘strcasecmp’ [-Werror=implicit-function-declaration]
opc-server.c: In function ‘main’:
opc-server.c:719:2: error: implicit declaration of function ‘bzero’ [-Werror=implicit-function-declaration]
opc-server.c: In function ‘server_config_from_json’:
opc-server.c:1018:59: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1018:59: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1022:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1022:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1027:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1027:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1032:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1032:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1037:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1037:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1042:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1042:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1047:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1047:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1052:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1052:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1057:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1057:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1062:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1062:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1067:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1067:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1072:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1072:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1077:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1077:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c:1082:36: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
opc-server.c:1082:36: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
opc-server.c: In function ‘rotate_frames’:
opc-server.c:1286:3: error: implicit declaration of function ‘timersub’ [-Werror=implicit-function-declaration]
opc-server.c: In function ‘render_thread’:
opc-server.c:1334:4: error: implicit declaration of function ‘usleep’ [-Werror=implicit-function-declaration]
opc-server.c: In function ‘join_multicast_group_on_all_ifaces’:
opc-server.c:1782:29: error: ‘IFF_LOOPBACK’ undeclared (first use in this function)
opc-server.c:1782:29: note: each undeclared identifier is reported only once for each function it appears in
opc-server.c:1783:29: error: ‘IFF_POINTOPOINT’ undeclared (first use in this function)
opc-server.c:1784:28: error: ‘IFF_MULTICAST’ undeclared (first use in this function)
opc-server.c:1787:19: error: storage size of ‘multicast_req’ isn’t known
opc-server.c:1787:19: error: unused variable ‘multicast_req’ [-Werror=unused-variable]
opc-server.c: In function ‘e131_server_thread’:
opc-server.c:1905:7: error: ‘uint’ undeclared (first use in this function)
cc1: all warnings being treated as errors
make: *** [opc-server.o] Error 1
Making backups of old device tree files...
Copying new device tree files...
Copying config file to /etc
Leaving existing /etc/ledscape-config.json intact.
Enabling kernel module...
Done. Please enter reboot to reboot the machine and enable changes.

The make: *** [opc-server.o] Error 1 is a little worrying.

After reboot I run-ledscape and get the following output;
./run-ledscape: 11: ./run-ledscape: ./opc-server: not found
I noted that a recent commit was to fix a compilation error. Any chance its not quite fixed? Any suggestions on how to fix it?

Hi Yona, I'm having some stability issues while trying to create a smooth, slow changing output display. I have tried turning off dithering and interpolation but the output is not smooth at all. I have attached a simple processing sketch that performs single stepping of the RGB values and on my system, the instability is quite obvious. I'm running a Beagle Bone Black and I have updated it to the latest build and I'm running Processing from a PC. My processing code is below and I'm using an OPC.pde file which says it was modified by you in late 2014.

Any suggestions?
Thanks for you help.
Paul

/**

• This program single steps the RGB values to test the stability of the output
  */

OPC opc;
int x;

//========== Setup ===========================
void setup() {
size(400,400);
opc = new OPC(this, "192.168.0.25", 7890);
float spacing = height / 16.0;
opc.ledGrid16x16(0, width/2, height/2, spacing, 0, true);
}

//=============== Draw ====================================
void draw() {

x++;
if (x == 155) {
x = 0;}

println("red = ",x, "Green = ",x, "Blue = ",x/2);
loadPixels();

for (int i = 0; i < (width*height); i++) {        
  pixels[i] = color(x,x,x/2);
}

updatePixels();
delay(500);
opc.writePixels();
}

It seems that in ledscape.service.in, it may be better to automatically restart the service if it dies, as well as set the niceness a bit lower (so it has higher priority), e.g.:

Restart=always
Nice=-20

Also, I had issues with setting my network configuration through /etc/network/interfaces on the current BBB image. Essentially it worked on boot, but as soon as the network cable was disconnected the interface lost its static IP. Apparently this is due to wicd. Thus you can either uninstall wicd, or set the IP via wicd-curses (or the appropriate config file in /etc/wicd/).

It seems TI has broken uio_pruss in favor of its new PRU RPM stuff, starting with RCN's 4.1.11-ti kernels. Recently John Syne patched the BBB kernel to fix some issues. I wonder if LEDscape will be updated to use this new mechanism?

Yona, I was wondering what it would take to add a simple c-file that would allow custom led patterns to be done. I envision it would basically be an extension of the current opc-server functionality, but rather than running a "demo" pattern it would run custom defined patterns. Ideally though, this would occur outside of the opc-server code. It some ways it would be similar to (https://github.com/Yona-Appletree/LEDscape/blob/09cea258c8efba1708a9aa5c36174262013b3b76/red-test.c) but would retain the dithering, interpolation, and pin mapping functionality of opc-server. Ryan

for our installation, we will probably not have one BBB with straight led strips but drive LEDs arranged in panels. is there a way to define the mapping between the logical bitmap and the physical strip arrangement?

i guess that would belong into the ledscape driver itself to work for all processes that feed data to the pixels. if there is none, did you think about how to implement that? i can have a go at that, but ideally it would be reusable.

It seems as if the channels passed in are ignored by the opcserver. I would expect it to map the channel to a pin on the board, but it doesn't seem to be doing that.

I just did a fresh clone of LEDscape and I get the following error make'ing on a BeagleBone Black.

pasm.c:1356:1: fatal error: opening dependency file am335x/pasm/.pasm.d: No such file or directory

The full output of the make is here [1].

I'm running Debian, the 2014-11-11 image.

I've had success with LEDscape before. I'm not sure what has changed this time.

--Mark

[1] http://paste.debian.net/134992/

when i try to use ledscape_close, i always get a segfault. i tried that with exiting the loop in rgb-test and it happens there as well.

then again, i can simply comment out that line and don't see anything bad happen. the leds just stay their last color until i start another program.

I would like to reduce the number of channels for two reasons:

1. The current configuration only has enough memory to drive ~600 pixels per strip, and I would like to do more.
2. I would like to minimize the CPU usage.

My current approach was to:

1. Change #define LEDSCAPE_NUM_STRIPS 8 in ledscape.h
2. Define the GPIOs in ledscape.c, eg.:

static const uint8_t gpios0[] = {
2, 3, 7, 8, 9, 10, 11, 14
};
(and no others; well actually I chose all 8 on the right side of P9, but you get the idea)

1. Change "48" to "8" in pru/templates/ws281x.p.

Is that correct? I'm having some odd tearing/flickering issues, but I'm not sure if they are related.

i am not too happy that opc-server goes into demo mode. i would prefer to disable that and and have the opc-server just leave the pixels alone until external data arrives.

i see that demo gets active when there is no data received for 5 seconds.
https://github.com/Yona-Appletree/LEDscape/blob/master/opc-server.c#L798

would it make sense to have a build option to not even compile the demo thread in at all? i could also make a cli option to disable demo, and in that case not even start the demo thread.

an advanced option could be to also allow an external program as demo source. like adding opc support to rgb-test and start up that program when no data is received, but allowing to start a different configurable program.

I've just installed LEDscape and I'm getting 99% percent CPU used on my BBB. It's enough to slow down the simple web interface program I've got running. Is this normal?

So far I've just run rgb-test and ./run-ledscape ...

Hey, was there a reason why you deleted the multipin branch? I would love to see it coming back, because I was using it. I killed my bbb and now i am stuck with setting up my old software :(

I'd like to get LEDscape running on a newer image than Wheezy.

I've gotten everything to compile, however I'm bumping into nonexistent GPIO at runtime as follows.. wonder if this is something easy to fix? I notice that if i ls on the /sys/class/gpio dir I have loads of available in higher numbers, however the single digits are lacking.

Specifically the line: pru_gpio:173: /sys/class/gpio/gpio2/value: Unable to open?

note that gpio2 above randomly changes between 2, 3, and 7 on different runs.

full message...

Loaded config file from /etc/ledscape-config.json.
Config file written to /etc/ledscape-config.json
[main] Starting server on ports (tcp=7890, udp=7890) for 20 pixels on 48 strips
[main] Demo Mode Enabled
Allocating buffers for 960 pixels (23040 bytes)
[main] Initializing / Updating server...frame_size1=960
Starting demo data thread
[e131] Not starting e131 server; Port is zero.
[render] Starting render thread for 960 total pixels
[udp] Starting UDP server on port 7890
[main] Starting LEDscape...pru_init: PRU 0: data 0xb456d000 @ 8192 bytes,  DMA 0xb44ed000 / 9c940000 @ 262144 bytes
pru_init: PRU 1: data 0xa4446000 @ 8192 bytes,  DMA 0xa42c0000 / 9c940000 @ 262144 bytes
pru_gpio:173: /sys/class/gpio/gpio2/value: Unable to open? No such file or directory

Hi! We're building an installation around the RGB123 48-output RS485 boards, and we're pretty happy with LEDscape and OPC so far.

But I'm noticing flicker whenever interpolation is enabled. It's more obvious at low client frame rates.

Here's a quick and not very good video (sorry) demonstrating the flicker. First few seconds are with interpolation on, next few seconds with interpolation off, with the client code running at about 5fps to make the effect more photographable.
https://vine.co/v/M2Yte1jr1ae

It looks as if the interpolation is fading to black in between frames, and it sounds like it might be similar to the issue described here:
https://twitter.com/hypher/status/459948735707901952

This is on a Beaglebone Black Rev C with Debian and the RGB-123 48-output cape. I believe it happens with the 24-output cape as well, will confirm.

As requested by @ggreenwood, I would like to add a "black" or "clear" demo mode that zeros the output of all pixels upon starting, but then does nothing else. It may also be prudent to change the name from "demo mode" to "idle mode" or something similar.

I noticed the newer tiles coming from china are moving to 1/4 scan instead of 1/8 or 1/16 scan. I was wondering if its possible to modify the PRU firmware to support 1/4 scan? I know 1/4 scan 16x32 tiles need twice the data clocked in as there is 4 lines on at 1 time instead of 2. any thoughts? the PRU source is highly confusing to me as I came from a BASIC world.

Hi Yona,

Firstly, thank you for all your contributions to this branch of LEDScape.

I am not sure how to make direct contact with you, so I hope this message is not out of place. I'm wondering whether you would be available for some freelance development work. I am looking for a pru template solution for another LED RGB driver chip. The protocol is a slight modification to the WS281x template. I would be happy for you to commit this solution to this branch once done.

Thanks

Hi,

I'm wondering if it's possible to have greater control over pixel granularity, meaning uint16 [R,G,B] values as opposed to just 0-255? I believe the OPC protocol could be sufficiently modified to accept greater than uint8 values. I guess what I'm asking is: can the PRU do more granular stepping and does the WS2812 spec support it?

Sorry if this is the wrong place to be asking!

Yona,

Apologies if I am abusing the "Issues" as a forum. I'm wondering if you would recommend leaving dithering on or off in the following scenario:

We produce and consume OPC frames on the same BBB and simply loop back the UDP messages on localhost. This allows us to use the OGL OPC simulator to test patterns for people without hardware. Since our strands are 100LEDs we have a max rate of 300fps. We are close to this with a rate of around 240FPS both producing OPC frames and consuming them using opc-server.

I'm turning dithering and interpolation off at these rates since our effects are time-driven functions that are driven by delta-T, not frame index. At these rates I think it's the right thing to do but I'd like your opinion in the matter.

Cheers,
Mattias