David,
William's suggestion of the PRU is a really good one.
I know there are examples on the forum for using them - even though I
personally haven't looked at them.
You should be able to do everything inside the PRU - You only need 144
bytes per buffer (assuming 1 color / 1 bpp).
So even having
The way I see it is that you have two options. You could use the PRUs, or
you could use the McSPI hardware module. I would attempt to help you but I
really do not have any experience with the ws28xx style serial protocol
that many seem to use with external lighting of this type.
I can tell you tha
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.
Ab
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
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
searche
>
>
>
> *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 kthr
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 p
Additionally just below the call to msleep() linked to above you have
nested loops two deep so . . .
http://stackoverflow.com/questions/24643432/big-o-nested-while-loop
On Mon, Mar 21, 2016 at 1:44 PM, William Hermans wrote:
> So, I'm just now getting back to you, and I see you all have been
> d
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/davidg
On Mon, 21 Mar 2016 14:31:56 -0500, you wrote:
>So, let me see if I understand your idea:
>My display looks like this:
>R0
>...
>R7
Ah, ok, dot matrix then.
>
>Data is written to the LED drivers while power is applied to one row.
>Then, new data is written and power is applied to the next row,
So, let me see if I understand your idea:
My display looks like this:
R0
...
R7
Data is written to the LED drivers while power is applied to one row.
Then, new data is written and power is applied to the next row, etc.
"I'd be tempted to do the following approach: Divide the scan time
into one
On Mon, 21 Mar 2016 11:16:49 -0500, you wrote:
>Hmm... I'm using UCN5821 driver chips from Allegro. They do indeed have a
>hardware latch (strobe) which latches the received serial data from the
>internal shift register to the outputs.
>
>My write algorithm is (per row):
>1> set_current_state(TAS
Hmm... I'm using UCN5821 driver chips from Allegro. They do indeed have a
hardware latch (strobe) which latches the received serial data from the
internal shift register to the outputs.
My write algorithm is (per row):
1> set_current_state(TASK_RUNNING)
2> If new data is ready in RAM, memcpy it t
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, rea
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)
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
c
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 com
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
18 matches
Mail list logo
