Re: [beagleboard] Re: Issue with USB devices through a USB hub

[William Hermans]

The USB interface on the beaglebones can be very picky what it'll accept.
So simply picking a different USB hub may, or may not solve your problem.


On Mon, Mar 21, 2016 at 10:00 PM, Karina  wrote:

> Actually, the version of the linux kernel i am running on my beagle bone
> is v3.8.13 - bone 70.
>
> -Karina
>
>
> On Monday, March 21, 2016 at 9:49:32 PM UTC-7, Karina wrote:
>>
>> Hi,
>>
>> I have a unpowered 2-port USB hub that I have connected to the BeagleBone
>> Black (Rev C). I have two (serial over ) USB devices connected to the two
>> port of the USB hub. They are are not powered to begin with. When i power
>> up the Beagle Bone, i see the USB hub listed in the output for 'lsusb'. Now
>> i power up the two USB device hanging off the USB hub. But i do not see the
>> USB devices listed in the output of 'lsusb'. Also, there is no /dev/ttyUSB*
>> file. For my project, it wold be ideal for the beagle bone to be powered up
>> before these USB devices. Any idea on what i have messed up or missed?
>>
>> I have verified that if i connect the USB device directly into the USB
>> port on the beagle bone black, then I can power the USB device after the
>> beagle bone is powered up and it shows up in the output of 'lsusb' and i
>> can control the device.
>>
>> Here are some more specifics about my setup.
>> 1. I am using the beagle bone black Rev C board.
>> 2. I am running Debian linux (jessie v 8.3) on the beagle bone black .
>> The version of the linux kernel is v3.8.15 -bone 71.
>> 3. I am powering the beagle bone with the power supply ( instead of over
>> the USB connector for etherent over USB).
>>
>> Thanks,
>> Karina
>>
>> --
> 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

[William Hermans]

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 that a very simple, and cheap msp430g2553 project would be
more that enough to do all this - bare metal. So no needs for a cpld or
FPGA or anything fancy like that. But again as mentioned by Matt above, you
have to design a PCB, + circuit and the costs add up despite the fact that
a G2553 is only about $2-$3 sold as singles.

Anyway, maybe someone here knows the McSPI module well enough to comment on
"shifting out" data to your matrix ? As in actually knowing what they're
talking about . . .

How does this buffer work anyhow ? Is this like a bit field in both
dimensions, or what ? Kind of hard to grasp on a simple code glancing ;)

On Mon, Mar 21, 2016 at 4:36 PM, David Good  wrote:

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

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

[beagleboard] Re: Issue with USB devices through a USB hub

[Karina]

Actually, the version of the linux kernel i am running on my beagle bone is 
v3.8.13 - bone 70.

-Karina

On Monday, March 21, 2016 at 9:49:32 PM UTC-7, Karina wrote:
>
> Hi,
>
> I have a unpowered 2-port USB hub that I have connected to the BeagleBone 
> Black (Rev C). I have two (serial over ) USB devices connected to the two 
> port of the USB hub. They are are not powered to begin with. When i power 
> up the Beagle Bone, i see the USB hub listed in the output for 'lsusb'. Now 
> i power up the two USB device hanging off the USB hub. But i do not see the 
> USB devices listed in the output of 'lsusb'. Also, there is no /dev/ttyUSB* 
> file. For my project, it wold be ideal for the beagle bone to be powered up 
> before these USB devices. Any idea on what i have messed up or missed?
>
> I have verified that if i connect the USB device directly into the USB 
> port on the beagle bone black, then I can power the USB device after the 
> beagle bone is powered up and it shows up in the output of 'lsusb' and i 
> can control the device.
>
> Here are some more specifics about my setup.
> 1. I am using the beagle bone black Rev C board.
> 2. I am running Debian linux (jessie v 8.3) on the beagle bone black . The 
> version of the linux kernel is v3.8.15 -bone 71. 
> 3. I am powering the beagle bone with the power supply ( instead of over 
> the USB connector for etherent over USB).
>
> Thanks,
> Karina
>
>

-- 
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] Issue with USB devices through a USB hub

[Karina]

Hi,

I have a unpowered 2-port USB hub that I have connected to the BeagleBone 
Black (Rev C). I have two (serial over ) USB devices connected to the two 
port of the USB hub. They are are not powered to begin with. When i power 
up the Beagle Bone, i see the USB hub listed in the output for 'lsusb'. Now 
i power up the two USB device hanging off the USB hub. But i do not see the 
USB devices listed in the output of 'lsusb'. Also, there is no /dev/ttyUSB* 
file. For my project, it wold be ideal for the beagle bone to be powered up 
before these USB devices. Any idea on what i have messed up or missed?

I have verified that if i connect the USB device directly into the USB port 
on the beagle bone black, then I can power the USB device after the beagle 
bone is powered up and it shows up in the output of 'lsusb' and i can 
control the device.

Here are some more specifics about my setup.
1. I am using the beagle bone black Rev C board.
2. I am running Debian linux (jessie v 8.3) on the beagle bone black . The 
version of the linux kernel is v3.8.15 -bone 71. 
3. I am powering the beagle bone with the power supply ( instead of over 
the USB connector for etherent over USB).

Thanks,
Karina

-- 
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] How is a default Device Tree Blob determined?

[Greg]

I think that's a significant piece of info in understanding how the device 
tree data structure works for the Beaglebones.
I've got several books on the Beaglebone + Google searching did not yield 
an answer.

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

Re: [beagleboard] How is a default Device Tree Blob determined?

[Robert Nelson]

On Mon, Mar 21, 2016 at 8:21 PM, Greg  wrote:
> I am trying to learn how a Device Tree Blob is selected (BeagleBoneBlack)
> if:
>
> 1.  No cape is plugged in.
> 2.  All dtb and cape lines in uEnv.txt are commented.
>
> In other words a default set-up with no specific DTB or DTBO specified.
>
> What is the process or data used for determining which DTB is used?
>

We look at the eeprom:

http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=150c5235d230f597641bd8a8fbd8e4afa0fd16cd;hb=HEAD#l164

Regards,


-- 
Robert Nelson
https://rcn-ee.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.

[beagleboard] How is a default Device Tree Blob determined?

[Greg]

I am trying to learn how a Device Tree Blob is selected (BeagleBoneBlack) 
if:

1.  No cape is plugged in.
2.  All dtb and cape lines in uEnv.txt are commented.

In other words a default set-up with no specific DTB or DTBO specified.

What is the process or data used for determining which DTB is used?

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

[CEinTX]

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.

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 n is a value in microseconds. I honestly do not know how
>>> responsive timers are in kernel space, but in userspace high resolution
>>> timers do not work. It does not matter if one uses an RT kernel or not. So
>>> system API calls such as usleep() really do not work, as there is some
>>> system call overhead involved. In kernel space . . . again I have no hands
>>> on personally, but I'd be leery of any sleep() type call until I actually
>>> tested it

Re: [beagleboard] Re: beagle bone xenomai RTNET

[Charles Steinkuehler]

If you need real-time access to Ethernet and other kernel-driven I/O
like SPI and I2C, I would recommend using the PREEMPT_RT kernel rather
than Xenomai.

