[beagleboard] No free space on SD card partition after writing 2016-06-05

[Wally Bkg]

bone-debian-8.5-lxqt-4gb-armhf-2016-06-05-4gb.img.xz leaves no free space on 
the partition it creates when written to an SD card.  I've done it using both 
dd and Etcher, on two different brands of 8GB cards.

Its not a show-stopper since grow-partition.sh still works after the Beaglebone 
has booted, but after I make the card I've a few scripts I like to copy over to 
set up NAT apt-get install some things that aren't part of the standard image.

Its good to see that the Cloud9 fade.js analogWrite() example is working again. 
 Haven't completed all my "newbie tests" yet, but so far the only issue is the 
Bonescript Interactive Guide web page only works for the first two "levels".  
The example using the on-board LEDs all seem to work, but the pages for the 
specific functions like analogWrite() and digitalRead() don't work because they 
don't render correctly.  I've used the latest Chrome browser and Firefox 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1fe989d1-cba7-45f3-a344-113e11d82455%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: trouble with image bone-debian-8.5 / 2016-06-05

[Wally Bkg]

Why all these changes to /sys/devices tree?  
Its ugly and will remain ugly no matter what they do with the names, but these 
changes break existing code and documentation to what benefit?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/af94584f-72fd-4a0c-9221-d3f59b79e91a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Release date update?

[bambaloe1969]

Hi Gerald,

Any news on the X15?
I noticed the "ON HOLD" at 
http://www.elinux.org/Beagleboard:BeagleBoard-X15 (last updated on 26 May).
 
With regards,

Patrick Tan

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/10e6a67c-3992-4ff5-88f6-ffb2b590edae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] 4DCAPE-43 cape frame rate

[jezweston]

What frame rate can the Beaglebone Black manage through the 4D 
Systems 4DCAPE-43 display?

Can it do smooth full colour, full size video? I'd like to either stream 
video off the SD card or load short clips into memory and then loop them.

Digging through forum archives and datasheets doesn't find me an answer.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/570daefc-f56e-40e3-bc19-f28c26ee73e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Release date update?

[Gerald Coley]

If there is any news to report, I will update the Wiki. So, assume that the
information on the Wiki is the latest status.

Gerald


On Mon, Jun 20, 2016 at 7:52 AM,  wrote:

> Hi Gerald,
>
> Any news on the X15?
> I noticed the "ON HOLD" at
> http://www.elinux.org/Beagleboard:BeagleBoard-X15 (last updated on 26
> May).
>
> With regards,
>
> Patrick Tan
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/10e6a67c-3992-4ff5-88f6-ffb2b590edae%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BfDCKusZBBj__Jttyf7%3DTO2TxtQ93uPqrysPB0%2BY5zPwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4DCAPE-43 cape frame rate

[Robert Nelson]

On Mon, Jun 20, 2016 at 1:40 AM,   wrote:
> What frame rate can the Beaglebone Black manage through the 4D Systems
> 4DCAPE-43 display?
>
> Can it do smooth full colour, full size video? I'd like to either stream
> video off the SD card or load short clips into memory and then loop them.

It's only 16bit (full colour = 24bit), therefor no need to lookup the rest. ;)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjcKWMn-5Ni-ce%2Bp63iXWP%3DyaHO9DwktuwJW%2BkCpxTwvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: No free space on SD card partition after writing 2016-06-05

[Graham]

If you have access to a Linux desktop, you can take the card after you 
write it, then plug it in to the Linux desktop and use Gparted to expand 
the partition size to the limit of the card, before you ever insert it into 
the BBB.

That way, you have full card memory available on the initial boot.

--- Graham

==

On Monday, June 20, 2016 at 7:32:32 AM UTC-5, Wally Bkg wrote:
>
> bone-debian-8.5-lxqt-4gb-armhf-2016-06-05-4gb.img.xz leaves no free space 
> on the partition it creates when written to an SD card.  I've done it using 
> both dd and Etcher, on two different brands of 8GB cards.
>
> Its not a show-stopper since grow-partition.sh still works after the 
> Beaglebone has booted, but after I make the card I've a few scripts I like 
> to copy over to set up NAT apt-get install some things that aren't part of 
> the standard image.
>
> Its good to see that the Cloud9 fade.js analogWrite() example is working 
> again.  Haven't completed all my "newbie tests" yet, but so far the only 
> issue is the Bonescript Interactive Guide web page only works for the first 
> two "levels".  The example using the on-board LEDs all seem to work, but 
> the pages for the specific functions like analogWrite() and digitalRead() 
> don't work because they don't render correctly.  I've used the latest 
> Chrome browser and Firefox 
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0cb2c173-7737-4afe-a781-58852173ee9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] codesys available for beaglebone

[toni incog]

Just came along this one:

http://store.codesys.com/codesys-control-for-beaglebone-sl.html

Codesys is an implementation of iec 1131, language(s) & runtime for 
real-time plc applications. It's is used in industrial automation. E.g. 
Wago, Beckhoff en Schneider do sell plc's with codesys runtime & 
development. An implementation for r-pi is also available. I haven't tried 
it yet.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dfb20db4-7dfc-4bc2-a661-97c22234e366%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[epi kao]

Hello, thanks again.

so today i have try now with a HDMI TFT 1280x800 (EDID compatible) to force 
the Resolution to 800x480.

For this, i have try to edit the uEnv.txt file:
root@beaglebone:/media/root/rootfs/boot# vi uEnv.txt

*then i have edit the cmdline as follow, but unfortunately the resolution 
does not change after restart, so whats wrong?:*

uname_r=3.8.13-bone70
#dtb=
cmdline=coherent_pool=1M quiet video=HDMI-A-1:800x480M@60e 
cape_universal=disable init=/lib/systemd/systemd

##Example


then i have

Am Sonntag, 19. Juni 2016 20:29:42 UTC+2 schrieb William Hermans:
>
> I guess RPi provides a similar feature, and you need not manually handle 
>> them using the config.txt file.
>>
>
> The rPI BSP is a mess compared to the beaglebone. As far as I can tell 
> there is nothing standard about it. However, it does make some things 
> easier. Just as an example, here is some of the file structure, on my rPI3 
> Rasbian Jessie.
>
> william@rpi:~$ lsblk
> NAMEMAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> sda   8:00 931.5G  0 disk
> └─sda18:10 931.5G  0 part
> mmcblk0 179:00  14.7G  0 disk
> ├─mmcblk0p1 179:1060M  0 part /boot
> └─mmcblk0p2 179:20  14.6G  0 part /
>
> william@rpi:~$ ls /boot/
> bcm2708-rpi-b.dtb   bcm2710-rpi-3-b.dtb  COPYING.linux  fixup_x.dat  
> LICENCE.broadcom  start_db.elf
> bcm2708-rpi-b-plus.dtb  bootcode.bin fixup_cd.dat   issue.txt
> LICENSE.oraclestart.elf
> bcm2708-rpi-cm.dtb  cmdline.txt  fixup.dat  kernel7.img  
> overlays  start_x.elf
> bcm2709-rpi-2-b.dtb config.txt   fixup_db.dat   kernel.img   
> start_cd.elf
>
> william@rpi:~$ cat /boot/cmdline.txt
> dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 
> root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes 
> rootwait
>
> william@rpi:~$ cat /boot/config.txt
> # For more options and information see
> # http://www.raspberrypi.org/documentation/configuration/config-txt.md
> # Some settings may impact device functionality. See link above for details
>
> # uncomment if you get no picture on HDMI for a default "safe" mode
> #hdmi_safe=1
>
> # uncomment this if your display has a black border of unused pixels 
> visible
> # and your display can output without overscan
> #disable_overscan=1
>
> # uncomment the following to adjust overscan. Use positive numbers if 
> console
> # goes off screen, and negative if there is too much border
> #overscan_left=16
> #overscan_right=16
> #overscan_top=16
> #overscan_bottom=16
>
> # uncomment to force a console size. By default it will be display's size 
> minus
> # overscan.
> #framebuffer_width=1280
> #framebuffer_height=720
>
> # uncomment if hdmi display is not detected and composite is being output
> #hdmi_force_hotplug=1
>
> # uncomment to force a specific HDMI mode (this will force VGA)
> #hdmi_group=1
> #hdmi_mode=1
>
> # uncomment to force a HDMI mode rather than DVI. This can make audio work 
> in
> # DMT (computer monitor) modes
> #hdmi_drive=2
>
> # uncomment to increase signal to HDMI, if you have interference, 
> blanking, or
> # no display
> #config_hdmi_boost=4
>
> # uncomment for composite PAL
> #sdtv_mode=2
>
> #uncomment to overclock the arm. 700 MHz is the default.
> #arm_freq=800
>
> # Uncomment some or all of these to enable the optional hardware interfaces
> #dtparam=i2c_arm=on
> #dtparam=i2s=on
> #dtparam=spi=on
>
> # Uncomment this to enable the lirc-rpi module
> #dtoverlay=lirc-rpi
>
> # Additional overlays and parameters are documented /boot/overlays/README
>
> # Enable audio (loads snd_bcm2835)
> dtparam=audio=on
>
>
>
> On Sun, Jun 19, 2016 at 8:48 AM, TJF > 
> wrote:
>
>>
>>
>> Am Sonntag, 19. Juni 2016 00:18:00 UTC+2 schrieb epi kao:
>>>
>>> thanks, and yes i already knew this link.
>>> But there is only explained how to read (for debug) the EDID infos. That 
>>> is not really usefull. I need more functions as only resolution and refresh 
>>> rate
>>>
>>> So it seems that with a raspberry i have more adjust functions to set 
>>> the hdmi output-timings?
>>>
>>
>> Why do you think you have to provide this additional information? Let the 
>> frame buffer driver compute them. Therefor, as William mentioned, specify 
>> the cmdline variable in file /boot/uEnv.txt like
>>  
>>
>>>   cmdline=coherent_pool=1M quiet *video=HDMI-A-1:800x480M@60e* 
>>> cape_universal=disable init=/lib/systemd/systemd
>>>
>>
>> Note the "M" after the resolution here. It requires individual 
>> calculation of the timings (in contrast to reading them from a pre-defined 
>> table, see framebuffer documentation for details). That way you can skip 
>> EDID and specify any resolution in a convenient way. I guess RPi provides a 
>> similar feature, and you need not manually handle them using the config.txt 
>> file.
>>
>> BR
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google G

Re: [beagleboard] disable edid (hdmi, rgb video output)

[Charles Steinkuehler]

On 6/20/2016 8:36 AM, epi kao wrote:
> Hello, thanks again.
> 
> so today i have try now with a HDMI TFT 1280x800 (EDID compatible) to force 
> the 
> Resolution to 800x480.
> 
> For this, i have try to edit the uEnv.txt file:
> root@beaglebone:/media/root/rootfs/boot# vi uEnv.txt
> 
> *then i have edit the cmdline as follow, but unfortunately the resolution 
> does 
> not change after restart, so whats wrong?:*

After the system boots, verify your kernel command line switches are
actually making it to the kernel by running:

  cat /proc/cmdline

...and look through the output of dmesg for hints as to what might be
going wrong.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/105b1491-a81d-0538-c8c5-7524fb770eac%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[epi kao]

so what i receive:

root@beaglebone:/# cat /proc/cmdline

console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 
rootwait fixrtc coherent_pool=1M quiet cape_universal=enable

BTW, i have read following code on a other side in the internet:

kms_force_mode=video=HDMI-A-1:800x480M@60


But unfortunately for me, it's not clear how to implement this correctly in the 
cmdline?


thanks



Am Montag, 20. Juni 2016 15:50:18 UTC+2 schrieb Charles Steinkuehler:
>
> On 6/20/2016 8:36 AM, epi kao wrote: 
> > Hello, thanks again. 
> > 
> > so today i have try now with a HDMI TFT 1280x800 (EDID compatible) to 
> force the 
> > Resolution to 800x480. 
> > 
> > For this, i have try to edit the uEnv.txt file: 
> > root@beaglebone:/media/root/rootfs/boot# vi uEnv.txt 
> > 
> > *then i have edit the cmdline as follow, but unfortunately the 
> resolution does 
> > not change after restart, so whats wrong?:* 
>
> After the system boots, verify your kernel command line switches are 
> actually making it to the kernel by running: 
>
>   cat /proc/cmdline 
>
> ...and look through the output of dmesg for hints as to what might be 
> going wrong. 
>
> -- 
> Charles Steinkuehler 
> cha...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c07cba63-d178-4a95-9592-7a4f2a2b8b17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[Robert Nelson]

On Mon, Jun 20, 2016 at 9:00 AM, epi kao  wrote:
> so what i receive:
>
> root@beaglebone:/# cat /proc/cmdline
>
> console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4
> rootwait fixrtc coherent_pool=1M quiet cape_universal=enable
>
> BTW, i have read following code on a other side in the internet:
>
> kms_force_mode=video=HDMI-A-1:800x480M@60
>
>
> But unfortunately for me, it's not clear how to implement this correctly in
> the cmdline?

There's an example in /boot/uEnv.txt:

cmdline=coherent_pool=1M quiet video=HDMI-A-1:1024x768@60e

remove the "#" and set the video parameters you need.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhvnWdX-tJVeoMXjWBDUb6AS9X3AEFCx1hNRYjU%2BHSnDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[epi kao]

*>remove the "#" and set the video parameters you need.*

still not working...

Am Montag, 20. Juni 2016 16:04:32 UTC+2 schrieb RobertCNelson:
>
> On Mon, Jun 20, 2016 at 9:00 AM, epi kao > 
> wrote: 
> > so what i receive: 
> > 
> > root@beaglebone:/# cat /proc/cmdline 
> > 
> > console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 
> > rootwait fixrtc coherent_pool=1M quiet cape_universal=enable 
> > 
> > BTW, i have read following code on a other side in the internet: 
> > 
> > kms_force_mode=video=HDMI-A-1:800x480M@60 
> > 
> > 
> > But unfortunately for me, it's not clear how to implement this correctly 
> in 
> > the cmdline? 
>
> There's an example in /boot/uEnv.txt: 
>
> cmdline=coherent_pool=1M quiet video=HDMI-A-1:1024x768@60e 
>
> remove the "#" and set the video parameters you need. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f69ba36f-5105-40cd-a25d-f55d2932e419%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[Charles Steinkuehler]

On 6/20/2016 9:25 AM, epi kao wrote:
> />remove the "#" and set the video parameters you need./
> 
> still not working...

Provide your uEnv.txt, /etc/dogtag, and /proc/cmdline and we might be
able to make a suggestion for what to try next.  Otherwise, we're just
guessing.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/40d0ba98-3645-c432-33dc-dbbae526fd4d%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[Robert Nelson]

On Mon, Jun 20, 2016 at 9:25 AM, epi kao  wrote:
>>remove the "#" and set the video parameters you need.
>
> still not working...

okay, post your full, /boot/uEnv.txt

and what rootfs is this?

cat /etc/dogtag

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhqGaHkNn2%2B9tBW4tv%3Dch-LJteucynN_5mx8QzKBohXpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[epi kao]

as requested (it seems that uEnv.txt has different directorys?, anyway I 
have changed uEnv.txt on the directory /media/root/rootfs/boot):

root@beaglebone:/# cat /etc/dogtag
BeagleBoard.org Debian Image 2016-01-24

root@beaglebone:/# cat /proc/cmdline
console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 
rootwait  fixrtc coherent_pool=1M quiet 
cape_universal=enable

then the uEnv.txt file:

uname_r=3.8.13-bone70
dtb=
cmdline=coherent_pool=1M quiet video=HDMI-A-1:800x480M@60e 
cape_universal=disable init=/lib/systemd/systemd

##Example
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Disable HDMI/eMMC
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

##Disable HDMI
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

##Disable eMMC
#cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G

##Audio Cape (needs HDMI Audio disabled)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02


##enable BBB: eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

uuid=682afa8f-f182-4b65-a144-91e06633914d

thanks







Am Montag, 20. Juni 2016 16:27:40 UTC+2 schrieb RobertCNelson:
>
> On Mon, Jun 20, 2016 at 9:25 AM, epi kao > 
> wrote: 
> >>remove the "#" and set the video parameters you need. 
> > 
> > still not working... 
>
> okay, post your full, /boot/uEnv.txt 
>
> and what rootfs is this? 
>
> cat /etc/dogtag 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/99f7288b-d1d1-4955-b031-810865a798dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[Robert Nelson]

There's two uEnv.txt's for compatibility with old eMMC's..

/uEnv.txt -> /boot/uEnv.txt

HOWEVER, /uEnv.txt doesn't have the features of /boot/uEnv.txt

So make sure your uEnv.txt is found in /boot/uEnv.txt

Otherwise your /boot/uEnv.txt looks fine..

Regards

On Mon, Jun 20, 2016 at 9:40 AM, epi kao  wrote:
> as requested (it seems that uEnv.txt has different directorys?, anyway I
> have changed uEnv.txt on the directory /media/root/rootfs/boot):
>
> root@beaglebone:/# cat /etc/dogtag
> BeagleBoard.org Debian Image 2016-01-24
>
> root@beaglebone:/# cat /proc/cmdline
> console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4
> rootwait  fixrtc coherent_pool=1M quiet
> cape_universal=enable
>
> then the uEnv.txt file:
>
> uname_r=3.8.13-bone70
> dtb=
> cmdline=coherent_pool=1M quiet video=HDMI-A-1:800x480M@60e
> cape_universal=disable init=/lib/systemd/systemd
>
> ##Example
> #cape_disable=capemgr.disable_partno=
> #cape_enable=capemgr.enable_partno=
>
> ##Disable HDMI/eMMC
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
>
> ##Disable HDMI
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>
> ##Disable eMMC
> #cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G
>
> ##Audio Cape (needs HDMI Audio disabled)
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
> #cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02
>
>
> ##enable BBB: eMMC Flasher:
> ##make sure, these tools are installed: dosfstools rsync
> #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
>
> uuid=682afa8f-f182-4b65-a144-91e06633914d
>
> thanks
>
>
>
>
>
>
>
> Am Montag, 20. Juni 2016 16:27:40 UTC+2 schrieb RobertCNelson:
>>
>> On Mon, Jun 20, 2016 at 9:25 AM, epi kao  wrote:
>> >>remove the "#" and set the video parameters you need.
>> >
>> > still not working...
>>
>> okay, post your full, /boot/uEnv.txt
>>
>> and what rootfs is this?
>>
>> cat /etc/dogtag
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/99f7288b-d1d1-4955-b031-810865a798dd%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjndBZ912Y99xm2Y0tmPvFwXyZON_6YStMftT2szYnywA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[epi kao]

ok. now please find below the uEnv.txt directly from /boot (not from 
rootfs..)! but it don't  work although

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_3.0

uname_r=4.1.15-ti-rt-r43
#uuid=
#dtb=

##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)

##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb

##BeagleBone Black: eMMC disabled:
#dtb=am335x-boneblack-hdmi-overlay.dtb

##BeagleBone Black: HDMI Audio/eMMC disabled:
#dtb=am335x-boneblack-nhdmi-overlay.dtb

##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
#dtb=am335x-boneblack-overlay.dtb

##BeagleBone Black: wl1835
#dtb=am335x-boneblack-wl1835mod.dtb

##BeagleBone Green: eMMC disabled
#dtb=am335x-bonegreen-overlay.dtb

cmdline=coherent_pool=1M quiet cape_universal=enable

#In the event of edid real failures, uncomment this next line:
cmdline=coherent_pool=1M quiet cape_universal=enable 
video=HDMI-A-1:x800@400e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=

