I take that back. The last thing I saw I thought was cool was this:
https://github.com/boxysean/beaglebone-DMX
But also done in 2013 it seems. Matt R also had a github project working
with ws28xx serial type LEDs. But it's probably very similar to boxysean's
DMX project. Just a different serial pr
Back on topic.
I wonder if it wouldn't be simpler, and easier for everyone if someone
where to just write / create a setup script for both options. It's been a
while, so I do not recall the finer details with each process. But I can
say while I do not know everything, I'm also not a novice Linux u
On Wed, Mar 1, 2017 at 10:19 PM, Robert Nelson <
robertcnel...@beagleboard.org> wrote:
> The above is disabled by default as of 2-3 weeks ago..
>
I'm still kind of on the fence. I can completely understand wanting to just
type ssh root@beaglebone and *bam* be right where I need to be to start
wor
On Mar 1, 2017 9:36 PM, "William Hermans" wrote:
By the way, leaving root enabled via port 22 with no passwd, is an
extremely bad idea. So may while those people will whine to no end about
that "problem". Perhaps they should be made to understand the implications
of leaving port 22 wide open to r
By the way, leaving root enabled via port 22 with no passwd, is an
extremely bad idea. So may while those people will whine to no end about
that "problem". Perhaps they should be made to understand the implications
of leaving port 22 wide open to root access ?
On Wed, Mar 1, 2017 at 8:27 PM, Rober
On Wed, Mar 1, 2017 at 7:53 PM, Jason Kridner
wrote:
>
> Let's see who screams.
>
> Probably the same people as disabling root ssh access. ;-)
>
That's actually kind of funny. Funny in that recently I noticed that when
rebooting one of the later 2016 image from ssh. The ssh connection was not
pr
On Wed, Mar 1, 2017 at 8:39 PM, Robert Nelson wrote:
> On Wed, Mar 1, 2017 at 8:13 PM, Jason Kridner wrote:
>>
>>
>> On Wed, Mar 1, 2017 at 8:53 PM William Hermans wrote:
>>>
>>> Jason,
>>>
>>> Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify
>>> the the board overlay fil
On Wed, Mar 1, 2017 at 8:53 PM, Jason Kridner wrote:
>
>
> On Wed, Mar 1, 2017 at 9:39 PM Robert Nelson
> wrote:
>>
>> On Wed, Mar 1, 2017 at 8:13 PM, Jason Kridner wrote:
>> >
>> >
>> > On Wed, Mar 1, 2017 at 8:53 PM William Hermans
>> > wrote:
>> >>
>> >> Jason,
>> >>
>> >> Is this a pure uEn
So, here are my thoughts about all that. Not that what I say really means a
whole lot. Other than it's just another opinion.
In all honestly, I do not really care what goes on with the TI kernels.
Ti's views with what is enabled, and how it's enabled does not really jibe
with the way I personally
On Wed, Mar 1, 2017 at 9:39 PM Robert Nelson
wrote:
> On Wed, Mar 1, 2017 at 8:13 PM, Jason Kridner wrote:
> >
> >
> > On Wed, Mar 1, 2017 at 8:53 PM William Hermans
> wrote:
> >>
> >> Jason,
> >>
> >> Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify
> >> the the board o
On Wed, Mar 1, 2017 at 8:13 PM, Jason Kridner wrote:
>
>
> On Wed, Mar 1, 2017 at 8:53 PM William Hermans wrote:
>>
>> Jason,
>>
>> Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify
>> the the board overlay file. Or maybe it was one of the includes, I forget
>> which.
>
>
>
On Wed, Mar 1, 2017 at 8:53 PM William Hermans wrote:
> Jason,
>
> Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify
> the the board overlay file. Or maybe it was one of the includes, I forget
> which.
>
There is also a kernel module blacklist configuration file. I'm not s
Jason,
Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify
the the board overlay file. Or maybe it was one of the includes, I forget
which.
On Wed, Mar 1, 2017 at 6:37 PM, Jason Kridner wrote:
>
>
> On Mar 1, 2017, at 7:48 PM, William Hermans wrote:
>
> I had the PRU's wor
> On Mar 1, 2017, at 7:48 PM, William Hermans wrote:
>
> I had the PRU's working with an 4.x kernel around 4-5 months ago. Basically I
> downloaded Jason's PRU github files, and got two of the examples working.
> Back then, you could only use the older UIO PRU source examples with the
> *bon
I had the PRU's working with an 4.x kernel around 4-5 months ago. Basically
I downloaded Jason's PRU github files, and got two of the examples working.
Back then, you could only use the older UIO PRU source examples with the
*bone* kernel, as TI's kernel was remoteproc only. Now days, supposedly
it
Once you get it working on the old stuff, come back and ask how to get it
moved forward. It is pretty easy once you know your PRU code is working.
With the remote-proc driver, you can throw the built .elf files into
/lib/firmware and trigger them to load by the kernel, without needing to
have a li
Hi Mike,
As Greg said, PRU development is severely hampered by incomplete,
out-dated, and mutually-exclusive sets of instructions. Derek Molloy's book
may be based on an older Beaglebone Black, but at least it's self-contained
and consistent. I struggled for a long time to get the PRU working o
Hi Mike-
>
>
There are several possible paths. Since you mentioned Derek Molloy's book,
here is my project which was inspired by his chapter on the PRU:
https://www.hackster.io/Greg-R/beaglebone-pru-adc-a42a71
If you look at this, you will see that I used the RemoteProc framework.
This framew
18 matches
Mail list logo
