Re: [beagleboard] Re: PRU RemoteProc documentation

2021-03-02 Thread Fisher Grubb 
2393.327782] WARNING: CPU: 0 PID: 1810 at drivers/bus/omap_l3_noc.c:147 
> l3_interrupt_handler+0x368/0x3a4
> [ 2393.327790] 4400.ocp:L3 Standard Error: MASTER PRUSS2 PRU1 TARGET 
> PCIE1 (Read): At Address: 0x00806664 : Data Access in Supervisor mode 
> during Functional access
>
>
>
> Keep us posted I'm interested if you find more data I think we will be 
> seeing many more questions about remoteproc once people start running DSP 
> and M4 code especially about resource tables 
>
> Mark 
>
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Sun, Feb 28, 2021 at 11:46 PM, Fisher Grubb
>  wrote:
>
> Hi all,
>
> I solved my issue in the end of it not booting, or causing errors with 
> "L3_main" in the title from remoteProc to dmesg.
>
> The issue turned out to be both having interrupts from the IEP timer, and 
> that C++ needs .init_array in the linker command file to actually 
> initialise the constructors.
> The linker did add the .init_array section at the end of the binary, but I 
> don't think actually got the code to jump to the needed addresses without 
> that section specifically put into the linker file.
>
> I assume the interrupt issue may be been due to using an empty 
> resource_table, so the kernel module didn't set anything up to receive them 
> on the Linux side, but then the timer sent them.
> I'm not fully sure about that because I believe I've also left them 
> enabled, and not had dmesg errors.
>
> I still can't find any RemoteProc documentation of the possible config 
> options, or how to get extra info out of the kernel modules, such as what 
> it's doing as it processes the resource_table.
>
> Fisher
>
> On Friday, 12 February 2021 at 02:29:00 UTC+10 din...@gmail.com wrote:
>
> The error message is emitted from the system bus driver 
> (drivers/bus/omap_l3_noc.c ). 
>
> I interpret it as a bug in your PRU firmware. When issue occurs, please 
> try to inspect the PRU state. See 
> https://zeekhuge.me/post/ptp_docs_commands_and_tools/ , or use JTAG.
>
> Regards,
> Dimitar
> On Thursday, February 11, 2021 at 7:30:58 AM UTC+2 Fisher Grubb wrote:
>
> Hi Dimitar,
>
> Thanks for your reply, yes, I don't understand that as its code to flash 
> lights.  Its built with different states, which makes it more complicated, 
> but only flashes LEDs.
>
> How can I know what the kernel module is doing so I can see more details 
> and know where to look?  Such as, is this happening when the firmware is 
> being processed by the module, or is this the module giving the error once 
> the code is trying to run on the PRU?
>
> Thanks,
> Fisher
>
> On Thursday, 11 February 2021 at 02:58:57 UTC+10 din...@gmail.com wrote:
>
> Looks like PRU attempts to access PCIE1 address space. I suspect it's a 
> bug in your PRU firmware.
>
> MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): At Address: 0x00806664
>
> TI has tutorials how to use JTAG to debug PRU. Another option is 
> https://markayoder.github.io/PRUCookbook/04debug/debug.html
>
> Regards,
> Dimitar
>
> On Wednesday, February 10, 2021 at 2:27:01 PM UTC+2 Fisher Grubb wrote:
>
> Hi all,
>
> I've done a few searches and couldn't find any threads or "conversations" 
> in this forum/group on the remoteproc kernel module for loading firmware 
> onto the PRUs.
>
> The remoteproc framework is supposed to be a Linux standard, there are 
> some generic documents for it, but I've only found a general diagram and 
> explanation in TIs SDK docs for their implementation.
>
> Simple code to flash LEDs loads and runs fine, but larger, more 
> complicated code that also just flashes LEDs fails to load, occasionally 
> parts of it run, or none of it runs and the there's a bit of a stack trace 
> in dmesg.
>
> The first line of the error in dmesg is:
> 4400.ocp:L3 Standard Error: MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): At 
> Address: 0x00806664 : Data Access in Supervisor mode during Functional 
> access
>
> Is this resource_table related?  Or its meaning that there's a strange 
> memory access?
>
>
> I'm trying to find out:
>
>1. How to get verbose info that shows what the pru_rproc kernel module 
>is doing
>2. How to configure it, maybe commandline, or through the sysfs
>3. Documentation of how it functions, and what it expects, such as the 
>resource_table and firmware layout to match, how it handles errors etc.
>
> Thanks,
> Fisher
>
> Here's my dmesg:
>
> [   76.711182] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
> [   76.736257] IPv6: ADDRCONF(NETDEV_CHANGE): usb1: link becomes ready
&

[beagleboard] Re: PRU RemoteProc documentation

2021-02-28 Thread Fisher Grubb 
Hi all,

I solved my issue in the end of it not booting, or causing errors with 
"L3_main" in the title from remoteProc to dmesg.

The issue turned out to be both having interrupts from the IEP timer, and 
that C++ needs .init_array in the linker command file to actually 
initialise the constructors.
The linker did add the .init_array section at the end of the binary, but I 
don't think actually got the code to jump to the needed addresses without 
that section specifically put into the linker file.

I assume the interrupt issue may be been due to using an empty 
resource_table, so the kernel module didn't set anything up to receive them 
on the Linux side, but then the timer sent them.
I'm not fully sure about that because I believe I've also left them 
enabled, and not had dmesg errors.

I still can't find any RemoteProc documentation of the possible config 
options, or how to get extra info out of the kernel modules, such as what 
it's doing as it processes the resource_table.

Fisher

On Friday, 12 February 2021 at 02:29:00 UTC+10 din...@gmail.com wrote:

> The error message is emitted from the system bus driver 
> (drivers/bus/omap_l3_noc.c ). 
>
> I interpret it as a bug in your PRU firmware. When issue occurs, please 
> try to inspect the PRU state. See 
> https://zeekhuge.me/post/ptp_docs_commands_and_tools/ , or use JTAG.
>
> Regards,
> Dimitar
> On Thursday, February 11, 2021 at 7:30:58 AM UTC+2 Fisher Grubb wrote:
>
>> Hi Dimitar,
>>
>> Thanks for your reply, yes, I don't understand that as its code to flash 
>> lights.  Its built with different states, which makes it more complicated, 
>> but only flashes LEDs.
>>
>> How can I know what the kernel module is doing so I can see more details 
>> and know where to look?  Such as, is this happening when the firmware is 
>> being processed by the module, or is this the module giving the error once 
>> the code is trying to run on the PRU?
>>
>> Thanks,
>> Fisher
>>
>> On Thursday, 11 February 2021 at 02:58:57 UTC+10 din...@gmail.com wrote:
>>
>>> Looks like PRU attempts to access PCIE1 address space. I suspect it's a 
>>> bug in your PRU firmware.
>>>
>>> MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): At Address: 0x00806664
>>>
>>> TI has tutorials how to use JTAG to debug PRU. Another option is 
>>> https://markayoder.github.io/PRUCookbook/04debug/debug.html
>>>
>>> Regards,
>>> Dimitar
>>>
>>> On Wednesday, February 10, 2021 at 2:27:01 PM UTC+2 Fisher Grubb wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've done a few searches and couldn't find any threads or 
>>>> "conversations" in this forum/group on the remoteproc kernel module for 
>>>> loading firmware onto the PRUs.
>>>>
>>>> The remoteproc framework is supposed to be a Linux standard, there are 
>>>> some generic documents for it, but I've only found a general diagram and 
>>>> explanation in TIs SDK docs for their implementation.
>>>>
>>>> Simple code to flash LEDs loads and runs fine, but larger, more 
>>>> complicated code that also just flashes LEDs fails to load, occasionally 
>>>> parts of it run, or none of it runs and the there's a bit of a stack trace 
>>>> in dmesg.
>>>>
>>>> The first line of the error in dmesg is:
>>>> 4400.ocp:L3 Standard Error: MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): 
>>>> At Address: 0x00806664 : Data Access in Supervisor mode during Functional 
>>>> access
>>>>
>>>> Is this resource_table related?  Or its meaning that there's a strange 
>>>> memory access?
>>>>
>>>>
>>>> I'm trying to find out:
>>>>
>>>>1. How to get verbose info that shows what the pru_rproc kernel 
>>>>module is doing
>>>>2. How to configure it, maybe commandline, or through the sysfs
>>>>3. Documentation of how it functions, and what it expects, such as 
>>>>the resource_table and firmware layout to match, how it handles errors 
>>>> etc.
>>>>
>>>> Thanks,
>>>> Fisher
>>>>
>>>> Here's my dmesg:
>>>>
>>>> [   76.711182] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
>>>> [   76.736257] IPv6: ADDRCONF(NETDEV_CHANGE): usb1: link becomes ready
>>>> [   77.894970] NOHZ: local_softirq_pending 08
>>>> [   77.903344] NOHZ: local_softirq_pending 08
>>>> [   77.923339] NOHZ: local_softirq_pending 08
>&g

[beagleboard] Re: PRU RemoteProc documentation

2021-02-10 Thread Fisher Grubb 
Hi Dimitar,

Thanks for your reply, yes, I don't understand that as its code to flash 
lights.  Its built with different states, which makes it more complicated, 
but only flashes LEDs.

How can I know what the kernel module is doing so I can see more details 
and know where to look?  Such as, is this happening when the firmware is 
being processed by the module, or is this the module giving the error once 
the code is trying to run on the PRU?

Thanks,
Fisher

On Thursday, 11 February 2021 at 02:58:57 UTC+10 din...@gmail.com wrote:

> Looks like PRU attempts to access PCIE1 address space. I suspect it's a 
> bug in your PRU firmware.
>
> MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): At Address: 0x00806664
>
> TI has tutorials how to use JTAG to debug PRU. Another option is 
> https://markayoder.github.io/PRUCookbook/04debug/debug.html
>
> Regards,
> Dimitar
>
> On Wednesday, February 10, 2021 at 2:27:01 PM UTC+2 Fisher Grubb wrote:
>
>> Hi all,
>>
>> I've done a few searches and couldn't find any threads or "conversations" 
>> in this forum/group on the remoteproc kernel module for loading firmware 
>> onto the PRUs.
>>
>> The remoteproc framework is supposed to be a Linux standard, there are 
>> some generic documents for it, but I've only found a general diagram and 
>> explanation in TIs SDK docs for their implementation.
>>
>> Simple code to flash LEDs loads and runs fine, but larger, more 
>> complicated code that also just flashes LEDs fails to load, occasionally 
>> parts of it run, or none of it runs and the there's a bit of a stack trace 
>> in dmesg.
>>
>> The first line of the error in dmesg is:
>> 4400.ocp:L3 Standard Error: MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): 
>> At Address: 0x00806664 : Data Access in Supervisor mode during Functional 
>> access
>>
>> Is this resource_table related?  Or its meaning that there's a strange 
>> memory access?
>>
>>
>> I'm trying to find out:
>>
>>1. How to get verbose info that shows what the pru_rproc kernel 
>>module is doing
>>2. How to configure it, maybe commandline, or through the sysfs
>>3. Documentation of how it functions, and what it expects, such as 
>>the resource_table and firmware layout to match, how it handles errors 
>> etc.
>>
>> Thanks,
>> Fisher
>>
>> Here's my dmesg:
>>
>> [   76.711182] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
>> [   76.736257] IPv6: ADDRCONF(NETDEV_CHANGE): usb1: link becomes ready
>> [   77.894970] NOHZ: local_softirq_pending 08
>> [   77.903344] NOHZ: local_softirq_pending 08
>> [   77.923339] NOHZ: local_softirq_pending 08
>> [   77.967346] NOHZ: local_softirq_pending 08
>> [   77.977416] NOHZ: local_softirq_pending 08
>> [   78.009731] NOHZ: local_softirq_pending 08
>> [   78.227509] NOHZ: local_softirq_pending 08
>> [   78.414768] NOHZ: local_softirq_pending 08
>> [   78.478154] NOHZ: local_softirq_pending 08
>> [   78.483369] NOHZ: local_softirq_pending 08
>> [  139.787136] remoteproc remoteproc6: powering up 4b2b4000.pru
>> [  139.792152] remoteproc remoteproc6: Booting fw image PRU-LEDs.out, 
>> size 32644
>> [  139.792176] remoteproc remoteproc6: remote processor 4b2b4000.pru is 
>> now up
>> [  152.475360] remoteproc remoteproc6: stopped remote processor 
>> 4b2b4000.pru
>> [  207.719337] pru-rproc 4b2b4000.pru: can't provide a NULL firmware
>> [  234.455246] remoteproc remoteproc6: powering up 4b2b4000.pru
>> [  234.455834] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, 
>> size 369696
>> [  234.455878] remoteproc remoteproc6: remote processor 4b2b4000.pru is 
>> now up
>> [  241.915304] remoteproc remoteproc6: stopped remote processor 
>> 4b2b4000.pru
>> [  254.522378] remoteproc remoteproc6: powering up 4b2b4000.pru
>> [  254.522557] remoteproc remoteproc6: Booting fw image PRU-LEDs.out, 
>> size 32644
>> [  254.522577] remoteproc remoteproc6: remote processor 4b2b4000.pru is 
>> now up
>> [  257.559216] remoteproc remoteproc6: stopped remote processor 
>> 4b2b4000.pru
>> [  375.451166] remoteproc remoteproc6: powering up 4b2b4000.pru
>> [  375.451886] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, 
>> size 369696
>> [  375.451931] remoteproc remoteproc6: remote processor 4b2b4000.pru is 
>> now up
>> [  380.203249] remoteproc remoteproc6: stopped remote processor 
>> 4b2b4000.pru
>> [  387.895263] remoteproc remoteproc6: powering up 4b2b4000.pru
>> [  387.895392] remoteproc remoteproc6: Booting fw image PRU-LEDs.out, 
>