##Disable HDMI/eMMC (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

##Disable HDMI (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

##Disable eMMC (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G

##Audio Cape (needs HDMI Audio disabled) (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02


##enable Generic eMMC Flasher:


Am Montag, 20. Juni 2016 16:44:54 UTC+2 schrieb RobertCNelson:
>
> There's two uEnv.txt's for compatibility with old eMMC's.. 
>
> /uEnv.txt -> /boot/uEnv.txt 
>
> HOWEVER, /uEnv.txt doesn't have the features of /boot/uEnv.txt 
>
> So make sure your uEnv.txt is found in /boot/uEnv.txt 
>
> Otherwise your /boot/uEnv.txt looks fine.. 
>
> Regards 
>
> On Mon, Jun 20, 2016 at 9:40 AM, epi kao > 
> wrote: 
> > as requested (it seems that uEnv.txt has different directorys?, anyway I 
> > have changed uEnv.txt on the directory /media/root/rootfs/boot): 
> > 
> > root@beaglebone:/# cat /etc/dogtag 
> > BeagleBoard.org Debian Image 2016-01-24 
> > 
> > root@beaglebone:/# cat /proc/cmdline 
> > console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 
> > rootwait  fixrtc coherent_pool=1M quiet 
> > cape_universal=enable 
> > 
> > then the uEnv.txt file: 
> > 
> > uname_r=3.8.13-bone70 
> > dtb= 
> > cmdline=coherent_pool=1M quiet video=HDMI-A-1:800x480M@60e 
> > cape_universal=disable init=/lib/systemd/systemd 
> > 
> > ##Example 
> > #cape_disable=capemgr.disable_partno= 
> > #cape_enable=capemgr.enable_partno= 
> > 
> > ##Disable HDMI/eMMC 
> > 
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
>  
>
> > 
> > ##Disable HDMI 
> > #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
> > 
> > ##Disable eMMC 
> > #cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G 
> > 
> > ##Audio Cape (needs HDMI Audio disabled) 
> > #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI 
> > #cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02 
> > 
> > 
> > ##enable BBB: eMMC Flasher: 
> > ##make sure, these tools are installed: dosfstools rsync 
> > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh 
> > 
> > uuid=682afa8f-f182-4b65-a144-91e06633914d 
> > 
> > thanks 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Am Montag, 20. Juni 2016 16:27:40 UTC+2 schrieb RobertCNelson: 
> >> 
> >> On Mon, Jun 20, 2016 at 9:25 AM, epi kao  wrote: 
> >> >>remove the "#" and set the video parameters you need. 
> >> > 
> >> > still not working... 
> >> 
> >> okay, post your full, /boot/uEnv.txt 
> >> 
> >> and what rootfs is this? 
> >> 
> >> cat /etc/dogtag 
> >> 
> >> 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...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/beagleboard/99f7288b-d1d1-4955-b031-810865a798dd%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d2c1dab1-92be-4653-823c-fcd445fbca4a%40googlegroups.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[Robert Nelson]

On Mon, Jun 20, 2016 at 9:57 AM, epi kao  wrote:
> ok. now please find below the uEnv.txt directly from /boot (not from
> rootfs..)! but it don't  work although
>
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_3.0
>
> uname_r=4.1.15-ti-rt-r43
> #uuid=
> #dtb=
>
> ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)
>
> ##BeagleBone Black: HDMI (Audio/Video) disabled:
> #dtb=am335x-boneblack-emmc-overlay.dtb
>
> ##BeagleBone Black: eMMC disabled:
> #dtb=am335x-boneblack-hdmi-overlay.dtb
>
> ##BeagleBone Black: HDMI Audio/eMMC disabled:
> #dtb=am335x-boneblack-nhdmi-overlay.dtb
>
> ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
> #dtb=am335x-boneblack-overlay.dtb
>
> ##BeagleBone Black: wl1835
> #dtb=am335x-boneblack-wl1835mod.dtb
>
> ##BeagleBone Green: eMMC disabled
> #dtb=am335x-bonegreen-overlay.dtb
>
> cmdline=coherent_pool=1M quiet cape_universal=enable
>
> #In the event of edid real failures, uncomment this next line:
> cmdline=coherent_pool=1M quiet cape_universal=enable
> video=HDMI-A-1:x800@400e

^ only have one "cmdline=" u-boot doesn't always pick the one you want
when you have two variables..

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhuyujmgDTJ3TNokdjb6SJJcvoMJrURVC3Av9sMLPGaPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[epi kao]

ok. thank, it works :-)  failure was two command line, and the cmdline from 
the uEnv.txt at /boot was still wrong, below the correct:

#In the event of edid real failures, uncomment this next line:
cmdline=coherent_pool=1M quiet video=HDMI-A-1:800x480M@60e 
cape_universal=disable init=/lib/systemd/systemd

so now i am really interested if resolution like 1920x720 or 320x240 also 
works... maybe anyone still know this?


Am Montag, 20. Juni 2016 17:00:28 UTC+2 schrieb RobertCNelson:
>
> On Mon, Jun 20, 2016 at 9:57 AM, epi kao > 
> wrote: 
> > ok. now please find below the uEnv.txt directly from /boot (not from 
> > rootfs..)! but it don't  work although 
> > 
> > #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_3.0 
> > 
> > uname_r=4.1.15-ti-rt-r43 
> > #uuid= 
> > #dtb= 
> > 
> > ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just 
> works..) 
> > 
> > ##BeagleBone Black: HDMI (Audio/Video) disabled: 
> > #dtb=am335x-boneblack-emmc-overlay.dtb 
> > 
> > ##BeagleBone Black: eMMC disabled: 
> > #dtb=am335x-boneblack-hdmi-overlay.dtb 
> > 
> > ##BeagleBone Black: HDMI Audio/eMMC disabled: 
> > #dtb=am335x-boneblack-nhdmi-overlay.dtb 
> > 
> > ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled: 
> > #dtb=am335x-boneblack-overlay.dtb 
> > 
> > ##BeagleBone Black: wl1835 
> > #dtb=am335x-boneblack-wl1835mod.dtb 
> > 
> > ##BeagleBone Green: eMMC disabled 
> > #dtb=am335x-bonegreen-overlay.dtb 
> > 
> > cmdline=coherent_pool=1M quiet cape_universal=enable 
> > 
> > #In the event of edid real failures, uncomment this next line: 
> > cmdline=coherent_pool=1M quiet cape_universal=enable 
> > video=HDMI-A-1:x800@400e 
>
> ^ only have one "cmdline=" u-boot doesn't always pick the one you want 
> when you have two variables.. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/65243862-2529-488d-a2d9-316ebc6d7824%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[Charles Steinkuehler]

On 6/20/2016 10:17 AM, epi kao wrote:
> 
> so now i am really interested if resolution like 1920x720 or 320x240 also 
> works... maybe anyone still know this?

You should be able to craft any resolution within the frequency range
of the AM335x LCD pixel clock.  Very low resolutions (like 320x240)
may encounter problems since they require pixel doubling in the HDMI
framer to keep the HDMI clock within it's legal range.  The driver
should handle this properly, but the code path is probably not tested
a bunch for HDMI (you'd typically connect a low-resolution LCD like
that directly rather than via HDMI).

Just try it and see.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c440acda-7e56-a996-ab96-c77c8105ba16%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[epi kao]

it seems that 320x240 is not working? what is the reason? it's to low? and 
how can i access now this resolution? thanks

Am Montag, 20. Juni 2016 17:17:25 UTC+2 schrieb epi kao:
>
> ok. thank, it works :-)  failure was two command line, and the cmdline 
> from the uEnv.txt at /boot was still wrong, below the correct:
>
> #In the event of edid real failures, uncomment this next line:
> cmdline=coherent_pool=1M quiet video=HDMI-A-1:800x480M@60e 
> cape_universal=disable init=/lib/systemd/systemd
>
> so now i am really interested if resolution like 1920x720 or 320x240 also 
> works... maybe anyone still know this?
>
>
> Am Montag, 20. Juni 2016 17:00:28 UTC+2 schrieb RobertCNelson:
>>
>> On Mon, Jun 20, 2016 at 9:57 AM, epi kao  wrote: 
>> > ok. now please find below the uEnv.txt directly from /boot (not from 
>> > rootfs..)! but it don't  work although 
>> > 
>> > #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_3.0 
>> > 
>> > uname_r=4.1.15-ti-rt-r43 
>> > #uuid= 
>> > #dtb= 
>> > 
>> > ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just 
>> works..) 
>> > 
>> > ##BeagleBone Black: HDMI (Audio/Video) disabled: 
>> > #dtb=am335x-boneblack-emmc-overlay.dtb 
>> > 
>> > ##BeagleBone Black: eMMC disabled: 
>> > #dtb=am335x-boneblack-hdmi-overlay.dtb 
>> > 
>> > ##BeagleBone Black: HDMI Audio/eMMC disabled: 
>> > #dtb=am335x-boneblack-nhdmi-overlay.dtb 
>> > 
>> > ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled: 
>> > #dtb=am335x-boneblack-overlay.dtb 
>> > 
>> > ##BeagleBone Black: wl1835 
>> > #dtb=am335x-boneblack-wl1835mod.dtb 
>> > 
>> > ##BeagleBone Green: eMMC disabled 
>> > #dtb=am335x-bonegreen-overlay.dtb 
>> > 
>> > cmdline=coherent_pool=1M quiet cape_universal=enable 
>> > 
>> > #In the event of edid real failures, uncomment this next line: 
>> > cmdline=coherent_pool=1M quiet cape_universal=enable 
>> > video=HDMI-A-1:x800@400e 
>>
>> ^ only have one "cmdline=" u-boot doesn't always pick the one you want 
>> when you have two variables.. 
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/954bae54-010d-44a8-b25e-b32ed61df3c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] trouble with image bone-debian-8.5 / 2016-06-05

[John Syne]

What was ugly was the original board files with duplicate code in the kernel 
source for each platform. Anyway, why is this ugly? It is simply a device 
address and a label. The driver needs this information, so you can either hard 
code it (not a good idea because it leads to duplicate code) or you can define 
it in the device tree. Same thing for gpio numbers, interrupts, dma channels, 
etc. Take the time to understand the format and it won’t seem so confusing. 

Regards,
John




> On Jun 20, 2016, at 5:42 AM, Wally Bkg  wrote:
> 
> Why all these changes to /sys/devices tree?  
> Its ugly and will remain ugly no matter what they do with the names, but 
> these changes break existing code and documentation to what benefit?
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/af94584f-72fd-4a0c-9221-d3f59b79e91a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/857DCC55-C464-4245-8329-E4079993E427%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB boot from SPI flash

[Joe Desbonnet]

I just tried the latest u-boot 2016.05 and it worked this time without any 
difficulty.  I just had to edit configs/am335x_boneblack_defconfig and 
replace option CONFIG_SYS_EXTRA_OPTIONS with 
CONFIG_SYS_EXTRA_OPTIONS="SPI_BOOT" and add line CONFIG_SPI_FLASH_STMICRO=y 
 (because my SPI flash chip is a ST Microelectronics M25P16).

I was able to program the flash from another build of u-boot with the SPI 
bus enabled by entering the following commands from the u-boot command 
prompt:

sf probe 0
sf erase 0 +20
mmc rescan
fatload mmc 0 ${loadaddr} MLO.byteswap
sf write ${loadaddr} 0 ${filesize}
fatload mmc 0 ${loadaddr} u-boot.img
sf write ${loadaddr} 0x2 ${filesize}

To test, hold down the Beaglebone Black S2 button while applying power. 
That kicks in an alternative boot order which puts boot over SPI0 bus at 
the top of the list.

Joe.


On Wednesday, 15 June 2016 12:13:08 UTC+1, Joe Desbonnet wrote:
>
> I'm attempting to implement boot to Linux from SPI flash on the Beaglebone 
> Black. The motivation is to implement secure boot using u-boot vboot from 
> write protected SPI flash. 
>
> I've been working with 2016.01 u-boot release. 
>
> My progress to date is that I can boot the u-boot SPL (MLO) from SPI and 
> that runs, but it didn't find any SPI device to boot from. So patched the 
> code to enable pin mux for SPI0 and forced SPI boot in common/spl/spl.c. 
>
> Now I can see it loading u-boot.img from 0x2 over the SPI bus. But it 
> hangs when attempting to jump to the loaded u-boot.
>
> Wondering has anyone got a howto on this? 
>
> Thanks,
> Joe.
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2dd48a31-98ed-4666-af7a-0678bb15d7fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] trouble with image bone-debian-8.5 / 2016-06-05

[TJF]

Am Montag, 20. Juni 2016 18:09:36 UTC+2 schrieb john3909:
>
> It is simply a device address and a label. The driver needs this 
> information, so you can either hard code it (not a good idea because it 
> leads to duplicate code) or you can define it in the device tree. Same 
> thing for gpio numbers, interrupts, dma channels, etc. Take the time to 
> understand the format and it won’t seem so confusing.
>

If it is that easy, why do kernel developers have the same problems like 
Wally Bkg and myself, and problems of this kind are everywhere?

Guys like Derek Molloy spend a lot of effort in writing good tutorials. And 
most documentations are outdated with the next small kernel update?

Names in /sys should never change! OK, sometimes it needs a clean-up. But 
that should only happen when the major kernel version number changes. And a 
clear documentation is obligatory.

BR

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/65f23bc0-684b-4b79-8f0d-987a295526d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] trouble with image bone-debian-8.5 / 2016-06-05

[John Syne]

Because Devicetree is new and there is an effort to achieve consistency between 
all architectures. Remember, devicetree started on the PowerPC platform and it 
was only when Linus complained about the code duplication and conflicts between 
ARM platforms that Devicetree was adopted by the ARM community. There are still 
architectures who still have board files so expect more churn as these 
architectures adopt devicetree. In addition, as companies like TI mainstream 
their patches, they are also making changes to the devicetree, so it will be 
some time before this settles down. 

Regards,
John




> On Jun 20, 2016, at 10:10 AM, TJF  wrote:
> 
> 
> Am Montag, 20. Juni 2016 18:09:36 UTC+2 schrieb john3909:
> It is simply a device address and a label. The driver needs this information, 
> so you can either hard code it (not a good idea because it leads to duplicate 
> code) or you can define it in the device tree. Same thing for gpio numbers, 
> interrupts, dma channels, etc. Take the time to understand the format and it 
> won’t seem so confusing.
> 
> If it is that easy, why do kernel developers have the same problems like 
> Wally Bkg and myself, and problems of this kind are everywhere?
> 
> Guys like Derek Molloy spend a lot of effort in writing good tutorials. And 
> most documentations are outdated with the next small kernel update?
> 
> Names in /sys should never change! OK, sometimes it needs a clean-up. But 
> that should only happen when the major kernel version number changes. And a 
> clear documentation is obligatory.
> 
> BR
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/65f23bc0-684b-4b79-8f0d-987a295526d6%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/AD6D7248-4E41-4B85-AFC7-993F79AB1E11%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] trouble with image bone-debian-8.5 / 2016-06-05

[Robert Nelson]

On Mon, Jun 20, 2016 at 12:10 PM, TJF  wrote:
>
> Am Montag, 20. Juni 2016 18:09:36 UTC+2 schrieb john3909:
>>
>> It is simply a device address and a label. The driver needs this
>> information, so you can either hard code it (not a good idea because it
>> leads to duplicate code) or you can define it in the device tree. Same thing
>> for gpio numbers, interrupts, dma channels, etc. Take the time to understand
>> the format and it won’t seem so confusing.
>
>
> If it is that easy, why do kernel developers have the same problems like
> Wally Bkg and myself, and problems of this kind are everywhere?
>
> Guys like Derek Molloy spend a lot of effort in writing good tutorials. And
> most documentations are outdated with the next small kernel update?
>
> Names in /sys should never change! OK, sometimes it needs a clean-up. But
> that should only happen when the major kernel version number changes. And a
> clear documentation is obligatory.

No one is forcing you to upgrade either..

We go out of our way to allow you to install almost any kernel version.

3.8.13-boneX -> 4.7.X

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiYUnC-KuBg4DyOdNVfUc8VYgomb2YeO49T1XzT5yQBmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[Stewart]

I'm looking to write a simple app for BBB.  When started from the command 
line, it would set up the ADC in continuous mode and read ~1 M samples from 
e.g. AN0 into memory.  After the capture is complete, it would write the 
data to a file and exit.

Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 
MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would 
be acceptable.

What is an easy way to do this?  Most Beaglebone ADC examples sample at 
kilohertz rates or slower.

This guide: 
http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide 
speaks of 200 KSPS.  What is the limitation here?

I've seen various suggestions to use the PRU, but don't understand why.  I 
would think that since DMA would be required anyway, there should be no 
requirement to otherwise access the hardware with tight timing.  If PRU is 
indeed necessary, is there a suitable example or tutorial?  (None of the 
libpruio built-in examples deal with rapid sampling or large amounts of 
data.)

Any other ideas for a simple way to capture data fast will be gratefully 
appreciated.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Capture analog input at near maximum sample rate?

[snelson . stuff]

I'm looking to write a simple app for BBB.  When started from the command 
line, it would set up the ADC in continuous mode and read ~1 M samples from 
e.g. AN0 into memory.  After the capture is complete, it would write the 
data to a file and exit.

Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 
MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would 
be acceptable.

What is an easy way to do this?  Most Beaglebone ADC examples sample at 
kilohertz rates or slower.

This guide: 
http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide 
speaks of 200 KSPS.  What is the limitation here?

I've seen various suggestions to use the PRU, but don't understand why.  I 
would think that since DMA would be required anyway, there should be no 
requirement to otherwise access the hardware with tight timing.  If PRU is 
indeed necessary, is there a suitable example or tutorial?  (None of the 
libpruio built-in examples deal with rapid sampling or large amounts of 
data.)

Any other ideas for a simple way to capture data fast will be gratefully 
appreciated.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] disable edid (hdmi, rgb video output)

[ramona . pierre]

so because cmdline does not work with qvga i must study the variant with 
following link:
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD7-01-00A1.dts#L230

does anyone know, if I can see also a result on the hdmi-output with that, 
or does I disable the hdmi-output with that?

thanks

