Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[Soapy Smith]

Hi William, one note on CCS.  I haven't used it at all.  The 
compiler/assembler (clpru) and associated includes and libraries are 
present in the Beaglebone testing image (Debian 8, version 4 kernel).
I had to tweak add a symbolic link for the clpru, but that's it.  After 
that, the Makefiles included in the labs worked perfectly.  All done at the 
command line.  No CCS IDE required.
I wasn't excited about CCS either, but then I discovered the clpru stuff 
and no problems.

On Wednesday, February 10, 2016 at 9:19:12 PM UTC-5, William Hermans wrote:
>
> *Hi William, please see the above.  I have the PRU Cape, but I haven't got 
>> this far in the labs.  The other labs with remoteproc and other associated 
>> modules works so far.*
>>
>
> Hi Soapy,
>
> Thanks, but I have been aware of that guide for some time now. The 
> example, blinks a PRU cape LED, not one of the USR leds on beaglebone. 
> That's problem #1( not everyone wants to buy yet more hardware to explore 
> an experimental concept). 
>
> Problem #2 the guide is based on code composer studio. If you can not see 
> the problem with that, then chances are I will probably never convince you 
> it is a problem. For many of us though, a requirement of using CCS is a 
> major problem.
>
> Problem #3, there is no in depth code explanation, just setup "do x.y.z 
> exact steps", and thats it. So, for me, no code explanation is not really 
> the problem. The problem is no one bothers explaining how the rpmsg 
> mechanism works in conjunction with our specific hardware. That is to say, 
> many of us already know how the hardware works, but how do "WE" control the 
> hardware through this software ? 1 or 2 *good* examples would go a very 
> long ways here.
>
> Problem #4, as ybeagle3 mentions above, performance. If we're wanting to 
> use a PRU or two, chances are pretty good we want / need performance. 
> Granted, there are probably ways to tweak rpmsg, but at some point one has 
> to wonder why even bother.
>
> Problem #5, and possibly the biggest turn off for me aside from very 
> little documentation. This software is experimental, incomplete, and has no 
> proven track record. Which means, no one knows how stable the software is 
> right now. Anyone saying they know if full of it. While on the other hand, 
> the UIO PRU based software has been around a good long time, is proven, and 
> is probably in many commercial grade applications. Not to mention 
> scientific applications, etc.
>
> Anyway, I still think remoteproc / rpmsg is a really cool idea - In 
> concept. In reality though it has a very long ways to go, and no telling if 
> it will ever make it passed the experimental stage. Then if it does, how 
> long will it take ? 
>
> Another thing. This hardware( beaglebone ) is an open sourced design. So 
> who in their right mind thought it would be a good idea to demonstrate such 
> a cool idea using a closed source toolchain / toolset ? Oh, right. The same 
> company who says they do not support the PRU's to begin with . . .
>
> Do also keep in mind, that I actualy am PRO TI . . .
>
>
>

-- 
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] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[Soapy Smith]

http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_6:_Blinking_LEDs_with_RPMsg_from_Linux_User_Space

Hi William, please see the above.  I have the PRU Cape, but I haven't got 
this far in the labs.  The other labs with remoteproc and other associated 
modules works so far.

Regards,
Greg

On Wednesday, February 10, 2016 at 7:25:27 PM UTC-5, William Hermans wrote:
>
> *William, what are you talking about? Why would I take what you say 
>> personally? You make these blanket statements about a technology you say 
>> you don’t know how to use and recommend that everyone else not use this 
>> technology. If you want to stay with a dead technology, that is your call, 
>> but there is no reason for anyone to stay away from RemoteProc/RPMSG. 
>> Manufacturers other than TI have embraced this technology which open up a 
>> range of cores you can interact with, such as DSP, CortexM4, PRU, etc. Yes, 
>> I know you told me you have no interest in the x15 so this is probably not 
>> important to you and I respect that. *
>>
>
> So, using something consistent , that is well documented, and has been 
> proven to work over the last several years does not make it "dead tech". It 
> makes it something that actually works for many people. No one cares what 
> TI adopts, except perhaps you, and TI. People care what works, with the 
> least amount of resistance.
>
> So hey lets put the squash on this right now. Why don't you write us some 
> code in the next day or two that blinks the USR leds in some kind of 
> pattern that proves the remoteproc / rpmsg is actually functional / usable. 
> As no one cares if you can write 100 "hello world " messages into 
> /var/log/messages . . . I can do that with a bash script and no PRU . . .
>
> You do that, and I'll concede that remoteproc is at least semi useful.
>
>
> On Wed, Feb 10, 2016 at 4:57 PM, John Syne  > wrote:
>
>> William, what are you talking about? Why would I take what you say 
>> personally? You make these blanket statements about a technology you say 
>> you don’t know how to use and recommend that everyone else not use this 
>> technology. If you want to stay with a dead technology, that is your call, 
>> but there is no reason for anyone to stay away from RemoteProc/RPMSG. 
>> Manufacturers other than TI have embraced this technology which open up a 
>> range of cores you can interact with, such as DSP, CortexM4, PRU, etc. Yes, 
>> I know you told me you have no interest in the x15 so this is probably not 
>> important to you and I respect that. 
>>
>> Soapy, I use the drivers from Starterware and adapt them to work on the 
>> PRU, so I always use the C compiler. There is a github repo were several of 
>> the Starterware drivers have been ported to the PRU. This will save you a 
>> bunch of time. 
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 10, 2016, at 2:47 PM, William Hermans > > wrote:
>>
>> Hi Soapy,
>>
>> Yeah John always seems to take things personally, or out of context. I 
>> have no problem what so ever with anyone using whatever they want. 
>> Including the OP. My comment were merely to point out that remoteproc / 
>> rpmsg are not finished, have known issues, and are a pain in the backside 
>> to initially get working.
>>
>> So for someone using prussdrv, it is probably a bad idea to even start 
>> thinking about using remoteproc / rpmsg. Unless they're just experimenting 
>> . . . where then it could be a good learning experience I suppose. Me . . . 
>> I'd rather something were fully functional and well documented before I 
>> invest my time into it. remoteproc is neither of these.
>>
>> On Wed, Feb 10, 2016 at 3:42 PM, Soapy Smith > > wrote:
>>
>>> remoteproc definitely has some bad behavior.  But what I am doing is 
>>> just as experimental, and no motors (all data transfer) involved.
>>>
>>> What is currently considered a reliable methodology for getting the most 
>>> out of the PRUs?
>>> Also, what about C versus assembler?  Will C alone suffice, or is there 
>>> real need to do some assembler?
>>> I've found that there are actually two different assemblers, the older 
>>> pasm (apparently no longer supported), and the assembler part of clpru.
>>> If you are just starting out in PRU work, should pasm even be considered?
>>>
>>> Regards,
>>> Greg
>>>
>>> On Wednesday, February 10, 2016 at 4:49:49 PM UTC-5, William Hermans 
>>> wrote:
>>>>
>>>> I would rec

Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[Soapy Smith]