On 3/21/2016 8:08 AM, saga...@gmail.com wrote:
> did you manage to find something? im having the same issue.
> 
> thanks for the update if any :)
> 
> On Wednesday, July 15, 2015 at 5:04:22 PM UTC+2, gowtham sandilya wrote:
> 
> Hi Everyone,
> 
> I am working on a project which requires two computers to communicate in a
> real time fashion. I already have a i5 computer with xenomai and rtnet
> (http://www.rtnet.org/) installed.  I want the other computer to have low
> level peripherals like GPIOs, I2C, SPI etc. I found that beaglebone fits
> these requirements nicely. I found that I can install xenomai on 
> beaglebone
> using a debian image (here
> 
> )
> . I was wondering if RTNET can also be installed in the default fashion? I
> was hoping to see if anyone actually tried installing rtnet on beaglebone
> black and got it to work?
> 
> Thank you for your time.
> 
> Regards,
> Gowtham Garimella.
> 
> -- 
> 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.
> 


-- 
Charles Steinkuehler
char...@steinkuehler.net

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

[William Hermans]

>
>
>
> *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 n is a value in microseconds. I honestly do not know how
>> responsive timers are in kernel space, but in userspace high resolution
>> timers do not work. It does not matter if one uses an RT kernel or not. So
>> system API calls such as usleep() really do not work, as there is some
>> system call overhead involved. In kernel space . . . again I have no hands
>> on personally, but I'd be leery of any sleep() type call until I actually
>> tested it on the specific platform I planned using it on.
>>
>> On Mon, Mar 21, 2016 at 1:23 PM, Harvey White 
>> wrote:
>>
>>> 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, etc.
>>> >
>>> >"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."
>>> >
>>> >When you say "digit", I assume you are thinking in terms of a
>>> multiplexed
>>> >7-segment readout style display, which in my case would be the same
>>> thing
>>> >as a row.  My driver operates on one row at a time before going to
>>> sleep.
>>> >Are you suggesting that I scan through all 8 rows and then have a
>>> special
>>> >9th "row" time where I do things like the memcpy?  This would be pretty
>>> >close to a VSYNC idea, right?  I suppose that this 9th "row" wouldn't
>>> have
>>> >to wait a full row time, but could schedule the next row sooner.
>>> Hmm
>>> >
>>>
>>> Exactly, VSync or Hsync depending on what analogy you want.  In this
>>> case, Vsync would be right.
>>>
>>> If you're doing an operating system, then your timing is really
>>> generated by interrupts, so I'd be using a relatively high priority
>>> hardware interrupt from a timer here, or if you want to do an
>>> operating system, then just give the remaining time back to the OS so
>>> it can pick the next task.  No need to chew up one tick period.
>>>
>>> In my OS, tasks suspended or delayed check the time (or semaphore) or
>>> yield back the time, then the OS simply looks for the next active
>>> task.
>>>
>>>
>>>
>>> >You are totally right about MCUs and burning the LEDs.  This particular
>>> >display is safe because the LEDs are not being over-driven.  Your idea
>>> >about a CPLD is a good one.  I've never used them, but have know about
>>> >them.  I found this XC2C32A for $1.8USD.  I will probably try this out
>>> at
>>> >some point just 

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

[David Good]

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 n is a value in microseconds. I honestly do not know how
> responsive timers are in kernel space, but in userspace high resolution
> timers do not work. It does not matter if one uses an RT kernel or not. So
> system API calls such as usleep() really do not work, as there is some
> system call overhead involved. In kernel space . . . again I have no hands
> on personally, but I'd be leery of any sleep() type call until I actually
> tested it on the specific platform I planned using it on.
>
> On Mon, Mar 21, 2016 at 1:23 PM, Harvey White 
> wrote:
>
>> 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, etc.
>> >
>> >"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."
>> >
>> >When you say "digit", I assume you are thinking in terms of a multiplexed
>> >7-segment readout style display, which in my case would be the same thing
>> >as a row.  My driver operates on one row at a time before going to sleep.
>> >Are you suggesting that I scan through all 8 rows and then have a special
>> >9th "row" time where I do things like the memcpy?  This would be pretty
>> >close to a VSYNC idea, right?  I suppose that this 9th "row" wouldn't
>> have
>> >to wait a full row time, but could schedule the next row sooner.  Hmm
>> >
>>
>> Exactly, VSync or Hsync depending on what analogy you want.  In this
>> case, Vsync would be right.
>>
>> If you're doing an operating system, then your timing is really
>> generated by interrupts, so I'd be using a relatively high priority
>> hardware interrupt from a timer here, or if you want to do an
>> operating system, then just give the remaining time back to the OS so
>> it can pick the next task.  No need to chew up one tick period.
>>
>> In my OS, tasks suspended or delayed check the time (or semaphore) or
>> yield back the time, then the OS simply looks for the next active
>> task.
>>
>>
>>
>> >You are totally right about MCUs and burning the LEDs.  This particular
>> >display is safe because the LEDs are not being over-driven.  Your idea
>> >about a CPLD is a good one.  I've never used them, but have know about
>> >them.  I found this XC2C32A for $1.8USD.  I will probably try this out at
>> >some point just for educational purposes :)
>>
>> You would want the Xilinx free version of their web support (ISE),
>> which works fine those chips.  You'll need to find the USB programming
>> cable as well, I got mine from Amazon.
>>
>> There are times when it's nice to be able to throw hardware at a
>> problem.  You have the driver done well enough, but IIRC, there are
>> some subsystems out there that do this.  A simple Atmel Mega processor
>> would work well for this, if you wanted.
>>
>> The nice thing about the XC2C32A and the Xc2C64A is that they have
>> exactly the same footprint.  Once you get to 128 or 256 cells, you go
>> to a TQFP-100 package.
>>
>> I'd recommend VHDL (simply because I like it) for the design language.
>> Remember that in VHDL you do not have to design components like chips,
>> but you can tell the chip "I want a divide by 37 counter" by
>> explaining how it counts, and then let the program built it.  This
>> makes it an easier design process than designing the counter with
>> logic by itself.
>>
>> Harvey
>>
>>
>> >
>> >
>> http://www.digikey.com/product-detail/en/xilinx-inc/XC2C32A-6VQG44I/122-1704-ND/1952030
>> >
>> >--David
>> >
>> >
>> >On Mon, Mar 21, 2016 at 12:28 PM, Harvey White 
>> >wrote:
>> >
>> >> 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

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

[William Hermans]

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
> 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 n is a value in microseconds. I honestly do not know how
> responsive timers are in kernel space, but in userspace high resolution
> timers do not work. It does not matter if one uses an RT kernel or not. So
> system API calls such as usleep() really do not work, as there is some
> system call overhead involved. In kernel space . . . again I have no hands
> on personally, but I'd be leery of any sleep() type call until I actually
> tested it on the specific platform I planned using it on.
>
> On Mon, Mar 21, 2016 at 1:23 PM, Harvey White 
> wrote:
>
>> 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, etc.
>> >
>> >"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."
>> >
>> >When you say "digit", I assume you are thinking in terms of a multiplexed
>> >7-segment readout style display, which in my case would be the same thing
>> >as a row.  My driver operates on one row at a time before going to sleep.
>> >Are you suggesting that I scan through all 8 rows and then have a special
>> >9th "row" time where I do things like the memcpy?  This would be pretty
>> >close to a VSYNC idea, right?  I suppose that this 9th "row" wouldn't
>> have
>> >to wait a full row time, but could schedule the next row sooner.  Hmm
>> >
>>
>> Exactly, VSync or Hsync depending on what analogy you want.  In this
>> case, Vsync would be right.
>>
>> If you're doing an operating system, then your timing is really
>> generated by interrupts, so I'd be using a relatively high priority
>> hardware interrupt from a timer here, or if you want to do an
>> operating system, then just give the remaining time back to the OS so
>> it can pick the next task.  No need to chew up one tick period.
>>
>> In my OS, tasks suspended or delayed check the time (or semaphore) or
>> yield back the time, then the OS simply looks for the next active
>> task.
>>
>>
>>
>> >You are totally right about MCUs and burning the LEDs.  This particular
>> >display is safe because the LEDs are not being over-driven.  Your idea
>> >about a CPLD is a good one.  I've never used them, but have know about
>> >them.  I found this XC2C32A for $1.8USD.  I will probably try this out at
>> >some point just for educational purposes :)
>>
>> You would want the Xilinx free version of their web support (ISE),
>> which works fine those chips.  You'll need to find the USB programming
>> cable as well, I got mine from Amazon.
>>
>> There are times when it's nice to be able to throw hardware at a
>> problem.  You have the driver done well enough, but IIRC, there are
>> some subsystems out there that do this.  A simple Atmel Mega processor
>> would work well for this, if you wanted.
>>
>> The nice thing about the XC2C32A and the Xc2C64A is that they have
>> exactly the same footprint.  Once you get to 128 or 256 cells, you go
>> to a TQFP-100 package.
>>
>> I'd recommend VHDL (simply because I like it) for the design language.
>> Remember that in VHDL you do not have to design components like chips,
>> but you can tell the chip "I want a divide by 37 counter" by
>> explaining how it counts, and then let the program built it.  This
>> makes it an easier design process than designing the counter with
>> logic by itself.
>>
>> Harvey
>>
>>
>> >
>> >
>> http://www.digikey.com/product-detail/en/xilinx-inc/XC2C32A-6VQG44I/122-1704-ND/1952030
>> >
>> >--David
>> >
>> >
>> >On Mon, Mar 21, 2016 at 12:28 PM, Harvey White 
>> >wrote:
>> >
>> >> 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(TASK_RUNNING)
>> >>
>> >> For state 2, I'd be tempted to do a non-interruptible write to the
>> >> display memory (or protect it by a semaphore).  You want to interlock
>> >> the process so that you have a safe zone to write new d

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

[William Hermans]

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 n is a value in microseconds. I honestly do not know how
responsive timers are in kernel space, but in userspace high resolution
timers do not work. It does not matter if one uses an RT kernel or not. So
system API calls such as usleep() really do not work, as there is some
system call overhead involved. In kernel space . . . again I have no hands
on personally, but I'd be leery of any sleep() type call until I actually
tested it on the specific platform I planned using it on.

On Mon, Mar 21, 2016 at 1:23 PM, Harvey White 
wrote:

> 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, etc.
> >
> >"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."
> >
> >When you say "digit", I assume you are thinking in terms of a multiplexed
> >7-segment readout style display, which in my case would be the same thing
> >as a row.  My driver operates on one row at a time before going to sleep.
> >Are you suggesting that I scan through all 8 rows and then have a special
> >9th "row" time where I do things like the memcpy?  This would be pretty
> >close to a VSYNC idea, right?  I suppose that this 9th "row" wouldn't have
> >to wait a full row time, but could schedule the next row sooner.  Hmm
> >
>
> Exactly, VSync or Hsync depending on what analogy you want.  In this
> case, Vsync would be right.
>
> If you're doing an operating system, then your timing is really
> generated by interrupts, so I'd be using a relatively high priority
> hardware interrupt from a timer here, or if you want to do an
> operating system, then just give the remaining time back to the OS so
> it can pick the next task.  No need to chew up one tick period.
>
> In my OS, tasks suspended or delayed check the time (or semaphore) or
> yield back the time, then the OS simply looks for the next active
> task.
>
>
>
> >You are totally right about MCUs and burning the LEDs.  This particular
> >display is safe because the LEDs are not being over-driven.  Your idea
> >about a CPLD is a good one.  I've never used them, but have know about
> >them.  I found this XC2C32A for $1.8USD.  I will probably try this out at
> >some point just for educational purposes :)
>
> You would want the Xilinx free version of their web support (ISE),
> which works fine those chips.  You'll need to find the USB programming
> cable as well, I got mine from Amazon.
>
> There are times when it's nice to be able to throw hardware at a
> problem.  You have the driver done well enough, but IIRC, there are
> some subsystems out there that do this.  A simple Atmel Mega processor
> would work well for this, if you wanted.
>
> The nice thing about the XC2C32A and the Xc2C64A is that they have
> exactly the same footprint.  Once you get to 128 or 256 cells, you go
> to a TQFP-100 package.
>
> I'd recommend VHDL (simply because I like it) for the design language.
> Remember that in VHDL you do not have to design components like chips,
> but you can tell the chip "I want a divide by 37 counter" by
> explaining how it counts, and then let the program built it.  This
> makes it an easier design process than designing the counter with
> logic by itself.
>
> Harvey
>
>
> >
> >
> http://www.digikey.com/product-detail/en/xilinx-inc/XC2C32A-6VQG44I/122-1704-ND/1952030
> >
> >--David
> >
> >
> >On Mon, Mar 21, 2016 at 12:28 PM, Harvey White 
> >wrote:
> >
> >> 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(TASK_RUNNING)
> >>
> >> For state 2, I'd be tempted to do a non-interruptible write to the
> >> display memory (or protect it by a semaphore).  You want to interlock
> >> the process so that you have a safe zone to write new data to the
> >> memory.
> >> >2> If new data is ready in RAM, memcpy it to the real display buffer in
> >> RAM.
> >>
> >> This should not cause a problem unless the data changes somehow.
> >> >3> Serially shift out next row data in the background, but do not latch
> >> yet
> >> >(background)
> >>
> >> This may be too fast for you to see, and you don't want

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

[Harvey White]

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, etc.
>
>"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."
>
>When you say "digit", I assume you are thinking in terms of a multiplexed
>7-segment readout style display, which in my case would be the same thing
>as a row.  My driver operates on one row at a time before going to sleep.
>Are you suggesting that I scan through all 8 rows and then have a special
>9th "row" time where I do things like the memcpy?  This would be pretty
>close to a VSYNC idea, right?  I suppose that this 9th "row" wouldn't have
>to wait a full row time, but could schedule the next row sooner.  Hmm
>

Exactly, VSync or Hsync depending on what analogy you want.  In this
case, Vsync would be right.

If you're doing an operating system, then your timing is really
generated by interrupts, so I'd be using a relatively high priority
hardware interrupt from a timer here, or if you want to do an
operating system, then just give the remaining time back to the OS so
it can pick the next task.  No need to chew up one tick period.

In my OS, tasks suspended or delayed check the time (or semaphore) or
yield back the time, then the OS simply looks for the next active
task.



>You are totally right about MCUs and burning the LEDs.  This particular
>display is safe because the LEDs are not being over-driven.  Your idea
>about a CPLD is a good one.  I've never used them, but have know about
>them.  I found this XC2C32A for $1.8USD.  I will probably try this out at
>some point just for educational purposes :)

You would want the Xilinx free version of their web support (ISE),
which works fine those chips.  You'll need to find the USB programming
cable as well, I got mine from Amazon.

There are times when it's nice to be able to throw hardware at a
problem.  You have the driver done well enough, but IIRC, there are
some subsystems out there that do this.  A simple Atmel Mega processor
would work well for this, if you wanted.  

The nice thing about the XC2C32A and the Xc2C64A is that they have
exactly the same footprint.  Once you get to 128 or 256 cells, you go
to a TQFP-100 package.  

I'd recommend VHDL (simply because I like it) for the design language.
Remember that in VHDL you do not have to design components like chips,
but you can tell the chip "I want a divide by 37 counter" by
explaining how it counts, and then let the program built it.  This
makes it an easier design process than designing the counter with
logic by itself.

Harvey


>
>http://www.digikey.com/product-detail/en/xilinx-inc/XC2C32A-6VQG44I/122-1704-ND/1952030
>
>--David
>
>
>On Mon, Mar 21, 2016 at 12:28 PM, Harvey White 
>wrote:
>
>> 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(TASK_RUNNING)
>>
>> For state 2, I'd be tempted to do a non-interruptible write to the
>> display memory (or protect it by a semaphore).  You want to interlock
>> the process so that you have a safe zone to write new data to the
>> memory.
>> >2> If new data is ready in RAM, memcpy it to the real display buffer in
>> RAM.
>>
>> This should not cause a problem unless the data changes somehow.
>> >3> Serially shift out next row data in the background, but do not latch
>> yet
>> >(background)
>>
>> This may be too fast for you to see, and you don't want it slow.
>>
>> >4> Blank the display - This is not actually working right now.  I never
>> see
>> >the blank line move. Hmm
>>
>> I'm assuming you have the data for the new row in the buffer, of
>> course,
>>
>> >5> Adjust the multiplexed row select pins to the next row (A2...A0)
>> >6> Latch the data already in the serial buffers
>>
>> Problem with blanking and unblanking the whole display could cause
>> flicker.
>> >7> Unblank the display
>> >8> set_current_state(TASK_INTERRUPTIBLE)
>> >9> usleep until time to update next row
>> >
>> >I wanted to spend a little time as possible with the LEDs off, which is
>> why
>> >I'm shifting data while the LEDs are still showing the current row data.
>>
>> That shouldn't be a problem at all, the chip is designed for it.
>>
>> >Using this technique, I've seen ghosting issues when a mcu is very fast as
>> >the drivers themselves need a little time to switch the state of their
>> >outputs, and also the high-side switching power transistors sometimes need
>> >some time to fully turn off.  I don't think that's what I'm seeing here
>

Re: [beagleboard] bbb Internal ADC configuration settings?

[Robert Nelson]

On Mon, Mar 21, 2016 at 2:52 PM, Audrey  wrote:
> Thanks John, do you know where to get kernel 4.1? This is the only place I
> know that has beaglebone images, but they don't specify which kernel each
> version has: http://beagleboard.org/latest-images

Fresh as of yesterday: 4.1.18-ti-r53

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots

We've been fixing up the usb gadget setup, so they are a more stable
then the "8.3" images on http://beagleboard.org/latest-images

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

Re: [beagleboard] bbb Internal ADC configuration settings?

[Audrey]

Thanks John, do you know where to get kernel 4.1? This is the only place I 
know that has beaglebone images, but they don't specify which kernel each 
version has: http://beagleboard.org/latest-images

I know that my beaglebone has the 
image BBB-eMMC-flasher-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz

On Saturday, March 19, 2016 at 4:15:04 PM UTC-4, john3909 wrote:
>
> Yeah, that is what I thought. IIO on the 3.8 kernel didn’t have a lot of 
> features and this is why you are having difficulty using it. I would 
> recommend upgrading to the 4.1 kernel or even the 4.4 kernel. I personally 
> use the 4.1 kernel, but I back ported IIO from the IIO-next kernel so that 
> I am using the latest IIO which includes DMA framework support. 
>
> Regards,
> John
>
>
>
>
> On Mar 19, 2016, at 9:46 AM, Audrey > wrote:
>
> Hi William, I did read that article you sent me. I was unable to follow 
> the Driver Configuration bit, but as far as the continuous mode is 
> concerned, after careful re-reading of the article, I think I understand 
> that you are trying to tell me that I should be in the /dev/iio:device0 
> directory to read the continuous mode. However, my problem is that buffer, 
> scan_elements, and mode, which the article says are used to set up the 
> continuous mode, should be in the /sys/bus/iio/devices/iio:device0 
> directory. And that was where I was in, but I could not find them, which is 
> my current problem. 
>
> John3909, my kernel version is 3.8.13-bone70.
>
> I think if this doesn't pan out, I will be looking into using the PRU, 
> although I would like to understand the current system better before moving 
> on to something more complicated.
>
> Thanks everyone for your help!
>
> On Friday, March 18, 2016 at 5:59:01 PM UTC-4, William Hermans wrote:
>>
>> Audrey,
>>
>> Please read the link I gave you a couple weeks ago . . . 
>> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Continuous_Mode
>>
>> Everything you need to know to use the ADC is explained on this page. But 
>> from your last post, and the paths you've shown us. You're in the wrong 
>> directory. Essentially, you're still in the one-shot directories, which are 
>> completely separate from the continuous mode directory structure.
>>
>> On Fri, Mar 18, 2016 at 1:46 PM, John Syne  wrote:
>>
>>> What is your kernel version?
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Mar 18, 2016, at 1:22 PM, Audrey  wrote:
>>>
>>> It says:
>>> root@beaglebone:/# echo 1 > 
>>> /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>>> -bash: /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en: No 
>>> such file or directory
>>>
>>> and I can't find scan_elements in sys/bus/iio/devices/iio:device0
>>> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
>>> total 0
>>> -r--r--r-- 1 root root 4096 Mar  1 21:13 dev
>>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage0_raw
>>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage1_raw
>>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage2_raw
>>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage3_raw
>>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage4_raw
>>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage5_raw
>>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage6_raw
>>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage7_raw
>>> -r--r--r-- 1 root root 4096 Mar  1 21:13 name
>>> drwxr-xr-x 2 root root0 Mar  1 21:13 power
>>> lrwxrwxrwx 1 root root0 Mar  1 20:47 subsystem -> 
>>> ../../../../../bus/iio
>>> -rw-r--r-- 1 root root 4096 Mar  1 20:47 uevent
>>>
>>>
>>> On Friday, March 18, 2016 at 4:15:00 PM UTC-4, john3909 wrote:


 On Mar 18, 2016, at 1:06 PM, Audrey  wrote:

 Hm. 

 Sorry, but unfortunately I'm still quite a bit lost. What should I be 
 doing to dev/iio:device0 (open?) in order to do the following:
 echo 1 > in_voltage0_en

 From memory, 

 echo 1 > /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en

 echo 1 > buffer/enable

 echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable

 Regards,
 John


 I'm assuming that I should be able to see in_voltage0_en and buffer in 
 the folder /sys/bus/iio/devices/iio:device0 but I currently do not see 
 those attributes/drivers/folders/buffers/whatever-you-want-to-call-them.

 Typing 
 root@beaglebone:/dev# open iio:device0
 doesn't seem to do anything.

 Do you think you could break your steps down even further?

 Thanks.

 On Friday, March 18, 2016 at 3:49:39 PM UTC-4, john3909 wrote:
>
> It is a driver, so you can open, poll and read from /dev/iio:device0
>
> For a quick test, do the following: After you enable the various 
> scan_channels, start the buffer and then do the following:
>
> dd if=/dev/iio:device0 of=~/test.txt
>
> Press ctrl-C to stop capture.
>
> Use hexdump to view the file

Re: [beagleboard] Remove graphical desktop packages from Debian image

[Robert Nelson]

On Mon, Mar 21, 2016 at 2:41 PM, David Good  wrote:
> 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?).

sudo apt-get remove lxqt-* xserver* --purge

But there's a lot of extra cruft..

For next time, take a look at:

iot image:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

Re: [beagleboard] gpio48 on a Bacon Cape Rev A on a Beaglebone Black Rev B

[Paul Wolfson]

*Oops*, missed an update to the script.  Thanks!

7c7
< clr=/sys/class/gpio/gpio48
---
> clr=/sys/class/gpio/gpio48
34a35,38
>
> # [NJO CHANGE] Set GPIO48 as an output
> echo 48 > /sys/class/gpio/export
> echo out > ${clr}/direction


-
Paul Wolfson, Ph.D., TX LPI, #A17473
Dallas Legal Technology
3402 Oak Grove Avenue, Suite 300-A
Dallas, Texas 75204-2353


*214-257-0984 (Tel)214-838-7220 (Fax)Send me an email. *
-
The contents of this email are confidential to the sender and the ordinary
user of the email address to which it was addressed, and may also be
privileged.  If you are not the addressee of the email, you may not copy,
forward, disclose or otherwise use it or any part of it in any form
whatsoever.  If you have received this email in error, please advise the
sender at  214-257-0984.  Thank you.
-

On Mon, Mar 21, 2016 at 2:09 PM, Paul Wolfson  wrote:

>
> I just purchased a Bacon Cape to play with and I am having trouble with
> initial diagnostics.   The bash test script
> https://github.com/SoCM/Embedded/blob/master/common/scripts-for-BBB/BBB/Bacon-test.sh
> complains that gpio48 is undefined.   As a result the character display
> tests are failing - quick hint -- hopefully something very simple?
>
> *bash constant definitions:*
>
> cape="BB-BONE-BACONE"
> clk=/sys/class/gpio/gpio2
> serial=/sys/class/gpio/gpio4
> latch=/sys/class/gpio/gpio5
> clr=/sys/class/gpio/gpio48
> button=/sys/class/gpio/gpio22
> red=/sys/class/pwm/pwm0
> green=/sys/class/pwm/pwm1
> blue=/sys/class/pwm/pwm2
> pot=/sys/devices/ocp*/bacon_adc_helper*/AIN5
> pot_min=0
> pot_max=180
>
>
> *output:*
>
> Red PWM
> Green PWM
> Blue PWM
> 7 segment display all off
> 7 segment display all on
> 7 segment display digit check
> 7 segment display digit check (with a dot)
> Press button to continue
> button pressed
> Slider test (press button to exit)
> total 0
>
>
> *pseudo device listing:*
>
> --w--- 1 root root 4096 Dec 31  1999 export
> lrwxrwxrwx 1 root root0 Mar 21 11:06 gpio2 ->
> ../../devices/virtual/gpio/gpio2
> lrwxrwxrwx 1 root root0 Mar 21 11:06 gpio22 ->
> ../../devices/virtual/gpio/gpio22
> lrwxrwxrwx 1 root root0 Mar 21 11:06 gpio4 ->
> ../../devices/virtual/gpio/gpio4
> lrwxrwxrwx 1 root root0 Mar 21 11:06 gpio5 ->
> ../../devices/virtual/gpio/gpio5
> ... no gpio48 port here?
> ...
> lrwxrwxrwx 1 root root0 Dec 31  1999 gpiochip0 ->
> ../../devices/virtual/gpio/gpiochip0
> lrwxrwxrwx 1 root root0 Dec 31  1999 gpiochip32 ->
> ../../devices/virtual/gpio/gpiochip32
> lrwxrwxrwx 1 root root0 Dec 31  1999 gpiochip64 ->
> ../../devices/virtual/gpio/gpiochip64
> lrwxrwxrwx 1 root root0 Dec 31  1999 gpiochip96 ->
> ../../devices/virtual/gpio/gpiochip96
> --w--- 1 root root 4096 Dec 31  1999 unexport
>
>
> TIA
> Paul Wolfson
> Dallas
>
> --
> 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] 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]

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 slot per digit plus one.  Use that time to allow synchronized
refresh to the display itself."

When you say "digit", I assume you are thinking in terms of a multiplexed
7-segment readout style display, which in my case would be the same thing
as a row.  My driver operates on one row at a time before going to sleep.
Are you suggesting that I scan through all 8 rows and then have a special
9th "row" time where I do things like the memcpy?  This would be pretty
close to a VSYNC idea, right?  I suppose that this 9th "row" wouldn't have
to wait a full row time, but could schedule the next row sooner.  Hmm

You are totally right about MCUs and burning the LEDs.  This particular
display is safe because the LEDs are not being over-driven.  Your idea
about a CPLD is a good one.  I've never used them, but have know about
them.  I found this XC2C32A for $1.8USD.  I will probably try this out at
some point just for educational purposes :)

http://www.digikey.com/product-detail/en/xilinx-inc/XC2C32A-6VQG44I/122-1704-ND/1952030

--David


On Mon, Mar 21, 2016 at 12:28 PM, Harvey White 
wrote:

> 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(TASK_RUNNING)
>
> For state 2, I'd be tempted to do a non-interruptible write to the
> display memory (or protect it by a semaphore).  You want to interlock
> the process so that you have a safe zone to write new data to the
> memory.
> >2> If new data is ready in RAM, memcpy it to the real display buffer in
> RAM.
>
> This should not cause a problem unless the data changes somehow.
> >3> Serially shift out next row data in the background, but do not latch
> yet
> >(background)
>
> This may be too fast for you to see, and you don't want it slow.
>
> >4> Blank the display - This is not actually working right now.  I never
> see
> >the blank line move. Hmm
>
> I'm assuming you have the data for the new row in the buffer, of
> course,
>
> >5> Adjust the multiplexed row select pins to the next row (A2...A0)
> >6> Latch the data already in the serial buffers
>
> Problem with blanking and unblanking the whole display could cause
> flicker.
> >7> Unblank the display
> >8> set_current_state(TASK_INTERRUPTIBLE)
> >9> usleep until time to update next row
> >
> >I wanted to spend a little time as possible with the LEDs off, which is
> why
> >I'm shifting data while the LEDs are still showing the current row data.
>
> That shouldn't be a problem at all, the chip is designed for it.
>
> >Using this technique, I've seen ghosting issues when a mcu is very fast as
> >the drivers themselves need a little time to switch the state of their
> >outputs, and also the high-side switching power transistors sometimes need
> >some time to fully turn off.  I don't think that's what I'm seeing here
> >though.
>
> Let's assume that it is a problem, so you can fix that.
> >
> >The display artifacts that I see look like stuttering on the display when
> >the processor gets busy.  I suspect that this is due to inconsistent
> usleep
> >times (Linux isn't an RTOS) but I'm still trying to catch it with my logic
> >analyzer.
> >
>
> I've had similar task interlocking problems with an RTOS, but I'd
> suggest a slightly different approach.
>
> >My basic question is this: Does the Linux kernel "usually" do this kind of
> >bit-banged driver for other things (I2C, video, framebuffers, audio, etc.)
> >or does it "usually" pass these tasks off to hardware peripherals?  The
> >question behind the question is: Am I doing this the "usual" way or am I
> >trying something very specialized.
>
> Not an expert on Linux at all, but it depends on the data rates, and
> whether or not there's hardware available to do it.
>
> >
> >My goal is to look into the framebuffer 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

Re: [beagleboard] Debian Jessie image BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb no ethernet.

[Daniel Benevides]

Robert,

It appears to be ignoring dhcp. And only gets an IPV6 address.

Note that this same BBB but with
the BBB-eMMC-flasher-debian-7.9-lxde-4gb-armhf-2015-11-03-4gb image and the
same network cable works, getting the 192.168.20.79 address via DHCP.

But it keeps not working with this Debian Jessie
image: BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb.

That's what I've done this time:

*- I modified the /etc/interfaces file and tested eth0 with "dhcp" and
"auto" parameters:*

auto eth0
allow-hotplug eth0

iface eth0 inet dhcp *(auto)*


*- The ifconfig eth0 command returns this:*

eth0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f0
  inet6 addr: fe80::564a:16ff:fef0:f1f0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:170 errors:0 dropped:0 overruns:0 frame:0
  TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:20587 (20.1 KiB)  TX bytes:7360 (7.1 KiB)
  Interrupt:175

*- The route -n command returns this:*

Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
192.168.7.0 0.0.0.0 255.255.255.252 U 0  00 usb0

Any suggestions?

Thanks...

Regards,

Daniel.


2016-03-21 14:09 GMT-03:00 Robert Nelson :

> On Mon, Mar 21, 2016 at 11:59 AM, Daniel Benevides
>  wrote:
> > Hello Robert...
> >
> > Thank you for answering so quickly.
> >
> > Unfortunately, the problem remains.
> >
> > Via eth0 I cannot access the BBB from the network nor from it I can reach
> > any IP destination on my network.
> >
> > What I did:
> >
> > 1) I flashed the BBB again, with the
> > BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb image.
> >
> > 2) I removed connman (apt-get remove connman).
> >
> > 3) I updated the interfaces file:
> >
> > # The loopback network interface
> > auto lo
> > iface lo inet loopback
> >
> > # The primary network interface
> > auto eth0
> > allow-hotplug eth0
> >
> > iface eth0 inet static
> >  address 192.168.20.79
> >  netmask 255.255.255.0
> >  network 192.168.20.0
> >  broadcast 192.168.20.255
> >  gateway 192.168.20.1
> >  dns-name-servers 192.168.20.200
> >
> > # Ethernet/RNDIS gadget (g_ether)
> > # Used by: /opt/scripts/boot/autoconfigure_usb0.sh
> > iface usb0 inet static
> > address 192.168.7.2
> > netmask 255.255.255.252nor
> > network 192.168.7.0
> > gateway 192.168.7.1
> >
> > 4) Turned off the BBB and turned it on.
> >
> > 5) Tried to connect to the BBB using PuTTY on the IP 192.168.20.79, but
> with
> > no luck.
> >
> > 6) Also plugged and unplugged the network cable -- with no luck also.
> >
> > 7) Over serial connection, the BBB shows me this welcome message (using
> > PuTTY):
> >
> > Debian GNU/Linux 8 beaglebone ttyGS0
> >
> > BeagleBoard.org Debian Image 2016-03-13
> >
> > Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian
> >
> > default username:password is [debian:temppwd]
> >
> > The IP Address for eth0 is: 192.168.20.79
> > The IP Address for usb0 is: 192.168.7.2
> > beaglebone login:
> >
> >
> > -- The /etc/resolv.conf file is empty.
> >
> > -- The ifconfig command returns this:
> >
> > eth0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f0
> >   inet addr:192.168.20.79  Bcast:192.168.20.255
> Mask:255.255.255.0
> >   inet6 addr: fe80::564a:16ff:fef0:f1f0/64 Scope:Link
> >   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >   RX packets:1432 errors:0 dropped:3 overruns:0 frame:0
> >   TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
> >   collisions:0 txqueuelen:1000
> >   RX bytes:163999 (160.1 KiB)  TX bytes:7927 (7.7 KiB)
> >   Interrupt:175
> >
> > loLink encap:Local Loopback
> >   inet addr:127.0.0.1  Mask:255.0.0.0
> >   inet6 addr: ::1/128 Scope:Host
> >   UP LOOPBACK RUNNING  MTU:65536  Metric:1
> >   RX packets:6087 errors:0 dropped:0 overruns:0 frame:0
> >   TX packets:6087 errors:0 dropped:0 overruns:0 carrier:0
> >   collisions:0 txqueuelen:0
> >   RX bytes:492956 (481.4 KiB)  TX bytes:492956 (481.4 KiB)
> >
> > usb0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f1
> >   inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
> >   inet6 addr: fe80::564a:16ff:fef0:f1f1/64 Scope:Link
> >   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >   RX packets:799 errors:0 dropped:5 overruns:0 frame:0
> >   TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
> >   collisions:0 txqueuelen:1000
> >   RX bytes:119293 (116.4 KiB)  TX bytes:9570 (9.3 KiB)
> >
> >
> > -- The route -n command returns this:
> >
> > Kernel IP routing table
> > Destination Gateway Genmask Flags Metric RefUse
> > Iface
> > 0.0.0.0 192.168.20.10.0.0.0 UG0

[beagleboard] gpio48 on a Bacon Cape Rev A on a Beaglebone Black Rev B

[Paul Wolfson]

I just purchased a Bacon Cape to play with and I am having trouble with 
initial diagnostics.   The bash test 
script 
https://github.com/SoCM/Embedded/blob/master/common/scripts-for-BBB/BBB/Bacon-test.sh
 
complains that gpio48 is undefined.   As a result the character display 
tests are failing - quick hint -- hopefully something very simple?

*bash constant definitions:*

cape="BB-BONE-BACONE"
clk=/sys/class/gpio/gpio2
serial=/sys/class/gpio/gpio4
latch=/sys/class/gpio/gpio5
clr=/sys/class/gpio/gpio48
button=/sys/class/gpio/gpio22
red=/sys/class/pwm/pwm0
green=/sys/class/pwm/pwm1
blue=/sys/class/pwm/pwm2
pot=/sys/devices/ocp*/bacon_adc_helper*/AIN5
pot_min=0
pot_max=180


*output:*

Red PWM
Green PWM
Blue PWM
7 segment display all off
7 segment display all on
7 segment display digit check
7 segment display digit check (with a dot)
Press button to continue
button pressed
Slider test (press button to exit)
total 0


*pseudo device listing:*

--w--- 1 root root 4096 Dec 31  1999 export
lrwxrwxrwx 1 root root0 Mar 21 11:06 gpio2 -> 
../../devices/virtual/gpio/gpio2
lrwxrwxrwx 1 root root0 Mar 21 11:06 gpio22 -> 
../../devices/virtual/gpio/gpio22
lrwxrwxrwx 1 root root0 Mar 21 11:06 gpio4 -> 
../../devices/virtual/gpio/gpio4
lrwxrwxrwx 1 root root0 Mar 21 11:06 gpio5 -> 
../../devices/virtual/gpio/gpio5
... no gpio48 port here? 
...
lrwxrwxrwx 1 root root0 Dec 31  1999 gpiochip0 -> 
../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx 1 root root0 Dec 31  1999 gpiochip32 -> 
../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx 1 root root0 Dec 31  1999 gpiochip64 -> 
../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx 1 root root0 Dec 31  1999 gpiochip96 -> 
../../devices/virtual/gpio/gpiochip96
--w--- 1 root root 4096 Dec 31  1999 unexport


TIA
Paul Wolfson
Dallas 

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

[Harvey White]

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(TASK_RUNNING)

For state 2, I'd be tempted to do a non-interruptible write to the
display memory (or protect it by a semaphore).  You want to interlock
the process so that you have a safe zone to write new data to the
memory.
>2> If new data is ready in RAM, memcpy it to the real display buffer in RAM.

This should not cause a problem unless the data changes somehow.
>3> Serially shift out next row data in the background, but do not latch yet
>(background)

This may be too fast for you to see, and you don't want it slow.

>4> Blank the display - This is not actually working right now.  I never see
>the blank line move. Hmm

I'm assuming you have the data for the new row in the buffer, of
course,

>5> Adjust the multiplexed row select pins to the next row (A2...A0)
>6> Latch the data already in the serial buffers

Problem with blanking and unblanking the whole display could cause
flicker.
>7> Unblank the display
>8> set_current_state(TASK_INTERRUPTIBLE)
>9> usleep until time to update next row
>
>I wanted to spend a little time as possible with the LEDs off, which is why
>I'm shifting data while the LEDs are still showing the current row data.