Am Montag, 20. Juni 2016 17:34:29 UTC+2 schrieb epi kao:
>
> it seems that 320x240 is not working? what is the reason? it's to low? and 
> how can i access now this resolution? thanks
>
> Am Montag, 20. Juni 2016 17:17:25 UTC+2 schrieb epi kao:
>>
>> ok. thank, it works :-)  failure was two command line, and the cmdline 
>> from the uEnv.txt at /boot was still wrong, below the correct:
>>
>> #In the event of edid real failures, uncomment this next line:
>> cmdline=coherent_pool=1M quiet video=HDMI-A-1:800x480M@60e 
>> cape_universal=disable init=/lib/systemd/systemd
>>
>> so now i am really interested if resolution like 1920x720 or 320x240 also 
>> works... maybe anyone still know this?
>>
>>
>> Am Montag, 20. Juni 2016 17:00:28 UTC+2 schrieb RobertCNelson:
>>>
>>> On Mon, Jun 20, 2016 at 9:57 AM, epi kao  wrote: 
>>> > ok. now please find below the uEnv.txt directly from /boot (not from 
>>> > rootfs..)! but it don't  work although 
>>> > 
>>> > #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_3.0 
>>> > 
>>> > uname_r=4.1.15-ti-rt-r43 
>>> > #uuid= 
>>> > #dtb= 
>>> > 
>>> > ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just 
>>> works..) 
>>> > 
>>> > ##BeagleBone Black: HDMI (Audio/Video) disabled: 
>>> > #dtb=am335x-boneblack-emmc-overlay.dtb 
>>> > 
>>> > ##BeagleBone Black: eMMC disabled: 
>>> > #dtb=am335x-boneblack-hdmi-overlay.dtb 
>>> > 
>>> > ##BeagleBone Black: HDMI Audio/eMMC disabled: 
>>> > #dtb=am335x-boneblack-nhdmi-overlay.dtb 
>>> > 
>>> > ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled: 
>>> > #dtb=am335x-boneblack-overlay.dtb 
>>> > 
>>> > ##BeagleBone Black: wl1835 
>>> > #dtb=am335x-boneblack-wl1835mod.dtb 
>>> > 
>>> > ##BeagleBone Green: eMMC disabled 
>>> > #dtb=am335x-bonegreen-overlay.dtb 
>>> > 
>>> > cmdline=coherent_pool=1M quiet cape_universal=enable 
>>> > 
>>> > #In the event of edid real failures, uncomment this next line: 
>>> > cmdline=coherent_pool=1M quiet cape_universal=enable 
>>> > video=HDMI-A-1:x800@400e 
>>>
>>> ^ only have one "cmdline=" u-boot doesn't always pick the one you want 
>>> when you have two variables.. 
>>>
>>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1d94c734-61b8-44e9-ad1a-f5d58261afa5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture analog input at near maximum sample rate?

[Micka]

the best woud be the PRU because you can store the data in the share
memory. That is the fastest way.

you can stop the acquisition whenever you want or let it go back at the
beginning of your memory and go on.


Le lun. 20 juin 2016 à 21:29,  a écrit :

> I'm looking to write a simple app for BBB.  When started from the command
> line, it would set up the ADC in continuous mode and read ~1 M samples from
> e.g. AN0 into memory.  After the capture is complete, it would write the
> data to a file and exit.
>
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24
> MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would
> be acceptable.
>
> What is an easy way to do this?  Most Beaglebone ADC examples sample at
> kilohertz rates or slower.
>
> This guide:
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
> speaks of 200 KSPS.  What is the limitation here?
>
> I've seen various suggestions to use the PRU, but don't understand why.  I
> would think that since DMA would be required anyway, there should be no
> requirement to otherwise access the hardware with tight timing.  If PRU is
> indeed necessary, is there a suitable example or tutorial?  (None of the
> libpruio built-in examples deal with rapid sampling or large amounts of
> data.)
>
> Any other ideas for a simple way to capture data fast will be gratefully
> appreciated.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtnELw1UDxA79pnBs-sZp-cG%3Dq8GRWoGJpuzFCCdjwodKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture analog input at near maximum sample rate?

[evilwulfie]

on the am355x processor the ADC used is 12 bit SAR ADC with a sample
rate of 200 KSPS

any faster and you will need an external ADC


On 6/20/2016 12:53 PM, Micka wrote:
> the best woud be the PRU because you can store the data in the share
> memory. That is the fastest way.
>
> you can stop the acquisition whenever you want or let it go back at
> the beginning of your memory and go on.
>
>
> Le lun. 20 juin 2016 à 21:29,  > a écrit :
>
> I'm looking to write a simple app for BBB.  When started from the
> command line, it would set up the ADC in continuous mode and read
> ~1 M samples from e.g. AN0 into memory.  After the capture is
> complete, it would write the data to a file and exit.
>
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles
> of 24 MHz adc_clk per sample).  If that's not practical, 800 KSPS
> or better would be acceptable.
>
> What is an easy way to do this?  Most Beaglebone ADC examples
> sample at kilohertz rates or slower.
>
> This guide:
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
> speaks of 200 KSPS.  What is the limitation here?
>
> I've seen various suggestions to use the PRU, but don't understand
> why.  I would think that since DMA would be required anyway, there
> should be no requirement to otherwise access the hardware with
> tight timing.  If PRU is indeed necessary, is there a suitable
> example or tutorial?  (None of the libpruio built-in examples deal
> with rapid sampling or large amounts of data.)
>
> Any other ideas for a simple way to capture data fast will be
> gratefully appreciated.
>
> 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
> .
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtnELw1UDxA79pnBs-sZp-cG%3Dq8GRWoGJpuzFCCdjwodKQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/31b48724-08e9-5adf-24a4-3f516dafbdef%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is there Beaglebone Black Guide for LED diagnostics?

[kmanivannan]

Hey gerald, and william. I bought the serial cable and I got this:




can you figure out what's wrong here? 


On Thursday, June 16, 2016 at 10:44:53 AM UTC-5, 
kmani...@houstonmechatronics.com wrote:
>
> oh ok! thanks. I'll buy it!
>
> On Wednesday, June 15, 2016 at 12:37:46 PM UTC-6, William Hermans wrote:
>>
>> *Flash using one of the official images to make sure everything is 
>>> working fine.*
>>>
>>> *Gerald*
>>
>>
>> And then buy a serial debug cable. That's what they are for. 
>> Troubleshooting . . .
>>
>> On Wed, Jun 15, 2016 at 10:17 AM, Gerald Coley  
>> wrote:
>>
>>> Flash using one of the official images to make sure everything is 
>>> working fine.
>>>
>>> Gerald
>>>
>>>
>>>
>>>
>>> On Wed, Jun 15, 2016 at 11:53 AM,  
>>> wrote:
>>>
 Hi Gerald,

 I'm running Ubuntu 16.04 in my uSD card and I'm booting my BBB. 
 It used to behave normally, as in, the USER LEDs blink. Finally, after 
 booting up, I used to get the heartbeat in USER LED0, and no lights on the 
 others.

 But now, I don't know what I did, but I can't connect to the board and 
 after a lot of time after booting, the  USER LED2 lights up dimly, and I 
 get the heartbeat from LED0.
 The board isn't getting connected. 

 What did I do? How to fix this?

 On Tuesday, June 14, 2016 at 10:42:41 AM UTC-5, Gerald wrote:
>
> http://beagleboard.org/getting-started
>
> Gerald
>
> On Tue, Jun 14, 2016 at 10:32 AM, Keerthana Manivannan <
> kmani...@houstonmechatronics.com> wrote:
>
>> Hey did you find any solution to this? :D
>>
>> You must have, it's been two years! hehe.
>>
>> On Tuesday, February 25, 2014 at 5:53:53 PM UTC-6, 
>> win...@winstonford.com wrote:
>>>
>>> Is there a guide for diagnosing Beaglebone black boot problems based 
>>> on LEDs?  
>>>
>>> For instance, when I boot, I end up with 1 of 2 scenarios:
>>> 1. user1 and user2 on solid.
>>> 2. user0 beating faster than a normal heartbeat, and user1 beating 
>>> intermittently.
>>>
>>> I am booting Ubuntu 12.04 from microSD.  It for weeks until now.  
>>> Now I can't ping, ssh, or http in.
>>>
>>> Any help appreciated,
>>> W
>>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/5fd10c01-31c0-4319-9bfd-b65d014a2309%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org
> http://beagleboard.org/
> gco...@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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/beagleboard/8815becb-74de-40c7-894c-23a33f818197%40googlegroups.com
  
 
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Gerald
>>>  
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>> gco...@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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/CAHK_S%2Bd_B7imaM%2BTDkJEuebv-S6X9c0pBuvmiiDNX%2B1Ok5xJww%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"B

Re: [beagleboard] Re: Is there Beaglebone Black Guide for LED diagnostics?

[Robert Nelson]

On Mon, Jun 20, 2016 at 3:14 PM, 
wrote:

> Hey gerald, and william. I bought the serial cable and I got this:
>
>
> 
>
>
> can you figure out what's wrong here?
>

What's the issue?

Your running 16.04, i need to tweak connman, so just:

sudo ifconfig -a
sudo dhclient eth0

and then you'll have internet..

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhhhtJp2SgkkkD2KLOXjXKPbAgBi8y-mQfEVGZPTjSBRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is there Beaglebone Black Guide for LED diagnostics?

[kmanivannan]

no, I think the beaglebone black is connected via the serial port cable, 
not the usb. I want to connect to the BBB through the USB.

On Monday, June 20, 2016 at 3:19:21 PM UTC-5, RobertCNelson wrote:
>
>
>
> On Mon, Jun 20, 2016 at 3:14 PM,  > wrote:
>
>> Hey gerald, and william. I bought the serial cable and I got this:
>>
>>
>> 
>>
>>
>> can you figure out what's wrong here? 
>>
>
> What's the issue?
>
> Your running 16.04, i need to tweak connman, so just:
>
> sudo ifconfig -a
> sudo dhclient eth0
>
> and then you'll have internet..
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ca6e77ff-8b61-4249-aa56-597cc95f627b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture analog input at near maximum sample rate?

[Hunyue Yau]

The ADC block is rated for 200Ksps max. The easiest thing to do is a quick 
char device driver that configure the ADC with the right settling times and 
have the DMA engine gather the data. Once you have that all you need to do is 
cat /dev/foobar > file.

The block doesn't run from 24MHz. It is divided down.  IIRC, it needs to be 
around 6MHz.

The PRU is indeed unnecessary and a waste of resources. All that does is turn 
the flexible PRU into a DMA engine but there is a hard DMA engine on the SoC 
already. 

In Monday, June 20, 2016 12:09:03 snelson.st...@gmail.com wrote:
> I'm looking to write a simple app for BBB.  When started from the command
> line, it would set up the ADC in continuous mode and read ~1 M samples from
> e.g. AN0 into memory.  After the capture is complete, it would write the
> data to a file and exit.
> 
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24
> MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would
> be acceptable.
> 
> What is an easy way to do this?  Most Beaglebone ADC examples sample at
> kilohertz rates or slower.
> 
> This guide:
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
> speaks of 200 KSPS.  What is the limitation here?
> 
> I've seen various suggestions to use the PRU, but don't understand why.  I
> would think that since DMA would be required anyway, there should be no
> requirement to otherwise access the hardware with tight timing.  If PRU is
> indeed necessary, is there a suitable example or tutorial?  (None of the
> libpruio built-in examples deal with rapid sampling or large amounts of
> data.)
> 
> Any other ideas for a simple way to capture data fast will be gratefully
> appreciated.
> 
> Thank
-- 
Hunyue Yau
http://www.hy-research.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1496053.WtKKS7Pqg7%40acer0.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is there Beaglebone Black Guide for LED diagnostics?

[Robert Nelson]

On Mon, Jun 20, 2016 at 3:23 PM, 
wrote:

> no, I think the beaglebone black is connected via the serial port cable,
> not the usb. I want to connect to the BBB through the USB.
>

So, "YOU" need to configure the usb port to do that.

It's not a hardware default.

It's done in software, using the g_multi driver:

The magic is done in this script on bootup:

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYgzU%3DwgrRqCiZV6r9PNdkC3NewUwqPqyyKDLgwwd3uHMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is there Beaglebone Black Guide for LED diagnostics?

[kmanivannan]

perfect, it worked, thanks! :)

On Monday, June 20, 2016 at 3:28:38 PM UTC-5, RobertCNelson wrote:
>
>
>
> On Mon, Jun 20, 2016 at 3:23 PM,  > wrote:
>
>> no, I think the beaglebone black is connected via the serial port cable, 
>> not the usb. I want to connect to the BBB through the USB.
>>
>
> So, "YOU" need to configure the usb port to do that.
>
> It's not a hardware default.
>
> It's done in software, using the g_multi driver:
>
> The magic is done in this script on bootup:
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9796b907-1670-4a62-812d-4fbcf7443211%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

I have been working on adding DMA to the ADC driver, but it currently it throws 
overflow errors before DMA starts. The DMA should trigger when the ADC fifo 
reaches a predefined threshold, but for some reason there is a delay before DMA 
triggers. The ADC driver uses the IIO framework and I’m using their 
experimental DMA buffer framework which has its share of issues. I’m trying to 
diagnose the error by replicating the setup in Starterware.  Unfortunately the 
CCS debugger isn’t all that helpful so now I’m trying to get my Lauterbach 
working Starterware, but I have to translate the CCS GEL scripts to Lauterbach 
Practice scripts. 

Regarding the sampling rate, the datasheet does specify 200ksps, but if you 
setup the sample delay, open delay, etc, it should be possible to achieve 
something like 1.5msps, but I haven’t been able to verify this yet. 

Regards,
John




> On Jun 20, 2016, at 12:00 PM, Stewart  wrote:
> 
> I'm looking to write a simple app for BBB.  When started from the command 
> line, it would set up the ADC in continuous mode and read ~1 M samples from 
> e.g. AN0 into memory.  After the capture is complete, it would write the data 
> to a file and exit.
> 
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 MHz 
> adc_clk per sample).  If that's not practical, 800 KSPS or better would be 
> acceptable.
> 
> What is an easy way to do this?  Most Beaglebone ADC examples sample at 
> kilohertz rates or slower.
> 
> This guide: 
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide speaks 
> of 200 KSPS.  What is the limitation here?
> 
> I've seen various suggestions to use the PRU, but don't understand why.  I 
> would think that since DMA would be required anyway, there should be no 
> requirement to otherwise access the hardware with tight timing.  If PRU is 
> indeed necessary, is there a suitable example or tutorial?  (None of the 
> libpruio built-in examples deal with rapid sampling or large amounts of data.)
> 
> Any other ideas for a simple way to capture data fast will be gratefully 
> appreciated.
> 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0543FF25-240A-4275-8BB4-5F93E48F28D9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture analog input at near maximum sample rate?

[John Syne]

I have been working on adding DMA to the ADC driver, but it currently it throws 
overflow errors before DMA starts. The DMA should trigger when the ADC fifo 
reaches a predefined threshold, but for some reason there is a delay before DMA 
triggers. The ADC driver uses the IIO framework and I’m using their 
experimental DMA buffer framework which has its share of issues. I’m trying to 
diagnose the error by replicating the setup in Starterware.  Unfortunately the 
CCS debugger isn’t all that helpful so now I’m trying to get my Lauterbach 
working Starterware, but I have to translate the CCS GEL scripts to Lauterbach 
Practice scripts. 

Regarding the sampling rate, the datasheet does specify 200ksps, but if you 
setup the sample delay, open delay, etc, it should be possible to achieve 
something like 1.5msps, but I haven’t been able to verify this yet. 

Regards,
John




> On Jun 20, 2016, at 1:24 PM, Hunyue Yau  wrote:
> 
> The ADC block is rated for 200Ksps max. The easiest thing to do is a quick 
> char device driver that configure the ADC with the right settling times and 
> have the DMA engine gather the data. Once you have that all you need to do is 
> cat /dev/foobar > file.
> 
> The block doesn't run from 24MHz. It is divided down.  IIRC, it needs to be 
> around 6MHz.
> 
> The PRU is indeed unnecessary and a waste of resources. All that does is turn 
> the flexible PRU into a DMA engine but there is a hard DMA engine on the SoC 
> already. 
> 
> In Monday, June 20, 2016 12:09:03 snelson.st...@gmail.com wrote:
>> I'm looking to write a simple app for BBB.  When started from the command
>> line, it would set up the ADC in continuous mode and read ~1 M samples from
>> e.g. AN0 into memory.  After the capture is complete, it would write the
>> data to a file and exit.
>> 
>> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24
>> MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would
>> be acceptable.
>> 
>> What is an easy way to do this?  Most Beaglebone ADC examples sample at
>> kilohertz rates or slower.
>> 
>> This guide:
>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
>> speaks of 200 KSPS.  What is the limitation here?
>> 
>> I've seen various suggestions to use the PRU, but don't understand why.  I
>> would think that since DMA would be required anyway, there should be no
>> requirement to otherwise access the hardware with tight timing.  If PRU is
>> indeed necessary, is there a suitable example or tutorial?  (None of the
>> libpruio built-in examples deal with rapid sampling or large amounts of
>> data.)
>> 
>> Any other ideas for a simple way to capture data fast will be gratefully
>> appreciated.
>> 
>> Thank
> -- 
> Hunyue Yau
> http://www.hy-research.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/1496053.WtKKS7Pqg7%40acer0.
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/DA5DED53-9DB1-48CD-A1E6-1881C0B5BD50%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture analog input at near maximum sample rate?

[snelson . stuff]

Thanks for the reply.

I'm looking at the AM335x Technical Reference Manual, downloaded from
http://phytec.com/wiki/images/7/72/AM335x_techincal_reference_manual.pdf

Section 12.2.2 reads (in part):
Clock Signal Max Freq
adc_clk24 MHz
ADC clock(typ)

Section12.3.7 reads (in part):
Sampling rate can be as fast as every 15 ADC clock cycles

This works out to 1.6 MSPS, a number that I've also seen in numerous 
credible posts.  It seems logical, requiring 12 clock cycles for the SAR 
process; the remaining 3 being overhead to sample, initialize and store.

However, I've not heard of anyone actually get it to work at anything near 
that speed, though I also haven't found any info stating why it can't.  
There is an ADC_CLKDIV Register described in section 12.5.1.13 .  Although 
the 'Reset' value is 0 (corresponding to division by 1), I've read in 
various places that the 'default' value (presumably initialized by some 
driver) is 7 (corresponding to division by 8), which would indeed make the 
'15 ADC clock cycles' sample rate 200 KSPS.

Do you know what the obstacle is?   


On Monday, June 20, 2016 at 1:01:46 PM UTC-7, Wulf Man wrote:
>
> on the am355x processor the ADC used is 12 bit SAR ADC with a sample rate 
> of 200 KSPS
>
> any faster and you will need an external ADC
>
>
> On 6/20/2016 12:53 PM, Micka wrote:
>
> the best woud be the PRU because you can store the data in the share 
> memory. That is the fastest way.
>
> you can stop the acquisition whenever you want or let it go back at the 
> beginning of your memory and go on. 
>
>
> Le lun. 20 juin 2016 à 21:29, < snelso...@gmail.com 
> > a écrit :
>
>> I'm looking to write a simple app for BBB.  When started from the command 
>> line, it would set up the ADC in continuous mode and read ~1 M samples from 
>> e.g. AN0 into memory.  After the capture is complete, it would write the 
>> data to a file and exit.
>>
>> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 
>> MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would 
>> be acceptable.
>>
>> What is an easy way to do this?  Most Beaglebone ADC examples sample at 
>> kilohertz rates or slower.
>>
>> This guide: 
>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide 
>> speaks of 200 KSPS.  What is the limitation here?
>>
>> I've seen various suggestions to use the PRU, but don't understand why.  
>> I would think that since DMA would be required anyway, there should be no 
>> requirement to otherwise access the hardware with tight timing.  If PRU is 
>> indeed necessary, is there a suitable example or tutorial?  (None of the 
>> libpruio built-in examples deal with rapid sampling or large amounts of 
>> data.)
>>
>> Any other ideas for a simple way to capture data fast will be gratefully 
>> appreciated.
>>
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> 
>> https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> 
> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtnELw1UDxA79pnBs-sZp-cG%3Dq8GRWoGJpuzFCCdjwodKQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f381261d-fcb9-4c27-b58c-4298337f0c8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] apt-get -y install ntp gives error Failed to fetch http://security...

[Matt]

Thanks Robert.  Worked like a charm.

Did have to also install libopts25 with 

apt-get -y install libopts25