Hi John, are you referring to the modules/drivers:

pruss_remoteproc.ko
virtio_rpmsg_bus.ko
rpmsg_pru.ko

The above plus some examples are already loaded and built in the latest 
"testing" images which use kernel 4.
pruss_remoteproc is showing up in lsmod without doing anything at all.  The 
Debian 8.3 based distro boots up with pruss_remoteproc inserted.

If you are referring to something different or in addition to the above, 
could you please post an example link to github?

Regards,
Greg

On Wednesday, February 10, 2016 at 6:57:37 PM UTC-5, john3909 wrote
>
>
> Soapy, I use the drivers from Starterware and adapt them to work on the 
> PRU, so I always use the C compiler. There is a github repo were several of 
> the Starterware drivers have been ported to the PRU. This will save you a 
> bunch of time. 
>
> Regards,
> John
>
>

-- 
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: Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[Soapy Smith]

remoteproc definitely has some bad behavior.  But what I am doing is just 
as experimental, and no motors (all data transfer) involved.

What is currently considered a reliable methodology for getting the most 
out of the PRUs?
Also, what about C versus assembler?  Will C alone suffice, or is there 
real need to do some assembler?
I've found that there are actually two different assemblers, the older pasm 
(apparently no longer supported), and the assembler part of clpru.
If you are just starting out in PRU work, should pasm even be considered?

Regards,
Greg

On Wednesday, February 10, 2016 at 4:49:49 PM UTC-5, William Hermans wrote:
>
> I would recommend staying away from remoteproc and rpmsg at least until 
> it's out of experimental.
>
>
>

-- 
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: Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[Soapy Smith]

Bill, I have been studying this myself, it is complex, and the learning 
curve looks to be pretty steep to a newbie embedded programmer.
Here's as clear of an explanation as I have been able to find:

http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg

>
I've got the PRU Cape and that combined with the Debian distro and version 
4 kernel it is pretty easy to run the example code using the kernel driver. 
 Understanding what is going on is another story.  If you go to 
exploringbeaglebone.com and look in the chapter "Extra Content Linux Kernel 
Programming" there are 3 articles which guide you through the workings of 
kernel drivers.

Regards,
Greg

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

[beagleboard] Re: Using GPIO pins and scratchpad of the PRU with C

[Soapy Smith]

OK, I see they extended the C language for R30 and R31!

I haven't found any good examples were C and assembler are mixed.  I have 
seen statements which say there are multiple ways to accomplish it.
It looks like the simplest is to inject assembler code directly into the C 
code.  See page 76.  There is also a section on "Intrinsics" on page 89.  I 
think that might be what you are looking for.