That shouldn't be a problem at all, the chip is designed for it.

>Using this technique, I've seen ghosting issues when a mcu is very fast as
>the drivers themselves need a little time to switch the state of their
>outputs, and also the high-side switching power transistors sometimes need
>some time to fully turn off.  I don't think that's what I'm seeing here
>though.

Let's assume that it is a problem, so you can fix that.
>
>The display artifacts that I see look like stuttering on the display when
>the processor gets busy.  I suspect that this is due to inconsistent usleep
>times (Linux isn't an RTOS) but I'm still trying to catch it with my logic
>analyzer.
>

I've had similar task interlocking problems with an RTOS, but I'd
suggest a slightly different approach.

>My basic question is this: Does the Linux kernel "usually" do this kind of
>bit-banged driver for other things (I2C, video, framebuffers, audio, etc.)
>or does it "usually" pass these tasks off to hardware peripherals?  The
>question behind the question is: Am I doing this the "usual" way or am I
>trying something very specialized.

Not an expert on Linux at all, but it depends on the data rates, and
whether or not there's hardware available to do it.  

>
>My goal is to look into the framebuffer 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

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] Debian Jessie image BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb no ethernet.

[Robert Nelson]

On Mon, Mar 21, 2016 at 11:59 AM, Daniel Benevides
 wrote:
> Hello Robert...
>
> Thank you for answering so quickly.
>
> Unfortunately, the problem remains.
>
> Via eth0 I cannot access the BBB from the network nor from it I can reach
> any IP destination on my network.
>
> What I did:
>
> 1) I flashed the BBB again, with the
> BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb image.
>
> 2) I removed connman (apt-get remove connman).
>
> 3) I updated the interfaces file:
>
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
> # The primary network interface
> auto eth0
> allow-hotplug eth0
>
> iface eth0 inet static
>  address 192.168.20.79
>  netmask 255.255.255.0
>  network 192.168.20.0
>  broadcast 192.168.20.255
>  gateway 192.168.20.1
>  dns-name-servers 192.168.20.200
>
> # Ethernet/RNDIS gadget (g_ether)
> # Used by: /opt/scripts/boot/autoconfigure_usb0.sh
> iface usb0 inet static
> address 192.168.7.2
> netmask 255.255.255.252nor
> network 192.168.7.0
> gateway 192.168.7.1
>
> 4) Turned off the BBB and turned it on.
>
> 5) Tried to connect to the BBB using PuTTY on the IP 192.168.20.79, but with
> no luck.
>
> 6) Also plugged and unplugged the network cable -- with no luck also.
>
> 7) Over serial connection, the BBB shows me this welcome message (using
> PuTTY):
>
> Debian GNU/Linux 8 beaglebone ttyGS0
>
> BeagleBoard.org Debian Image 2016-03-13
>
> Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian
>
> default username:password is [debian:temppwd]
>
> The IP Address for eth0 is: 192.168.20.79
> The IP Address for usb0 is: 192.168.7.2
> beaglebone login:
>
>
> -- The /etc/resolv.conf file is empty.
>
> -- The ifconfig command returns this:
>
> eth0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f0
>   inet addr:192.168.20.79  Bcast:192.168.20.255  Mask:255.255.255.0
>   inet6 addr: fe80::564a:16ff:fef0:f1f0/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1432 errors:0 dropped:3 overruns:0 frame:0
>   TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:163999 (160.1 KiB)  TX bytes:7927 (7.7 KiB)
>   Interrupt:175
>
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:6087 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:6087 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:492956 (481.4 KiB)  TX bytes:492956 (481.4 KiB)
>
> usb0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f1
>   inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
>   inet6 addr: fe80::564a:16ff:fef0:f1f1/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:799 errors:0 dropped:5 overruns:0 frame:0
>   TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:119293 (116.4 KiB)  TX bytes:9570 (9.3 KiB)
>
>
> -- The route -n command returns this:
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> 0.0.0.0 192.168.20.10.0.0.0 UG0  00 eth0
> 192.168.7.0 0.0.0.0 255.255.255.252 U 0  00 usb0
> 192.168.20.00.0.0.0 255.255.255.0   U 0  00 eth0
>
>
> -- The iptables -L command returns this:
>
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
>
>
> Do you have any other ideas on how to solve this?

Not really, as i never use static routes.  But what you have now
'should' work...

I guess, are you sure your cable is correct, (aka a cross over)...

Otherwise, I'd just stick the beagle's mac into your dhcp server. ;)

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

Re: [beagleboard] Debian Jessie image BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb no ethernet.

[Daniel Benevides]

Hello Robert...

Thank you for answering so quickly.

Unfortunately, the problem remains.

Via eth0 I cannot access the BBB from the network nor from it I can reach
any IP destination on my network.

What I did:

*1) I flashed the BBB again, with
the BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb image.*

*2) I removed connman (*apt-get remove connman*).*

*3) I updated the interfaces file:*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
allow-hotplug eth0

iface eth0 inet static
 address 192.168.20.79
 netmask 255.255.255.0
 network 192.168.20.0
 broadcast 192.168.20.255
 gateway 192.168.20.1
 dns-name-servers 192.168.20.200

# Ethernet/RNDIS gadget (g_ether)
# Used by: /opt/scripts/boot/autoconfigure_usb0.sh
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.252nor
network 192.168.7.0
gateway 192.168.7.1

*4) Turned off the BBB and turned it on.*

*5) Tried to connect to the BBB using PuTTY on the IP 192.168.20.79, but
with no luck.*

*6) Also plugged and unplugged the network cable -- with no luck also.*

*7) Over serial connection, the BBB shows me this welcome message (using
PuTTY):*

Debian GNU/Linux 8 beaglebone ttyGS0

BeagleBoard.org Debian Image 2016-03-13

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

default username:password is [debian:temppwd]

The IP Address for eth0 is: 192.168.20.79
The IP Address for usb0 is: 192.168.7.2
beaglebone login:


-- The /etc/resolv.conf file is empty.

*-- The ifconfig command returns this:*

eth0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f0
  inet addr:192.168.20.79  Bcast:192.168.20.255  Mask:255.255.255.0
  inet6 addr: fe80::564a:16ff:fef0:f1f0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1432 errors:0 dropped:3 overruns:0 frame:0
  TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:163999 (160.1 KiB)  TX bytes:7927 (7.7 KiB)
  Interrupt:175

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:6087 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6087 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:492956 (481.4 KiB)  TX bytes:492956 (481.4 KiB)

usb0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f1
  inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
  inet6 addr: fe80::564a:16ff:fef0:f1f1/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:799 errors:0 dropped:5 overruns:0 frame:0
  TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:119293 (116.4 KiB)  TX bytes:9570 (9.3 KiB)


*-- The route -n command returns this:*

Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
0.0.0.0 192.168.20.10.0.0.0 UG0  00 eth0
192.168.7.0 0.0.0.0 255.255.255.252 U 0  00 usb0
192.168.20.00.0.0.0 255.255.255.0   U 0  00 eth0


-- The iptables -L command returns this:

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination


*Do you have any other ideas on how to solve this?*

Thank you again!

Regards,

Daniel.



2016-03-21 10:44 GMT-03:00 Robert Nelson :

> On Mon, Mar 21, 2016 at 8:36 AM, Daniel Benevides
>  wrote:
> > Hello,
> >
> > I'm a newbie with beaglebones black running debian...
> >
> > The problem arises with a beaglebone black rev c and the image
> > BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb.img, but also
> happened
> > with BBB-eMMC-flasher-debian-8.3-lxqt-4gb-armhf-2016-03-13-4gb.img.
> >
> > I cannot access the network through eth0.
> >
> > The same beaglebone worked with a debian wheezy image installed...
> >
> > Here is the problem:
> >
> > I've found the instructions on the thread
> > https://groups.google.com/forum/#!topic/beagleboard/7pex-V9vYWw and
> removed
> > connman, but the problem remains.
> >
> > I have the following configuration on the beaglebone:
> >
> >  /etc/network/interfaces file:
> >
> > auto lo
> > iface lo inet loopback
> >
> > allow-hotplug eth0
>
> ^^^  So remove your network cable and plug it back in.. Otherwise do
> it this way:
>
> auto eth0
> allow-hotplug eth0
>
> iface eth0 inet static
>  address 192.168.20.79
>  netmask 255.255.255.0
>  network 192.168.20.0
>  broadcast 192.168.20.255
>  gateway 192.16

Re: [beagleboard] User LEDs stop blinking

[Gerald Coley]

Sounds like you damaged the processor. It will need to be replaced/

http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage

Gerald

On Mon, Mar 21, 2016 at 10:25 AM,  wrote:

> We are using a beaglebone black Rev A5C for our project. Mpu 6050 and
> ultrasonic sensor HCSR04 was interfaced at the time of operating when it
> showed an error and the putty session got terminated.  When  I plugged in
> again the user leds didn't turn on!!! Tried several times and also tried
> booting it again and powering it up with adapter as well. None of the abv
> worked. Only the PWR led glows for a sec at the instant when I connect the
> USB then no other activity happens. ( Pressing the power switch the led
> lights up for a sec)
> Please help
>
> 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.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.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.