[beagleboard] PRU RemoteProc documentation

2021-02-10 Thread Fisher Grubb 
Hi all,

I've done a few searches and couldn't find any threads or "conversations" 
in this forum/group on the remoteproc kernel module for loading firmware 
onto the PRUs.

The remoteproc framework is supposed to be a Linux standard, there are some 
generic documents for it, but I've only found a general diagram and 
explanation in TIs SDK docs for their implementation.

Simple code to flash LEDs loads and runs fine, but larger, more complicated 
code that also just flashes LEDs fails to load, occasionally parts of it 
run, or none of it runs and the there's a bit of a stack trace in dmesg.

The first line of the error in dmesg is:
4400.ocp:L3 Standard Error: MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): At 
Address: 0x00806664 : Data Access in Supervisor mode during Functional 
access

Is this resource_table related?  Or its meaning that there's a strange 
memory access?


I'm trying to find out:

   1. How to get verbose info that shows what the pru_rproc kernel module 
   is doing
   2. How to configure it, maybe commandline, or through the sysfs
   3. Documentation of how it functions, and what it expects, such as the 
   resource_table and firmware layout to match, how it handles errors etc.

Thanks,
Fisher

Here's my dmesg:

[   76.711182] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[   76.736257] IPv6: ADDRCONF(NETDEV_CHANGE): usb1: link becomes ready
[   77.894970] NOHZ: local_softirq_pending 08
[   77.903344] NOHZ: local_softirq_pending 08
[   77.923339] NOHZ: local_softirq_pending 08
[   77.967346] NOHZ: local_softirq_pending 08
[   77.977416] NOHZ: local_softirq_pending 08
[   78.009731] NOHZ: local_softirq_pending 08
[   78.227509] NOHZ: local_softirq_pending 08
[   78.414768] NOHZ: local_softirq_pending 08
[   78.478154] NOHZ: local_softirq_pending 08
[   78.483369] NOHZ: local_softirq_pending 08
[  139.787136] remoteproc remoteproc6: powering up 4b2b4000.pru
[  139.792152] remoteproc remoteproc6: Booting fw image PRU-LEDs.out, size 
32644
[  139.792176] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  152.475360] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  207.719337] pru-rproc 4b2b4000.pru: can't provide a NULL firmware
[  234.455246] remoteproc remoteproc6: powering up 4b2b4000.pru
[  234.455834] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
369696
[  234.455878] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  241.915304] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  254.522378] remoteproc remoteproc6: powering up 4b2b4000.pru
[  254.522557] remoteproc remoteproc6: Booting fw image PRU-LEDs.out, size 
32644
[  254.522577] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  257.559216] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  375.451166] remoteproc remoteproc6: powering up 4b2b4000.pru
[  375.451886] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
369696
[  375.451931] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  380.203249] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  387.895263] remoteproc remoteproc6: powering up 4b2b4000.pru
[  387.895392] remoteproc remoteproc6: Booting fw image PRU-LEDs.out, size 
32644
[  387.895411] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  390.959144] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  407.879207] remoteproc remoteproc6: powering up 4b2b4000.pru
[  407.879755] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
369696
[  407.879800] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  425.139157] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  628.915190] remoteproc remoteproc6: powering up 4b2b4000.pru
[  628.915736] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
369876
[  628.915780] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  840.639171] pru-rproc 4b2b4000.pru: can't change firmware while running
[  845.259199] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  852.903126] remoteproc remoteproc6: powering up 4b2b4000.pru
[  852.903663] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
370028
[  852.903716] [ cut here ]
[  852.903735] WARNING: CPU: 0 PID: 1810 at drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x368/0x3a4
[  852.903744] 4400.ocp:L3 Standard Error: MASTER PRUSS2 PRU1 TARGET 
PCIE1 (Read): At Address: 0x00806664 : Data Access in Supervisor mode 
during Functional access
[  852.903750] Modules linked in: rpmsg_rpc rpmsg_proto pru_rproc 
pruss_intc bnep pruss pvrsrvkm(O) pruss_soc_bus ti_vpe ti_sc 
videobuf2_dma_contig ti_csc ti_vpdma v4l2_mem2mem v4l2_common 
videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media btsdio 
bluetooth joydev ecdh_generic brcmfmac stmpe_adc brcmutil cfg80211 
omap_remoteproc virtio_rpmsg_bus rpmsg_core usb_f_ncm

Re: [beagleboard] Re: Pin MUX and other Mode Settings

2020-11-03 Thread Fisher Grubb 
Thanks Thomas,

I'll look into your project, I had come across it before, but wanted to
first complete the TI hands on labs to get my mind around the basics.

I'll have a look further, though for basic pin configuration to test code,
are the config-pin and gpioinfo commands all one needs?

How does one find out which pin IO files in the /sys/class folder control
which pins?  The image has changed and older instructions don't work.

I've come across this page:
https://www.elinux.org/EBC_Exercise_41_Pin_Muxing_for_the_AI

Fisher



On Wed, 4 Nov 2020 at 00:40, TJF  wrote:

> Hi Fisher!
>
> For pinmuxing without limitations and performed from user space (no
> re-booting) check out libpruio .
>
> Drop rpmsg, it isn't helpful at all (for real projects and professional
> development). UIO_PRUSS is the driver to use.
>
> Regards
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/svMxQX6__f8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/65fcac23-5740-473c-b3cd-c412d076926ao%40googlegroups.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/CAD4Xxq_EoROKXg1xFNk%2BmqZYZJvVhW6ntE-%2Bf1Tkj6gS9hvDbA%40mail.gmail.com.

[beagleboard] Re: Interfacing a 16x2 char HD44780 LCD display

2020-11-03 Thread Fisher Grubb 
Hi all,

I'm in the process of doing a project with the PRUs, only just started, and 
learning how to do MUX and pad settings etc, using TI's hands on labs, plus 
have seen some of your work Mark.

I'll be later using a 20 x 4 char LCD which is the same interface & 
protocol.

Is that something you'd like me to post back here if/when I get it all 
working?

As long as I can get MUX and other settings done to allow the PRU access to 
the pads/pins, then should all be fine.

Fisher

On Tuesday, 3 November 2020 at 10:56:25 UTC+10 amf wrote:

> Hi Mark
> Seen RCN's response below. I have several of the *hd44780 LCD displays 
> also, *spent the weekend trying to get it to work with the info RCN 
> provided. Seems the R/W line is always high, thus all the data signals are 
> distorted. If I pull the R/W line low, then the data signals are ok, but 
> nothing is written to the display. I know the displays are good, I wrote a 
> uart-to-parallel with an atmel chip several years ago. if you have success 
> with the Linux driver, I would like to know. 
> amf
>
> On Thursday, October 29, 2020 at 1:39:54 PM UTC-5 Mark A. Yoder wrote:
>
>> I've just recently discovered I have access to lots of 16x2 LCD displays.
>>
>> I see there are many examples of interfacing it to a Linux machine, but 
>> most are via user space.  I'm looking for kernel space examples.  *modinfo 
>> hd44780* shows a driver is there, but how do I use it.  
>>
>> Is there a device tree for the hd44780 for a parallel interface?
>>
>> --Mark
>>
>