On Thursday, June 9, 2016 at 4:10:55 PM UTC-7, RobertCNelson wrote:
>
> On Thu, Jun 9, 2016 at 5:47 PM, Matt99eo  > wrote: 
> > Hi, 
> > 
> > I am trying to reinstall ntp on some BBB running 3.8.13-bone70  debian 
> > wheezy. 
> > 
> > When I run apt-get -y install --reinstall ntp I get: 
> > 
> > apt-get install --reinstall ntp 
> > Reading package lists... Done 
> > Building dependency tree 
> > Reading state information... Done 
> > 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 81 not 
> > upgraded. 
> > Need to get 494 kB of archives. 
> > After this operation, 0 B of additional disk space will be used. 
> > Err http://security.debian.org/ wheezy/updates/main ntp armhf 
> > 1:4.2.6.p5+dfsg-2+deb7u4 
> >   404  Not Found [IP: 128.101.240.215 80] 
> > Failed to fetch 
> > 
> http://security.debian.org/pool/updates/main/n/ntp/ntp_4.2.6.p5+dfsg-2+deb7u4_armhf.deb
>  
> > 404  Not Found [IP: 128.101.240.215 80] 
> > E: Unable to fetch some archives, maybe run apt-get update or try with 
> > --fix-missing? 
> > 
> > I don't want to run apt-get update -- as this device is running remotely 
> off 
> > a 2G slow connection. 
> > 
> > How can I fix this without having to run apt-get update? 
>
> Look at: 
>
> http://security.debian.org/pool/updates/main/n/ntp/ 
>
> See: ntp_4.2.6.p5+dfsg-2+deb7u6_armhf.deb 
>
> wget 
> http://security.debian.org/pool/updates/main/n/ntp/ntp_4.2.6.p5+dfsg-2+deb7u6_armhf.deb
>  
>
> sudo dpkg -i ntp_4.2.6.p5+dfsg-2+deb7u6_armhf.deb 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a378a317-ccc1-43c9-a0ae-aed1bd4eef76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture analog input at near maximum sample rate?

[snelson . stuff]

> the best woud be the PRU because you can store the data in the share 
memory.

Do you mean the 12KB data memory?  As I understand it, it's only shared 
between PRUs, not directly with the CPU.  Moving data from there to the CPU 
would require DMA, as 'programmed' access would not keep up with 1.6 MSPS.  
Is that right?  But if I understand correctly, the ADC can be configured to 
send its results (through an intermediate FIFO) to DMA, so the PRU would 
just be a needless layer of complexity.

Of course, If I could find free or inexpensive software that needed little 
or no modification to do the job, I wouldn't mind if it happened to use the 
PRU :)

Thanks.

On Monday, June 20, 2016 at 12:53:28 PM UTC-7, Micka wrote:
>
> the best woud be the PRU because you can store the data in the share 
> memory. That is the fastest way.
>
> you can stop the acquisition whenever you want or let it go back at the 
> beginning of your memory and go on.
>
>
> Le lun. 20 juin 2016 à 21:29, > a 
> écrit :
>
>> I'm looking to write a simple app for BBB.  When started from the command 
>> line, it would set up the ADC in continuous mode and read ~1 M samples from 
>> e.g. AN0 into memory.  After the capture is complete, it would write the 
>> data to a file and exit.
>>
>> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 
>> MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would 
>> be acceptable.
>>
>> What is an easy way to do this?  Most Beaglebone ADC examples sample at 
>> kilohertz rates or slower.
>>
>> This guide: 
>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide 
>> speaks of 200 KSPS.  What is the limitation here?
>>
>> I've seen various suggestions to use the PRU, but don't understand why.  
>> I would think that since DMA would be required anyway, there should be no 
>> requirement to otherwise access the hardware with tight timing.  If PRU is 
>> indeed necessary, is there a suitable example or tutorial?  (None of the 
>> libpruio built-in examples deal with rapid sampling or large amounts of 
>> data.)
>>
>> Any other ideas for a simple way to capture data fast will be gratefully 
>> appreciated.
>>
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bd593480-ae6b-453b-addd-0b9cb07036d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[William Hermans]

The ADC module is a 200ksps SAR module . . .You're only going to be able to
sample 200k samples per second . . .

Additionally you can use:


   1. PRUs ( Programmable Real-time Units )
   2. IIO ( industrial IO )
   3. /dev/mem/ + mmap()


To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work
for reading 200ksps for 7 channel simultaneously. But CPU usage is so high,
that you're not going ot be able to do a whole lot more in addition to
reading the ADC in this fashion. Hence, the PRU are best used, as this
offers hardware offload( very little CPU load needed - and only when
reading values out  ).

On Mon, Jun 20, 2016 at 12:00 PM, Stewart  wrote:

> I'm looking to write a simple app for BBB.  When started from the command
> line, it would set up the ADC in continuous mode and read ~1 M samples from
> e.g. AN0 into memory.  After the capture is complete, it would write the
> data to a file and exit.
>
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24
> MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would
> be acceptable.
>
> What is an easy way to do this?  Most Beaglebone ADC examples sample at
> kilohertz rates or slower.
>
> This guide:
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
> speaks of 200 KSPS.  What is the limitation here?
>
> I've seen various suggestions to use the PRU, but don't understand why.  I
> would think that since DMA would be required anyway, there should be no
> requirement to otherwise access the hardware with tight timing.  If PRU is
> indeed necessary, is there a suitable example or tutorial?  (None of the
> libpruio built-in examples deal with rapid sampling or large amounts of
> data.)
>
> Any other ideas for a simple way to capture data fast will be gratefully
> appreciated.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORp6fi1O6wbX92umVoCWhQwOQRC2bpNKe%3DkFEQ3vBE%3D-8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture analog input at near maximum sample rate?

[William Hermans]

http://lmgtfy.com/?q=AM335c+ADC+module ->
http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Introduction

An analog-to-digital converter (abbreviated ADC) is a device that uses
> sampling to convert a continuous quantity to a discrete time representation
> in digital form.
>
> The TSC_ADC_SS (Touchscreen_ADC_subsystem) is an 8 channel general purpose
> ADC, with optional support for interleaving Touch Screen conversions. The
> TSC_ADC_SS can be used and configured in one of the following application
> options:
>
>- 8 general purpose ADC channels
>- 4 wire TS, with 4 general purpose ADC channels
>- 5 wire TS, with 3 general purpose ADC channels
>- 8 wire TS
>
> *ADC used is 12 bit SAR ADC with a sample rate of 200 KSPS (Kilo Samples
> Per Second).* The ADC samples the analog signal when "start of
> conversion" signal is high and continues sampling 1 clock cycle after the
> falling edge. It captures the signal at the end of sampling period and
> starts conversion. It uses 12 clock cycles to digitize the sampled input;
> then an "end of conversion" signal is enabled high indicating that the
> digital data ADCOUT<11:0> is ready for SW to consume. A new conversion
> cycle can be initiated after the previous data is read. Please note that
> the ADC output is positive binary weighted data.
>




On Mon, Jun 20, 2016 at 2:33 PM,  wrote:

> > the best woud be the PRU because you can store the data in the share
> memory.
>
> Do you mean the 12KB data memory?  As I understand it, it's only shared
> between PRUs, not directly with the CPU.  Moving data from there to the CPU
> would require DMA, as 'programmed' access would not keep up with 1.6 MSPS.
> Is that right?  But if I understand correctly, the ADC can be configured to
> send its results (through an intermediate FIFO) to DMA, so the PRU would
> just be a needless layer of complexity.
>
> Of course, If I could find free or inexpensive software that needed little
> or no modification to do the job, I wouldn't mind if it happened to use the
> PRU :)
>
> Thanks.
>
> On Monday, June 20, 2016 at 12:53:28 PM UTC-7, Micka wrote:
>>
>> the best woud be the PRU because you can store the data in the share
>> memory. That is the fastest way.
>>
>> you can stop the acquisition whenever you want or let it go back at the
>> beginning of your memory and go on.
>>
>>
>> Le lun. 20 juin 2016 à 21:29,  a écrit :
>>
>>> I'm looking to write a simple app for BBB.  When started from the
>>> command line, it would set up the ADC in continuous mode and read ~1 M
>>> samples from e.g. AN0 into memory.  After the capture is complete, it would
>>> write the data to a file and exit.
>>>
>>> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24
>>> MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would
>>> be acceptable.
>>>
>>> What is an easy way to do this?  Most Beaglebone ADC examples sample at
>>> kilohertz rates or slower.
>>>
>>> This guide:
>>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
>>> speaks of 200 KSPS.  What is the limitation here?
>>>
>>> I've seen various suggestions to use the PRU, but don't understand why.
>>> I would think that since DMA would be required anyway, there should be no
>>> requirement to otherwise access the hardware with tight timing.  If PRU is
>>> indeed necessary, is there a suitable example or tutorial?  (None of the
>>> libpruio built-in examples deal with rapid sampling or large amounts of
>>> data.)
>>>
>>> Any other ideas for a simple way to capture data fast will be gratefully
>>> appreciated.
>>>
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/bd593480-ae6b-453b-addd-0b9cb07036d6%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://b

Re: [beagleboard] Capture analog input at near maximum sample rate?

[William Hermans]

>
> The ADC block is rated for 200Ksps max. The easiest thing to do is a quick
> char device driver that configure the ADC with the right settling times and
> have the DMA engine gather the data. Once you have that all you need to do
> is
> cat /dev/foobar > file.
>

No point. IIO is already included, and used with the latest debian images.

On Mon, Jun 20, 2016 at 3:07 PM, William Hermans  wrote:

> http://lmgtfy.com/?q=AM335c+ADC+module ->
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Introduction
>
> An analog-to-digital converter (abbreviated ADC) is a device that uses
>> sampling to convert a continuous quantity to a discrete time representation
>> in digital form.
>>
>> The TSC_ADC_SS (Touchscreen_ADC_subsystem) is an 8 channel general
>> purpose ADC, with optional support for interleaving Touch Screen
>> conversions. The TSC_ADC_SS can be used and configured in one of the
>> following application options:
>>
>>- 8 general purpose ADC channels
>>- 4 wire TS, with 4 general purpose ADC channels
>>- 5 wire TS, with 3 general purpose ADC channels
>>- 8 wire TS
>>
>> *ADC used is 12 bit SAR ADC with a sample rate of 200 KSPS (Kilo Samples
>> Per Second).* The ADC samples the analog signal when "start of
>> conversion" signal is high and continues sampling 1 clock cycle after the
>> falling edge. It captures the signal at the end of sampling period and
>> starts conversion. It uses 12 clock cycles to digitize the sampled input;
>> then an "end of conversion" signal is enabled high indicating that the
>> digital data ADCOUT<11:0> is ready for SW to consume. A new conversion
>> cycle can be initiated after the previous data is read. Please note that
>> the ADC output is positive binary weighted data.
>>
>
>
>
>
> On Mon, Jun 20, 2016 at 2:33 PM,  wrote:
>
>> > the best woud be the PRU because you can store the data in the share
>> memory.
>>
>> Do you mean the 12KB data memory?  As I understand it, it's only shared
>> between PRUs, not directly with the CPU.  Moving data from there to the CPU
>> would require DMA, as 'programmed' access would not keep up with 1.6 MSPS.
>> Is that right?  But if I understand correctly, the ADC can be configured to
>> send its results (through an intermediate FIFO) to DMA, so the PRU would
>> just be a needless layer of complexity.
>>
>> Of course, If I could find free or inexpensive software that needed
>> little or no modification to do the job, I wouldn't mind if it happened to
>> use the PRU :)
>>
>> Thanks.
>>
>> On Monday, June 20, 2016 at 12:53:28 PM UTC-7, Micka wrote:
>>>
>>> the best woud be the PRU because you can store the data in the share
>>> memory. That is the fastest way.
>>>
>>> you can stop the acquisition whenever you want or let it go back at the
>>> beginning of your memory and go on.
>>>
>>>
>>> Le lun. 20 juin 2016 à 21:29,  a écrit :
>>>
 I'm looking to write a simple app for BBB.  When started from the
 command line, it would set up the ADC in continuous mode and read ~1 M
 samples from e.g. AN0 into memory.  After the capture is complete, it would
 write the data to a file and exit.

 Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of
 24 MHz adc_clk per sample).  If that's not practical, 800 KSPS or better
 would be acceptable.

 What is an easy way to do this?  Most Beaglebone ADC examples sample at
 kilohertz rates or slower.

 This guide:
 http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
 speaks of 200 KSPS.  What is the limitation here?

 I've seen various suggestions to use the PRU, but don't understand
 why.  I would think that since DMA would be required anyway, there should
 be no requirement to otherwise access the hardware with tight timing.  If
 PRU is indeed necessary, is there a suitable example or tutorial?  (None of
 the libpruio built-in examples deal with rapid sampling or large amounts of
 data.)

 Any other ideas for a simple way to capture data fast will be
 gratefully appreciated.

 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...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsub

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

You should read the info Steward provided. There is a conflict in the AM3358 
datasheet because it does say max 200ksps, but in the register settings, it 
does show you can configure the ADC for 1.6msps. There are discussions on E2E 
about this issue and no one from TI has said you cannot achieve 1.6msps. 

Regards,
John




> On Jun 20, 2016, at 2:53 PM, William Hermans  wrote:
> 
> The ADC module is a 200ksps SAR module . . .You're only going to be able to 
> sample 200k samples per second . . . 
> 
> Additionally you can use:
> 
> PRUs ( Programmable Real-time Units )
> IIO ( industrial IO )
> /dev/mem/ + mmap()
> 
> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work for 
> reading 200ksps for 7 channel simultaneously. But CPU usage is so high, that 
> you're not going ot be able to do a whole lot more in addition to reading the 
> ADC in this fashion. Hence, the PRU are best used, as this offers hardware 
> offload( very little CPU load needed - and only when reading values out  ).
> 
> On Mon, Jun 20, 2016 at 12:00 PM, Stewart  > wrote:
> I'm looking to write a simple app for BBB.  When started from the command 
> line, it would set up the ADC in continuous mode and read ~1 M samples from 
> e.g. AN0 into memory.  After the capture is complete, it would write the data 
> to a file and exit.
> 
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 MHz 
> adc_clk per sample).  If that's not practical, 800 KSPS or better would be 
> acceptable.
> 
> What is an easy way to do this?  Most Beaglebone ADC examples sample at 
> kilohertz rates or slower.
> 
> This guide: 
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide 
>  
> speaks of 200 KSPS.  What is the limitation here?
> 
> I've seen various suggestions to use the PRU, but don't understand why.  I 
> would think that since DMA would be required anyway, there should be no 
> requirement to otherwise access the hardware with tight timing.  If PRU is 
> indeed necessary, is there a suitable example or tutorial?  (None of the 
> libpruio built-in examples deal with rapid sampling or large amounts of data.)
> 
> Any other ideas for a simple way to capture data fast will be gratefully 
> appreciated.
> 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CALHSORp6fi1O6wbX92umVoCWhQwOQRC2bpNKe%3DkFEQ3vBE%3D-8A%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CDE96EC4-4C68-4022-9390-7F5011F12FB5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[snelson . stuff]

Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.

But can you please confirm that by "200ksps for 7 channel simultaneously" 
you mean that each of the 7 channels is being sampled 200k times per 
second.  If so, that's 1.4M captures per second, enough for my project.

> But CPU usage is so high, that you're not going to be able to do a whole 
lot more in addition to reading the ADC in this fashion.

This is essentially a lab experiment.  The program only needs to run 
correctly once (though it will take many executions to get all the external 
factors right).  On each run, the BBB has no other tasks to perform.  It 
won't start writing the results to a file until after the capture is 
complete.  If CPU usage during the capture is 95%, that's fine.  If it's 
105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's 
250%, then I'm in trouble.

If not missing samples requires running in single-user mode with no 
networking and only a serial console, that's IMO a minor nuisance compared 
to learning about PRU, etc. and debugging a much more complex program.

On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote:
>
> The ADC module is a 200ksps SAR module . . .You're only going to be able 
> to sample 200k samples per second . . . 
>
> Additionally you can use:
>
>
>1. PRUs ( Programmable Real-time Units )
>2. IIO ( industrial IO )
>3. /dev/mem/ + mmap()
>
>
> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work 
> for reading 200ksps for 7 channel simultaneously. But CPU usage is so high, 
> that you're not going ot be able to do a whole lot more in addition to 
> reading the ADC in this fashion. Hence, the PRU are best used, as this 
> offers hardware offload( very little CPU load needed - and only when 
> reading values out  ).
>
> On Mon, Jun 20, 2016 at 12:00 PM, Stewart  > wrote:
>
>> I'm looking to write a simple app for BBB.  When started from the command 
>> line, it would set up the ADC in continuous mode and read ~1 M samples from 
>> e.g. AN0 into memory.  After the capture is complete, it would write the 
>> data to a file and exit.
>>
>> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 
>> MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would 
>> be acceptable.
>>
>> What is an easy way to do this?  Most Beaglebone ADC examples sample at 
>> kilohertz rates or slower.
>>
>> This guide: 
>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide 
>> speaks of 200 KSPS.  What is the limitation here?
>>
>> I've seen various suggestions to use the PRU, but don't understand why.  
>> I would think that since DMA would be required anyway, there should be no 
>> requirement to otherwise access the hardware with tight timing.  If PRU is 
>> indeed necessary, is there a suitable example or tutorial?  (None of the 
>> libpruio built-in examples deal with rapid sampling or large amounts of 
>> data.)
>>
>> Any other ideas for a simple way to capture data fast will be gratefully 
>> appreciated.
>>
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2ff2e93c-ca65-46ec-a755-5c7f830da2b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[evilwulfie]

um no the 7 channels go into a analog mux and you can only have one
selected input at a time.

On 6/20/2016 3:35 PM, snelson.st...@gmail.com wrote:
> Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.
>
> But can you please confirm that by "200ksps for 7 channel
> simultaneously" you mean that each of the 7 channels is being sampled
> 200k times per second.  If so, that's 1.4M captures per second, enough
> for my project.
>
> > But CPU usage is so high, that you're not going to be able to do a
> whole lot more in addition to reading the ADC in this fashion.
>
> This is essentially a lab experiment.  The program only needs to run
> correctly once (though it will take many executions to get all the
> external factors right).  On each run, the BBB has no other tasks to
> perform.  It won't start writing the results to a file until after the
> capture is complete.  If CPU usage during the capture is 95%, that's
> fine.  If it's 105%, I'll slow the sample rate a bit to avoid losing
> samples.  But if it's 250%, then I'm in trouble.
>
> If not missing samples requires running in single-user mode with no
> networking and only a serial console, that's IMO a minor nuisance
> compared to learning about PRU, etc. and debugging a much more complex
> program.
>
> On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote:
>
> The ADC module is a 200ksps SAR module . . .You're only going to
> be able to sample 200k samples per second . . .
>
> Additionally you can use:
>
>  1. PRUs ( Programmable Real-time Units )
>  2. IIO ( industrial IO )
>  3. /dev/mem/ + mmap()
>
>
> To read 200ksps. Personally, I've proven that /dev/mem + mmap()
> can work for reading 200ksps for 7 channel simultaneously. But CPU
> usage is so high, that you're not going ot be able to do a whole
> lot more in addition to reading the ADC in this fashion. Hence,
> the PRU are best used, as this offers hardware offload( very
> little CPU load needed - and only when reading values out  ).
>
> On Mon, Jun 20, 2016 at 12:00 PM, Stewart  > wrote:
>
> I'm looking to write a simple app for BBB.  When started from
> the command line, it would set up the ADC in continuous mode
> and read ~1 M samples from e.g. AN0 into memory.  After the
> capture is complete, it would write the data to a file and exit.
>
> Ideally, it would run at the hardware limit of 1.6 MSPS (15
> cycles of 24 MHz adc_clk per sample).  If that's not
> practical, 800 KSPS or better would be acceptable.
>
> What is an easy way to do this?  Most Beaglebone ADC examples
> sample at kilohertz rates or slower.
>
> This guide:
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
> 
> 
> speaks of 200 KSPS.  What is the limitation here?
>
> I've seen various suggestions to use the PRU, but don't
> understand why.  I would think that since DMA would be
> required anyway, there should be no requirement to otherwise
> access the hardware with tight timing.  If PRU is indeed
> necessary, is there a suitable example or tutorial?  (None of
> the libpruio built-in examples deal with rapid sampling or
> large amounts of data.)
>
> Any other ideas for a simple way to capture data fast will be
> gratefully appreciated.
>
> 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...@googlegroups.com
> .
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout
> .
>
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/2ff2e93c-ca65-46ec-a755-5c7f830da2b1%40googlegroups.com
> .
> For more opt

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