On Tuesday, February 9, 2016 at 7:56:44 AM UTC-5, lucas wrote:
>
> Ah, thank you. These are excellent resources. I think I found the answer 
> to my first question in the PRU Optimizing C/C++ Compiler v2.1 User Guide:
>
> Section: 5.7.2 Global Register Variables
>
> The C/C++ compiler extends the C language by adding a special convention 
>> to the register storage class specifier to allow the allocation of global 
>> registers. This special global declaration has the form: register type 
>> regid The regid parameter can be __R30 and __R31. The identifiers _ _R30 
>> and _ _R31 are each bound to their corresponding register R30 and R31, 
>> respectively. These are control registers and should always be declared as 
>> volatile. 
>
>
> I am still a bit uncertain about the scratch pad. I have a value stored in 
> a C variable, but how could I copy that value into inline assembler - so 
> that I can write it to the scratch pad?
>
>
>
> On Tuesday, February 9, 2016 at 1:37:14 PM UTC+1, Soapy Smith wrote:
>>
>> There is a manual for the C compiler and the assembler:
>>
>> http://processors.wiki.ti.com/index.php/PRU-ICSS
>>
>> The links are on the right side of the page.
>>
>> Some of the PRU hardware specific registers are accessed via a large 
>> union in a header file.  It uses structs with "bit fields" so you can 
>> easily access individual bits in the register.
>> Look for a header file called pru_cfg.h.  But specifically to your 
>> question, I'm still trying to figure out how the PRU input and output 
>> registers R30 and R31 are done in C, as I
>> don't see those called out in the header file (in information overload at 
>> this point!).
>>
>> Regarding the scratchpad, I believe it can't be accessed via C.  However, 
>> you can embed assembler codes into C source code.
>> If you go here:
>>
>>
>> https://training.ti.com/sitara-processors-building-blocks-for-pru-development-summary
>>
>> Download the firmware development slides and look at page 8.
>>
>> Regards,
>> Greg
>>
>>

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

[beagleboard] Re: Using GPIO pins and scratchpad of the PRU with C

[Soapy Smith]

There is a manual for the C compiler and the assembler:

http://processors.wiki.ti.com/index.php/PRU-ICSS

The links are on the right side of the page.

Some of the PRU hardware specific registers are accessed via a large union 
in a header file.  It uses structs with "bit fields" so you can easily 
access individual bits in the register.
Look for a header file called pru_cfg.h.  But specifically to your 
question, I'm still trying to figure out how the PRU input and output 
registers R30 and R31 are done in C, as I
don't see those called out in the header file (in information overload at 
this point!).

Regarding the scratchpad, I believe it can't be accessed via C.  However, 
you can embed assembler codes into C source code.
If you go here:

https://training.ti.com/sitara-processors-building-blocks-for-pru-development-summary

Download the firmware development slides and look at page 8.

Regards,
Greg

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

[beagleboard] Re: Will the webcast "Taking the BeagleBone Cookbook recipes beyond BeagleBone Black" be available?

[Soapy Smith]

There is a 2-layer sign-in process, first you need an O'Reilly account, 
then you have to register for the webcast.

It's essentially a 1.5 hour long info-mercial for both Beagleboard.org and 
"Beaglebone Cookbook" with the two authors of the book discussing numerous 
Beagleboard topics.

It's really good.  What I got out of it is a better understanding of the 
history and motivation for Beagleboard.org.
It's really starting to branch out and you will see where they are headed 
with this technology.

Starting about 80 minutes in there is a discussion of the Device Tree and 
how it relates to "mainline Linux".  Worth a listen!

I watched using Firefox in Ubuntu 14.04.  O'Reilly's media player is one of 
the best I have seen.  There is a row of icons at the bottom you can use to 
control the session.
Very informative presentation by authors Mark Yoder and Jason Kridner!

-- 
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: Cape manager on linux 4.1: can't load bone_eqep2b cape

[Soapy Smith]

# grep part-number bone_eqep2-00A0.dts
part-number = "bone_eqep2";
# grep part-number bone_eqep2b.dts
part-number = "bone_eqep2";

The source files for eqep2 and eqep2b both have the same part number?
The dts files are in 

/opt/source/bb.org-overlays/src/arm



>

-- 
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: Cannot install minicom with Jessie 8.3 lxqt

[Soapy Smith]

I think there is a conflict you can see in the dts files for 
"exclusive-use", P9.26.
Not sure, but I think this will cause the IO error message.
The dts files are in /opt/source/bb.org-overlays/src/arm.

cape-universaln:
"P9.26",

BB-UART1:
exclusive-use =
"P9.24", // uart1_txd
"P9.26", // uart1_rxd


>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln
>
>  The instructions only show entries 0 to 3.  I type:
>  
>  sh -c "echo 'BB-UART1' > /sys/devices/platform/bone_capemgr/slots"
>  
>  and I get:
>  
>  sh: echo: I/O error
>
>  Can you tell me what I am doing wrong?
>  
>  Thanks.
>  
>
>
>

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

Re: [beagleboard] SPI Overlay not changing states BBB 4.1.15-ti-r43 Debian Image 2015-11-12

[Soapy Smith]

I did some experiments and see what appears to be serious errors in dmesg. 
 (not experienced in reading these).

I boot, and then look at slots:
0: PF  -1 
 1: PF  -1 
 2: PF  -1 
 3: PF  -1 
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,univ-emmc

This is normal.  I'm using a slightly modified version of univ-emmc to 
connect PRUs.
This works as expected.  I had not tried additional changes to the slots 
until now.
Remove slot 4:
# echo -4 > slots
cat slots 
 0: PF  -1 
 1: PF  -1 
 2: PF  -1 
 3: PF  -1 

All looks good to this point.  Now add a different dtbo:
# echo cape-universal > slots