[beagleboard] User LEDs stop blinking

[shwetamaste94]

We are using a beaglebone black Rev A5C for our project. Mpu 6050 and 
ultrasonic sensor HCSR04 was interfaced at the time of operating when it showed 
an error and the putty session got terminated.  When  I plugged in again the 
user leds didn't turn on!!! Tried several times and also tried booting it again 
and powering it up with adapter as well. None of the abv worked. Only the PWR 
led glows for a sec at the instant when I connect the USB then no other 
activity happens. ( Pressing the power switch the led lights up for a sec)
Please help

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.

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

[David Good]

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 to the real display buffer in RAM.
3> Serially shift out next row data in the background, but do not latch yet
(background)
4> Blank the display - This is not actually working right now.  I never see
the blank line move. Hmm
5> Adjust the multiplexed row select pins to the next row (A2...A0)
6> Latch the data already in the serial buffers
7> Unblank the display
8> set_current_state(TASK_INTERRUPTIBLE)
9> usleep until time to update next row

I wanted to spend a little time as possible with the LEDs off, which is why
I'm shifting data while the LEDs are still showing the current row data.
Using this technique, I've seen ghosting issues when a mcu is very fast as
the drivers themselves need a little time to switch the state of their
outputs, and also the high-side switching power transistors sometimes need
some time to fully turn off.  I don't think that's what I'm seeing here
though.

The display artifacts that I see look like stuttering on the display when
the processor gets busy.  I suspect that this is due to inconsistent usleep
times (Linux isn't an RTOS) but I'm still trying to catch it with my logic
analyzer.

My basic question is this: Does the Linux kernel "usually" do this kind of
bit-banged driver for other things (I2C, video, framebuffers, audio, etc.)
or does it "usually" pass these tasks off to hardware peripherals?  The
question behind the question is: Am I doing this the "usual" way or am I
trying something very specialized.

My goal is to look into the framebuffer devices and see if I can learn
anything there, but kernel programming is very new to me.

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?"
>
> Harvey
>
>
>
> >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

Re: [beagleboard] Re: GSoC Project: a realtime audio effects Box

[Valentin Le bescond]

"bachelor thesis about acoustic measurements". Cool, can I read it ?

I've built a sound level monitoring station with a raspberry pi and a
wolfson audio card (with added IEPE bias).
Then it's all the ALSA API for capture and Qt for the rest on the software
side (IIR Filters, Network stuff etc.).
I didn't implement playback though.

Actually I wanted to do it with the BBB first but the audio cape was
nowhere to be found in stock !!


Le lun. 21 mars 2016 à 16:34, 'Johannes Wegener' via BeagleBoard <
beagleboard@googlegroups.com> a écrit :

> Hi,
> thank you for your reply!
>
>
> Am Montag, 21. März 2016 10:33:16 UTC+1 schrieb Oolav:
>>
>> Well I'd love to see that ! The "acoustic measurement box" especially...
>>
>
> If there are more people interested in this - I could easy try to focus
> this project around that. I have quite some experience with that topic
> since I wrote my bachelor thesis about acoustic measurements!
>
>
>>
>> I have done similar things already with a raspberry pi if you need help.
>>
> Interesting! What did you use in terms of hardware/software?
>
> Regards,
> Johannes
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/M__bEuvgvOA/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Debian Jessie (armhf) and wxPython

[Mark A. Yoder]

I have a bigger question Robert.  How do you know which version goes with 
which release?  Is there a web site I could check?

--Mark

On Monday, March 21, 2016 at 10:25:00 AM UTC-4, RobertCNelson wrote:
>
> On Mon, Mar 21, 2016 at 9:16 AM, Robert Jonathan Šimon 
> > wrote: 
> > Hi, 
> > I tried to use this package on my Beaglebone black with Debian Jessie, 
> but 
> > it ran with this error "E: Package 'python-wxgtk2.8' has no installation 
> > candidate". Does anyone know how to fix this? I tried to google it, but 
> I 
> > couldn't find anything. 
>
> Debain (8.x) Jessie has: python-wxgtk3.0 
>
> Debian (7.x) Wheezy was the last version with python-wxgtk2.8 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.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.

[beagleboard] problem replicape delta printer, z-probing

[lenny72]

Hi,

I've started using the beaglebone recently and bought the replicape rev B3 
to hook it to a delta printer.

I am wondering if anyone is also having problems with getting the z-probe 
to work? I use a inductive 5v end-stop. On the hardware side everything is 
working, it shows in the terminal when i trigger the z-probe. But doesn't 
react when it is probing.

I connected the probe to z2, and modified the config file:
"end_stop_Z2_stops = x_ccw, y_ccw, z_ccw".

Any help would be appreciated

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian Jessie (armhf) and wxPython

[Robert Nelson]

On Mon, Mar 21, 2016 at 11:11 AM, Mark A. Yoder  wrote:
> I have a bigger question Robert.  How do you know which version goes with
> which release?  Is there a web site I could check?

The easy way:

https://packages.debian.org/name

"name" = search term:

So:

https://packages.debian.org/python-wxgtk

Shows:

wheezy: python-wxgtk2.8

jessie/stretch: python-wxgtk3.0

(ignore sid, python-wxgtk2.8, that's just a package 'left/stuck' in
the repo for one arch)

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

[beagleboard] Re: GSoC Project: a realtime audio effects Box

['Johannes Wegener' via BeagleBoard]

Hi,
thank you for your reply!

Am Montag, 21. März 2016 10:33:16 UTC+1 schrieb Oolav:
>
> Well I'd love to see that ! The "acoustic measurement box" especially...
>

If there are more people interested in this - I could easy try to focus 
this project around that. I have quite some experience with that topic 
since I wrote my bachelor thesis about acoustic measurements! 
 

>
> I have done similar things already with a raspberry pi if you need help.
>
Interesting! What did you use in terms of hardware/software?

Regards,
Johannes 

-- 
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] Debian Jessie (armhf) and wxPython

[Robert Nelson]

On Mon, Mar 21, 2016 at 9:31 AM, Robert Jonathan Šimon
 wrote:
> I read, hat it is kbackwards incopatible is it true? I need it to use it
> with Printrun (to control my 3D printer

No, you'll need to rebuild your application.. (or just use wheezy, as
both wheezy/jessie are supported)..

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

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

[Harvey White]

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?"

Harvey



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

Re: [beagleboard] Debian Jessie (armhf) and wxPython

[Robert Jonathan Šimon]