You don’t read the IIO driver that way. You read the samples from 
/dev/iio:device0. You can modify the open delay, sample delay, in the 
devicetree, but because the current driver uses interrupts, the cpu utilization 
increases as you increase the sample rate. Also, the convertor is specified as 
200ksps, but there is only one converter for all channel which use a 
multiplexor to select each ADC channel.  So if you use 2 channels, then each 
channel is sampled at 100ksps. 

Regards,
John




> On Jun 20, 2016, at 3:35 PM, snelson.st...@gmail.com wrote:
> 
> Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.
> 
> But can you please confirm that by "200ksps for 7 channel simultaneously" you 
> mean that each of the 7 channels is being sampled 200k times per second.  If 
> so, that's 1.4M captures per second, enough for my project.
> 
> > But CPU usage is so high, that you're not going to be able to do a whole 
> > lot more in addition to reading the ADC in this fashion.
> 
> This is essentially a lab experiment.  The program only needs to run 
> correctly once (though it will take many executions to get all the external 
> factors right).  On each run, the BBB has no other tasks to perform.  It 
> won't start writing the results to a file until after the capture is 
> complete.  If CPU usage during the capture is 95%, that's fine.  If it's 
> 105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's 
> 250%, then I'm in trouble.
> 
> If not missing samples requires running in single-user mode with no 
> networking and only a serial console, that's IMO a minor nuisance compared to 
> learning about PRU, etc. and debugging a much more complex program.
> 
> On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote:
> The ADC module is a 200ksps SAR module . . .You're only going to be able to 
> sample 200k samples per second . . . 
> 
> Additionally you can use:
> 
> PRUs ( Programmable Real-time Units )
> IIO ( industrial IO )
> /dev/mem/ + mmap()
> 
> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work for 
> reading 200ksps for 7 channel simultaneously. But CPU usage is so high, that 
> you're not going ot be able to do a whole lot more in addition to reading the 
> ADC in this fashion. Hence, the PRU are best used, as this offers hardware 
> offload( very little CPU load needed - and only when reading values out  ).
> 
> On Mon, Jun 20, 2016 at 12:00 PM, Stewart > 
> wrote:
> I'm looking to write a simple app for BBB.  When started from the command 
> line, it would set up the ADC in continuous mode and read ~1 M samples from 
> e.g. AN0 into memory.  After the capture is complete, it would write the data 
> to a file and exit.
> 
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 MHz 
> adc_clk per sample).  If that's not practical, 800 KSPS or better would be 
> acceptable.
> 
> What is an easy way to do this?  Most Beaglebone ADC examples sample at 
> kilohertz rates or slower.
> 
> This guide: 
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide 
>  
> speaks of 200 KSPS.  What is the limitation here?
> 
> I've seen various suggestions to use the PRU, but don't understand why.  I 
> would think that since DMA would be required anyway, there should be no 
> requirement to otherwise access the hardware with tight timing.  If PRU is 
> indeed necessary, is there a suitable example or tutorial?  (None of the 
> libpruio built-in examples deal with rapid sampling or large amounts of data.)
> 
> Any other ideas for a simple way to capture data fast will be gratefully 
> appreciated.
> 
> 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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/2ff2e93c-ca65-46ec-a755-5c7f830da2b1%4

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/382609/1349287#1349287 


Regards,
John




> On Jun 20, 2016, at 12:00 PM, Stewart  wrote:
> 
> I'm looking to write a simple app for BBB.  When started from the command 
> line, it would set up the ADC in continuous mode and read ~1 M samples from 
> e.g. AN0 into memory.  After the capture is complete, it would write the data 
> to a file and exit.
> 
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 MHz 
> adc_clk per sample).  If that's not practical, 800 KSPS or better would be 
> acceptable.
> 
> What is an easy way to do this?  Most Beaglebone ADC examples sample at 
> kilohertz rates or slower.
> 
> This guide: 
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide speaks 
> of 200 KSPS.  What is the limitation here?
> 
> I've seen various suggestions to use the PRU, but don't understand why.  I 
> would think that since DMA would be required anyway, there should be no 
> requirement to otherwise access the hardware with tight timing.  If PRU is 
> indeed necessary, is there a suitable example or tutorial?  (None of the 
> libpruio built-in examples deal with rapid sampling or large amounts of data.)
> 
> Any other ideas for a simple way to capture data fast will be gratefully 
> appreciated.
> 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/30BAF407-1354-4CEC-95DE-BB6A5803AA1E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: No free space on SD card partition after writing 2016-06-05

[Wally Bkg]

I know that, that is why I said its not a show-stopper, and Windows users can 
still boot the card and run grow_partition.sh, but the previous testing lxqt 
images were apparently sized to match the 4GB eMMC.

If there is a reason for it, (new slightly smaller eMMC chip to save a few 
pennies on some board revisions?) that's fine, but if its an error that crept 
into the image making process, I thought RCN might want to know.  I did verify 
that the 0 bytes free didn't interfere with the Beaglebone initial boot up.


I was pretty impressed by the Etcher application, at least on a current version 
of Linux,  If it works as well on Windows it'll help a lot of people get 
started with newer images.  Maybe its better now, but a few months ago my BBG 
shipped with a pretty useless image in the eMMC.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1f44806b-9916-4927-aabc-0e35cf42079b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[snelson . stuff]

I'm well aware of the analog mux and fully understand that if N channels 
are being sampled, the maximum sample rate for each channel is reduced by a 
factor of N.

However, Mr. Hermans, who clearly knows what he is talking about, stated 
"I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
channel simultaneously."
It's reasonable to assume that he would not have included the "7 channel 
simultaneously" part unless it was somehow relevant to the performance he 
observed.

And, if the ADC is actually capable of doing conversions at a 1.6 MHz rate, 
then it could sample all 8 channels at 200KSPS each, and maybe that's what 
Mr. Hermans was observing.


On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote:
>
> um no the 7 channels go into a analog mux and you can only have one 
> selected input at a time.
>
> On 6/20/2016 3:35 PM, snelso...@gmail.com  wrote:
>
> Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.
>
> But can you please confirm that by "200ksps for 7 channel simultaneously" 
> you mean that each of the 7 channels is being sampled 200k times per 
> second.  If so, that's 1.4M captures per second, enough for my project.
>
> > But CPU usage is so high, that you're not going to be able to do a whole 
> lot more in addition to reading the ADC in this fashion.
>
> This is essentially a lab experiment.  The program only needs to run 
> correctly once (though it will take many executions to get all the external 
> factors right).  On each run, the BBB has no other tasks to perform.  It 
> won't start writing the results to a file until after the capture is 
> complete.  If CPU usage during the capture is 95%, that's fine.  If it's 
> 105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's 
> 250%, then I'm in trouble.
>
> If not missing samples requires running in single-user mode with no 
> networking and only a serial console, that's IMO a minor nuisance compared 
> to learning about PRU, etc. and debugging a much more complex program.
>
> On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote: 
>>
>> The ADC module is a 200ksps SAR module . . .You're only going to be able 
>> to sample 200k samples per second . . . 
>>
>> Additionally you can use:
>>
>>
>>1. PRUs ( Programmable Real-time Units ) 
>>2. IIO ( industrial IO ) 
>>3. /dev/mem/ + mmap() 
>>
>>
>> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work 
>> for reading 200ksps for 7 channel simultaneously. But CPU usage is so high, 
>> that you're not going ot be able to do a whole lot more in addition to 
>> reading the ADC in this fashion. Hence, the PRU are best used, as this 
>> offers hardware offload( very little CPU load needed - and only when 
>> reading values out  ).
>>
>> On Mon, Jun 20, 2016 at 12:00 PM, Stewart  wrote:
>>
>>> I'm looking to write a simple app for BBB.  When started from the 
>>> command line, it would set up the ADC in continuous mode and read ~1 M 
>>> samples from e.g. AN0 into memory.  After the capture is complete, it would 
>>> write the data to a file and exit.
>>>
>>> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 
>>> MHz adc_clk per sample).  If that's not practical, 800 KSPS or better would 
>>> be acceptable.
>>>
>>> What is an easy way to do this?  Most Beaglebone ADC examples sample at 
>>> kilohertz rates or slower.
>>>
>>> This guide: 
>>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide 
>>> speaks of 200 KSPS.  What is the limitation here?
>>>
>>> I've seen various suggestions to use the PRU, but don't understand why.  
>>> I would think that since DMA would be required anyway, there should be no 
>>> requirement to otherwise access the hardware with tight timing.  If PRU is 
>>> indeed necessary, is there a suitable example or tutorial?  (None of the 
>>> libpruio built-in examples deal with rapid sampling or large amounts of 
>>> data.)
>>>
>>> Any other ideas for a simple way to capture data fast will be gratefully 
>>> appreciated.
>>>
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> 
>>> https://groups.google.com/d/
>>> msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving em

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[William Hermans]

>
> However, Mr. Hermans, who clearly knows what he is talking about, stated
> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7
> channel simultaneously."
> It's reasonable to assume that he would not have included the "7 channel
> simultaneously" part unless it was somehow relevant to the performance he
> observed.
>

You're not understanding correctly . . . the ADC module is rated for
200ksps only. Not 1M, not 2M, 200ksps.

On Mon, Jun 20, 2016 at 4:40 PM,  wrote:

> I'm well aware of the analog mux and fully understand that if N channels
> are being sampled, the maximum sample rate for each channel is reduced by a
> factor of N.
>
> However, Mr. Hermans, who clearly knows what he is talking about, stated
> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7
> channel simultaneously."
> It's reasonable to assume that he would not have included the "7 channel
> simultaneously" part unless it was somehow relevant to the performance he
> observed.
>
> And, if the ADC is actually capable of doing conversions at a 1.6 MHz
> rate, then it could sample all 8 channels at 200KSPS each, and maybe that's
> what Mr. Hermans was observing.
>
>
> On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote:
>>
>> um no the 7 channels go into a analog mux and you can only have one
>> selected input at a time.
>>
>> On 6/20/2016 3:35 PM, snelso...@gmail.com wrote:
>>
>> Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.
>>
>> But can you please confirm that by "200ksps for 7 channel simultaneously"
>> you mean that each of the 7 channels is being sampled 200k times per
>> second.  If so, that's 1.4M captures per second, enough for my project.
>>
>> > But CPU usage is so high, that you're not going to be able to do a
>> whole lot more in addition to reading the ADC in this fashion.
>>
>> This is essentially a lab experiment.  The program only needs to run
>> correctly once (though it will take many executions to get all the external
>> factors right).  On each run, the BBB has no other tasks to perform.  It
>> won't start writing the results to a file until after the capture is
>> complete.  If CPU usage during the capture is 95%, that's fine.  If it's
>> 105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's
>> 250%, then I'm in trouble.
>>
>> If not missing samples requires running in single-user mode with no
>> networking and only a serial console, that's IMO a minor nuisance compared
>> to learning about PRU, etc. and debugging a much more complex program.
>>
>> On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote:
>>>
>>> The ADC module is a 200ksps SAR module . . .You're only going to be able
>>> to sample 200k samples per second . . .
>>>
>>> Additionally you can use:
>>>
>>>
>>>1. PRUs ( Programmable Real-time Units )
>>>2. IIO ( industrial IO )
>>>3. /dev/mem/ + mmap()
>>>
>>>
>>> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work
>>> for reading 200ksps for 7 channel simultaneously. But CPU usage is so high,
>>> that you're not going ot be able to do a whole lot more in addition to
>>> reading the ADC in this fashion. Hence, the PRU are best used, as this
>>> offers hardware offload( very little CPU load needed - and only when
>>> reading values out  ).
>>>
>>> On Mon, Jun 20, 2016 at 12:00 PM, Stewart  wrote:
>>>
 I'm looking to write a simple app for BBB.  When started from the
 command line, it would set up the ADC in continuous mode and read ~1 M
 samples from e.g. AN0 into memory.  After the capture is complete, it would
 write the data to a file and exit.

 Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of
 24 MHz adc_clk per sample).  If that's not practical, 800 KSPS or better
 would be acceptable.

 What is an easy way to do this?  Most Beaglebone ADC examples sample at
 kilohertz rates or slower.

 This guide:
 http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
 speaks of 200 KSPS.  What is the limitation here?

 I've seen various suggestions to use the PRU, but don't understand
 why.  I would think that since DMA would be required anyway, there should
 be no requirement to otherwise access the hardware with tight timing.  If
 PRU is indeed necessary, is there a suitable example or tutorial?  (None of
 the libpruio built-in examples deal with rapid sampling or large amounts of
 data.)

 Any other ideas for a simple way to capture data fast will be
 gratefully appreciated.

 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...@googlegroups.com.
 To view this discussion on the web

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[William Hermans]

http://www.ti.com/lit/ds/sprs717j/sprs717j.pdf

Page 3:

– 12-Bit Successive Approximation Register
(SAR) ADC
• 200K Samples per Second
• Input can be Selected from any of the Eight Analog *Inputs
Multiplexed* *Through
an 8:1 Analog Switch*
• Can be Configured to Operate as a 4-Wire, 5-Wire, or 8-Wire Resistive
Touch Screen Controller (TSC) Interface

On Mon, Jun 20, 2016 at 4:44 PM, William Hermans  wrote:

> However, Mr. Hermans, who clearly knows what he is talking about, stated
>> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7
>> channel simultaneously."
>> It's reasonable to assume that he would not have included the "7 channel
>> simultaneously" part unless it was somehow relevant to the performance he
>> observed.
>>
>
> You're not understanding correctly . . . the ADC module is rated for
> 200ksps only. Not 1M, not 2M, 200ksps.
>
> On Mon, Jun 20, 2016 at 4:40 PM,  wrote:
>
>> I'm well aware of the analog mux and fully understand that if N channels
>> are being sampled, the maximum sample rate for each channel is reduced by a
>> factor of N.
>>
>> However, Mr. Hermans, who clearly knows what he is talking about, stated
>> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7
>> channel simultaneously."
>> It's reasonable to assume that he would not have included the "7 channel
>> simultaneously" part unless it was somehow relevant to the performance he
>> observed.
>>
>> And, if the ADC is actually capable of doing conversions at a 1.6 MHz
>> rate, then it could sample all 8 channels at 200KSPS each, and maybe that's
>> what Mr. Hermans was observing.
>>
>>
>> On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote:
>>>
>>> um no the 7 channels go into a analog mux and you can only have one
>>> selected input at a time.
>>>
>>> On 6/20/2016 3:35 PM, snelso...@gmail.com wrote:
>>>
>>> Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.
>>>
>>> But can you please confirm that by "200ksps for 7 channel
>>> simultaneously" you mean that each of the 7 channels is being sampled 200k
>>> times per second.  If so, that's 1.4M captures per second, enough for my
>>> project.
>>>
>>> > But CPU usage is so high, that you're not going to be able to do a
>>> whole lot more in addition to reading the ADC in this fashion.
>>>
>>> This is essentially a lab experiment.  The program only needs to run
>>> correctly once (though it will take many executions to get all the external
>>> factors right).  On each run, the BBB has no other tasks to perform.  It
>>> won't start writing the results to a file until after the capture is
>>> complete.  If CPU usage during the capture is 95%, that's fine.  If it's
>>> 105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's
>>> 250%, then I'm in trouble.
>>>
>>> If not missing samples requires running in single-user mode with no
>>> networking and only a serial console, that's IMO a minor nuisance compared
>>> to learning about PRU, etc. and debugging a much more complex program.
>>>
>>> On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote:

 The ADC module is a 200ksps SAR module . . .You're only going to be
 able to sample 200k samples per second . . .

 Additionally you can use:


1. PRUs ( Programmable Real-time Units )
2. IIO ( industrial IO )
3. /dev/mem/ + mmap()


 To read 200ksps. Personally, I've proven that /dev/mem + mmap() can
 work for reading 200ksps for 7 channel simultaneously. But CPU usage is so
 high, that you're not going ot be able to do a whole lot more in addition
 to reading the ADC in this fashion. Hence, the PRU are best used, as this
 offers hardware offload( very little CPU load needed - and only when
 reading values out  ).

 On Mon, Jun 20, 2016 at 12:00 PM, Stewart  wrote:

> I'm looking to write a simple app for BBB.  When started from the
> command line, it would set up the ADC in continuous mode and read ~1 M
> samples from e.g. AN0 into memory.  After the capture is complete, it 
> would
> write the data to a file and exit.
>
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of
> 24 MHz adc_clk per sample).  If that's not practical, 800 KSPS or better
> would be acceptable.
>
> What is an easy way to do this?  Most Beaglebone ADC examples sample
> at kilohertz rates or slower.
>
> This guide:
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide
> speaks of 200 KSPS.  What is the limitation here?
>
> I've seen various suggestions to use the PRU, but don't understand
> why.  I would think that since DMA would be required anyway, there should
> be no requirement to otherwise access the hardware with tight timing.  If
> PRU is indeed necessary, is there a suitable example or tutorial?  (None 
> of
> the libpruio built-in example

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

The ADC uses a sequencer and you can only read the sample when the samples are 
complete. The sequencer provides an interrupt or triggers a DMA transfer when 
the EOC (End of Conversion) is achieved. Since you cannot service interrupts in 
userspace, you will have to poll repeatedly to wait for the conversion to 
complete. Given the non deterministic nature of Linux, you will miss some of 
the conversions when you processor utilization is high. Polling itself will 
cause high CPU utilization. Hence the /dev/mem + mmap() won’t work. 

Regards,
John




> On Jun 20, 2016, at 4:40 PM, snelson.st...@gmail.com wrote:
> 
> I'm well aware of the analog mux and fully understand that if N channels are 
> being sampled, the maximum sample rate for each channel is reduced by a 
> factor of N.
> 
> However, Mr. Hermans, who clearly knows what he is talking about, stated 
> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
> channel simultaneously."
> It's reasonable to assume that he would not have included the "7 channel 
> simultaneously" part unless it was somehow relevant to the performance he 
> observed.
> 
> And, if the ADC is actually capable of doing conversions at a 1.6 MHz rate, 
> then it could sample all 8 channels at 200KSPS each, and maybe that's what 
> Mr. Hermans was observing.
> 
> 
> On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote:
> um no the 7 channels go into a analog mux and you can only have one selected 
> input at a time.
> 
> On 6/20/2016 3:35 PM, snelso...@gmail.com  wrote:
>> Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.
>> 
>> But can you please confirm that by "200ksps for 7 channel simultaneously" 
>> you mean that each of the 7 channels is being sampled 200k times per second. 
>>  If so, that's 1.4M captures per second, enough for my project.
>> 
>> > But CPU usage is so high, that you're not going to be able to do a whole 
>> > lot more in addition to reading the ADC in this fashion.
>> 
>> This is essentially a lab experiment.  The program only needs to run 
>> correctly once (though it will take many executions to get all the external 
>> factors right).  On each run, the BBB has no other tasks to perform.  It 
>> won't start writing the results to a file until after the capture is 
>> complete.  If CPU usage during the capture is 95%, that's fine.  If it's 
>> 105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's 
>> 250%, then I'm in trouble.
>> 
>> If not missing samples requires running in single-user mode with no 
>> networking and only a serial console, that's IMO a minor nuisance compared 
>> to learning about PRU, etc. and debugging a much more complex program.
>> 
>> On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote:
>> The ADC module is a 200ksps SAR module . . .You're only going to be able to 
>> sample 200k samples per second . . . 
>> 
>> Additionally you can use:
>> 
>> PRUs ( Programmable Real-time Units )
>> IIO ( industrial IO )
>> /dev/mem/ + mmap()
>> 
>> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work for 
>> reading 200ksps for 7 channel simultaneously. But CPU usage is so high, that 
>> you're not going ot be able to do a whole lot more in addition to reading 
>> the ADC in this fashion. Hence, the PRU are best used, as this offers 
>> hardware offload( very little CPU load needed - and only when reading values 
>> out  ).
>> 
>> On Mon, Jun 20, 2016 at 12:00 PM, Stewart > wrote:
>> I'm looking to write a simple app for BBB.  When started from the command 
>> line, it would set up the ADC in continuous mode and read ~1 M samples from 
>> e.g. AN0 into memory.  After the capture is complete, it would write the 
>> data to a file and exit.
>> 
>> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 MHz 
>> adc_clk per sample).  If that's not practical, 800 KSPS or better would be 
>> acceptable.
>> 
>> What is an easy way to do this?  Most Beaglebone ADC examples sample at 
>> kilohertz rates or slower.
>> 
>> This guide: 
>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide 
>>  
>> speaks of 200 KSPS.  What is the limitation here?
>> 
>> I've seen various suggestions to use the PRU, but don't understand why.  I 
>> would think that since DMA would be required anyway, there should be no 
>> requirement to otherwise access the hardware with tight timing.  If PRU is 
>> indeed necessary, is there a suitable example or tutorial?  (None of the 
>> libpruio built-in examples deal with rapid sampling or large amounts of 
>> data.)
>> 
>> Any other ideas for a simple way to capture data fast will be gratefully 
>> appreciated.
>> 
>> Thanks.
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "B

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[snelson . stuff]

> You're not understanding correctly . . . the ADC module is rated for 
200ksps only. Not 1M, not 2M, 200ksps.

So your "7 channel simultaneously" comment had nothing to do with the total 
sample rate, but merely indicates that this 200 KSPS rate was achieved even 
though some additional overhead (e.g. distributing the captured data into 7 
different buffers) was present.  Is that correct?

But in that case, I'm confused by john3909's link, wherein a TI spokesman 
stated that the 200 kSPS value is for 3 MHz ADC clock, though the maximum 
ADC clk frequency is 24 MHz.  A further clarification was that the 24 MHz 
ADC clk could only be achieved when the master oscillator is 24 MHz, but I 
confirmed at 
https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SCH.pdf?raw=true 
that Y2 is indeed 24 MHz on production boards.

On Monday, June 20, 2016 at 4:45:04 PM UTC-7, William Hermans wrote:
>
> However, Mr. Hermans, who clearly knows what he is talking about, stated 
>> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
>> channel simultaneously."
>> It's reasonable to assume that he would not have included the "7 channel 
>> simultaneously" part unless it was somehow relevant to the performance he 
>> observed.
>>
>
> You're not understanding correctly . . . the ADC module is rated for 
> 200ksps only. Not 1M, not 2M, 200ksps.
>
> On Mon, Jun 20, 2016 at 4:40 PM, > 
> wrote:
>
>> I'm well aware of the analog mux and fully understand that if N channels 
>> are being sampled, the maximum sample rate for each channel is reduced by a 
>> factor of N.
>>
>> However, Mr. Hermans, who clearly knows what he is talking about, stated 
>> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
>> channel simultaneously."
>> It's reasonable to assume that he would not have included the "7 channel 
>> simultaneously" part unless it was somehow relevant to the performance he 
>> observed.
>>
>> And, if the ADC is actually capable of doing conversions at a 1.6 MHz 
>> rate, then it could sample all 8 channels at 200KSPS each, and maybe that's 
>> what Mr. Hermans was observing.
>>
>>
>> On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote:
>>>
>>> um no the 7 channels go into a analog mux and you can only have one 
>>> selected input at a time.
>>>
>>> On 6/20/2016 3:35 PM, snelso...@gmail.com wrote:
>>>
>>> Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.
>>>
>>> But can you please confirm that by "200ksps for 7 channel 
>>> simultaneously" you mean that each of the 7 channels is being sampled 200k 
>>> times per second.  If so, that's 1.4M captures per second, enough for my 
>>> project.
>>>
>>> > But CPU usage is so high, that you're not going to be able to do a 
>>> whole lot more in addition to reading the ADC in this fashion.
>>>
>>> This is essentially a lab experiment.  The program only needs to run 
>>> correctly once (though it will take many executions to get all the external 
>>> factors right).  On each run, the BBB has no other tasks to perform.  It 
>>> won't start writing the results to a file until after the capture is 
>>> complete.  If CPU usage during the capture is 95%, that's fine.  If it's 
>>> 105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's 
>>> 250%, then I'm in trouble.
>>>
>>> If not missing samples requires running in single-user mode with no 
>>> networking and only a serial console, that's IMO a minor nuisance compared 
>>> to learning about PRU, etc. and debugging a much more complex program.
>>>
>>> On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote: 

 The ADC module is a 200ksps SAR module . . .You're only going to be 
 able to sample 200k samples per second . . . 

 Additionally you can use:


1. PRUs ( Programmable Real-time Units ) 
2. IIO ( industrial IO ) 
3. /dev/mem/ + mmap() 


 To read 200ksps. Personally, I've proven that /dev/mem + mmap() can 
 work for reading 200ksps for 7 channel simultaneously. But CPU usage is so 
 high, that you're not going ot be able to do a whole lot more in addition 
 to reading the ADC in this fashion. Hence, the PRU are best used, as this 
 offers hardware offload( very little CPU load needed - and only when 
 reading values out  ).

 On Mon, Jun 20, 2016 at 12:00 PM, Stewart  wrote:

> I'm looking to write a simple app for BBB.  When started from the 
> command line, it would set up the ADC in continuous mode and read ~1 M 
> samples from e.g. AN0 into memory.  After the capture is complete, it 
> would 
> write the data to a file and exit.
>
> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 
> 24 MHz adc_clk per sample).  If that's not practical, 800 KSPS or better 
> would be acceptable.
>
> What is an easy way to do this?  Most Beaglebone ADC examples sample 
> at kil

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[William Hermans]

Stop second guessing what I mean by what I type, and just read that dammed
datasheet. I even pasted a quote of the relevant information, and it's
quite clear.

On Mon, Jun 20, 2016 at 5:06 PM,  wrote:

> > You're not understanding correctly . . . the ADC module is rated for
> 200ksps only. Not 1M, not 2M, 200ksps.
>
> So your "7 channel simultaneously" comment had nothing to do with the
> total sample rate, but merely indicates that this 200 KSPS rate was
> achieved even though some additional overhead (e.g. distributing the
> captured data into 7 different buffers) was present.  Is that correct?
>
> But in that case, I'm confused by john3909's link, wherein a TI spokesman
> stated that the 200 kSPS value is for 3 MHz ADC clock, though the maximum
> ADC clk frequency is 24 MHz.  A further clarification was that the 24 MHz
> ADC clk could only be achieved when the master oscillator is 24 MHz, but I
> confirmed at
> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SCH.pdf?raw=true
> that Y2 is indeed 24 MHz on production boards.
>
> On Monday, June 20, 2016 at 4:45:04 PM UTC-7, William Hermans wrote:
>>
>> However, Mr. Hermans, who clearly knows what he is talking about, stated
>>> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7
>>> channel simultaneously."
>>> It's reasonable to assume that he would not have included the "7 channel
>>> simultaneously" part unless it was somehow relevant to the performance he
>>> observed.
>>>
>>
>> You're not understanding correctly . . . the ADC module is rated for
>> 200ksps only. Not 1M, not 2M, 200ksps.
>>
>> On Mon, Jun 20, 2016 at 4:40 PM,  wrote:
>>
>>> I'm well aware of the analog mux and fully understand that if N channels
>>> are being sampled, the maximum sample rate for each channel is reduced by a
>>> factor of N.
>>>
>>> However, Mr. Hermans, who clearly knows what he is talking about, stated
>>> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7
>>> channel simultaneously."
>>> It's reasonable to assume that he would not have included the "7 channel
>>> simultaneously" part unless it was somehow relevant to the performance he
>>> observed.
>>>
>>> And, if the ADC is actually capable of doing conversions at a 1.6 MHz
>>> rate, then it could sample all 8 channels at 200KSPS each, and maybe that's
>>> what Mr. Hermans was observing.
>>>
>>>
>>> On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote:

 um no the 7 channels go into a analog mux and you can only have one
 selected input at a time.

 On 6/20/2016 3:35 PM, snelso...@gmail.com wrote:

 Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.

 But can you please confirm that by "200ksps for 7 channel
 simultaneously" you mean that each of the 7 channels is being sampled 200k
 times per second.  If so, that's 1.4M captures per second, enough for my
 project.

 > But CPU usage is so high, that you're not going to be able to do a
 whole lot more in addition to reading the ADC in this fashion.

 This is essentially a lab experiment.  The program only needs to run
 correctly once (though it will take many executions to get all the external
 factors right).  On each run, the BBB has no other tasks to perform.  It
 won't start writing the results to a file until after the capture is
 complete.  If CPU usage during the capture is 95%, that's fine.  If it's
 105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's
 250%, then I'm in trouble.

 If not missing samples requires running in single-user mode with no
 networking and only a serial console, that's IMO a minor nuisance compared
 to learning about PRU, etc. and debugging a much more complex program.

 On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote:
>
> The ADC module is a 200ksps SAR module . . .You're only going to be
> able to sample 200k samples per second . . .
>
> Additionally you can use:
>
>
>1. PRUs ( Programmable Real-time Units )
>2. IIO ( industrial IO )
>3. /dev/mem/ + mmap()
>
>
> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can
> work for reading 200ksps for 7 channel simultaneously. But CPU usage is so
> high, that you're not going ot be able to do a whole lot more in addition
> to reading the ADC in this fashion. Hence, the PRU are best used, as this
> offers hardware offload( very little CPU load needed - and only when
> reading values out  ).
>
> On Mon, Jun 20, 2016 at 12:00 PM, Stewart  wrote:
>
>> I'm looking to write a simple app for BBB.  When started from the
>> command line, it would set up the ADC in continuous mode and read ~1 M
>> samples from e.g. AN0 into memory.  After the capture is complete, it 
>> would
>> write the data to a file and exit.
>>
>> Ideal

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

Currently the ADC driver is configured for 16x oversample, Open Delay = 152 
cycles and Sample Delay = 1 cycles.


 time in us for processing a single channel, calculated as follows:

 num cycles = open delay + (sample delay + conv time) * averaging

 num cycles: 152 + (1 + 13) * 16 = 376

 clock frequency: 24MHz / 8 = 3MHz
 clock period: 1 / 3MHz = 333ns

 processing time: 376 * 333ns = 125us



Regards,
John




> On Jun 20, 2016, at 5:06 PM, snelson.st...@gmail.com wrote:
> 
> > You're not understanding correctly . . . the ADC module is rated for 
> > 200ksps only. Not 1M, not 2M, 200ksps.
> 
> So your "7 channel simultaneously" comment had nothing to do with the total 
> sample rate, but merely indicates that this 200 KSPS rate was achieved even 
> though some additional overhead (e.g. distributing the captured data into 7 
> different buffers) was present.  Is that correct?
> 
> But in that case, I'm confused by john3909's link, wherein a TI spokesman 
> stated that the 200 kSPS value is for 3 MHz ADC clock, though the maximum ADC 
> clk frequency is 24 MHz.  A further clarification was that the 24 MHz ADC clk 
> could only be achieved when the master oscillator is 24 MHz, but I confirmed 
> at 
> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SCH.pdf?raw=true
>  that Y2 is indeed 24 MHz on production boards.
> 
> On Monday, June 20, 2016 at 4:45:04 PM UTC-7, William Hermans wrote:
> However, Mr. Hermans, who clearly knows what he is talking about, stated 
> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
> channel simultaneously."
> It's reasonable to assume that he would not have included the "7 channel 
> simultaneously" part unless it was somehow relevant to the performance he 
> observed.
> 
> You're not understanding correctly . . . the ADC module is rated for 200ksps 
> only. Not 1M, not 2M, 200ksps.
> 
> On Mon, Jun 20, 2016 at 4:40 PM, > wrote:
> I'm well aware of the analog mux and fully understand that if N channels are 
> being sampled, the maximum sample rate for each channel is reduced by a 
> factor of N.
> 
> However, Mr. Hermans, who clearly knows what he is talking about, stated 
> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
> channel simultaneously."
> It's reasonable to assume that he would not have included the "7 channel 
> simultaneously" part unless it was somehow relevant to the performance he 
> observed.
> 
> And, if the ADC is actually capable of doing conversions at a 1.6 MHz rate, 
> then it could sample all 8 channels at 200KSPS each, and maybe that's what 
> Mr. Hermans was observing.
> 
> 
> On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote:
> um no the 7 channels go into a analog mux and you can only have one selected 
> input at a time.
> 
> On 6/20/2016 3:35 PM, snelso...@gmail.com <> wrote:
>> Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.
>> 
>> But can you please confirm that by "200ksps for 7 channel simultaneously" 
>> you mean that each of the 7 channels is being sampled 200k times per second. 
>>  If so, that's 1.4M captures per second, enough for my project.
>> 
>> > But CPU usage is so high, that you're not going to be able to do a whole 
>> > lot more in addition to reading the ADC in this fashion.
>> 
>> This is essentially a lab experiment.  The program only needs to run 
>> correctly once (though it will take many executions to get all the external 
>> factors right).  On each run, the BBB has no other tasks to perform.  It 
>> won't start writing the results to a file until after the capture is 
>> complete.  If CPU usage during the capture is 95%, that's fine.  If it's 
>> 105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's 
>> 250%, then I'm in trouble.
>> 
>> If not missing samples requires running in single-user mode with no 
>> networking and only a serial console, that's IMO a minor nuisance compared 
>> to learning about PRU, etc. and debugging a much more complex program.
>> 
>> On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote:
>> The ADC module is a 200ksps SAR module . . .You're only going to be able to 
>> sample 200k samples per second . . . 
>> 
>> Additionally you can use:
>> 
>> PRUs ( Programmable Real-time Units )
>> IIO ( industrial IO )
>> /dev/mem/ + mmap()
>> 
>> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work for 
>> reading 200ksps for 7 channel simultaneously. But CPU usage is so high, that 
>> you're not going ot be able to do a whole lot more in addition to reading 
>> the ADC in this fashion. Hence, the PRU are best used, as this offers 
>> hardware offload( very little CPU load needed - and only when reading values 
>> out  ).
>> 
>> On Mon, Jun 20, 2016 at 12:00 PM, Stewart > wrote:
>> I'm looking to write a simple app for BBB.  When started from the command 
>> line, it would set up the ADC in continuous mode and read ~1 M samples from 
>> e.g. AN0 into m

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[snelson . stuff]

Thanks for the link.  Given the recent update to the data sheet, it seems 
pretty likely that the 200 kSPS total sample rate limit is correct, even 
though that conflicts with both the (older) TRM and the comments in 2014 by 
Biser 
Gatchev-XID .  So, it appears to be a 
waste of time to attempt 800 kSPS+.


Sorry to have bothered you all,
Stewart

On Monday, June 20, 2016 at 4:55:03 PM UTC-7, William Hermans wrote:
>
> http://www.ti.com/lit/ds/sprs717j/sprs717j.pdf
>
> Page 3:
>
> – 12-Bit Successive Approximation Register
> (SAR) ADC
> • 200K Samples per Second
> • Input can be Selected from any of the Eight Analog *Inputs Multiplexed* 
> *Through 
> an 8:1 Analog Switch*
> • Can be Configured to Operate as a 4-Wire, 5-Wire, or 8-Wire Resistive 
> Touch Screen Controller (TSC) Interface
>
> On Mon, Jun 20, 2016 at 4:44 PM, William Hermans  > wrote:
>
>> However, Mr. Hermans, who clearly knows what he is talking about, stated 
>>> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
>>> channel simultaneously."
>>> It's reasonable to assume that he would not have included the "7 channel 
>>> simultaneously" part unless it was somehow relevant to the performance he 
>>> observed.
>>>
>>
>> You're not understanding correctly . . . the ADC module is rated for 
>> 200ksps only. Not 1M, not 2M, 200ksps.
>>
>> On Mon, Jun 20, 2016 at 4:40 PM, > 
>> wrote:
>>
>>> I'm well aware of the analog mux and fully understand that if N channels 
>>> are being sampled, the maximum sample rate for each channel is reduced by a 
>>> factor of N.
>>>
>>> However, Mr. Hermans, who clearly knows what he is talking about, stated 
>>> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
>>> channel simultaneously."
>>> It's reasonable to assume that he would not have included the "7 channel 
>>> simultaneously" part unless it was somehow relevant to the performance he 
>>> observed.
>>>
>>> And, if the ADC is actually capable of doing conversions at a 1.6 MHz 
>>> rate, then it could sample all 8 channels at 200KSPS each, and maybe that's 
>>> what Mr. Hermans was observing.
>>>
>>>
>>> On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote:

 um no the 7 channels go into a analog mux and you can only have one 
 selected input at a time.

 On 6/20/2016 3:35 PM, snelso...@gmail.com wrote:

 Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.

 But can you please confirm that by "200ksps for 7 channel 
 simultaneously" you mean that each of the 7 channels is being sampled 200k 
 times per second.  If so, that's 1.4M captures per second, enough for my 
 project.

 > But CPU usage is so high, that you're not going to be able to do a 
 whole lot more in addition to reading the ADC in this fashion.

 This is essentially a lab experiment.  The program only needs to run 
 correctly once (though it will take many executions to get all the 
 external 
 factors right).  On each run, the BBB has no other tasks to perform.  It 
 won't start writing the results to a file until after the capture is 
 complete.  If CPU usage during the capture is 95%, that's fine.  If it's 
 105%, I'll slow the sample rate a bit to avoid losing samples.  But if 
 it's 
 250%, then I'm in trouble.

 If not missing samples requires running in single-user mode with no 
 networking and only a serial console, that's IMO a minor nuisance compared 
 to learning about PRU, etc. and debugging a much more complex program.

 On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote: 