Now the ssh connection to the board closes.
But it's not a hard crash, I can ssh back in.  From dmesg:
[  287.654746] Unable to handle kernel NULL pointer dereference at virtual 
address 0004
That is at least one problem, I think there are more.

I'm sure there are plenty of other clues.  dmesg is pretty long, so I 
attached a file.
I'm using 4.1.15-ti-rt-r43 on a Beaglebone Black.

Greg


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) 
(gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 
UTC 2016
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine model: TI AM335x BeagleBone Black
[0.00] cma: Reserved 24 MiB at 0x9e00
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 130560
[0.00] free_area_init_node: node 0, pgdat c0c19b00, node_mem_map 
df96d000
[0.00]   Normal zone: 1152 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 130560 pages, LIFO batch:31
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES2.1 (sgx neon )
[0.00] PERCPU: Embedded 13 pages/cpu @df91 s24128 r8192 d20928 
u53248
[0.00] pcpu-alloc: s24128 r8192 d20928 u53248 alloc=13*4096
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 129408
[0.00] Kernel command line: console=ttyO0,115200n8 
root=UUID=bf6d4cec-84ce-40ee-b81b-cd2860ffc4b0 ro rootfstype=ext4 rootwait 
coherent_pool=1M quiet cape_universal=enable
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Memory: 474228K/522240K available (7201K kernel code, 935K 
rwdata, 3764K rodata, 560K init, 954K bss, 23436K reserved, 24576K 
cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xffc0 - 0xfff0   (3072 kB)
vmalloc : 0xe080 - 0xff00   ( 488 MB)
lowmem  : 0xc000 - 0xe000   ( 512 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf80 - 0xbfe0   (   6 MB)
  .text : 0xc0008000 - 0xc0abd7bc   (10966 kB)
  .init : 0xc0abe000 - 0xc0b4a000   ( 560 kB)
  .data : 0xc0b4a000 - 0xc0c33f2c   ( 936 kB)
   .bss : 0xc0c36000 - 0xc0d249a0   ( 955 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 
interrupts
[0.00] OMAP clockevent source: timer2 at 2400 Hz
[0.12] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 
89478484971ns
[0.24] clocksource timer1: mask: 0x max_cycles: 0x, 
max_idle_ns: 79635851949 ns
[0.32] OMAP clocksource: timer1 at 2400 Hz
[0.000223] Console: colour dummy device 80x30
[0.000385] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[0.000388] This ensures that you still see kernel messages. Please
[0.000391] update your kernel commandline.
[0.088944] Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
[0.088950] pid_max: default: 32768 minimum: 301
[0.089090] Security Framework initialized
[0.089158] AppArmor: A

Re: [beagleboard] Does apt-get upgrade not update BoneScript?

[Soapy Smith]

Hi Wally-

I've run into a similar problem whereby I downloaded the "Recommended" 
image from the beagleboard.org webpage,
only to find that "Recommended" is not necessarily the same as "good" or 
"working".
Linux seems to change and move quickly.

For the cost of a microSD card and a few minutes of experimentation, you 
could try an image from here:

https://rcn-ee.com/rootfs/bb.org/testing/

I having good success (I'm not using Bonescript) with images in the 
2016-01-24 folder.
Get the regular (not the flasher) image and you are ready to test.
One thing thing I have had problems with with these testing images is 
unreliable USB network connection.  I'm transitioning to LAN anyway and 
that works great.

Regards,
Greg

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

[beagleboard] Re: Will the webcast "Taking the BeagleBone Cookbook recipes beyond BeagleBone Black" be available?

[Soapy Smith]

>
> I missed the webcast as well.  I'm not sure if it will show up here, but 
> it looks like the newest video is 2 days old:
>

 https://www.youtube.com/user/OreillyMedia/videos

So maybe in the next few days the recording will appear.

Regarding the BBG, one thing for sure the chip that does HDMI is not there. 
 No video.

Regards,
Greg

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

Re: [beagleboard] Using Universal IO to set pullup/pulldown on a PRU input

[Soapy Smith]

After a large dose of confusion, I got it figured out.

I'm using the univ-emmc blob on a Beaglebone Black.
I found the pin entries in the dts file, and changed the value from 0x26 to 
0x2e.
Now when I use config-pin P9_27 pruin, for example, the resistor is 
disengaged.
I'm using the -f option and a file to set pin configurations as required. 
 Very convenient!

This was the last piece of the puzzle in getting demo code running with 
TI's PRU Cape and remoteproc.
The schematic of the cape has a resistor network connected to a switch, and 
the pull-down was loading
the cape's network and not allowing the voltage to exceed threshold.

The help and the universal IO is very much appreciated!

Regards,
Greg


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

[beagleboard] Using Universal IO to set pullup/pulldown on a PRU input

[Soapy Smith]

I can set a PRU input as follows:

config-pin P9_27 pruin

However, I need to control the pullup/pulldown resistor as well.
This can be done when the pin is in GPIO mode.
How is this controlled in pruin mode?

Regards,
Greg

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

[beagleboard] Re: How to use current universal cape device tree and ADC at the same time

[Soapy Smith]

>
> I don't see any difference.  When I use the command git pull, the command 
> line response is "Already up-to-date.".
>
 
I had already removed the bb.org-overlays directory and git cloned from
 git clone https://github.com/beagleboard/bb.org-overlays

After ./install.sh, I see the same dtbo files in /lib/firmware.

Are you sure "git pull" is all that is required?

Another question I have on this overlay system:  What determines the 
overlay which is loaded at boot?
Is there another influence besides the uEnv.txt file?
A cape board can have an EEPROM which describes the overlay to apply.
I know there is also an EEPROM on the BBB as well.  Does this one also 
contain a default overlay which
is loaded in the case of no cape?

Regards,
Greg
 

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

[beagleboard] Re: How to use current universal cape device tree and ADC at the same time

[Soapy Smith]

Hi Niv-

I've been looking at the kernel 4 implementation of device trees today.
Here are a couple of things which may help.

cd to this directory:

/sys/devices/platform/ocp/ocp:cape-universal

ls and you should see a file called status.
cat status

This should give you a listing of the currently enabled GPIOs.
"ocp" means "on chip peripheral".  A GPIO is one of several types of ocp.

Here is the first few lines of what I see on my BBB:
 0 P9_92114 IN  0
 1 P9_42  7 IN  0
 2 P9_91116 IN  0
 3 P9_30112 IN  0
 4 P9_27115 IN  0
 5 P9_26 14 IN  0
 6 P9_24 15 IN  0
 7 P9_23 49 IN  0
 8 P9_22  2 IN  0
 9 P9_21  3 IN  0

This continues on and shows GPIOs enabled on the P8 header as well.
So just taking an example P9_27:

config-pin -q P9_27
P9_27 Mode: default Direction: in Value: 0

The command runs successfully.
Now, try the command on a pin which is not listed in the status file:
config-pin -q P9_28
P9_28 pinmux file not found!
cape-universala overlay not found
run "config-pin overlay cape-universala" to load the cape

So I reproduce the a similar result as what you see for P8_43.
There is no overlay cape-universala being compiled by Robert's script.
The command config-pin was written by another person and is described here:
https://github.com/cdsteinkuehler/beaglebone-universal-io

I suspect the error message being emitted by config-pin needs to be updated.
Otherwise, the first part of the error message is correct in that the GPIO 
is not active on the pin.

The pin you need as a GPIO P8_43 needs to be designated as such by the 
overlay file.
Now, the question is, does one of the existing overlay files have this pin 
designated as GPIO?

Regards,
Greg

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

Re: [beagleboard] I can't access 192.168.7.2 after flashing Debian 8.2 to eMMC.

[Soapy Smith]

I am very confused, is that not one of the

Recommended Debian Images

at the very top of the beagleboard.org web page???

http://beagleboard.org/latest-images

On Monday, January 25, 2016 at 9:06:27 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Jan 25, 2016 at 6:17 PM,  > 
> wrote: 
> > 
> > I can't access 192.168.7.2 after flashing Debian 8.2 to eMMC. 
> > How do I enable it? 
> > I loaded up the latest image to an SD card. 
> > Runs great when booted from SD card, both E:\ and 192.168.7.2 methods 
> work. 
> > Edited /boot/uEnv.txt to enable flash 
> > Flashed to eMMC. 
> > Boots fine, I get the FAT partition on host PC (Windows 7 Pro). 
> > But I no longer have 192.168.7.2. 
> > Reboot with a virgin image on SD card and I get ethernet over usb again. 
> > Reflash with flashing image and same bum result. 
> > Debian 8.2 (BeagleBone, BeagleBone Black, Seeed BeagleBone Green, Arrow 
> > BeagleBone Black Industrial - 2GB SD) 2015-11-12 
>
> That image is broken, use a known good snapshot: 
>
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

Re: [beagleboard] I can't access 192.168.7.2 after flashing Debian 8.2 to eMMC.

[Soapy Smith]

I'm very very confused, is that the one of the official working

Recommended Debian Images


On Monday, January 25, 2016 at 9:06:27 PM UTC-5, RobertCNelson wrote:
>
> > Debian 8.2 (BeagleBone, BeagleBone Black, Seeed BeagleBone Green, Arrow 
> > BeagleBone Black Industrial - 2GB SD) 2015-11-12 
>
> That image is broken, use a known good snapshot: 
>
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

Re: [beagleboard] Re: Cannot access beaglebones?

[Soapy Smith]

My mistake, I wasn't clear at all.  Allow me to restate...

There is one line return after issuing the command sudo dhclient eth2, and 
then the shell locks up.
There is no message returned.  Only a blinking cursor and nothing further 
happens.
Let's see if I can paste in what it looks like:

user@host:~$ sudo dhclient eth2
(blinking cursor here)

On Monday, January 25, 2016 at 1:45:40 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Jan 25, 2016 at 12:42 PM, Soapy Smith  > wrote: 
> > sudo dhclient eth2  (or whatever is obviously the BBG from looking at 
> > ifconfig) 
> > 
> > There is one line return and then nothing happens (after entering 
> password 
> > due to sudo). 
>
> "nothing happens"...  on success, yes "nothing happens".. 
>
>

-- 
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: Cannot access beaglebones?

[Soapy Smith]

sudo dhclient eth2  (or whatever is obviously the BBG from looking at 
ifconfig)

There is one line return and then nothing happens (after entering password 
due to sudo).

On a healthy board, at the first "sudo dhclient ethX", there is a quick 
line feed and no messages.
The second time, I get
RTNETLINK answers: File exists

On Monday, January 25, 2016 at 1:15:33 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Jan 25, 2016 at 12:05 PM, Soapy Smith  > wrote: 
> > I've always seen marginal success in USB connectivity with BBB.  I 
> recently 
> > acquired a couple of BBG, at first I thought these were solid, but now I 
> am 
> > seeing problems. 
> > 
> > There is a difference seen in the host computer from the shell command 
> > ifconfig -a. 
> > Here is ifconfig -a for a working BBG: 
> > 
> > eth0  Link encap:Ethernet  HWaddr 6c:0b:84:09:f9:de 
> >   inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0 
> >   inet6 addr: fe80::6e0b:84ff:fe09:f9de/64 Scope:Link 
> >   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
> >   RX packets:982290 errors:0 dropped:0 overruns:0 frame:0 
> >   TX packets:613548 errors:0 dropped:0 overruns:0 carrier:0 
> >   collisions:0 txqueuelen:1000 
> >   RX bytes:1196203986 (1.1 GB)  TX bytes:107826806 (107.8 MB) 
> >   Interrupt:20 Memory:f710-f712 
> > 
> > eth1  Link encap:Ethernet  HWaddr ec:24:b8:f6:e1:7c 
> >   inet addr:192.168.7.1  Bcast:192.168.7.255  Mask:255.255.255.0 
> >   inet6 addr: fe80::ee24:b8ff:fef6:e17c/64 Scope:Link 
> >   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
> >   RX packets:64 errors:0 dropped:0 overruns:0 frame:0 
> >   TX packets:63 errors:0 dropped:0 overruns:0 carrier:0 
> >   collisions:0 txqueuelen:1000 
> >   RX bytes:10319 (10.3 KB)  TX bytes:15361 (15.3 KB) 
> > 
> > loLink encap:Local Loopback 
> >   inet addr:127.0.0.1  Mask:255.0.0.0 
> >   inet6 addr: ::1/128 Scope:Host 
> >   UP LOOPBACK RUNNING  MTU:65536  Metric:1 
> >   RX packets:30214 errors:0 dropped:0 overruns:0 frame:0 
> >   TX packets:30214 errors:0 dropped:0 overruns:0 carrier:0 
> >   collisions:0 txqueuelen:0 
> >   RX bytes:3210722 (3.2 MB)  TX bytes:3210722 (3.2 MB) 
> > 
> > Now here is a different BBG flashed with the exact same image Debian 
> 8.2: 
> > eth0  Link encap:Ethernet  HWaddr 6c:0b:84:09:f9:de 
> >   inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0 
> >   inet6 addr: fe80::6e0b:84ff:fe09:f9de/64 Scope:Link 
> >   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
> >   RX packets:982671 errors:0 dropped:0 overruns:0 frame:0 
> >   TX packets:613978 errors:0 dropped:0 overruns:0 carrier:0 
> >   collisions:0 txqueuelen:1000 
> >   RX bytes:1196254756 (1.1 GB)  TX bytes:107922637 (107.9 MB) 
> >   Interrupt:20 Memory:f710-f712 
> > 
> > eth4  Link encap:Ethernet  HWaddr 68:c9:0b:ed:25:23 
> >   inet6 addr: fe80::6ac9:bff:feed:2523/64 Scope:Link 
> >   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
> >   RX packets:42 errors:0 dropped:0 overruns:0 frame:0 
> >   TX packets:52 errors:0 dropped:0 overruns:0 carrier:0 
> >   collisions:0 txqueuelen:1000 
> >   RX bytes:6487 (6.4 KB)  TX bytes:12510 (12.5 KB) 
> > 
> > loLink encap:Local Loopback 
> >   inet addr:127.0.0.1  Mask:255.0.0.0 
> >   inet6 addr: ::1/128 Scope:Host 
> >   UP LOOPBACK RUNNING  MTU:65536  Metric:1 
> >   RX packets:30316 errors:0 dropped:0 overruns:0 frame:0 
> >   TX packets:30316 errors:0 dropped:0 overruns:0 carrier:0 
> >   collisions:0 txqueuelen:0 
> >   RX bytes:3218638 (3.2 MB)  TX bytes:3218638 (3.2 MB) 
> > 
> > The obvious difference is seen at eth4 for the non-working versus eth1 
> for 
> > the working board. 
> > eth1 (the working board) is getting an inet address. 
> > eth4 (the non-working board) is not getting an inet address. 
>
> how about "sudo dhclient eth4" ? 
>
> ps.. the "eth1" vs "eth4" is a udev issue that "you" need to fix on your 
> host*.. 
>
> The BBG (on the other end of the usb cable) can't tell your host how 
> to name it. (ethX).. 
>
> * /etc/udev/rules.d/70-persistent-net.rules 
>
> So your first BBG will get eth1, second eth2, third eth3, etc... 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

[beagleboard] Re: Cannot access beaglebones?

[Soapy Smith]

I've always seen marginal success in USB connectivity with BBB.  I recently 
acquired a couple of BBG, at first I thought these were solid, but now I am 
seeing problems.

There is a difference seen in the host computer from the shell command 
ifconfig -a.
Here is ifconfig -a for a working BBG:

eth0  Link encap:Ethernet  HWaddr 6c:0b:84:09:f9:de  
  inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fe80::6e0b:84ff:fe09:f9de/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:982290 errors:0 dropped:0 overruns:0 frame:0
  TX packets:613548 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:1196203986 (1.1 GB)  TX bytes:107826806 (107.8 MB)
  Interrupt:20 Memory:f710-f712 

eth1  Link encap:Ethernet  HWaddr ec:24:b8:f6:e1:7c  
  inet addr:192.168.7.1  Bcast:192.168.7.255  Mask:255.255.255.0
  inet6 addr: fe80::ee24:b8ff:fef6:e17c/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:64 errors:0 dropped:0 overruns:0 frame:0
  TX packets:63 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:10319 (10.3 KB)  TX bytes:15361 (15.3 KB)

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

Now here is a different BBG flashed with the exact same image Debian 8.2:
eth0  Link encap:Ethernet  HWaddr 6c:0b:84:09:f9:de  
  inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fe80::6e0b:84ff:fe09:f9de/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:982671 errors:0 dropped:0 overruns:0 frame:0
  TX packets:613978 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:1196254756 (1.1 GB)  TX bytes:107922637 (107.9 MB)
  Interrupt:20 Memory:f710-f712 

eth4  Link encap:Ethernet  HWaddr 68:c9:0b:ed:25:23  
  inet6 addr: fe80::6ac9:bff:feed:2523/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:42 errors:0 dropped:0 overruns:0 frame:0
  TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:6487 (6.4 KB)  TX bytes:12510 (12.5 KB)

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

The obvious difference is seen at eth4 for the non-working versus eth1 for 
the working board.
eth1 (the working board) is getting an inet address.
eth4 (the non-working board) is not getting an inet address.

The BBG which does not connect will keep trying over and over.
I am using Ubuntu 14.04.

Regards,
Greg



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

Re: [beagleboard] Re: Is BoneScript more trouble than its worth?

[Soapy Smith]

Found your github 
repository: https://github.com/cdsteinkuehler/beaglebone-universal-io

Awesome!  Much appreciated.

Greg

On Saturday, January 23, 2016 at 9:49:26 AM UTC-5, Charles Steinkuehler 
wrote:
>
> For 3.8 kernels it's "bone-pinmux-helper", found in: 
>
> ./drivers/misc/cape/beaglebone/bone-pinmux-helper.c 
>
> ...in the kernel source tree. 
>
> On 1/23/2016 8:16 AM, Soapy Smith wrote: 
> > What is the name of the kernel module? 
> > Has this been deployed in the Debian 8.2 release? 
> > I've been poking around in 8.2, and there are interesting differences 
> > compared to 7.9. 
> > 
> > A bash script run after boot can set up the pins? 
> > 
> > On Friday, January 22, 2016 at 5:48:25 PM UTC-5, Charles Steinkuehler 
> wrote: 
> >> 
> >> "pinmux helper" is a kernel module that exports control of the pinmux 
> >> settings to the sysfs filesystem where they can be manipulated by 
> >> user-mode programs after boot.  This helper module is used extensively 
> >> by the "universal" cape I created which enables most of the AM335x 
> >> hardware modules and allows run-time switching of the pinmux values 
> >> (via the pinmux helper) to select the desired pin function. 
> >> 
> >> On 1/22/2016 4:38 PM, Soapy Smith wrote: 
> >>> What is a "pinmux helper"? 
> >>> 
> >>> On Friday, January 22, 2016 at 5:32:19 PM UTC-5, Jason Kridner wrote: 
> >>>> 
> >>>> The examples in http://beagleboard.org/cookbook have all be tested 
> to 
> >>>> work. Handling of corner cases is a bit wonky in 0.2.5, but I'm 
> hopeful 
> >>>> that moving to the 4.1 kernel and using pinmux helpers rather than 
> >>>> dynamically creating device trees will reduce the complexity for 
> >> newbies. 
> >>>> That work is starting now. 
> >> 
> >> -- 
> >> Charles Steinkuehler 
> >> cha...@steinkuehler.net  
> >> 
> > 
>
>
> -- 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is BoneScript more trouble than its worth?

[Soapy Smith]

What is the name of the kernel module?
Has this been deployed in the Debian 8.2 release?
I've been poking around in 8.2, and there are interesting differences 
compared to 7.9.

A bash script run after boot can set up the pins?

On Friday, January 22, 2016 at 5:48:25 PM UTC-5, Charles Steinkuehler wrote:
>
> "pinmux helper" is a kernel module that exports control of the pinmux 
> settings to the sysfs filesystem where they can be manipulated by 
> user-mode programs after boot.  This helper module is used extensively 
> by the "universal" cape I created which enables most of the AM335x 
> hardware modules and allows run-time switching of the pinmux values 
> (via the pinmux helper) to select the desired pin function. 
>
> On 1/22/2016 4:38 PM, Soapy Smith wrote: 
> > What is a "pinmux helper"? 
> > 
> > On Friday, January 22, 2016 at 5:32:19 PM UTC-5, Jason Kridner wrote: 
> >> 
> >> The examples in http://beagleboard.org/cookbook have all be tested to 
> >> work. Handling of corner cases is a bit wonky in 0.2.5, but I'm hopeful 
> >> that moving to the 4.1 kernel and using pinmux helpers rather than 
> >> dynamically creating device trees will reduce the complexity for 
> newbies. 
> >> That work is starting now. 
>
> -- 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is BoneScript more trouble than its worth?

[Soapy Smith]

What is a "pinmux helper"?

On Friday, January 22, 2016 at 5:32:19 PM UTC-5, Jason Kridner wrote:
>
> The examples in http://beagleboard.org/cookbook have all be tested to 
> work. Handling of corner cases is a bit wonky in 0.2.5, but I'm hopeful 
> that moving to the 4.1 kernel and using pinmux helpers rather than 
> dynamically creating device trees will reduce the complexity for newbies. 
> That work is starting now.
>
>
>>
>>

-- 
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: Is BoneScript more trouble than its worth?

[Soapy Smith]

>
> I was initially very enthusiastic about Bonescript when I first started 
> with the BBB.
>
It should be a good starting point for a beginner, assuming it all works!

One of the concerns I eventually realized was the potential timing problems 
with Javascript based embedded devices.
It's a function of how the language works.

After I got the book "Exploring Beaglebone" by Derek Molloy, I've abandoned 
Bonescript for C/C++.
The trade-off is a large learning curve required for the language(s) and 
associated tool chains.
I think it is inevitable if you want to get the most power from the BBB you 
will need to go in this direction.

Greg 

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

[beagleboard] Re: bone_capemgr.* - no such file or directory (Debian 8.2 2015-11-12)

[Soapy Smith]

The cape management scheme looks to be very different in Jessie/Debian 8.2.
Also the kernel modules are different than Wheezy/Debian 7.9.
Is there an explanation online which explains the changes?
Any tips/pointers on how to track these kinds of changes would be very 
appreciated.

I'm specifically interested in module pruss_remoteproc.
I've been struggling to get the pru cape to work; I think this might help 
me move forward having this already set up in Jessie/Debian 8.2,
that is, if I can find the information on what is going on with this.

Regards,
Greg


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

[beagleboard] Re: robustness BBB

[Soapy Smith]

I can't answer the question, however, are you aware of the industrial BBB 
from Special Computing:

http://specialcomp.com/beaglebone/

Look at 22911.  At least it covers your required temperature range.

-- 
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: BBB SPI: 6 cs signals needed

[Soapy Smith]

>
> Exploring Beaglebone Chapter 8 
>

I can't recommend this book highly enough.  There is a section in Chapter 8 
which shows how to get more CS controls using the GPIOs and simple external 
logic.
This chapter alone will make the price of the book worth it.

Regards,
Greg 

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

[beagleboard] Re: How to disable debug in Cloud9

[Soapy Smith]

Click the little green bug once.  It will turn black.  This will deactivate 
the debugger.

-- 
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: YouTube tutorial video to install JTAG connector on BeagleBone Black

[Soapy Smith]

Sorry, it's about the serial debug port J1, not the JTAG.

Regards,
Greg

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

[beagleboard] Re: YouTube tutorial video to install JTAG connector on BeagleBone Black

[Soapy Smith]

I did a quick scan of an article in the latest issue of Linux Journal.  
There is quite a long article on Beaglebone Black, including discussion of 
some unusual connector adapter to USB.  I'm not sure if it is JTAG.  I'll 
take a look this evening.

Regards,
Greg


>

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

[beagleboard] Newbie Cloud9 IDE Issues: Console and cut and paste

[Soapy Smith]

Hello, I've just started working through "Programming the BeagleBone Black" 
by Simon Monk.
I'm seeing some differences between what is in the book and the behavior of 
the Cloud9 IDE.

I'm running Chrome browser on Ubuntu 14.04 on an Asus laptop.  I 
successfully upgraded the Debian image to 
BeagleBoard.org BeagleBone Debian Image 2014-05-14
on my C version BBB.  The BBB gets attached to the network when plugged 
into USB, and browsing to the IP address
and correct port to get to the Cloud9 IDE works perfectly.

Issue #1 is that I don't see a "Console" quite like seen in the book.  
There is a reaction to a simple JavaScript console.log expression,
but running this causes a complex process which looks like a debugging 
shell.  You can see the result, however, sometimes it is hidden
and you have to scroll on the shell to be able to see the result.  Is this 
a configuration problem?  I want the result of Run to simply go to
a console output, not a complicated debugger (at least for this level of 
simple examples).  I've attached screen shot which shows the result
of running a single line console.log(2+2);

Issue #2:  Cut and paste does not work.  I get a "Native Clipboard Not 
Available" message.  Is there some means to resolve this?
That would be a real drag to not be able to cut and paste!

Regards,
Greg


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