I read, hat it is kbackwards incopatible is it true? I need it to use it 
with Printrun (to control my 3D printer

Dne pondělí 21. března 2016 15:25:00 UTC+1 RobertCNelson napsal(a):
>
> On Mon, Mar 21, 2016 at 9:16 AM, Robert Jonathan Šimon 
> > wrote: 
> > Hi, 
> > I tried to use this package on my Beaglebone black with Debian Jessie, 
> but 
> > it ran with this error "E: Package 'python-wxgtk2.8' has no installation 
> > candidate". Does anyone know how to fix this? I tried to google it, but 
> I 
> > couldn't find anything. 
>
> Debain (8.x) Jessie has: python-wxgtk3.0 
>
> Debian (7.x) Wheezy was the last version with python-wxgtk2.8 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.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.

Re: [beagleboard] Debian Jessie (armhf) and wxPython

[Robert Nelson]

On Mon, Mar 21, 2016 at 9:16 AM, Robert Jonathan Šimon
 wrote:
> Hi,
> I tried to use this package on my Beaglebone black with Debian Jessie, but
> it ran with this error "E: Package 'python-wxgtk2.8' has no installation
> candidate". Does anyone know how to fix this? I tried to google it, but I
> couldn't find anything.

Debain (8.x) Jessie has: python-wxgtk3.0

Debian (7.x) Wheezy was the last version with python-wxgtk2.8

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

[beagleboard] Debian Jessie (armhf) and wxPython

[Robert Jonathan Šimon]

Hi,
I tried to use this package on my Beaglebone black with Debian Jessie, but 
it ran with this error "E: Package 'python-wxgtk2.8' has no installation 
candidate". Does anyone know how to fix this? I tried to google it, but I 
couldn't find anything.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Install Custom Kernel

[Greg]

Try this:

https://eewiki.net/display/linuxonarm/BeagleBone+Black

I've used the steps in this guide and created a good microSD to boot into 
Debian on the BBB.
Very concise and well done series of steps on this web page.

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

Re: [beagleboard] Debian Jessie image BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb no ethernet.

[Robert Nelson]

On Mon, Mar 21, 2016 at 8:36 AM, Daniel Benevides
 wrote:
> Hello,
>
> I'm a newbie with beaglebones black running debian...
>
> The problem arises with a beaglebone black rev c and the image
> BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb.img, but also happened
> with BBB-eMMC-flasher-debian-8.3-lxqt-4gb-armhf-2016-03-13-4gb.img.
>
> I cannot access the network through eth0.
>
> The same beaglebone worked with a debian wheezy image installed...
>
> Here is the problem:
>
> I've found the instructions on the thread
> https://groups.google.com/forum/#!topic/beagleboard/7pex-V9vYWw and removed
> connman, but the problem remains.
>
> I have the following configuration on the beaglebone:
>
>  /etc/network/interfaces file:
>
> auto lo
> iface lo inet loopback
>
> allow-hotplug eth0

^^^  So remove your network cable and plug it back in.. Otherwise do
it this way:

auto eth0
allow-hotplug eth0

iface eth0 inet static
 address 192.168.20.79
 netmask 255.255.255.0
 network 192.168.20.0
 broadcast 192.168.20.255
 gateway 192.168.20.1
 dns-name-servers 192.168.20.200

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

[beagleboard] Debian Jessie image BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb no ethernet.

[Daniel Benevides]

Hello,

I'm a newbie with beaglebones black running debian...

The problem arises with a beaglebone black rev c and the 
image BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb.img, but also 
happened with BBB-eMMC-flasher-debian-8.3-lxqt-4gb-armhf-2016-03-13-4gb.img.

I cannot access the network through eth0.

The same beaglebone worked with a debian wheezy image installed...

Here is the problem:

I've found the instructions on the thread 
https://groups.google.com/forum/#!topic/beagleboard/7pex-V9vYWw and removed 
connman, but the problem remains.

I have the following configuration on the beaglebone:

* /etc/network/interfaces file:*

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
address 192.168.20.79
netmask 255.255.255.0
network 192.168.20.0
broadcast 192.168.20.255
gateway 192.168.20.1
dns-name-servers 192.168.20.200

iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.252
network 192.168.7.0
gateway 192.168.7.1


* /etc/resolv.conf:*

nameserver 192.168.20.200
nameserver 8.8.8.8
nameserver 4.4.4.4

* ifconfig command returns:*

eth0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f0
  inet addr:192.168.20.79  Bcast:192.168.20.255  Mask:255.255.255.0
  inet6 addr: fe80::564a:16ff:fef0:f1f0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2652 errors:0 dropped:1 overruns:0 frame:0
  TX packets:2218 errors:16 dropped:63 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:272369 (265.9 KiB)  TX bytes:15461 (15.0 KiB)
  Interrupt:175

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:388 errors:0 dropped:0 overruns:0 frame:0
  TX packets:388 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:36764 (35.9 KiB)  TX bytes:36764 (35.9 KiB)

usb0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f1
  inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
  inet6 addr: fe80::564a:16ff:fef0:f1f1/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:886 errors:0 dropped:5 overruns:0 frame:0
  TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:129397 (126.3 KiB)  TX bytes:9712 (9.4 KiB)

**  iptables -L command returns:*

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

* route -n command returns:*

Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse 
Iface
0.0.0.0 192.168.20.10.0.0.0 UG0  00 eth0
192.168.7.0 0.0.0.0 255.255.255.252 U 0  00 usb0
192.168.20.00.0.0.0 255.255.255.0   U 0  00 eth0

REMARK: The first route I added manually - when the beaglebone boots, it 
was not configured, just the last two.

I cannot ping the beaglebone from another computer.
I cannot ping another computer from the beaglebone.

What am I missing?

Thanks in advance...

Regards,

Daniel.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: beagle bone xenomai RTNET

[sagan61]

did you manage to find something? im having the same issue.

thanks for the update if any :)

On Wednesday, July 15, 2015 at 5:04:22 PM UTC+2, gowtham sandilya wrote:
>
> Hi Everyone,
>
> I am working on a project which requires two computers to communicate in a 
> real time fashion. I already have a i5 computer with xenomai and rtnet (
> http://www.rtnet.org/) installed.  I want the other computer to have low 
> level peripherals like GPIOs, I2C, SPI etc. I found that beaglebone fits 
> these requirements nicely. I found that I can install xenomai on beaglebone 
> using a debian image (here 
> )
>  
> . I was wondering if RTNET can also be installed in the default fashion? I 
> was hoping to see if anyone actually tried installing rtnet on beaglebone 
> black and got it to work?
>
> Thank you for your time.
>
> Regards,
> Gowtham Garimella.
>

-- 
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] Restore image on board using flashing from sd card

[yerzhik]

I've made a mistake, copied file into the board's OS (wrote the entire OS 
kernel) and now its not loading. So I decided to update OS and followed 
steps such as downloading image and writing it to the micro SD card. Then I 
put card into beaglebone black and pushed the button and only after that 
plugged in the USB cable (for power). The porblem is that it never finishes 
the flashing image. (LED's are always blinking).

How can I restore my system? And what am i doing wrong?

-- 
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] BBB - Audio D2A with McASP (I2S) very 'scratchy' - help?

[Nigel Magnay]

Hello

I am trying to interface a D2A (Ti PCM3070) to a BBB, over I2S.

Annoyingly - it *very nearly works* - but the audio that results is 
"scratchy". I can't quite tell why this is the case (or what exactly the 
mode of failure is) or what I need to do next.

Basically it's interfaced in the same way the HDMI chip is for audio, and 
has a secondary I2C connection for configuring the chip. After boot, I can 
fire in the various required register settings into the chip with i2cset, 
and then just ffplay  and - success - audio coming out. But not 
quite right audio. Very nearly there audio. It sounds a bit like it's 
clipped (but adjusting that makes no difference), or a signed/unsigned 
issue, but it's really hard to tell.

At first I suspected the output was down to the MCLK not being right in my 
initial tests (the 3070 assumes a different MCLK by default), but after 
setting the dividers in the PCM3070 it made no particular difference. I'm 
also trying to send 48kHz/24-bit audio (I do not need particular 
flexibility for my application) as per the MCLK, but that made no 
difference either. In fact it rather sounds the same even if I send 44.1kHz 
files.

I have read reference to MCLK perhaps being the 'wrong phase'. I'm also 
digging into http://bbb.ieero.com/ and the kernel sources for McASP on the 
BBB - but I'm keen to avoid having to do custom kernel builds et al unless 
it's strictly necessary.

Ideas?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: GSoC Project: a realtime audio effects Box

[Oolav]

Well I'd love to see that ! The "acoustic measurement box" especially...

I have done similar things already with a raspberry pi if you need help.

Regards

Le jeudi 17 mars 2016 18:52:59 UTC+1, Johannes Wegener a écrit :
>
> Hello everyone,
> I like to participate in GSoC 2016 and have the idea of creating a nice 
> audio tool platform on the beagle board. So really would like from you what 
> you think of this idea and if it would be helpful for anybody else out 
> there?
>
> Here is my abstract:
>
>> In my project I’m trying to build the foundation for using a beagleboard 
>> device as a sound processor. I would like to implement the effects modular 
>> - they should do just little things and have an open routing between each 
>> other. It should be similar to Native Instrument’s Reaktor (see: NI’s 
>> Reaktor Homepage 
>> ). 
>> A graphical user interface however might be a stretch goal - maybe also 
>> DSPatcher could be used for this purpose (see: DSPatcher Sourceforge 
>> ). The effects might be 
>> implemented using DSPatch C++ Library. (see: DSPatch Homepage 
>> ) The usage of such 
>> an effects box might be a transportable mixing desk (when adding MIDI 
>> controllers for example), a guitar effects box, a synthesizer/sampler 
>> instrument, a music studio effect, an acoustic measurement box, 
>> room/speaker correction or a hrtf 
>>  based 3d 
>> sound headphone system (when adding a head tracking sensor and an headphone 
>> amplifier). It targets musicians, audio engineers and audio enthusiasts. It 
>> shall be based on the work already done by Henrik Langer and Robert Manzke 
>> (see: Linux-Based Low-Latency Multichannel Audio System (CTAG face2|4) 
>> ).
>>  
>> The project shall assess if the PRUs of BBB/BBG or the DSPs of the X15 
>> could be used to provide a better performance for real time audio. The 
>> minimum of implemented effects is an equalizer (consisting of a lowpass, 
>> highpass, bandpass and bandstop filters), dynamic effects 
>> (compressor/limiter/expander) and a convolution engine (use fftw if 
>> possible). As a stretched goal there could be generators (VCOs 
>>  - 
>> controlled via MIDI and or OSC, sample player), envelopers (ADSR 
>> 
>>  
>> - also controlled via midi), distortion (as a guitar effect for example), 
>> modulations effects (like chorus, flanger, phaser), reverberation (based on 
>> parameters, via an IR  
>> should be possible with the convolution engine) or pitch/time shifters.
>>
>> Even I pointed out complex effects these effects should be build of 
>> submodules which are connected to get theses effects working. For example a 
>> biquad 
>> filter  would 
>> consist of sample-delays, gain modules and summing modules. The equalizer 
>> would then consist of some of these filters - and then there are modules 
>> that calculate the right filter coefficients to get the desired filter (by 
>> giving a frequency, (optional) gain, (optional) Q and filter type). This 
>> module which calculates the filter coefficients could even consist of 
>> submodules for highpass, lowpass, bandpass and bandstop calculating modules.
>> MIDI could be done with rtmidi library.
>>
>
> Best regards,
> Johannes
>

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