-- 
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/f39b83f5-6178-4235-a7e2-ffac9f9b747fn%40googlegroups.com.

[beagleboard] Pin MUX and other Mode Settings

2020-10-30 Thread fisher . grubb 
Hi all,

I know this sort of topic has been discussed at different times, the 
Kernel, Capemgr and slots files have changed over the time.

uBoot is supposed to manage device tree overlays or something, at it seems 
that one has to reboot each time you want to change cape overlays.
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

I just want to first cover individual pin settings (MUX, pull resistors, 
input/output etc), and later make my own overlay.

What is the central resource that covers all this?

I'm hoping to find examples and documentation for:

   1. Individual pin control/settings
   2. The current device tree/Cape overlay system & files
   3. How uBoot conrols this, and other options one may do themselves.
   


There is the config-pin tool which is supposed to help one configure 
individual pins, where is the documentation and example uses for it?

The PRU is my main target, and I've been using TI's PRU hands on labs, 
which have been very helpful with RPMSG etc, but now I'm doing LEDs, 
buttons and IO, so need to configure pins to the external environment.

Thanks,
Fisher

-- 
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/8b2225dc-3549-49d4-9313-505cf8b1a441o%40googlegroups.com.

[beagleboard] Understanding Beagle Boot Process

2020-10-02 Thread fisher . grubb 
Hi all,

I've tried following scripts etc in /opt/scripts and while a number of them 
are used to control the boot and other processes of the board, I can't 
follow how they are called.

Please can someone tell me from the Kernel being loaded how I can start to 
follow the boot process?
Is this documented anywhere?

I have a BeagleBone AI and am trying to configure one of the USB ethernet 
connections to take a DHCP address.
I know settings are in /etc/detault, but there's now information of which 
scripts use those files etc.

I'll later need to follow more boot scripts for different things.

Thanks,
Fisher

-- 
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/e3be0615-f72b-4e55-bc34-1f8e5d2f9f69o%40googlegroups.com.

[beagleboard] Capes for PRU, BB-AI compatible?

2020-10-01 Thread fisher . grubb 
Hi all,

I know of the official PRU cape from TI, this was from 2014, when the 
BeagleBone Black came out, a long time ago.

I now have the BB-AI, while its most likely the cape is compatible, I'm 
sure there must be something a lot more recent.

Is there at least a general purpose cape, which even has multiplexing 
selection so one may change how the on-board cape devices connect to the 
standard P8 and P9 headers?

I'm wanting to at least test basic items such as: LEDs, buttons, I2C and 
likely serial comms, other items could be ethernet comms, and maybe LCD 
screen.
It would be nice if these and other items on the board could be multiplexed 
according to what one is testing at the time. some may be allocated to PRU, 
others general purpose etc.

I'm wanting to do a lot of PRU testing and prototyping, so hope to be able 
to test all its features.

Thanks,
Fisher

-- 
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/c745b9bc-42d1-4936-8654-f1e544c57352o%40googlegroups.com.

Re: [beagleboard] Re: WiFi connectivity and possible external power supplies for BBAI

2020-09-27 Thread Fisher Grubb 
Hi all,

Thanks for your input, its very strange.  I got it working, by pinging the
IP address from my laptop.

They are both connected to the same WiFi network.  The routing table hasn't
changed at all, but I noticed that it took like 5 seconds to generate.  I
assumed that might have been normal for this board, but now its
instantaneous.

This device was given 192.168.1.175 via DHCP by my WiFi modem, so, I could
ping it from my laptop through the WiFi network.

I've rebooted, and it connects as normal, and internet via WiFi works
immediately.

Very strange, any ideas?

I'll reply here if anything changes.
Fisher

On Sat, 26 Sep 2020 at 03:38, jonnymo  wrote:

> In your /var/lib/connman folder you should have a file associated with
> your wlan0 config.
>
> ex:
> * $  sudo ls
>  /var/lib/connman/wifi_8091334a1523_4d6f4e6574494f54_managed_psk/*
> *data  settings*
>
> In the psk settings file, I tend to set this manually as such:
>
> *Name=MySSID*
> *SSID=pk2-passwd*
> *Frequency=2462*
> *Favorite=true*
> *AutoConnect=true*
> *Modified=2020-09-24T07:36:19.092924Z*
> *Passphrase=mypasswd*
> *IPv4.method=manual*
> *IPv4.netmask_prefixlen=21*
> *IPv6.method=off*
> *IPv6.privacy=disabled*
> *Hidden=true*
> *IPv4.local_address=192.168.2.210*
> *IPv4.gateway=192.168.2.1*
> *Nameservers=8.8.8.8;8.8.4.4;4.4.4.4;*
>
> The "Nameservers" setting wll set the /etc/resolv.conf with the nameserver
> associated with wlan0 and the same is so for  IPv4.gateway if you are
> running IPv4.
>
> This can be done manually as such:
>
> *# connmanctl config  --ipv4 manual  
> *
> *# connmanctl config  --nameservers *
>
> Ref:
>  https://variwiki.com/index.php?title=Static_IP_Address
>
> If your eth0 is not defined with nameservers and gateway, it is possible
> it will overwrite the /etc/resolv.conf when you plug in an ethernet cable
> and not set it when it is disconnected.  One test would be to reboot the
> board and see if the wlan0 connection recovers. Another is to  check
> /etc/resolv.conf when you plug in the ethernet cable and then when you
> disconnect it.
>
> You can also use 'dmesg' to see if there are any networking errors being
> reported when you are changing network connects.
>
>
> Cheers,
>
> Jon
>
>
>
> On Fri, Sep 25, 2020 at 8:21 AM  wrote:
>
>> Hi all,
>>
>> I'm also having issues with getting internet via WiFi on this BB-AI board.
>>
>> It connects to my WiFi network, gets a DHCP address, the routing table
>> shows the default route is 192.168.1.1, through wlan0 interface etc,
>> exactly the same top line of Matt's table.
>> The WiFi LED goes green (right next to the Ethernet port).
>>
>> I've connected through Ethernet and upgraded the software, but same issue
>> with WiFi connected but no network through it.
>>
>> It automatically sets the routing interface to Eth0 when I plug the
>> Ethernet in, then sets its back to wlan0 when I unplug it so that's great
>> but still no signs of life.
>>
>> There are a bunch of scripts in /opt/scripts, and configs in /etc/default.
>> In /etc/default, there's a settings file bb-wl18xx with
>> "TETHER_ENABLED=yes", I've changed it to "no".  That caused connman to not
>> connect the WiFi automatically, so I used connmancltl to set the agent back
>> on for it to connect again.
>>
>> What else can I check and change?  I've put my connman settings and route
>> command output are below, to me they show everything set up for this to
>> work.
>> My assumption is that either its a separate setting relating to boot
>> scripts etc, or its a driver/firmware issue.
>>
>> I've had this issue previously, but it worked once on the original board
>> image, but after updating to the latest image, it just doesn't work at all.
>>
>> My connman settings file in /var/lib/connman/
>>
>> [global]
>> OfflineMode=false
>>
>> [Wired]
>> Enable=true
>> Tethering=false
>>
>> [WiFi]
>> Enable=true
>> Tethering=false
>>
>> [Gadget]
>> Enable=false
>> Tethering=false
>>
>> [P2P]
>> Enable=false
>> Tethering=false
>>
>> [Bluetooth]
>> Enable=true
>> Tethering=false
>>
>>
>> *fisher@beaglebone*:*~*$route
>> Kernel IP routing table
>> DestinationGateway GenmaskFlags Metric Ref   Use
>> Iface
>> default 192.168.1.10.0.0.0 UG   0  00
>> wlan0
>> 192.168.1.0 0.0.0.0255.255.255.0   U0  00
>> wlan0
>> 192.168.1.1 0.0.0.0255.255.255.255 UH   0  00
>> wlan0
>> 192.168.6.0 0.0.0.0255.255.255.0   U0  00
>> usb1
>> 192.168.7.0 0.0.0.0255.255.255.0   U0  00
>> usb0
>> 192.168.8.0 0.0.0.0255.255.255.0   U0  00
>> SoftAp0
>>
>> *fisher@beaglebone*:*~*$ ping -I wlan0 192.168.1.1
>> PING 192.168.1.1 (192.168.1.1) from 192.168.1.175 wlan0: 56(84) bytes of
>> data.
>> ^C
>> --- 192.168.1.1 ping statistics ---
>> 9 packets transmitted, 0 received, 100% packet loss, time 178ms
>>
>> Fisher
>>
>>
>> On Tuesday, 14 July 2020 08:54:26 UTC+10,

Re: [beagleboard] Re: WiFi connectivity and possible external power supplies for BBAI

2020-09-25 Thread fisher . grubb 
Hi all,

I'm also having issues with getting internet via WiFi on this BB-AI board.

It connects to my WiFi network, gets a DHCP address, the routing table 
shows the default route is 192.168.1.1, through wlan0 interface etc, 
exactly the same top line of Matt's table.
The WiFi LED goes green (right next to the Ethernet port).

I've connected through Ethernet and upgraded the software, but same issue 
with WiFi connected but no network through it.

It automatically sets the routing interface to Eth0 when I plug the 
Ethernet in, then sets its back to wlan0 when I unplug it so that's great 
but still no signs of life.

There are a bunch of scripts in /opt/scripts, and configs in /etc/default.
In /etc/default, there's a settings file bb-wl18xx with 
"TETHER_ENABLED=yes", I've changed it to "no".  That caused connman to not 
connect the WiFi automatically, so I used connmancltl to set the agent back 
on for it to connect again.

What else can I check and change?  I've put my connman settings and route 
command output are below, to me they show everything set up for this to 
work.
My assumption is that either its a separate setting relating to boot 
scripts etc, or its a driver/firmware issue.

I've had this issue previously, but it worked once on the original board 
image, but after updating to the latest image, it just doesn't work at all.

My connman settings file in /var/lib/connman/

[global]
OfflineMode=false

[Wired]
Enable=true
Tethering=false

[WiFi]
Enable=true
Tethering=false

[Gadget]
Enable=false
Tethering=false

[P2P]
Enable=false
Tethering=false

[Bluetooth]
Enable=true
Tethering=false


*fisher@beaglebone*:*~*$route 
Kernel IP routing table 
DestinationGateway GenmaskFlags Metric Ref   Use Iface 
default 192.168.1.10.0.0.0 UG   0  00 wlan0 
192.168.1.0 0.0.0.0255.255.255.0   U0  00 wlan0 
192.168.1.1 0.0.0.0255.255.255.255 UH   0  00 wlan0 
192.168.6.0 0.0.0.0255.255.255.0   U0  00 usb1 
192.168.7.0 0.0.0.0255.255.255.0   U0  00 usb0 
192.168.8.0 0.0.0.0255.255.255.0   U0  00 
SoftAp0 

*fisher@beaglebone*:*~*$ ping -I wlan0 192.168.1.1 
PING 192.168.1.1 (192.168.1.1) from 192.168.1.175 wlan0: 56(84) bytes of 
data. 
^C 
--- 192.168.1.1 ping statistics --- 
9 packets transmitted, 0 received, 100% packet loss, time 178ms
 
Fisher
 

On Tuesday, 14 July 2020 08:54:26 UTC+10, jonnymo wrote:
>
> The values I provided should set the /etc/resolv.conf for the wlan0 
> interface. The gateway you would want to set for your config.  I typically 
> run with a static ip on my wlan0 so I edit the connman settings manually 
> for my environment.  The other option is to do it manually or with some 
> script that detects the loss of your usb network connection and then set 
> resolv.conf accordingly.  This does take root access, so I find it best to 
> just add it to the connman settings. 
>
> You could check your /etc/resolv.conf on your BBAI after you 
> experience the USB sleep mode on your laptop to see if there are any 
> settings still in there. If not, then that might explain why you can not 
> reach google.com when the usb interface is offline.
>
> Cheers,
>
> Jon 
>
> On Mon, Jul 13, 2020 at 3:08 PM Manderson  > wrote:
>
>> Hi Jon - thanks for your input.
>>
>> This is a snapshot of my working wlan0 
>>
>> wlan0: flags=-28605  mtu 1500
>> inet 192.168.1.50  netmask 255.255.255.0  broadcast 192.168.1.255
>> inet6 fe80::8291:33ff:fe4a:4223  prefixlen 64  scopeid 0x20
>> ether 80:91:33:4a:42:23  txqueuelen 1000  (Ethernet)
>> RX packets 20004  bytes 4482231 (4.2 MiB)
>> RX errors 0  dropped 375  overruns 0  frame 0
>> TX packets 2130  bytes 245657 (239.8 KiB)
>> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>
>> I am indeed using connman -- what do those two additional settings do?
>>
>> Output of `route`:
>> debian ~ $ route
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric RefUse 
>> Iface
>> default 192.168.1.1 0.0.0.0 UG0  00 
>> wlan0
>> 192.168.1.0 0.0.0.0 255.255.255.0   U 0  00 
>> wlan0
>> 192.168.1.1 0.0.0.0 255.255.255.255 UH0  00 
>> wlan0
>> 192.168.6.0 0.0.0.0 255.255.255.0   U 0  00 
>> usb1
>> 192.168.7.0 0.0.0.0 255.255.255.0   U 0  00 
>> usb0
>> 192.168.8.0 0.0.0.0 255.255.255.0   U 0  00 
>> SoftAp0
>>
>>
>> Best,
>> Matt
>>
>> On Thursday, July 9, 2020 at 5:02:44 PM UTC-7, jonnymo wrote:
>>>
>>> I suspect your resolv.conf got set back to the default with no 
>>> nameservers listed when the USB ethernet port went offline. 
>>>
>>> How do you have your wlan0 configured?
>>> If you used connman, you can add the

Re: [beagleboard] Multicore Support for Beagle

2017-05-24 Thread fisher . grubb 
Hi all,

I see this was asked a few years ago, are there still no further plans to add a 
multicore board to the lineup?

I ask as its very likely the company I work for would have ordered one if there 
was, we use the PI 3 and its not 100% ideal, we would love an RTC, I know the 
BBB CPU has an internal one and that would have helped us, especially with the 
onboard battery charger.

I have a strong suspicion that the PI 3 etc are more in demand than boards from 
beagleboard.org due to multiple cores.

I know the 2 different boards (pi and BBB) are targeted to different uses, BBB 
is great for lots of sensors and robotics etc, but I think it comes across out 
dated these days in comparison to the pi especially how the pi has evolved a 
lot with a more powerful processor every couple of years.

The new Octavia package is a great idea, I hope it help propel custom designs.

Any more thoughts?

Fisher

-- 
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/7f4d0c8b-82fe-45de-83cc-8d4077f182b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Official eQEP driver Support

2017-05-02 Thread fisher . grubb 
Hi Drew,

Thanks very much for your reply and info, I've previously seen your 2 
YouTube videos showing your setup from a few years ago which gave me some 
clues and I downloaded the same image you used then and saw it worked fine.

I had made a mistake by using 5v on the hall sensor as the datasheet 
claimed it only worked above 5v. I didn't add anything to reduce its output 
A and B channels, so I wondered if I damaged QEP 2b or the whole eQEP 
system.

Thankfully, the board is fine and I've found that the issue is actually the 
wrong mode values in the newer eQEP overlay files.

Nathaniel Lewis originally used modes 0x24 for the index and strobe pins, 
and 0x34 for channels A and B.  It seems that all or most updated images 
use modes 0x2c for all pins and so it seems that the driver doesn't work, 
when its just to do with pull-down resistors being enabled.

So, one doesn't have to use the Cape-Universal overlay if you don't want to.

I prefer to use separate overlays at the moment as I'm trying to get 
Simulink support for eQEP working as well as upgrading Simulink support to 
work with the newer images (kernel 4 and above as the slots path has 
changed etc).

Fisher

On Sunday, 23 April 2017 09:23:27 UTC+10, Drew Fustini wrote:
>
> On Thu, Apr 20, 2017 at 11:30 AM,   
> wrote: 
> > Hi all, 
> > 
> > I'm trying to use the eQEP Linux driver.  I can get it to load by adding 
> a 
> > device tree overlay, but it doesn't increment much.  I can see that its 
> > loaded (called tieqep) with lsmod etc. 
> > 
> > I've never used a quadrature encoder before, so I question if I just 
> havn't 
> > connected it correctly. 
> > 
> > At times it doesn't increment (reading Position file in 
> > /sys/device/ocp/epwmss48.. folder), other times it increments or 
> > decrements 2 or 3 positions. 
> > 
> > If I jiggle the wheel back and forth a small a amount, it counts a lot. 
>  The 
> > dual hall effect sensor outputs clean and clear waveforms at 3.3v, 90 
> > degrees out of phase, switches phase when change wheel direction just as 
> I 
> > expected. 
> > 
> > I'm only using channels A and B, did not touch other connections. 
> > 
> > I've tried using all 3 eQEPs separately (including the 2b overlay for 
> > alternate pins of eQEP2).  I've used Derek Molloy's P9 and P8 header 
> files. 
> > 
> > Currently have proto-cape with pins 35 (A input)and 33 (B input)on P8 
> header 
> > for eQEP1. 
> > 
> > Other eQEPs have same behaviour.  I've also swapped the beaglebone black 
> > board with a new one. 
> > 
> > I'm using kernel 4.4.9-ti-rt-r25 but with old llibraries and system from 
> > like 2015 I think as Simulink doesn't officially support anything 
> higher.  I 
> > only upgraded the kernel. 
> > 
> > Please let me know if anyone has any advice. 
> > 
> > Thanks, 
> > Fisher 
>
> I've been using a rotary encoder successfully with the tieqep driver: 
>
> https://blog.oshpark.com/2017/04/05/rotary-encoder-breakout-with-pull-up-resistors/
>  
>
> I'm running 4.4.47-ti-r87 on Debian 8.7.  I've got it connected to 
> P8.11 and P8.12.  I'm using config-pin to set the mode on those pins. 
> Details here: 
>
> https://github.com/adafruit/adafruit-beaglebone-io-python/blob/eqep/doc/rotary-encoder-eqep-test.md
>  
>
> The position does accurately reflect how many increments I turn the 
> encoder knob.  However, this is at a relatively low rate of speed as I 
> can not turn the knob as fast a motor with an encoder. 
>
> You could try using the Strawson library as an alternative to the 
> kernel driver.  I believe it has support for the encoders: 
> http://www.strawsondesign.com/#!manual-encoders 
>
> regards, 
> drew 
>

-- 
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/501c9199-d0c0-47e5-96b5-51686a4c74fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Official eQEP driver Support

2017-04-20 Thread fisher . grubb 
Hi all,

I'm trying to use the eQEP Linux driver.  I can get it to load by adding a 
device tree overlay, but it doesn't increment much.  I can see that its 
loaded (called tieqep) with lsmod etc.

I've never used a quadrature encoder before, so I question if I just havn't 
connected it correctly.

At times it doesn't increment (reading Position file in 
/sys/device/ocp/epwmss48.. folder), other times it increments or 
decrements 2 or 3 positions.

If I jiggle the wheel back and forth a small a amount, it counts a lot. 
 The dual hall effect sensor outputs clean and clear waveforms at 3.3v, 90 
degrees out of phase, switches phase when change wheel direction just as I 
expected.

I'm only using channels A and B, did not touch other connections.

I've tried using all 3 eQEPs separately (including the 2b overlay for 
alternate pins of eQEP2).  I've used Derek Molloy's P9 and P8 header files.

Currently have proto-cape with pins 35 (A input)and 33 (B input)on P8 
header for eQEP1.

Other eQEPs have same behaviour.  I've also swapped the beaglebone black 
board with a new one.

I'm using kernel 4.4.9-ti-rt-r25 but with old llibraries and system from 
like 2015 I think as Simulink doesn't officially support anything higher. 
 I only upgraded the kernel.

Please let me know if anyone has any advice.

Thanks,
Fisher

On Saturday, 14 November 2015 03:41:59 UTC+10, dickelbeck wrote:
>
> > I would like to make known a bug we ran into with reading the eQEP 
> module that resulted in position values not updating after exactly 1020 
> reads without closing the file pointer.
>
> Of course you are using a low level read function, not buffered userspace 
> IO like fscanf().  
> That is, use read() not fscanf().  Then try using seek() back to file 
> begin, offset 0, in between reads.
>
> HTH,
>
> Dick
>
>
>

-- 
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/fc07fe81-85fd-492d-9921-eafc88f89672%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Embedded development in OpenModelica similar to Simulink

2014-10-15 Thread Fisher Grubb 
Hi all,

Those interested in embedded development with Simulink will be happy to 
know that Mathworks released some form of official support for the 
BeagleBone Black with version R2014b and a hardware support package.

I'll be trying that out when my university finally gets its which may take 
months.

In the meantime, has anyone done anything with Openmodelica?  Its an open 
source alternative to Matlab and Simulink, mainly run by a University 
professor in I think Switzerland (or Sweden).

www.openmodelica.org

What about embedded development with it?  I will post in their forums also.

I hope its not too complicated to add PRU and other high featured/low level 
functionality to Simulink etc.

Many vehicle manufacturers use Simulink or similar stuff in their 
programming and testing of ECUs and similar projects to help manage and 
visualise the code better.  This can also be known as hardware in the 
loop depending on the scenario.

Hopefully there will be some open source development for those additions to 
SImulink and Openmodelica.

Fisher

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

Re: [beagleboard] BeagleBone Black RTC?

2014-07-07 Thread Fisher Grubb 
Hi all,

If one adds the feature in software, would it be physically possible to 
have the realtime clock feature (with wake up events etc) if it is done 
correctly in software?

Is the software implementation the only thing stopping RTC functionality 
(besides needing to connect a battery to the power management chip)?

Fisher

On Saturday, 11 May 2013 04:40:59 UTC+10, Gerald wrote:

 These documents are correct. In fact, I know the author fairly well.

 Yes, you can add the battery if you chose to. But, the SW needs to be 
 there to support it. Also, you need the SW to put the PMIC to power down 
 mode and shut everything down and not to turn off the power.

 So. add the battery and you will see that the RTC function, does not work. 
 You will need to add that support to the SW.

 So as I said, No RTC support, just like, the BeagleBone.

 Gerald


 On Fri, May 10, 2013 at 1:33 PM, eoin@gmail.com javascript: wrote:

 That is not correct (Although it may have been at the time you wrote 
 that) 


 http://www.digikey.com/web%20export/supplier%20content/ti_296/mkt/boards/BBB_SRM.pdf?redirected=1
 Page 40 of the PDF linked...
 Four pads are provided on the board to allow access to the battery pins 
 on the TPS65217C. The pads can be loaded with a 4x4 header or  you may  
 just wire a battery into the pads. In addition they could provide access 
 via a cape if desired. 

 There is no fuel gauge function provide by the TPS65217C. That would need 
 to be added if that function was required.  Access to 1-wire  SPI,  or I2C 
 interfaces required to use a fuel gauge will need to be accessed by using 
 the expansion headers on the board.

 NOTE: Refer to the TPS65217C documentation before connecting anything to 
 these pins.
 http://www.ti.com/lit/ds/slvsb64f/slvsb64f.pdf

 Hope that helps others.



 On Friday, February 1, 2013 7:59:13 AM UTC-5, Gerald wrote:

 Same as Beaglebone. No RTC battery capability.

 Gerald


 On Fri, Feb 1, 2013 at 1:51 AM, Alexander Holler hol...@ahsoftware.de 
 wrote:

 Hello,

 I've ust had a look at the specs for BeagleBone Black.

 As usual, my first question was: Does it support RTC operation?

 Having a first look at the schematics, it does not look like it is 
 possible to connect some coin battery or similiar to drive the processor 
 in 
 RTC only mode. Am I right and this another non-RTC design which needs an 
 external RTC connected to I2C or similiar?

 Regards,

 Alexander


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

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





 -- 
 Gerald
  
 ger...@beagleboard.org
 g-co...@ti.com 
 http://beagleboard.org/
 http://circuitco.com/support/
  
  -- 
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  




 -- 
 Gerald
  
 ger...@beagleboard.org javascript:
 g-co...@ti.com javascript: 
 http://beagleboard.org/
 http://circuitco.com/support/
  

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

[beagleboard] Re: BeagleBone Black RTC?

2014-07-07 Thread Fisher Grubb 
Hi David,

Yes, I have also seen small boards from Adafruit, though if I need an RTC 
and it is possible to implement a fully functional one with the current 
board by just adding a battery, I wouldn't add any extra components, 
especially since the RTC in the CPU seems to have wake up events.

I am doing a Masters project in control systems at university and am hoping 
to either not have any external boards or at least very minimal.

I will probably make my own board and won't add an RTC if I can implement 
one with what is already on the BBB, especially as it may have more 
features such as wake ups which a general I2C RTC won't have I don't think.

Fisher

On Tuesday, 8 July 2014 01:54:22 UTC+10, David Anders wrote:

 or just purchase a RTC Cape

 http://elinux.org/CircuitCo:RTC_Cape for $29.99MSRP


 On Friday, February 1, 2013 1:51:51 AM UTC-6, Alexander Holler wrote:

 Hello, 

 I've ust had a look at the specs for BeagleBone Black. 

 As usual, my first question was: Does it support RTC operation? 

 Having a first look at the schematics, it does not look like it is 
 possible to connect some coin battery or similiar to drive the processor 
 in RTC only mode. Am I right and this another non-RTC design which needs 
 an external RTC connected to I2C or similiar? 

 Regards, 

 Alexander 



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

Re: [beagleboard] Re: BeagleBone Black RTC?

2014-07-07 Thread Fisher Grubb 
Hi Dave and Gerald,

I don't have one of these boards yet so just wanted to check as I am 
assessing the BBB and comparing it to others for my university project.

If it is physically possible to add a rechargeable battery to the PMIC for 
it to power the board and be charged when external power is connected, that 
is a bonus that the BBB has on board battery charging (I assume only for 
low capacity LiPos like 800 mAh etc).

If the that battery also allows one to use the RTC within the Ti CPU as the 
RTC was intended which is to my knowledge to keep track of time (with 
calendar) and to wake the CPU up with events, then surely that means there 
is included RTC functionality if the SW is done correctly?

If one just needs to add some commands to a shutdown script for this to all 
work once the battery is added then its another justification in my report.

Am I off track?  Gerald, was your only issue with that the battery capacity 
between charges?  Is the SW just sending low level sleep commands to the 
CPU after kernel/OS has gone through some sleep or shut down process and 
I2C to the PMIC?

I haven't checked the power management chip docs or details of the AM355x 
to know the shutdown/sleep process for an RTC wake etc.

I'll look into it if I get one.

Fisher

On Tuesday, 8 July 2014 02:16:44 UTC+10, Gerald wrote:

 External RTC is the best solution. You could add a battery to the BBB and 
 use it with the right SW. But, depending on how many days you want it to 
 hold time, it may or may not work for you. 

 Gerald



 On Mon, Jul 7, 2014 at 11:04 AM, Fisher Grubb fisher...@gmail.com 
 javascript: wrote:

 Hi David,

 Yes, I have also seen small boards from Adafruit, though if I need an RTC 
 and it is possible to implement a fully functional one with the current 
 board by just adding a battery, I wouldn't add any extra components, 
 especially since the RTC in the CPU seems to have wake up events.

 I am doing a Masters project in control systems at university and am 
 hoping to either not have any external boards or at least very minimal.

 I will probably make my own board and won't add an RTC if I can implement 
 one with what is already on the BBB, especially as it may have more 
 features such as wake ups which a general I2C RTC won't have I don't think.

 Fisher


 On Tuesday, 8 July 2014 01:54:22 UTC+10, David Anders wrote:

 or just purchase a RTC Cape

 http://elinux.org/CircuitCo:RTC_Cape for $29.99MSRP


 On Friday, February 1, 2013 1:51:51 AM UTC-6, Alexander Holler wrote:

 Hello, 

 I've ust had a look at the specs for BeagleBone Black. 

 As usual, my first question was: Does it support RTC operation? 

 Having a first look at the schematics, it does not look like it is 
 possible to connect some coin battery or similiar to drive the 
 processor 
 in RTC only mode. Am I right and this another non-RTC design which 
 needs 
 an external RTC connected to I2C or similiar? 

 Regards, 

 Alexander 

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




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

[beagleboard] Re: Assessing BeableBone Black capabilities

2014-07-02 Thread Fisher Grubb 
, generate audio waveforms, decode video signals, sample sensors, etc... 
 the sky really is the limit. You can share memory with the main processor 
 and do complex computational tasks(eg computer vision) while having 
 realtime IO. All the information is available online, but it's all 
 scattered which makes the learning curve pretty steep. I'm working on a 
 beginner's guide to the PRU based on my own learning experience to 
 hopefully make it easier to get started.

 PWM seems to be 2 types: hi and low resolution, 3 of each to make 6 in 
 total.  The hi seems to have 2 outputs per unit, can they have separate 
 duty cycles?  I would like to control 6 separate motors.
 -TJF answered this. I'd add that you can also generate your own 
 high-resolution PWM using the handy PRU-ICSS.

 On Tuesday, July 1, 2014 1:03:36 AM UTC-7, Fisher Grubb wrote:

 Hi,

 My name is Fisher, I'm doing a Masters in control system research and 
 need to choose a controller board for my project.

 It will control a 6 wheel car (wild thumper) to keep a rod (inverted 
 pendulum) upright.

 I am looking to understand the BBB in more detail to know if I should 
 consider it or not.

 I will be using the controller board with Simulink from Mathworks in the 
 same way it can be used with RPi or Arduino.  I hope to control the 6 
 motors with PWM, read a few voltages with ADC, may be use some I2C and SPI 
 etc.

 The BBB may be a strong choice for me if I can use the 2 x IO processors 
 to do realtime stuff while the CPU does other things.


 I have a few questions, mainly how its used/programmed compared to the 
 Raspberry Pi as they can both run Debian Linux.

- Are there BBB python libraries for general things like PWM, ADC, 
I2C and other general IO like in RPi?
- How different is the BBB to use and program to RPi?
- The BBB seems to have 2 x IO processors in its  PRU-ICSS, I think 
they are 200MHz each, how easy is it to use them for inputs, outputs and 
calculations separate from the CPU?  Is there a kernel module?
- The PRU-ICSS does not really seem to be documented except for in a 
GIT project, the documents there seem to have info from Texas instruments 
(who make the CPU) but not official.  Is this subsystem used by others? 
 How?
- PWM seems to be 2 types: hi and low resolution, 3 of each to make 6 
in total.  The hi seems to have 2 outputs per unit, can they have 
 separate 
duty cycles?  I would like to control 6 separate motors.
- The BBB seems to have an 8 channel, 12 bit ADC
- Are any issues with the board such as can't use certain IO's at the 
same time, such as using 6 PWM outputs with 2 ADC, I2C or SPI?

 Here is the GIT project for the PRU that I have found, Ti seems to refer 
 to it as well, I think in a forum of theirs.

 https://github.com/beagleboard/am335x_pru_package

 To my knowledge, the BBB has:


- 1GHz ARM v8 32 bit CPU from Ti
- 3D GPU with max 720p through HDMI
- 2 x IO processors in the PRU-ICSS
- 3 hi resolution PWM (eHRPWM)
- 3 low resolution PWM (eCAP)
- Some quadrature encoder inputs


 I appreciate any input from anyone.

 Thanks,

 Fisher



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

[beagleboard] Assessing BeableBone Black capabilities

2014-07-01 Thread Fisher Grubb 
Hi,

My name is Fisher, I'm doing a Masters in control system research and need 
to choose a controller board for my project.

It will control a 6 wheel car (wild thumper) to keep a rod (inverted 
pendulum) upright.

I am looking to understand the BBB in more detail to know if I should 
consider it or not.

I will be using the controller board with Simulink from Mathworks in the 
same way it can be used with RPi or Arduino.  I hope to control the 6 
motors with PWM, read a few voltages with ADC, may be use some I2C and SPI 
etc.

The BBB may be a strong choice for me if I can use the 2 x IO processors to 
do realtime stuff while the CPU does other things.


I have a few questions, mainly how its used/programmed compared to the 
Raspberry Pi as they can both run Debian Linux.

   - Are there BBB python libraries for general things like PWM, ADC, I2C 
   and other general IO like in RPi?
   - How different is the BBB to use and program to RPi?
   - The BBB seems to have 2 x IO processors in its  PRU-ICSS, I think they 
   are 200MHz each, how easy is it to use them for inputs, outputs and 
   calculations separate from the CPU?  Is there a kernel module?
   - The PRU-ICSS does not really seem to be documented except for in a GIT 
   project, the documents there seem to have info from Texas instruments (who 
   make the CPU) but not official.  Is this subsystem used by others?  How?
   - PWM seems to be 2 types: hi and low resolution, 3 of each to make 6 in 
   total.  The hi seems to have 2 outputs per unit, can they have separate 
   duty cycles?  I would like to control 6 separate motors.
   - The BBB seems to have an 8 channel, 12 bit ADC
   - Are any issues with the board such as can't use certain IO's at the 
   same time, such as using 6 PWM outputs with 2 ADC, I2C or SPI?

Here is the GIT project for the PRU that I have found, Ti seems to refer to 
it as well, I think in a forum of theirs.

https://github.com/beagleboard/am335x_pru_package

To my knowledge, the BBB has:


   - 1GHz ARM v8 32 bit CPU from Ti
   - 3D GPU with max 720p through HDMI
   - 2 x IO processors in the PRU-ICSS
   - 3 hi resolution PWM (eHRPWM)
   - 3 low resolution PWM (eCAP)
   - Some quadrature encoder inputs


I appreciate any input from anyone.

Thanks,

Fisher

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