>
> The ADC module is a 200ksps SAR module . . .You're only going to be 
> able to sample 200k samples per second . . . 
>
> Additionally you can use:
>
>
>1. PRUs ( Programmable Real-time Units ) 
>2. IIO ( industrial IO ) 
>3. /dev/mem/ + mmap() 
>
>
> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can 
> work for reading 200ksps for 7 channel simultaneously. But CPU usage is 
> so 
> high, that you're not going ot be able to do a whole lot more in addition 
> to reading the ADC in this fashion. Hence, the PRU are best used, as this 
> offers hardware offload( very little CPU load needed - and only when 
> reading values out  ).
>
> On Mon, Jun 20, 2016 at 12:00 PM, Stewart  wrote:
>
>> I'm looking to write a simple app for BBB.  When started from the 
>> command line, it would set up the ADC in continuous mode and read ~1 M 
>> samples from e.g. AN0 into memory.  After the capture is complete, it 
>> would 
>> write the data to a file and exit.
>>
>> Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 
>> 24 MHz adc_clk per sample).  If that's not practical, 800 KSPS or better 
>> would be accep

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

Well, I think that is still to be determined if the ADC can sample higher than 
200ksps and that is why I’m adding DMA to this driver. But in any case, why not 
use a higher speed ADC connected via SPI or McASP? You can purchase boards that 
sample at a higher rate and connect those to the BBB. 

Regards,
John




> On Jun 20, 2016, at 5:27 PM, snelson.st...@gmail.com wrote:
> 
> Thanks for the link.  Given the recent update to the data sheet, it seems 
> pretty likely that the 200 kSPS total sample rate limit is correct, even 
> though that conflicts with both the (older) TRM and the comments in 2014 by 
> Biser Gatchev-XID  .  So, it appears to be 
> a waste of time to attempt 800 kSPS+.
> 
> 
> Sorry to have bothered you all,
> Stewart
> 
> On Monday, June 20, 2016 at 4:55:03 PM UTC-7, William Hermans wrote:
> http://www.ti.com/lit/ds/sprs717j/sprs717j.pdf 
> 
> 
> Page 3:
> 
> – 12-Bit Successive Approximation Register
> (SAR) ADC
> • 200K Samples per Second
> • Input can be Selected from any of the Eight Analog Inputs Multiplexed 
> Through an 8:1 Analog Switch
> • Can be Configured to Operate as a 4-Wire, 5-Wire, or 8-Wire Resistive Touch 
> Screen Controller (TSC) Interface
> 
> On Mon, Jun 20, 2016 at 4:44 PM, William Hermans  > wrote:
> However, Mr. Hermans, who clearly knows what he is talking about, stated 
> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
> channel simultaneously."
> It's reasonable to assume that he would not have included the "7 channel 
> simultaneously" part unless it was somehow relevant to the performance he 
> observed.
> 
> You're not understanding correctly . . . the ADC module is rated for 200ksps 
> only. Not 1M, not 2M, 200ksps.
> 
> On Mon, Jun 20, 2016 at 4:40 PM, > wrote:
> I'm well aware of the analog mux and fully understand that if N channels are 
> being sampled, the maximum sample rate for each channel is reduced by a 
> factor of N.
> 
> However, Mr. Hermans, who clearly knows what he is talking about, stated 
> "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 
> channel simultaneously."
> It's reasonable to assume that he would not have included the "7 channel 
> simultaneously" part unless it was somehow relevant to the performance he 
> observed.
> 
> And, if the ADC is actually capable of doing conversions at a 1.6 MHz rate, 
> then it could sample all 8 channels at 200KSPS each, and maybe that's what 
> Mr. Hermans was observing.
> 
> 
> On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote:
> um no the 7 channels go into a analog mux and you can only have one selected 
> input at a time.
> 
> On 6/20/2016 3:35 PM, snelso...@gmail.com <> wrote:
>> Wow, I think that /dev/mem + mmap() is the easy solution!  Many thanks.
>> 
>> But can you please confirm that by "200ksps for 7 channel simultaneously" 
>> you mean that each of the 7 channels is being sampled 200k times per second. 
>>  If so, that's 1.4M captures per second, enough for my project.
>> 
>> > But CPU usage is so high, that you're not going to be able to do a whole 
>> > lot more in addition to reading the ADC in this fashion.
>> 
>> This is essentially a lab experiment.  The program only needs to run 
>> correctly once (though it will take many executions to get all the external 
>> factors right).  On each run, the BBB has no other tasks to perform.  It 
>> won't start writing the results to a file until after the capture is 
>> complete.  If CPU usage during the capture is 95%, that's fine.  If it's 
>> 105%, I'll slow the sample rate a bit to avoid losing samples.  But if it's 
>> 250%, then I'm in trouble.
>> 
>> If not missing samples requires running in single-user mode with no 
>> networking and only a serial console, that's IMO a minor nuisance compared 
>> to learning about PRU, etc. and debugging a much more complex program.
>> 
>> On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote:
>> The ADC module is a 200ksps SAR module . . .You're only going to be able to 
>> sample 200k samples per second . . . 
>> 
>> Additionally you can use:
>> 
>> PRUs ( Programmable Real-time Units )
>> IIO ( industrial IO )
>> /dev/mem/ + mmap()
>> 
>> To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work for 
>> reading 200ksps for 7 channel simultaneously. But CPU usage is so high, that 
>> you're not going ot be able to do a whole lot more in addition to reading 
>> the ADC in this fashion. Hence, the PRU are best used, as this offers 
>> hardware offload( very little CPU load needed - and only when reading values 
>> out  ).
>> 
>> On Mon, Jun 20, 2016 at 12:00 PM, Stewart > wrote:
>> I'm looking to write a simple app for BBB.  When started from the command 
>> line, it would set up the ADC in continuous mode and read ~1 M samples from 
>> e.g. AN0 into memory.  After the capture is complete, it would write the 
>> data to a file a

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[William Hermans]

So going back to what I said earlier. When using /dev/mem + mmap() yes, I
was (actually ) reading more than
 200ksps from 7 channels simultaneously. For a total of somewhere around
1.5Msps

BUT

Only 1 sample in ~8-9 per second was valid. So what I proved is possible is
completely different from what is accurate / possible for the AM335x's on
die ADC module.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrDDvqZhv2nMOM15ymqiLEWH1DyXBC%3D2ygrZM%3DPfmA7gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

That is a totally different issue. You were reading the same sample over and 
over again as opposed to increasing the sample rate by changing the clock 
divider, open delay, sample delay, etc. In any case, at 200ksps, each sample 
occurs every 5uS. How is a user space app going to process samples at 5uS? Even 
when you poll for the EOC with 8 channels configured, you still have to service 
the samples every 40uS and that is still not possible from a userspace app. 

My guess is the app you had was reading the same sample at a higher rate than 
1.5msps and then the scheduler switched out your app to service background 
tasks and then return a while later and then your app would read the same 
sample again. The average sample rate would then result in 1.5msps. Not a good 
idea. You should enable the channel ID to see when you miss samples. 

Regards,
John




> On Jun 20, 2016, at 5:49 PM, William Hermans  wrote:
> 
> So going back to what I said earlier. When using /dev/mem + mmap() yes, I was 
> (actually ) reading more than
>  200ksps from 7 channels simultaneously. For a total of somewhere around 
> 1.5Msps 
> 
> ***BUT***
> 
> Only 1 sample in ~8-9 per second was valid. So what I proved is possible is 
> completely different from what is accurate / possible for the AM335x's on die 
> ADC module.
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CALHSORrDDvqZhv2nMOM15ymqiLEWH1DyXBC%3D2ygrZM%3DPfmA7gw%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9E0C21BE-E530-475E-A7B8-5753C0F9B63A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[ybeagle3]

The ADC is a SAR ADC. Overclocking it is likely to have side effects on the 
analog end of things which will reduce accuracy.

Ignoring that it is a very bad idea to keep doing things in userland:

On Monday, June 20, 2016 18:06:09 John Syne wrote:
> That is a totally different issue. You were reading the same sample over and
> over again as opposed to increasing the sample rate by changing the clock
> divider, open delay, sample delay, etc. In any case, at 200ksps, each
> sample occurs every 5uS. How is a user space app going to process samples
> at 5uS? Even when you poll for the EOC with 8 channels configured, you
> still have to service the samples every 40uS and that is still not possible
> from a userspace app.

You could use the FIFOs to reduce the read timing accuracy but you still risk 
getting scheduled away for (comparatively) long period of time. This probally 
means you will also need to check the status for FIFO overflows and

> 
> My guess is the app you had was reading the same sample at a higher rate
> than 1.5msps and then the scheduler switched out your app to service
> background tasks and then return a while later and then your app would read
> the same sample again. The average sample rate would then result in
> 1.5msps. Not a good idea. You should enable the channel ID to see when you
> miss samples.

It is not just missing sames but what is the overall accuracy of the data when 
the ADC module is overclocked? Does it appear anywhere near the 12bits of 
accuracy?
> 
> Regards,
> John
> 
> > On Jun 20, 2016, at 5:49 PM, William Hermans  wrote:
> > 
> > So going back to what I said earlier. When using /dev/mem + mmap() yes, I
> > was (actually ) reading more than> 
> >  200ksps from 7 channels simultaneously. For a total of somewhere around
> >  1.5Msps> 
> > ***BUT***
> > 
> > Only 1 sample in ~8-9 per second was valid. So what I proved is possible
> > is completely different from what is accurate / possible for the AM335x's
> > on die ADC module.

-- 
Hunyue Yau
http://www.hy-research.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1620.iAXeZpr9Qk%40acer0.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[William Hermans]

When you're writing directly to memory addresses ( registers ), you can't
tell me what is, and what isn't. *This* is exactly what the PRU does when
accessing peripherals modules. But, you'd be surprised what you can
accomplish from userland when  you pay close attention to what you should
*not* do in order to remain performant.

Anyway, reading from a memory location, and putting that value into another
location does not really take a lot of computational power, and then if
you're using an rt kernel. The scheduler is going to run in a tighter loop,
offering lower latency. But again, you have to be smart how you go about
things. Printing every, or even *any* samples to stdout will slow thigns
down considerably. Also, if you use a lot of API calls that have to go back
and forth to / from the kernel . . . that's going ot slow things down
considerably also. etc . . .

On Mon, Jun 20, 2016 at 6:14 PM,  wrote:

> The ADC is a SAR ADC. Overclocking it is likely to have side effects on the
> analog end of things which will reduce accuracy.
>
> Ignoring that it is a very bad idea to keep doing things in userland:
>
> On Monday, June 20, 2016 18:06:09 John Syne wrote:
> > That is a totally different issue. You were reading the same sample over
> and
> > over again as opposed to increasing the sample rate by changing the clock
> > divider, open delay, sample delay, etc. In any case, at 200ksps, each
> > sample occurs every 5uS. How is a user space app going to process samples
> > at 5uS? Even when you poll for the EOC with 8 channels configured, you
> > still have to service the samples every 40uS and that is still not
> possible
> > from a userspace app.
>
> You could use the FIFOs to reduce the read timing accuracy but you still
> risk
> getting scheduled away for (comparatively) long period of time. This
> probally
> means you will also need to check the status for FIFO overflows and
>
> >
> > My guess is the app you had was reading the same sample at a higher rate
> > than 1.5msps and then the scheduler switched out your app to service
> > background tasks and then return a while later and then your app would
> read
> > the same sample again. The average sample rate would then result in
> > 1.5msps. Not a good idea. You should enable the channel ID to see when
> you
> > miss samples.
>
> It is not just missing sames but what is the overall accuracy of the data
> when
> the ADC module is overclocked? Does it appear anywhere near the 12bits of
> accuracy?
> >
> > Regards,
> > John
> >
> > > On Jun 20, 2016, at 5:49 PM, William Hermans 
> wrote:
> > >
> > > So going back to what I said earlier. When using /dev/mem + mmap()
> yes, I
> > > was (actually ) reading more than>
> > >  200ksps from 7 channels simultaneously. For a total of somewhere
> around
> > >  1.5Msps>
> > > ***BUT***
> > >
> > > Only 1 sample in ~8-9 per second was valid. So what I proved is
> possible
> > > is completely different from what is accurate / possible for the
> AM335x's
> > > on die ADC module.
>
> --
> Hunyue Yau
> http://www.hy-research.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/1620.iAXeZpr9Qk%40acer0.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

You make a very good point and we have no idea what the ADC front end bandwidth 
is. You would think that TI would add some provisions in the ADC setup that can 
be whatever you want as long as you do not exceed 200ksps. The 200ksps I 
believe comes from a setting where clock divider = 8, open delay =1, sample 
delay = 0 and oversample = 1x. The fact that they allow a 24MHz clock, and no 
warning is interesting. This was also discussed on E2E and no one from TI shut 
the idea down. 

Anyway, if I can get the DMA to work, then we can test the concept ;-) If 
nothing else, at least we get a proper 200ksps ADC working on the ARM directly. 
No need for PRU. 

Regards,
John




> On Jun 20, 2016, at 6:14 PM, ybeag...@rehut.com wrote:
> 
> The ADC is a SAR ADC. Overclocking it is likely to have side effects on the 
> analog end of things which will reduce accuracy.
> 
> Ignoring that it is a very bad idea to keep doing things in userland:
> 
> On Monday, June 20, 2016 18:06:09 John Syne wrote:
>> That is a totally different issue. You were reading the same sample over and
>> over again as opposed to increasing the sample rate by changing the clock
>> divider, open delay, sample delay, etc. In any case, at 200ksps, each
>> sample occurs every 5uS. How is a user space app going to process samples
>> at 5uS? Even when you poll for the EOC with 8 channels configured, you
>> still have to service the samples every 40uS and that is still not possible
>> from a userspace app.
> 
> You could use the FIFOs to reduce the read timing accuracy but you still risk 
> getting scheduled away for (comparatively) long period of time. This probally 
> means you will also need to check the status for FIFO overflows and
> 
>> 
>> My guess is the app you had was reading the same sample at a higher rate
>> than 1.5msps and then the scheduler switched out your app to service
>> background tasks and then return a while later and then your app would read
>> the same sample again. The average sample rate would then result in
>> 1.5msps. Not a good idea. You should enable the channel ID to see when you
>> miss samples.
> 
> It is not just missing sames but what is the overall accuracy of the data 
> when 
> the ADC module is overclocked? Does it appear anywhere near the 12bits of 
> accuracy?
>> 
>> Regards,
>> John
>> 
>>> On Jun 20, 2016, at 5:49 PM, William Hermans  wrote:
>>> 
>>> So going back to what I said earlier. When using /dev/mem + mmap() yes, I
>>> was (actually ) reading more than> 
>>> 200ksps from 7 channels simultaneously. For a total of somewhere around
>>> 1.5Msps> 
>>> ***BUT***
>>> 
>>> Only 1 sample in ~8-9 per second was valid. So what I proved is possible
>>> is completely different from what is accurate / possible for the AM335x's
>>> on die ADC module.
> 
> -- 
> Hunyue Yau
> http://www.hy-research.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/1620.iAXeZpr9Qk%40acer0.
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/464B65A0-BD04-4154-AB4A-81AC3D8760CF%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

The latency in the RT kernel is only relevant for interrupts (preemption). The 
scheduler will still swap out user space apps to service background tasks and 
that is the same as the regular kernel. In any case, the ADC uses a sequencer 
to do the samples and those samples get stored in the fifo, so you have to wait 
until the fifo count is greater than a certain number and then read until the 
fifo is empty and poll again for samples. From what I recall, you were just 
reading the samples from the IIO driver. I don’t believe you had code to setup 
the sequencer, or maybe I’m wrong?

Regards,
John




> On Jun 20, 2016, at 6:32 PM, William Hermans  wrote:
> 
> When you're writing directly to memory addresses ( registers ), you can't 
> tell me what is, and what isn't. *This* is exactly what the PRU does when 
> accessing peripherals modules. But, you'd be surprised what you can 
> accomplish from userland when  you pay close attention to what you should 
> *not* do in order to remain performant.
> 
> Anyway, reading from a memory location, and putting that value into another 
> location does not really take a lot of computational power, and then if 
> you're using an rt kernel. The scheduler is going to run in a tighter loop, 
> offering lower latency. But again, you have to be smart how you go about 
> things. Printing every, or even *any* samples to stdout will slow thigns down 
> considerably. Also, if you use a lot of API calls that have to go back and 
> forth to / from the kernel . . . that's going ot slow things down 
> considerably also. etc . . .
> 
> On Mon, Jun 20, 2016 at 6:14 PM,  > wrote:
> The ADC is a SAR ADC. Overclocking it is likely to have side effects on the
> analog end of things which will reduce accuracy.
> 
> Ignoring that it is a very bad idea to keep doing things in userland:
> 
> On Monday, June 20, 2016 18:06:09 John Syne wrote:
> > That is a totally different issue. You were reading the same sample over and
> > over again as opposed to increasing the sample rate by changing the clock
> > divider, open delay, sample delay, etc. In any case, at 200ksps, each
> > sample occurs every 5uS. How is a user space app going to process samples
> > at 5uS? Even when you poll for the EOC with 8 channels configured, you
> > still have to service the samples every 40uS and that is still not possible
> > from a userspace app.
> 
> You could use the FIFOs to reduce the read timing accuracy but you still risk
> getting scheduled away for (comparatively) long period of time. This probally
> means you will also need to check the status for FIFO overflows and
> 
> >
> > My guess is the app you had was reading the same sample at a higher rate
> > than 1.5msps and then the scheduler switched out your app to service
> > background tasks and then return a while later and then your app would read
> > the same sample again. The average sample rate would then result in
> > 1.5msps. Not a good idea. You should enable the channel ID to see when you
> > miss samples.
> 
> It is not just missing sames but what is the overall accuracy of the data when
> the ADC module is overclocked? Does it appear anywhere near the 12bits of
> accuracy?
> >
> > Regards,
> > John
> >
> > > On Jun 20, 2016, at 5:49 PM, William Hermans  > > > wrote:
> > >
> > > So going back to what I said earlier. When using /dev/mem + mmap() yes, I
> > > was (actually ) reading more than>
> > >  200ksps from 7 channels simultaneously. For a total of somewhere around
> > >  1.5Msps>
> > > ***BUT***
> > >
> > > Only 1 sample in ~8-9 per second was valid. So what I proved is possible
> > > is completely different from what is accurate / possible for the AM335x's
> > > on die ADC module.
> 
> --
> Hunyue Yau
> http://www.hy-research.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/1620.iAXeZpr9Qk%40acer0 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web vis

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[William Hermans]

I never shared my /dev/mem + mmap() code with the group / publicly. For
what should be obvious reasons. I fact I do not think I shared it with
anyone. My reasoning is that if someone can figure out how to do this on
their own, then they probably earned the right, and with that comes
knowledge and responsibility.

As far as interrupts and rt. That does not matter. Interrupts happen all
the time, and the more you have, for whatever reason, the slower your
application will be. Regardless if your app generated that interrupt or not.

So if i understood what someone was talking about concerning remoteproc not
long ago. Moving interrupts to userspace . . . would be a very very bad
idea. You'd get all kind of context switching between processes /
interrupts fighting for time. Then jumping into and out of kernel space,
potentially copying data . . . yeah, very very bad idea.

On Mon, Jun 20, 2016 at 6:43 PM, John Syne  wrote:

> The latency in the RT kernel is only relevant for interrupts (preemption).
> The scheduler will still swap out user space apps to service background
> tasks and that is the same as the regular kernel. In any case, the ADC uses
> a sequencer to do the samples and those samples get stored in the fifo, so
> you have to wait until the fifo count is greater than a certain number and
> then read until the fifo is empty and poll again for samples. From what I
> recall, you were just reading the samples from the IIO driver. I don’t
> believe you had code to setup the sequencer, or maybe I’m wrong?
>
> Regards,
> John
>
>
>
>
> On Jun 20, 2016, at 6:32 PM, William Hermans  wrote:
>
> When you're writing directly to memory addresses ( registers ), you can't
> tell me what is, and what isn't. *This* is exactly what the PRU does when
> accessing peripherals modules. But, you'd be surprised what you can
> accomplish from userland when  you pay close attention to what you should
> *not* do in order to remain performant.
>
> Anyway, reading from a memory location, and putting that value into
> another location does not really take a lot of computational power, and
> then if you're using an rt kernel. The scheduler is going to run in a
> tighter loop, offering lower latency. But again, you have to be smart how
> you go about things. Printing every, or even *any* samples to stdout will
> slow thigns down considerably. Also, if you use a lot of API calls that
> have to go back and forth to / from the kernel . . . that's going ot slow
> things down considerably also. etc . . .
>
> On Mon, Jun 20, 2016 at 6:14 PM,  wrote:
>
>> The ADC is a SAR ADC. Overclocking it is likely to have side effects on
>> the
>> analog end of things which will reduce accuracy.
>>
>> Ignoring that it is a very bad idea to keep doing things in userland:
>>
>> On Monday, June 20, 2016 18:06:09 John Syne wrote:
>> > That is a totally different issue. You were reading the same sample
>> over and
>> > over again as opposed to increasing the sample rate by changing the
>> clock
>> > divider, open delay, sample delay, etc. In any case, at 200ksps, each
>> > sample occurs every 5uS. How is a user space app going to process
>> samples
>> > at 5uS? Even when you poll for the EOC with 8 channels configured, you
>> > still have to service the samples every 40uS and that is still not
>> possible
>> > from a userspace app.
>>
>> You could use the FIFOs to reduce the read timing accuracy but you still
>> risk
>> getting scheduled away for (comparatively) long period of time. This
>> probally
>> means you will also need to check the status for FIFO overflows and
>>
>> >
>> > My guess is the app you had was reading the same sample at a higher rate
>> > than 1.5msps and then the scheduler switched out your app to service
>> > background tasks and then return a while later and then your app would
>> read
>> > the same sample again. The average sample rate would then result in
>> > 1.5msps. Not a good idea. You should enable the channel ID to see when
>> you
>> > miss samples.
>>
>> It is not just missing sames but what is the overall accuracy of the data
>> when
>> the ADC module is overclocked? Does it appear anywhere near the 12bits of
>> accuracy?
>> >
>> > Regards,
>> > John
>> >
>> > > On Jun 20, 2016, at 5:49 PM, William Hermans 
>> wrote:
>> > >
>> > > So going back to what I said earlier. When using /dev/mem + mmap()
>> yes, I
>> > > was (actually ) reading more than>
>> > >  200ksps from 7 channels simultaneously. For a total of somewhere
>> around
>> > >  1.5Msps>
>> > > ***BUT***
>> > >
>> > > Only 1 sample in ~8-9 per second was valid. So what I proved is
>> possible
>> > > is completely different from what is accurate / possible for the
>> AM335x's
>> > > on die ADC module.
>>
>> --
>> Hunyue Yau
>> http://www.hy-research.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 f

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[William Hermans]

I seemed to have lost a post here that I made. *Somehow* . . .

Anyway, I never shared my /dev/mem + mmap() code with anyone, and I will
never post it on this group. So no one here would know what I've done in
code concerning that. My reason is simple. In order to use code of that
nature, you need to earn the right to do so, and hopefully have an
understanding of could happen if you're not careful.

Most of that code is peripheral setup, and the rest is simply reading from
the ADC buffer, and then printf() to screen. However, in order to get the
best performance you never let that data get put on screen by piping the
output of the executable to a file. *That* increases performance
drastically, and is a happy medium for not having to write a bunch of
read() / write() / open() calls for a simple test. Perfect ? Who cares, I
never did. I proved a point to myself, and that is all that matters to me.
I proved to myself that /dev/mem/ + mmap() works fine, and if you have an
application that does not need to spend a lot of CPU time doing things.
Then it would work fine. As it is. Reading from the ADC multiple channels
as fast as you can. Should probably be done using the PRUs. Simply so you
can use that CPU time saved to do other things. Perhaps even display that
data to the outside world from a web server.

Interrupts. They happen, and frequently. So it does not matter if your app
generated interrupts or not. Your app will constantly be interrupted by
them. So if you're using an rt kernel, "return latency" will be less.
Meaning, your app should be able to get things done faster.

Which brings me to another point. I hope I was misunderstanding someone
earlier this week talking about remoteproc and bringing interrupts to
userspace. *That* would be a terrible idea, and would generate all kinds of
context switching between userland, kernel space, processes, interrupts,
copying data to / from kernel space. . .  yeah it would be a bloody mess.
But you know what. That will just give me another reason to avoid what I'm
already avoiding now.  So, for me, no big deal. I guess.

On Mon, Jun 20, 2016 at 6:32 PM, William Hermans  wrote:

> When you're writing directly to memory addresses ( registers ), you can't
> tell me what is, and what isn't. *This* is exactly what the PRU does when
> accessing peripherals modules. But, you'd be surprised what you can
> accomplish from userland when  you pay close attention to what you should
> *not* do in order to remain performant.
>
> Anyway, reading from a memory location, and putting that value into
> another location does not really take a lot of computational power, and
> then if you're using an rt kernel. The scheduler is going to run in a
> tighter loop, offering lower latency. But again, you have to be smart how
> you go about things. Printing every, or even *any* samples to stdout will
> slow thigns down considerably. Also, if you use a lot of API calls that
> have to go back and forth to / from the kernel . . . that's going ot slow
> things down considerably also. etc . . .
>
> On Mon, Jun 20, 2016 at 6:14 PM,  wrote:
>
>> The ADC is a SAR ADC. Overclocking it is likely to have side effects on
>> the
>> analog end of things which will reduce accuracy.
>>
>> Ignoring that it is a very bad idea to keep doing things in userland:
>>
>> On Monday, June 20, 2016 18:06:09 John Syne wrote:
>> > That is a totally different issue. You were reading the same sample
>> over and
>> > over again as opposed to increasing the sample rate by changing the
>> clock
>> > divider, open delay, sample delay, etc. In any case, at 200ksps, each
>> > sample occurs every 5uS. How is a user space app going to process
>> samples
>> > at 5uS? Even when you poll for the EOC with 8 channels configured, you
>> > still have to service the samples every 40uS and that is still not
>> possible
>> > from a userspace app.
>>
>> You could use the FIFOs to reduce the read timing accuracy but you still
>> risk
>> getting scheduled away for (comparatively) long period of time. This
>> probally
>> means you will also need to check the status for FIFO overflows and
>>
>> >
>> > My guess is the app you had was reading the same sample at a higher rate
>> > than 1.5msps and then the scheduler switched out your app to service
>> > background tasks and then return a while later and then your app would
>> read
>> > the same sample again. The average sample rate would then result in
>> > 1.5msps. Not a good idea. You should enable the channel ID to see when
>> you
>> > miss samples.
>>
>> It is not just missing sames but what is the overall accuracy of the data
>> when
>> the ADC module is overclocked? Does it appear anywhere near the 12bits of
>> accuracy?
>> >
>> > Regards,
>> > John
>> >
>> > > On Jun 20, 2016, at 5:49 PM, William Hermans 
>> wrote:
>> > >
>> > > So going back to what I said earlier. When using /dev/mem + mmap()
>> yes, I
>> > > was (actually ) reading more than>
>> > >  200ksps from 7 channels simultane

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[William Hermans]

BY the way, when I say read from the ADC buffer. I do not mean that piece
of garbage /dev/iio:device0. I mean the ADC hardware buffer. FIFO0DATA
described on page 1095 of the TRM.

On Mon, Jun 20, 2016 at 7:27 PM, William Hermans  wrote:

> I seemed to have lost a post here that I made. *Somehow* . . .
>
> Anyway, I never shared my /dev/mem + mmap() code with anyone, and I will
> never post it on this group. So no one here would know what I've done in
> code concerning that. My reason is simple. In order to use code of that
> nature, you need to earn the right to do so, and hopefully have an
> understanding of could happen if you're not careful.
>
> Most of that code is peripheral setup, and the rest is simply reading from
> the ADC buffer, and then printf() to screen. However, in order to get the
> best performance you never let that data get put on screen by piping the
> output of the executable to a file. *That* increases performance
> drastically, and is a happy medium for not having to write a bunch of
> read() / write() / open() calls for a simple test. Perfect ? Who cares, I
> never did. I proved a point to myself, and that is all that matters to me.
> I proved to myself that /dev/mem/ + mmap() works fine, and if you have an
> application that does not need to spend a lot of CPU time doing things.
> Then it would work fine. As it is. Reading from the ADC multiple channels
> as fast as you can. Should probably be done using the PRUs. Simply so you
> can use that CPU time saved to do other things. Perhaps even display that
> data to the outside world from a web server.
>
> Interrupts. They happen, and frequently. So it does not matter if your app
> generated interrupts or not. Your app will constantly be interrupted by
> them. So if you're using an rt kernel, "return latency" will be less.
> Meaning, your app should be able to get things done faster.
>
> Which brings me to another point. I hope I was misunderstanding someone
> earlier this week talking about remoteproc and bringing interrupts to
> userspace. *That* would be a terrible idea, and would generate all kinds of
> context switching between userland, kernel space, processes, interrupts,
> copying data to / from kernel space. . .  yeah it would be a bloody mess.
> But you know what. That will just give me another reason to avoid what I'm
> already avoiding now.  So, for me, no big deal. I guess.
>
> On Mon, Jun 20, 2016 at 6:32 PM, William Hermans 
> wrote:
>
>> When you're writing directly to memory addresses ( registers ), you can't
>> tell me what is, and what isn't. *This* is exactly what the PRU does when
>> accessing peripherals modules. But, you'd be surprised what you can
>> accomplish from userland when  you pay close attention to what you should
>> *not* do in order to remain performant.
>>
>> Anyway, reading from a memory location, and putting that value into
>> another location does not really take a lot of computational power, and
>> then if you're using an rt kernel. The scheduler is going to run in a
>> tighter loop, offering lower latency. But again, you have to be smart how
>> you go about things. Printing every, or even *any* samples to stdout will
>> slow thigns down considerably. Also, if you use a lot of API calls that
>> have to go back and forth to / from the kernel . . . that's going ot slow
>> things down considerably also. etc . . .
>>
>> On Mon, Jun 20, 2016 at 6:14 PM,  wrote:
>>
>>> The ADC is a SAR ADC. Overclocking it is likely to have side effects on
>>> the
>>> analog end of things which will reduce accuracy.
>>>
>>> Ignoring that it is a very bad idea to keep doing things in userland:
>>>
>>> On Monday, June 20, 2016 18:06:09 John Syne wrote:
>>> > That is a totally different issue. You were reading the same sample
>>> over and
>>> > over again as opposed to increasing the sample rate by changing the
>>> clock
>>> > divider, open delay, sample delay, etc. In any case, at 200ksps, each
>>> > sample occurs every 5uS. How is a user space app going to process
>>> samples
>>> > at 5uS? Even when you poll for the EOC with 8 channels configured, you
>>> > still have to service the samples every 40uS and that is still not
>>> possible
>>> > from a userspace app.
>>>
>>> You could use the FIFOs to reduce the read timing accuracy but you still
>>> risk
>>> getting scheduled away for (comparatively) long period of time. This
>>> probally
>>> means you will also need to check the status for FIFO overflows and
>>>
>>> >
>>> > My guess is the app you had was reading the same sample at a higher
>>> rate
>>> > than 1.5msps and then the scheduler switched out your app to service
>>> > background tasks and then return a while later and then your app would
>>> read
>>> > the same sample again. The average sample rate would then result in
>>> > 1.5msps. Not a good idea. You should enable the channel ID to see when
>>> you
>>> > miss samples.
>>>
>>> It is not just missing sames but what is the overall accuracy of the
>>> data

Re: [beagleboard] Re: No free space on SD card partition after writing 2016-06-05

[Robert Nelson]

On Mon, Jun 20, 2016 at 6:05 PM, Wally Bkg  wrote:
> I know that, that is why I said its not a show-stopper, and Windows users can 
> still boot the card and run grow_partition.sh, but the previous testing lxqt 
> images were apparently sized to match the 4GB eMMC.
>
> If there is a reason for it, (new slightly smaller eMMC chip to save a few 
> pennies on some board revisions?) that's fine, but if its an error that crept 
> into the image making process, I thought RCN might want to know.  I did 
> verify that the 0 bytes free didn't interfere with the Beaglebone initial 
> boot up.

It's a little juggling game, the bb-node-red package got a little big
these last few weeks till i got the pre-build npm packages ironed out,
so those are smaller..

Otherwise, from trial and error we only partition 85% of eMMC stated size..

Here's the calculation logic with a few data-points..

#eMMC: (dd if=/dev/mmcblk1 of=/dev/null bs=1M #MB)
#Micron 3744MB (bbb): 3925868544 bytes -> 3925.86 Megabyte
#Kingston 3688MB (bbb): 3867148288 bytes -> 3867.15 Megabyte
#Kingston 3648MB (x15): 3825205248 bytes -> 3825.21 Megabyte (3648)
#
### seek=$((1024 * (700 + (gsize - 1) * 1000)))
## 1000 1GB = 700 #2GB = 1700 #4GB = 3700
## 990 1GB = 700 #2GB = 1690 #4GB = 3670
#
### seek=$((1024 * (gsize * 850)))
## x 850 (85%) #1GB = 850 #2GB = 1700 #4GB = 3400
#
dd if=/dev/zero of="${media}" bs=1024 count=0 seek=$((1024 * (gsize * 850)))

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYj3iZ4WfBG2n1ru5Z4VpnsgLVk84FixUQYaxbtpW7pX4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Power up initialisation failure/PMIC reset

[Karl Karpfen]

I played around a bit with this and it is quite strange:

When I reset the board by pressing the reset-button on BBG, on next boot-up 
the Ethernet PHY is working smoothly.

When I do the same programmatically by invoking a cold reset on SoC (by 
writing a 0x02 into reset register 0x44E00F00, the PHY stays in same 
unusable condition. According to TRM of AM335x such a reset should pull 
output NRESETIN_OUT to LOW which should be the same like pressing the 
reset-button.

Any idea why one is working and the other not although they should be the 
same?



Am Samstag, 18. Juni 2016 16:44:20 UTC+2 schrieb Karl Karpfen:
>
> Hi,
>
> I know there is a problem where the Ethernet (PHY?) in some seldom cases 
> isn't initialised properly on power-up ending up in a state where it can't 
> be used and therefore Ethernet is disabled. Now I have a BBG-cape where 
> this happens much more often than I know this from a plain BBB. Two 
> questions on this:
>
> 1. The BBG is powered externally by feeding 5V into VDD. Could a 
> not-so-steep power-on rising edge of VDD make this problem happen more 
> often?
>
> 2. When I'm in this state and press the reset-button on BBG, the problem 
> is solved when the board is back. Is there a possibility to invoke 
> something similar out of software by accessing the PMIC somehow? If yes - 
> what would have to be done?
>
> Thanks and keep the good work going! :-)
>
> Karl
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2403483b-84e7-4292-999f-e2410411db00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

[John Syne]

Ah, I thought you were talking about this solutions:

http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/ 


Otherwise, you would have to replicate much of the ADC driver in userspace and 
then loop, waiting for FIFO0COUNT>0, read samples from FIFO1DATA until 
FIFOCOUNT-0 and doing this in a way that doesn’t hog the CPU but still be fast 
enough to overflow the FIFO. At 1.5msps, you would have to do this in less than 
21uS assuming a average FIFO Count of 32. I just don’t see ti, but maybe you 
have a trick that I don’t know about ;-)

Did you enable StepID? This way you can see if you missed any samples. 

Regards,
John




> On Jun 20, 2016, at 7:49 PM, William Hermans  wrote:
> 
> BY the way, when I say read from the ADC buffer. I do not mean that piece of 
> garbage /dev/iio:device0. I mean the ADC hardware buffer. FIFO0DATA described 
> on page 1095 of the TRM.
> 
> On Mon, Jun 20, 2016 at 7:27 PM, William Hermans  > wrote:
> I seemed to have lost a post here that I made. *Somehow* . . .
> 
> Anyway, I never shared my /dev/mem + mmap() code with anyone, and I will 
> never post it on this group. So no one here would know what I've done in code 
> concerning that. My reason is simple. In order to use code of that nature, 
> you need to earn the right to do so, and hopefully have an understanding of 
> could happen if you're not careful.
> 
> Most of that code is peripheral setup, and the rest is simply reading from 
> the ADC buffer, and then printf() to screen. However, in order to get the 
> best performance you never let that data get put on screen by piping the 
> output of the executable to a file. *That* increases performance drastically, 
> and is a happy medium for not having to write a bunch of read() / write() / 
> open() calls for a simple test. Perfect ? Who cares, I never did. I proved a 
> point to myself, and that is all that matters to me. I proved to myself that 
> /dev/mem/ + mmap() works fine, and if you have an application that does not 
> need to spend a lot of CPU time doing things. Then it would work fine. As it 
> is. Reading from the ADC multiple channels as fast as you can. Should 
> probably be done using the PRUs. Simply so you can use that CPU time saved to 
> do other things. Perhaps even display that data to the outside world from a 
> web server.
> 
> Interrupts. They happen, and frequently. So it does not matter if your app 
> generated interrupts or not. Your app will constantly be interrupted by them. 
> So if you're using an rt kernel, "return latency" will be less. Meaning, your 
> app should be able to get things done faster.
> 
> Which brings me to another point. I hope I was misunderstanding someone 
> earlier this week talking about remoteproc and bringing interrupts to 
> userspace. *That* would be a terrible idea, and would generate all kinds of 
> context switching between userland, kernel space, processes, interrupts, 
> copying data to / from kernel space. . .  yeah it would be a bloody mess. But 
> you know what. That will just give me another reason to avoid what I'm 
> already avoiding now.  So, for me, no big deal. I guess.
> 
> On Mon, Jun 20, 2016 at 6:32 PM, William Hermans  > wrote:
> When you're writing directly to memory addresses ( registers ), you can't 
> tell me what is, and what isn't. *This* is exactly what the PRU does when 
> accessing peripherals modules. But, you'd be surprised what you can 
> accomplish from userland when  you pay close attention to what you should 
> *not* do in order to remain performant.
> 
> Anyway, reading from a memory location, and putting that value into another 
> location does not really take a lot of computational power, and then if 
> you're using an rt kernel. The scheduler is going to run in a tighter loop, 
> offering lower latency. But again, you have to be smart how you go about 
> things. Printing every, or even *any* samples to stdout will slow thigns down 
> considerably. Also, if you use a lot of API calls that have to go back and 
> forth to / from the kernel . . . that's going ot slow things down 
> considerably also. etc . . .
> 
> On Mon, Jun 20, 2016 at 6:14 PM,   > wrote:
> The ADC is a SAR ADC. Overclocking it is likely to have side effects on the
> analog end of things which will reduce accuracy.
> 
> Ignoring that it is a very bad idea to keep doing things in userland:
> 
> On Monday, June 20, 2016 18:06:09 John Syne wrote:
> > That is a totally different issue. You were reading the same sample over and
> > over again as opposed to increasing the sample rate by changing the clock
> > divider, open delay, sample delay, etc. In any case, at 200ksps, each
> > sample occurs every 5uS. How is a user space app going to process samples
> > at 5uS? Even when you poll for the EOC with 8 channels configured, you
> > still have to service the samples e