Re: [beagleboard] Re: Correct way t grant user permission to /dev/fb0 and /dev/input/event1

[Moscowbob]

Right, Google did not yield any direct answers but a few pointers here and 
there.
After messing up my rootfs a couple of times trying different things, I am 
back to square one.
I have discovered that although the "debian" user is member of video and 
input groups, it only helps in terms of running ts_calibrate and ts_test 
programs, launching any qt 5.5 program with eglfs, just terminates with 
failure message that egl could not be initialized - there is no message 
about permissions or anything else (like running a system command without 
sudo, you get a command not found error)

Launching program with sudo actually runs the program but with various 
warnings about environment variables that need to be set in order for qt to 
know the physical screen size.
logging in as debian and doing su, then launching program, everything works 
100%, no errors, warnings or anything else.
So in my limited knowledge of linux, i have come to the conclusion that all 
the problems above are due to permissions.

1. How can I determine where the permission failure is happening?
2. How would I grant the correct permissions for user "debian" to be able 
to run the qt program

Any advice, pointers, thoughts would be greatly appreciated.

Thanks

Rob



On Thursday, 6 August 2015 21:39:27 UTC+1, William Hermans wrote:
>
> The immediate thing to do, if not done already would be to google the 
> exact error message. This may, or may not give you an answer to your 
> problem.
>
> Indeed adding your user to a group in this case seems like the "real" way 
> to go. So preferable if you can nail down this issue.
>
> On Thu, Aug 6, 2015 at 1:18 PM, Moscowbob 
> > wrote:
>
>> Thanks for the replies gents I have opted for Barry's suggestion and just 
>> added the user to input group for /dev/event1, for fb0, the user is member 
>>  of viseo group by default.
>> This seemed to work when testing with ts_calibrate and ts_test - works 
>> withou sudo but, when trying to rung a QT5 program with eglfs, it fails 
>> with cannot initialise.
>> However, when running as sudo, the program works - I assume thewre are 
>> further permission problems somewhere so further insight or help will be 
>> greatly appreciated.
>>
>> Thabks
>>
>> Rob
>>
>>
>> On Monday, 3 August 2015 21:19:32 UTC+1, Barry Day wrote:
>>>
>>> For /dev/fb0 use addgroup to add your user to the video group
>>>
>> -- 
>> 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/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: libpruio adc pruio_config help

[TJF]

Hi!

Am Dienstag, 25. August 2015 00:44:22 UTC+2 schrieb 
180bob.we.had.a...@gmail.com:
>
> or is something I using out-of-date?
>

Yes, outdated. In the new (unpublished) code in file 
src/pruio/pruio_adc.bas at line 128

   d *= (Conf->ADC_CLKDIV + 1) * 417 '417 ≈ 100 / 2400 (= 1 GHz / 
2.4 MHz)
   d += 30 ' PRU cycles for restart [GHz]

   IF Tmr <= d THEN .Errr = @"sample rate too big" : RETURN .Errr

is replaced by

  d = (d * (Conf->ADC_CLKDIV + 1) * 1000) \ 24
  IF Tmr <= d ORELSE Tmr < 5000 THEN _
   .Errr = @"sample rate too big" : RETURN .Errr

BTW: The example triggers.bas 

 
may give you an idea how to use MM mode.

BR

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

Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)

[bharat gohil]

Sorry for that.I will take care.
Regards,
Bharat Gohil

On Mon, Aug 24, 2015 at 11:34 PM, Gerald Coley 
wrote:

> It is called the BeagleBoard-X15. Not BeagleboneX15.
>
> Gerald
>
>
> On Sun, Aug 23, 2015 at 11:46 PM, bharat gohil  wrote:
>
>> Find following patch to run two different OS on beagleboneX15 in AMP mode,
>> http://lists.denx.de/pipermail/u-boot/2015-August/222339.html
>>
>> Best Regards,
>> Bharat Gohil
>>
>>
>>
>> On Monday, March 30, 2015 at 7:09:24 PM UTC+5:30, bharat gohil wrote:
>>>
>>>
>>> 1) FreeRTOS on one Cortex-A15, GNU/Linux on the other
>>> I am trying to run this combination in AMP mode.
>>> I have successfully run Linux one and other core running barematal
>>> application.
>>> Possibly Run FreeRTOS instead of barematal application.
>>>
>>> 2)Running hypervisor in SMP mode
>>> Run Linux and FreeRTOS on hypervisor.
>>>
>>> 3) FreeRTOS on one Cortex-M4, GNU/Linux on the Cortex-A15 cores,...
>>> After completing "FreeRTOS on one Cortex-A15, GNU/Linux on the other" I
>>> will move to this.
>>>
>>> I will update you.
>>>
>>> Regards,
>>> Bharat Gohil
>>> ghl.b...@gmail.com
>>>
>>>
>>> On Sunday, November 9, 2014 at 10:46:09 AM UTC+5:30, robert.berger wrote:

 Hi,

 On Saturday, November 8, 2014 6:31:25 PM UTC+2, sixvolts wrote:
>
> Any ideas how this compares to the wandboard quad? 4x Cortex-A9 vs 2x
> Cortex-A15
>

 Well the Cortex-A15 includes full hardware visualization, which the
 Cortex-A9 lacks. If this new board with multiple Cortex-A15 and dual
 Cortex-M4 is reasonably priced it might used as a references board for an
 open source Linux/RTOS solution.

 *) FreeRTOS on one Cortex-A15, GNU/Linux on the other
 *) FreeRTOS on one Cortex-M4, GNU/Linux on the Cortex-A15 cores,...

 anyone interested in something like this?

 Regards,

 Robert

 --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>
> --
> 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/1t3yxkPYSB8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.go...@harman.com
+919427054633

-- 
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 GPIO max frequency/bus latency (without using PRU)?

[Andrew P. Lentvorski]

On Monday, August 24, 2015 at 5:39:54 PM UTC-7, Charles Steinkuehler wrote:
>
> On 8/24/2015 6:12 PM, Andrew P. Lentvorski wrote: 
> > I've been trying to hunt down the maximum frequency on the BeagleBone 
> Black 
> > GPIO pins. 
> > 
> > This *seems* to be dominated by the transaction latency across the L3/L4 
> > interconnect.  Fair enough.  So ... 
> > 
> > What's the latency number? 
> > 
> > I've *measured* about 166ns per transaction (I can create a roughly 3MHz 
> > toggle which is 2 pin flips which requires 6MTransactions/s which is 
> > 166.66ns per transaction).  But I don't know how to *calculate* that 
> number 
> > from the documentation. 
>
> I've measured 40 ns from the PRU.  I'm not sure if the CPU can match 
> this, but I'd be surprised if it couldn't. 
>

Well, there could be some silliness involving the fact that the memory is 
mmap'd in Linux.  A TLB access or something similar might be required that 
could add overhead.

This is a bit lower level than you'll find in most reference manuals, 
> and falls into the category of "if it's _really_ important to you, 
> contact the manufacturer and verify"...and I hope you're buying a 
> *LOT* of parts, because this is the sort of thing that is subject to 
> change with die revisions.  :) 
>

It actually surprises me that this information isn't documented.  However, 
I presume it's because most people using this high-end a processor really 
only use the peripherals.  The only thing most people really use the GPIO's 
for is generating interrupts.

I suspect I could live with things as they stand, but this is really going 
to make things ... annoying.

I may be better off just trying to do nasty things to the McSPI subsystem. 
 SPI really doesn't like bi-directional data lines, though.

-- 
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 GPIO a bit slow via /dev/mem and mmap?

[William Hermans]

So in that article I suppose Dan Saks is talking about function signatures,
in C++ versus C. The explanations seem very contrived, and I'm not sure I'd
consider much of the discussed code "good form"

*On the other hand, in:*
> *int f(char *const p);*
> *the const qualifier is at the top level, so*
> *it is not part of the function’s signa-*
> *ture. This function has the same sig-*
> *nature as:*
> *int f(char *p);*


This "form" or style of code is bad going by anything I've read. So . . .

inf f(const char *p) or *maybe* int f(char const *p). But unless I
misunderstood what Dan Saks is trying to say here. The article heading
should have been "Asterisk placement", and not top-level CV-qualifiers. Or
maybe the point is still valid, but could have been avoided entirely by
using "better" coding style. *shrug*

On Mon, Aug 24, 2015 at 6:25 PM, Andrew P. Lentvorski 
wrote:

> On Monday, August 24, 2015 at 5:10:11 PM UTC-7, William Hermans wrote:
>>
>> I think the actual scope matters more. e.g. global versus local scope.
>> But maybe I'm remembering wrongly as I recall reading something to this
>> effect years ago. Anyway, I find this link the best single resource for
>> explaining what volatile *is* - And . . I'm not trying to start an argument
>> or anything, I just like discussing programming in general.
>>
>> http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword
>>
>
> Um, that article is in violent agreement with me.  :)
>
> Incidentally, for a great explanation of why you have a choice of where to
>> place volatile and why you should place it after the data type (for
>> example, int volatile * foo), read Dan Sak's column "Top-Level
>> cv-Qualifiers in Function Parameters" (Embedded Systems Programming,
>> February 2000, p. 63).
>>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Re: Could use some bug tracking advice.

[Harvey White]

On Mon, 24 Aug 2015 18:19:14 -0700, you wrote:

>>
>> *I know the feeling.*
>>
>> * Good luck and don't hesitate to ask for more help, or at least advice,*
>> * for whatever I can do.  Linux I can't really talk about, the*
>> * fundamentals I think I can.*
>>
>
>I think Linux in this context was not so important. I mean it is / was, but
>I generally do ok with high level on topic discussions. So long as I know
>what my options are, everything is good.

It's more of a general operating system issue, and that is fundamental
knowledge.  Personally, I don't see a problem, but the list moderators
haven't seemed to have a problem either, so that's ok.

>
>*Ask either on the list or private email if you want.*
>>
>
>I don't mind asking here if that is fine with everyone. Technically, I felt
>a little funny posting here, as it was semi off topic( in relation to the
>beaglebone ), but maybe the discussion helps someone else too ? If there is
>a problem, then I have no issues moving to another forum.

True, except it *is* to get the beaglebone working, and *is* an issue
that can bite people writing somewhat more complicated projects.

I'd hope that it will help others, and for that matter, if someone
disagrees with what I've said, I'd welcome the discussion.  

Hopefully, the concepts will help with the more complicated projects
using any sort of beagle

Harvey

>
>On Mon, Aug 24, 2015 at 6:00 PM, Harvey White 
>wrote:
>
>> On Mon, 24 Aug 2015 17:40:33 -0700, you wrote:
>>
>> >Hey Harvey, and Walter
>> >
>> >Just kind of an update. Last night after our discussion I found a really
>> >good resource / discussion of what fork() is and the different ways it can
>> >be used. So with this information in mind along with our discussion
>> >yesterday it seems that what I want to do can indeed be done without using
>> >POSIX shared memory( I had little doubt ) - *and* seemingly more simple.
>>
>> That sounds good
>> >
>> >I'd still have to use a Semaphore - I think to keep the web server
>> callback
>> >from stalling my canbus routines. But I think that seems fairly
>> reasonable.
>> >
>>
>> That also sounds quite reasonable to do.  As your programs get more
>> complicated, you'll have to figure out how to interlock/protect/manage
>> resources.
>>
>> I have a project that manages a graphics engine (software), I2C slave
>> (ditto), heartbeat/errortask, I2C error reporting task, and the like;
>> and uses a FIFO, semaphores, queues and the like to protect resources
>> and manage memory.
>>
>> Probably a bit too complex, but it kinda grew that way.
>>
>>
>> >Still I may just implement semaphores into my current code to check it
>> out,
>> >but not sure when. Been a semi rough day, and I'm whooped . . .
>>
>> I know the feeling.
>>
>> Good luck and don't hesitate to ask for more help, or at least advice,
>> for whatever I can do.  Linux I can't really talk about, the
>> fundamentals I think I can.
>>
>> Ask either on the list or private email if you want.
>>
>> Harvey
>>
>> >
>> >On Sun, Aug 23, 2015 at 9:44 PM, William Hermans 
>> wrote:
>> >
>> >> OK have a good one, thanks for the discussion.
>> >>
>> >> On Sun, Aug 23, 2015 at 9:11 PM, Harvey White 
>> >> wrote:
>> >>
>> >>> On Sun, 23 Aug 2015 20:18:26 -0700 (PDT), you wrote:
>> >>>
>> >>> >
>> >>> >>
>> >>> >> *Well, you're certainly right that the callback is messing*
>> >>> >> * things up.  If I assume the same callback, then the callback is*
>> >>> >> * certainly changing data.  If you can set the right breakpoint, you
>> >>> can*
>> >>> >> * tag the situation *if* the breakpoint also knows that the process
>> is*
>> >>> >> * reading from the CAN bus.*
>> >>> >>
>> >>> >> * Had you considered disabling that callback function until the
>> read*
>> >>> >> * from the CANbus is finished?  Would it be practical?  That's where
>> >>> the*
>> >>> >> * semaphore might help a lot.*
>> >>> >>
>> >>> >> * what variables could be common between the two routines?*
>> >>> >>
>> >>> >> * Harvey*
>> >>> >>
>> >>> >
>> >>> >Well this is where previous experience fails me. I've pretty much
>> avoided
>> >>> >code related to threading in software. In the past. I do know of
>> fork()
>> >>> and
>> >>> >roughly what it is capable of, and I know about threads, but not to
>> >>> >implement them in C on Linux. Or what can be done with them. Lets talk
>> >>> code
>> >>> >a minute.
>> >>>
>> >>> OK, as well as I can follow it.
>> >>>
>> >>> >
>> >>> >*IPC - Server - Reads from canbus*
>> >>> >int main(){
>> >>> >struct can_frame frame;
>> >>> >int sock = InitializeCAN("vcan0");
>> >>> >
>> >>> >statistics_t *stats = NULL;
>> >>> >
>> >>> >const long shm_size = sysconf(_SC_PAGESIZE);
>> >>> >
>> >>> >int shm_fd = shm_open("acme", O_CREAT | O_RDWR, FILE_PERMS);
>> >>>
>> >>> **NOTE:  the problem may be "acme", since we know that acme products
>> >>> are not effective against roadrunners.
>> >>>
>> >>> >if(shm_fd == -1)
>> >>> >HandleError(strerror(errno));
>> 

Re: [beagleboard] BeagleBone Black GPIO a bit slow via /dev/mem and mmap?

[Andrew P. Lentvorski]

On Monday, August 24, 2015 at 5:10:11 PM UTC-7, William Hermans wrote:
>
> I think the actual scope matters more. e.g. global versus local scope. But 
> maybe I'm remembering wrongly as I recall reading something to this effect 
> years ago. Anyway, I find this link the best single resource for explaining 
> what volatile *is* - And . . I'm not trying to start an argument or 
> anything, I just like discussing programming in general.
>
> http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword
>

Um, that article is in violent agreement with me.  :)

Incidentally, for a great explanation of why you have a choice of where to 
> place volatile and why you should place it after the data type (for 
> example, int volatile * foo), read Dan Sak's column "Top-Level 
> cv-Qualifiers in Function Parameters" (Embedded Systems Programming, 
> February 2000, p. 63).
>


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

Re: [beagleboard] How to build kernel version 4.1.5-bone-rt-r15?

[William Hermans]

kernels are maintained by Robert AFAIK, and his build instructions are here:

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

He does have some customizations in addition. Which I'm not really sure
what all he does.

Is this the information you're after ?

On Mon, Aug 24, 2015 at 6:09 PM, ccrome  wrote:

> Hello, I installed the latest ubuntu image I found (
> images_bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img).
>
> I then followed the instructions here:
> http://elinux.org/BeagleBoardUbuntu#Install_Latest_Kernel_Image
>
> then executed this command to update to the 4.1 RT kernel:
>
> ./update_kernel.sh --bone-rt-kernel --lts
>
> which updates to "Linux beaglebone 4.1.5-bone-rt-r15 #1 PREEMPT RT Mon
> Aug 17 21:20:48 UTC 2015 armv7l GNU/Linux"
>
> Everything seems to work okay so far, but I can't figure out how that
> kernel was built.  Is there are wonderful script somewhere that builds this
> kernel?
>
> More generally, how are all the kernels available from ./update_kernel.sh
> built?
>
> Thanks,
>   -Caleb
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Re: Could use some bug tracking advice.

[William Hermans]

>
> *I know the feeling.*
>
> * Good luck and don't hesitate to ask for more help, or at least advice,*
> * for whatever I can do.  Linux I can't really talk about, the*
> * fundamentals I think I can.*
>

I think Linux in this context was not so important. I mean it is / was, but
I generally do ok with high level on topic discussions. So long as I know
what my options are, everything is good.

*Ask either on the list or private email if you want.*
>

I don't mind asking here if that is fine with everyone. Technically, I felt
a little funny posting here, as it was semi off topic( in relation to the
beaglebone ), but maybe the discussion helps someone else too ? If there is
a problem, then I have no issues moving to another forum.

On Mon, Aug 24, 2015 at 6:00 PM, Harvey White 
wrote:

> On Mon, 24 Aug 2015 17:40:33 -0700, you wrote:
>
> >Hey Harvey, and Walter
> >
> >Just kind of an update. Last night after our discussion I found a really
> >good resource / discussion of what fork() is and the different ways it can
> >be used. So with this information in mind along with our discussion
> >yesterday it seems that what I want to do can indeed be done without using
> >POSIX shared memory( I had little doubt ) - *and* seemingly more simple.
>
> That sounds good
> >
> >I'd still have to use a Semaphore - I think to keep the web server
> callback
> >from stalling my canbus routines. But I think that seems fairly
> reasonable.
> >
>
> That also sounds quite reasonable to do.  As your programs get more
> complicated, you'll have to figure out how to interlock/protect/manage
> resources.
>
> I have a project that manages a graphics engine (software), I2C slave
> (ditto), heartbeat/errortask, I2C error reporting task, and the like;
> and uses a FIFO, semaphores, queues and the like to protect resources
> and manage memory.
>
> Probably a bit too complex, but it kinda grew that way.
>
>
> >Still I may just implement semaphores into my current code to check it
> out,
> >but not sure when. Been a semi rough day, and I'm whooped . . .
>
> I know the feeling.
>
> Good luck and don't hesitate to ask for more help, or at least advice,
> for whatever I can do.  Linux I can't really talk about, the
> fundamentals I think I can.
>
> Ask either on the list or private email if you want.
>
> Harvey
>
> >
> >On Sun, Aug 23, 2015 at 9:44 PM, William Hermans 
> wrote:
> >
> >> OK have a good one, thanks for the discussion.
> >>
> >> On Sun, Aug 23, 2015 at 9:11 PM, Harvey White 
> >> wrote:
> >>
> >>> On Sun, 23 Aug 2015 20:18:26 -0700 (PDT), you wrote:
> >>>
> >>> >
> >>> >>
> >>> >> *Well, you're certainly right that the callback is messing*
> >>> >> * things up.  If I assume the same callback, then the callback is*
> >>> >> * certainly changing data.  If you can set the right breakpoint, you
> >>> can*
> >>> >> * tag the situation *if* the breakpoint also knows that the process
> is*
> >>> >> * reading from the CAN bus.*
> >>> >>
> >>> >> * Had you considered disabling that callback function until the
> read*
> >>> >> * from the CANbus is finished?  Would it be practical?  That's where
> >>> the*
> >>> >> * semaphore might help a lot.*
> >>> >>
> >>> >> * what variables could be common between the two routines?*
> >>> >>
> >>> >> * Harvey*
> >>> >>
> >>> >
> >>> >Well this is where previous experience fails me. I've pretty much
> avoided
> >>> >code related to threading in software. In the past. I do know of
> fork()
> >>> and
> >>> >roughly what it is capable of, and I know about threads, but not to
> >>> >implement them in C on Linux. Or what can be done with them. Lets talk
> >>> code
> >>> >a minute.
> >>>
> >>> OK, as well as I can follow it.
> >>>
> >>> >
> >>> >*IPC - Server - Reads from canbus*
> >>> >int main(){
> >>> >struct can_frame frame;
> >>> >int sock = InitializeCAN("vcan0");
> >>> >
> >>> >statistics_t *stats = NULL;
> >>> >
> >>> >const long shm_size = sysconf(_SC_PAGESIZE);
> >>> >
> >>> >int shm_fd = shm_open("acme", O_CREAT | O_RDWR, FILE_PERMS);
> >>>
> >>> **NOTE:  the problem may be "acme", since we know that acme products
> >>> are not effective against roadrunners.
> >>>
> >>> >if(shm_fd == -1)
> >>> >HandleError(strerror(errno));
> >>> >
> >>> >const int retval = ftruncate(shm_fd, shm_size);
> >>> >if(retval == -1)
> >>> >HandleError(strerror(errno));
> >>> >
> >>> >shared_memory = InitializeShm(shm_size * sizeof(char), shm_fd);
> >>> >close(shm_fd);
> >>> >
> >>> >while(1){
> >>> >frame = ReadFrame(sock);
> >>> >if(frame.can_dlc == FRAME_DLC)
> >>> >stats = ProcessFastpacket(frame);
> >>>
> >>> right at this point, you have no protection against access and no
> >>> interlocking.
> >>>
> >>> I'll have to give you pseudocode, because I don't know how to do this
> >>> in Linux.
> >>>
> >>> In the init routine, before you set up either main as a
> >>> process (I assume you do this).  Declare a semaphore:
> 

[beagleboard] How to build kernel version 4.1.5-bone-rt-r15?

[ccrome]

Hello, I installed the latest ubuntu image I found (
images_bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img).

I then followed the instructions 
here: http://elinux.org/BeagleBoardUbuntu#Install_Latest_Kernel_Image

then executed this command to update to the 4.1 RT kernel:

./update_kernel.sh --bone-rt-kernel --lts

which updates to "Linux beaglebone 4.1.5-bone-rt-r15 #1 PREEMPT RT Mon Aug 
17 21:20:48 UTC 2015 armv7l GNU/Linux"

Everything seems to work okay so far, but I can't figure out how that 
kernel was built.  Is there are wonderful script somewhere that builds this 
kernel?  

More generally, how are all the kernels available from ./update_kernel.sh 
built?

Thanks,
  -Caleb

-- 
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: Could use some bug tracking advice.

[Harvey White]

On Mon, 24 Aug 2015 17:40:33 -0700, you wrote:

>Hey Harvey, and Walter
>
>Just kind of an update. Last night after our discussion I found a really
>good resource / discussion of what fork() is and the different ways it can
>be used. So with this information in mind along with our discussion
>yesterday it seems that what I want to do can indeed be done without using
>POSIX shared memory( I had little doubt ) - *and* seemingly more simple.

That sounds good
>
>I'd still have to use a Semaphore - I think to keep the web server callback
>from stalling my canbus routines. But I think that seems fairly reasonable.
>

That also sounds quite reasonable to do.  As your programs get more
complicated, you'll have to figure out how to interlock/protect/manage
resources.

I have a project that manages a graphics engine (software), I2C slave
(ditto), heartbeat/errortask, I2C error reporting task, and the like;
and uses a FIFO, semaphores, queues and the like to protect resources
and manage memory.

Probably a bit too complex, but it kinda grew that way.


>Still I may just implement semaphores into my current code to check it out,
>but not sure when. Been a semi rough day, and I'm whooped . . .

I know the feeling.

Good luck and don't hesitate to ask for more help, or at least advice,
for whatever I can do.  Linux I can't really talk about, the
fundamentals I think I can.  

Ask either on the list or private email if you want.

Harvey

>
>On Sun, Aug 23, 2015 at 9:44 PM, William Hermans  wrote:
>
>> OK have a good one, thanks for the discussion.
>>
>> On Sun, Aug 23, 2015 at 9:11 PM, Harvey White 
>> wrote:
>>
>>> On Sun, 23 Aug 2015 20:18:26 -0700 (PDT), you wrote:
>>>
>>> >
>>> >>
>>> >> *Well, you're certainly right that the callback is messing*
>>> >> * things up.  If I assume the same callback, then the callback is*
>>> >> * certainly changing data.  If you can set the right breakpoint, you
>>> can*
>>> >> * tag the situation *if* the breakpoint also knows that the process is*
>>> >> * reading from the CAN bus.*
>>> >>
>>> >> * Had you considered disabling that callback function until the read*
>>> >> * from the CANbus is finished?  Would it be practical?  That's where
>>> the*
>>> >> * semaphore might help a lot.*
>>> >>
>>> >> * what variables could be common between the two routines?*
>>> >>
>>> >> * Harvey*
>>> >>
>>> >
>>> >Well this is where previous experience fails me. I've pretty much avoided
>>> >code related to threading in software. In the past. I do know of fork()
>>> and
>>> >roughly what it is capable of, and I know about threads, but not to
>>> >implement them in C on Linux. Or what can be done with them. Lets talk
>>> code
>>> >a minute.
>>>
>>> OK, as well as I can follow it.
>>>
>>> >
>>> >*IPC - Server - Reads from canbus*
>>> >int main(){
>>> >struct can_frame frame;
>>> >int sock = InitializeCAN("vcan0");
>>> >
>>> >statistics_t *stats = NULL;
>>> >
>>> >const long shm_size = sysconf(_SC_PAGESIZE);
>>> >
>>> >int shm_fd = shm_open("acme", O_CREAT | O_RDWR, FILE_PERMS);
>>>
>>> **NOTE:  the problem may be "acme", since we know that acme products
>>> are not effective against roadrunners.
>>>
>>> >if(shm_fd == -1)
>>> >HandleError(strerror(errno));
>>> >
>>> >const int retval = ftruncate(shm_fd, shm_size);
>>> >if(retval == -1)
>>> >HandleError(strerror(errno));
>>> >
>>> >shared_memory = InitializeShm(shm_size * sizeof(char), shm_fd);
>>> >close(shm_fd);
>>> >
>>> >while(1){
>>> >frame = ReadFrame(sock);
>>> >if(frame.can_dlc == FRAME_DLC)
>>> >stats = ProcessFastpacket(frame);
>>>
>>> right at this point, you have no protection against access and no
>>> interlocking.
>>>
>>> I'll have to give you pseudocode, because I don't know how to do this
>>> in Linux.
>>>
>>> In the init routine, before you set up either main as a
>>> process (I assume you do this).  Declare a semaphore:
>>>
>>> semaphore_handle shared_access; // create semaphore
>>> handle accessible to both processes.
>>> semaphore_create (shared_access);   // create
>>> semaphore
>>>
>>>
>>> then modify this next section to:
>>>
>>> if(stats != NULL){
>>> if (semaphore_take(shared_access), )
>>> {
>>> WriteToShm(shared_memory, stats);
>>> semaphore_give (shared_access);
>>> }
>>> stats = NULL;
>>> printf("%s", ReadFromShm(shared_memory));
>>> }
>>>task_delay(n);
>>>
>>> NOTE:   Process A hangs until it can "get" the semaphore; if Process B
>>> has it, B can keep it only long enough to send the packet
>>> >
>>> >if(stats != NULL){
>>> >WriteToShm(shared_memory, stats);
>>> >stats = NULL;
>>> >printf("%s", ReadFromShm(shared_memory));
>>> >}
>>> >}
>>> >}/* main() */
>>> >
>>> >
>>> >
>>> >*IPC - Client / webserver*
>>> >
>>> >int main(void

Re: [beagleboard] BeagleBone Black GPIO max frequency/bus latency (without using PRU)?

[William Hermans]

>
> *That's using the PRU direct I/O, *NOT* the GPIO pins.  There's a*
> * difference.  :)*


Ah ok, I remember I think Gerald( but as usual my memory is hazy here )
saying that the PRU can generate a 100Mhz or 200Mhz square wave. I
obviously assumed this was via GPIO, but I was wrong it seems. My bad.

On Mon, Aug 24, 2015 at 5:41 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 8/24/2015 7:26 PM, William Hermans wrote:
> >
> > So this is word of mouth from these very forums perhaps a couple years
> ago
> > but I do recall someone ( as in someone qualified to know - don't
> remember
> > exactly who ) saying that technically, GPIO's can be toggled on/off at
> > 100-200 Mhz - Using a PRU.
>
> That's using the PRU direct I/O, *NOT* the GPIO pins.  There's a
> difference.  :)
>
> Even the PRU can only get about 12.5 MHz out of a GPIO pin, although
> it can _easily_ get 100 MHz toggle rates (200 MHz update rate) from
> the PRU direct outputs.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 GPIO max frequency/bus latency (without using PRU)?

[Charles Steinkuehler]

On 8/24/2015 7:26 PM, William Hermans wrote:
> 
> So this is word of mouth from these very forums perhaps a couple years ago
> but I do recall someone ( as in someone qualified to know - don't remember
> exactly who ) saying that technically, GPIO's can be toggled on/off at
> 100-200 Mhz - Using a PRU.

That's using the PRU direct I/O, *NOT* the GPIO pins.  There's a
difference.  :)

Even the PRU can only get about 12.5 MHz out of a GPIO pin, although
it can _easily_ get 100 MHz toggle rates (200 MHz update rate) from
the PRU direct outputs.

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

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

Re: [beagleboard] Re: Could use some bug tracking advice.

[William Hermans]

Hey Harvey, and Walter

Just kind of an update. Last night after our discussion I found a really
good resource / discussion of what fork() is and the different ways it can
be used. So with this information in mind along with our discussion
yesterday it seems that what I want to do can indeed be done without using
POSIX shared memory( I had little doubt ) - *and* seemingly more simple.

I'd still have to use a Semaphore - I think to keep the web server callback
from stalling my canbus routines. But I think that seems fairly reasonable.

Still I may just implement semaphores into my current code to check it out,
but not sure when. Been a semi rough day, and I'm whooped . . .

On Sun, Aug 23, 2015 at 9:44 PM, William Hermans  wrote:

> OK have a good one, thanks for the discussion.
>
> On Sun, Aug 23, 2015 at 9:11 PM, Harvey White 
> wrote:
>
>> On Sun, 23 Aug 2015 20:18:26 -0700 (PDT), you wrote:
>>
>> >
>> >>
>> >> *Well, you're certainly right that the callback is messing*
>> >> * things up.  If I assume the same callback, then the callback is*
>> >> * certainly changing data.  If you can set the right breakpoint, you
>> can*
>> >> * tag the situation *if* the breakpoint also knows that the process is*
>> >> * reading from the CAN bus.*
>> >>
>> >> * Had you considered disabling that callback function until the read*
>> >> * from the CANbus is finished?  Would it be practical?  That's where
>> the*
>> >> * semaphore might help a lot.*
>> >>
>> >> * what variables could be common between the two routines?*
>> >>
>> >> * Harvey*
>> >>
>> >
>> >Well this is where previous experience fails me. I've pretty much avoided
>> >code related to threading in software. In the past. I do know of fork()
>> and
>> >roughly what it is capable of, and I know about threads, but not to
>> >implement them in C on Linux. Or what can be done with them. Lets talk
>> code
>> >a minute.
>>
>> OK, as well as I can follow it.
>>
>> >
>> >*IPC - Server - Reads from canbus*
>> >int main(){
>> >struct can_frame frame;
>> >int sock = InitializeCAN("vcan0");
>> >
>> >statistics_t *stats = NULL;
>> >
>> >const long shm_size = sysconf(_SC_PAGESIZE);
>> >
>> >int shm_fd = shm_open("acme", O_CREAT | O_RDWR, FILE_PERMS);
>>
>> **NOTE:  the problem may be "acme", since we know that acme products
>> are not effective against roadrunners.
>>
>> >if(shm_fd == -1)
>> >HandleError(strerror(errno));
>> >
>> >const int retval = ftruncate(shm_fd, shm_size);
>> >if(retval == -1)
>> >HandleError(strerror(errno));
>> >
>> >shared_memory = InitializeShm(shm_size * sizeof(char), shm_fd);
>> >close(shm_fd);
>> >
>> >while(1){
>> >frame = ReadFrame(sock);
>> >if(frame.can_dlc == FRAME_DLC)
>> >stats = ProcessFastpacket(frame);
>>
>> right at this point, you have no protection against access and no
>> interlocking.
>>
>> I'll have to give you pseudocode, because I don't know how to do this
>> in Linux.
>>
>> In the init routine, before you set up either main as a
>> process (I assume you do this).  Declare a semaphore:
>>
>> semaphore_handle shared_access; // create semaphore
>> handle accessible to both processes.
>> semaphore_create (shared_access);   // create
>> semaphore
>>
>>
>> then modify this next section to:
>>
>> if(stats != NULL){
>> if (semaphore_take(shared_access), )
>> {
>> WriteToShm(shared_memory, stats);
>> semaphore_give (shared_access);
>> }
>> stats = NULL;
>> printf("%s", ReadFromShm(shared_memory));
>> }
>>task_delay(n);
>>
>> NOTE:   Process A hangs until it can "get" the semaphore; if Process B
>> has it, B can keep it only long enough to send the packet
>> >
>> >if(stats != NULL){
>> >WriteToShm(shared_memory, stats);
>> >stats = NULL;
>> >printf("%s", ReadFromShm(shared_memory));
>> >}
>> >}
>> >}/* main() */
>> >
>> >
>> >
>> >*IPC - Client / webserver*
>> >
>> >int main(void) {
>> >struct mg_server *server = mg_create_server(NULL, ev_handler);
>> >
>> >mg_set_option(server, "listening_port", "8000");
>> >mg_set_option(server, "document_root", "./web");
>> >
>> >printf("Started on port %s\n", mg_get_option(server,
>> >"listening_port"));
>> >
>> >// POSIX IPC - shared memory
>> >const long shm_size = sysconf(_SC_PAGESIZE);
>> >int shm_fd = shm_open("file", O_CREAT | O_RDWR, FILE_PERMS);
>> >if(shm_fd == -1)
>> >HandleError(strerror(errno));
>> >
>> >const int retval = ftruncate(shm_fd, shm_size);
>> >if(retval == -1)
>> >HandleError(strerror(errno));
>> >
>> >shared_memory = InitializeShm(shm_size * sizeof(char), shm_fd);
>> >
>> >close(shm_fd);
>> >
>> >char id = 0x00;
>> >for (;;) {
>> >   

Re: [beagleboard] BeagleBone Black GPIO max frequency/bus latency (without using PRU)?

[Charles Steinkuehler]

On 8/24/2015 6:12 PM, Andrew P. Lentvorski wrote:
> I've been trying to hunt down the maximum frequency on the BeagleBone Black 
> GPIO pins.
> 
> This *seems* to be dominated by the transaction latency across the L3/L4 
> interconnect.  Fair enough.  So ...
> 
> What's the latency number?
> 
> I've *measured* about 166ns per transaction (I can create a roughly 3MHz 
> toggle which is 2 pin flips which requires 6MTransactions/s which is 
> 166.66ns per transaction).  But I don't know how to *calculate* that number 
> from the documentation.

I've measured 40 ns from the PRU.  I'm not sure if the CPU can match
this, but I'd be surprised if it couldn't.

> I've been through the TI reference manuals, the TI support forums, and a 
> bunch of other things, but *nobody* seems to be able to cough up an actual 
> number for this.

This is a bit lower level than you'll find in most reference manuals,
and falls into the category of "if it's _really_ important to you,
contact the manufacturer and verify"...and I hope you're buying a
*LOT* of parts, because this is the sort of thing that is subject to
change with die revisions.  :)

> Anybody have some references to frequencies and bus wait numbers?  They may 
> be out there, but GTMF/RTFM doesn't seem to be sufficient.
> 
> I don't need turbo speed, but the fact that it's entirely possible that I 
> may not even be able run at 1MHz (something *painfully* easy for most M0 or 
> M3/M4 cores) is, frankly, a bit of a shock.

So from my measurements with the PRU, the sustained write speed for
the GPIO is 40 ns per write.  With the GPIO clock at 100 MHz, that's
2.5 clocks per write, which is actually a pretty respectable
round-trip synchronization delay for crossing the various clock
domains involved.

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

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

Re: [beagleboard] BeagleBone Black GPIO a bit slow via /dev/mem and mmap?

[Charles Steinkuehler]

On 8/24/2015 5:06 PM, Andrew P. Lentvorski wrote:
> On Monday, August 24, 2015 at 7:27:35 AM UTC-7, Charles Steinkuehler wrote:
>>
>> Regardless, note that the maximum toggle rate of a GPIO pin using the 
>> PRU is about 12.5 MHz, dictated by the ~40 nS required to execute a 
>> write by the on-chip communication fabric (which means 80 nS period 
>> for a high/low toggle of the pin).  This assumes the CPU and the PRU 
>> have similar bandwidth to the L4 fabric, which may or may not be the 
>> case (but I suspect is true).
> 
> Do you have a pointer to the reference manual for this (if not, don't waste 
> a lot of time, I'll dig it out)?  Given that this seems to be *very* 
> fundamental about understanding the architecture, I really probably need to 
> chase this down exactly.

Refer to Chapter 10 in the TRM, which is all about the interconnects
(on-chip buses).  The GPIO live on L4_PER (except GPIO0, which is on
L4_WKUP) and are accessed via the L3S (L3 Slow clock domain).  You can
also see how the PRU and CPU tie into the interconnect (both tie to
the L3F or Fast clock domain), and what peripherals they can access
(both PRU and CPU can access the GPIO, no surprise there!).

I haven't done real-world timing tests with the CPU, but the results
of my real-world tests with the PRU are documented in the code I wrote
for the Machinekit project:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L137-L165

Assuming the performance bottleneck is the actual GPIO (which seems
likely), you should see similar performance metrics to the PRU when
accessing the GPIO banks from the CPU.

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

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

Re: [beagleboard] BeagleBone Black GPIO max frequency/bus latency (without using PRU)?

[William Hermans]

Andrew,

So this is word of mouth from these very forums perhaps a couple years ago
but I do recall someone ( as in someone qualified to know - don't remember
exactly who ) saying that technically, GPIO's can be toggled on/off at
100-200 Mhz - Using a PRU.

Without using the PRU's . . . well the link you posted a link to in your
other post was featured on HaD months ago, and is still the highest rate
I've seen to date. Frankly I do not think this is a hardware limitation so
much as an OS or software limitation. So no way really to generically
document that in the hardware specs.

Another thing to keep in mind is that the AM335x processors are generic
purpose processors, where many / all M0, M0+, M3/M4 are more specific
purpose. Geared towards doing a few things very well, and fast.

Anyway, if you need more speed, perhaps an RTOS or even just tightening up
the Linux "message pump" ( e.g. RT kernel ) might prove helpful ?

On Mon, Aug 24, 2015 at 4:12 PM, Andrew P. Lentvorski 
wrote:

> I've been trying to hunt down the maximum frequency on the BeagleBone
> Black GPIO pins.
>
> This *seems* to be dominated by the transaction latency across the L3/L4
> interconnect.  Fair enough.  So ...
>
>
> What's the latency number?
>
>
> I've *measured* about 166ns per transaction (I can create a roughly 3MHz
> toggle which is 2 pin flips which requires 6MTransactions/s which is
> 166.66ns per transaction).  But I don't know how to *calculate* that number
> from the documentation.
>
> I've been through the TI reference manuals, the TI support forums, and a
> bunch of other things, but *nobody* seems to be able to cough up an actual
> number for this.
>
> Anybody have some references to frequencies and bus wait numbers?  They
> may be out there, but GTMF/RTFM doesn't seem to be sufficient.
>
> I don't need turbo speed, but the fact that it's entirely possible that I
> may not even be able run at 1MHz (something *painfully* easy for most M0 or
> M3/M4 cores) is, frankly, a bit of a shock.
>
> 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.
>

-- 
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 GPIO a bit slow via /dev/mem and mmap?

[William Hermans]

>
> *This is one of those C quirks.  It's actually a habit from "const" but it
> applies to "volatile" as well.  Oddly, the qualifiers generally apply to
> the *left* except under certain circumstances where they can apply right.
> This gets people into trouble when they specify:*
>
> *volatile uint32_t volatile * blah;*
>
> *Which is actually a *redundant* specifier as opposed to what they wanted:*
>
> *volatile uint32_t * volatile blah;*
>
> *Not every compiler (*especially* embedded ones) will eject a warning on
> the duplicate declaration specifier.  So, I personally always put them on
> the right to avoid the issue.*
>

The volatile keyword is often misunderstood. But I do not think the
placement of the keyword matters so much as long it is either before or
immediately after the type. So like volatile int i or int volatile i would
be the same.

I think the actual scope matters more. e.g. global versus local scope. But
maybe I'm remembering wrongly as I recall reading something to this effect
years ago. Anyway, I find this link the best single resource for explaining
what volatile *is* - And . . I'm not trying to start an argument or
anything, I just like discussing programming in general.

http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword

On Mon, Aug 24, 2015 at 3:06 PM, Andrew P. Lentvorski 
wrote:

> On Monday, August 24, 2015 at 7:27:35 AM UTC-7, Charles Steinkuehler wrote:
>>
>>
>> Optimal would be a sequence of successive stores to the set and clear
>> register, with the addresses pre-calculated and sitting in registers
>> (or with a base address and use the str instruction with an immediate
>> offset).
>
>
> Good point.  I can beat the compiler into submission if I want to, but
> it's probably not worth the effort as I need to do other logic anyway.
>
>
>> You might also need to
>> move the volatile on the variable definitions.  I'm not a "C" guru,
>> but I think:
>>
>>   uint32_t volatile * gpio_setdataout_addr
>>
>> ...is different from:
>>
>>   volatile uint32_t * gpio_setdataout_addr
>>
>> ...you want the uint32_t to be volatile, not the pointer to it.
>
>
>
> This is one of those C quirks.  It's actually a habit from "const" but it
> applies to "volatile" as well.  Oddly, the qualifiers generally apply to
> the *left* except under certain circumstances where they can apply right.
> This gets people into trouble when they specify:
>
> volatile uint32_t volatile * blah;
>
> Which is actually a *redundant* specifier as opposed to what they wanted:
>
> volatile uint32_t * volatile blah;
>
> Not every compiler (*especially* embedded ones) will eject a warning on
> the duplicate declaration specifier.  So, I personally always put them on
> the right to avoid the issue.
>
> ...but I write C code like a hardware guy who programs in VHDL.  :)
>>
>
> Not a damn thing wrong with that, thank you very much.  Software-only
> people tend to be amazed that you can write a state machine that is
> *readable* in code.  A very experienced programmer once told me: "Your code
> is the most straightforward code I have ever read."
>
> Of course, I have to condemn you as a dirty apostate for not using
> Verilog.  :)  (Seriously, though, when is somebody going to produce an
> open-source VHDL simulator/compiler so that I can actually use it on
> projects?)
>
>
>
>> Regardless, note that the maximum toggle rate of a GPIO pin using the
>> PRU is about 12.5 MHz, dictated by the ~40 nS required to execute a
>> write by the on-chip communication fabric (which means 80 nS period
>> for a high/low toggle of the pin).  This assumes the CPU and the PRU
>> have similar bandwidth to the L4 fabric, which may or may not be the
>> case (but I suspect is true).
>>
>
> Do you have a pointer to the reference manual for this (if not, don't
> waste a lot of time, I'll dig it out)?  Given that this seems to be *very*
> fundamental about understanding the architecture, I really probably need to
> chase this down exactly.
>
> Thanks for the advice.  I appreciate your taking the time on this.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Beagle Bone Black and Chipsee 7" capacitive usb problem

[Robert Nelson]

On Mon, Aug 24, 2015 at 2:53 PM,   wrote:
> Hello,
> I'm using a Beagle Bone Black with the Chipsee 7" LCD, with the prebuilt
> image by Chipsee
> prebuilt-debian-chipsee-hmi-20140522.tar.gz
>
> I have many problem to use USB Audio board, and also USB FTDI RS232 VCP
> Seem that the kernel note have the driver for these devices.. what I can do
> to obtain or install this kernel/driver?

The Chipsee 7 is supporrted out of the box with the current images:

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

edit: /boot/uEnv.txt
set:

dtb=am335x-boneblack-bbb-exp-c.dtb

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] Want to connect webcam to BBB, but have some problems

[Robert Nelson]

On Mon, Aug 24, 2015 at 8:23 AM,   wrote:
> I want to connect webcam to BBB
>
> So I put the webcam's USB into the BBB's port,
>
> and checked the connection with bash of cloud9ide by 'lsusb'.
>
> then it says
>
>
> Bus 001 Device 002: ID 1b71:0056
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>
> also I checked the connection by 'ls',
>
> and there was video0.
>
> But if I try to do something with 'v4l2-ctl' command,
>
> it doesn't work and always says
>
>
> bash: v4l2-ctl: command not found

Do you have the debian package: "v4l-utils" installed?

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: shutdown procedure required for beaglebone black ??

[Robert Nelson]

On Sat, Aug 22, 2015 at 12:50 AM,   wrote:
> Hi Gerald,
>
> Do you mean the Linux umount command to un-mount the drive(s)?  In an
> earlier post, you said, "Assuming that the SW supports the power button
> function."  Were you saying that the umount command is assumed to support
> the function of the power button?
>
> Lawrence

Lawrence, are you a troll or lawyer? Based on how you question every email...

With the "current" images..

Push button -> signal to systemd -> systemd starts standard shutdown...

If your "image" doesn't do that, it's not "current"...

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] How to Erase the eMMC

[Robert Nelson]

Odd question, considering the answer was in the email you referenced...

On Sat, Aug 22, 2015 at 12:41 AM,   wrote:
> how can you mark the uSD as bootable?
>
> On Monday, May 13, 2013 at 1:25:29 PM UTC-5, RobertCNelson wrote:
>>
>> On Mon, May 13, 2013 at 1:22 PM, Robert P. J. Day 
>> wrote:
>> > On Mon, 13 May 2013, Robert Nelson wrote:
>> >
>> >> On Mon, May 13, 2013 at 1:13 PM, Robert P. J. Day
>> >>  wrote:
>> >> > On Mon, 13 May 2013, Gerald Coley wrote:
>> >> >
>> >> >> Basically. But if the fingers can't handle repeatedly holding the
>> >> >> button every time they boot, all they have to do is rename the MLO
>> >> >> file to something like MMM.
>> >> >
>> >> >   and that's the fundamental test, is it? the existence of a file
>> >> > called "MLO" in the eMMC FAT partition? i thought as much, just
>> >> > wanted
>> >> > to be sure.
>> >>
>> >> You could also toggle the 'boot flag' on the eMMC.. Then it'll default
>> >> to microSD over eMMC..
>> >>
>> >> fdisk ${DISK} <<-__EOF__
>> >> a
>> >> 1
>> >> w
>> >> __EOF__


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] Uncompressing Linux... done, booting the kernel.

[Robert Nelson]

On Mon, Aug 24, 2015 at 9:03 AM,   wrote:
>
>
> On Saturday, August 22, 2015 at 1:13:39 PM UTC-6, RobertCNelson wrote:
>>
>> As you seem to ignore the replies to this exact same question you asked
>> before..
>>
>> On Aug 21, 2015 6:50 PM,  wrote:
>> >
>> > Below is the text from console.  I used this image for a file system.
>> >
>> > Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11
>> >
>> > This image boots and I have network.  I then built 3.0.14 I downloaded
>> > from https://www.kernel.org/pub/linux/kernel/.  I used
>> > beagleboard_defconfig.  I made no changes.  I copied uImage to the second
>> > partition under /boot (where the working kernel is).  So I now have in the
>> > directory uImage-3.0.14+ (Angstrom's uImage) and my uImage-3.0.14.
>>
>> 3.0.14+ is NOT the same as 3.0.14, you need to add 'ALL' patches that made
>> it a '+'
>>
>> Regards,
>
>
> This post references a link which I did check out.  But it does not have
> TIDSPBRIDGE.  That is why I am trying to use 3.0.14+ image with 3.0.14
> source (which does have TIDSPBRIDGE).  Now if the source or patches for
> 3.0.14+ exist, I have not been able to find it.

TIDSPBRIDGE is dead...

for "3.0.14+ patchset" look at the patches at:

https://github.com/Angstrom-distribution/meta-ti/blob/master/recipes-kernel/linux/linux_3.0.bb

&

https://github.com/Angstrom-distribution/meta-ti/tree/master/recipes-kernel/linux/linux-3.0

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] my metal detector development for beaglebone black

[Harvey White]

On Sun, 23 Aug 2015 16:51:01 -0700 (PDT), you wrote:

>hi guys i am wanting to build a new type of metal detector  which in it 
>self is quite complex task starting with little bits c/c++ code and tying 
>to keep it simple i need to wirite 7 values of either on or off to 1 gpio 
>but infact need to a total of 7 gpio's all as one cycle so i have set 
>patern of  on or off values across the 7 gpios  after that patern is 
>executed is anthoner fixed pattern is done 7 times which the whole thing 
>keeps repeating the pattern below shows the state of the switches s57-s64 
>the gpio's need to be turn on in that order to turn the transistors on if 
>some could hep i would be greatful

*if* you can write these 8 values as a single byte then it's just a
lookup table with an index.  That should get the entire 8 bits change
at one time.  This can happen in some processors, and not in others. I
don't know this particular processor at all, so I can't say that this
is possible.

it's a possibility, but you need to look at the processor
documentation to see if it can be done.  Again, I do *not* know this
processor at all, but it can be done in other processors depending on
how the I/O ports are mapped.

Your best bet is to look at the documentation on the GPIO pins and how
they can be changed.

Harvey

>
>
>S57 S58 S59 S60 S61 S62 S63 S64 onoffoffonn/aonn/aoff
>
>
>onoffoffonn/aoffn/aon
>offononoffonn/aoffn/a?
>
>
>
>
>
>
>
>
>offononoffoffn/aonn/a
>
>
>
>
>
>
>
>
>offoffononononoffoff
>offoffonononoffoffon
>offoffononoffononoff+

-- 
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] BeagleBone Black GPIO max frequency/bus latency (without using PRU)?

[Andrew P. Lentvorski]

I've been trying to hunt down the maximum frequency on the BeagleBone Black 
GPIO pins.

This *seems* to be dominated by the transaction latency across the L3/L4 
interconnect.  Fair enough.  So ...


What's the latency number?


I've *measured* about 166ns per transaction (I can create a roughly 3MHz 
toggle which is 2 pin flips which requires 6MTransactions/s which is 
166.66ns per transaction).  But I don't know how to *calculate* that number 
from the documentation.

I've been through the TI reference manuals, the TI support forums, and a 
bunch of other things, but *nobody* seems to be able to cough up an actual 
number for this.

Anybody have some references to frequencies and bus wait numbers?  They may 
be out there, but GTMF/RTFM doesn't seem to be sufficient.

I don't need turbo speed, but the fact that it's entirely possible that I 
may not even be able run at 1MHz (something *painfully* easy for most M0 or 
M3/M4 cores) is, frankly, a bit of a shock.

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.

[beagleboard] Beagle Bone Black and Chipsee 7" capacitive usb problem

[giorgiofox]

Hello,
I'm using a Beagle Bone Black with the Chipsee 7" LCD, with the prebuilt 
image by Chipsee
prebuilt-debian-chipsee-hmi-20140522.tar.gz 


I have many problem to use USB Audio board, and also USB FTDI RS232 VCP
Seem that the kernel note have the driver for these devices.. what I can do 
to obtain or install this kernel/driver?

thanks in avance
Giorgio

-- 
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] Uncompressing Linux... done, booting the kernel.

[TheCajun]

On 2015-08-22 13:13, Robert Nelson wrote:

As you seem to ignore the replies to this exact same question you asked
before..

On Aug 21, 2015 6:50 PM,  wrote:


Below is the text from console.  I used this image for a file system.

Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11

This image boots and I have network.  I then built 3.0.14 I downloaded

from https://www.kernel.org/pub/linux/kernel/.  I used
beagleboard_defconfig.  I made no changes.  I copied uImage to the 
second
partition under /boot (where the working kernel is).  So I now have in 
the

directory uImage-3.0.14+ (Angstrom's uImage) and my uImage-3.0.14.

3.0.14+ is NOT the same as 3.0.14, you need to add 'ALL' patches that 
made

it a '+'


I tried to get the source for 3.0.14+.  The image that was create does 
not
have any source that I can find (or patches).  Which is why I went to 
kernel.org

Does anyone know where I can find source/patches for 3.0.14+?

Thank you.



Regards,


--
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: libpruio adc pruio_config help

[180bob . we . had . a . baby . its . a . boy]

Thanks! That code makes is much closer to what I am looking for. 

Question-- When trying to compile and run it I get  


root@beaglebone:~/libpruio-0.2/src/c_examples# ./rb_file 
config failed (sample rate too big)


Its failing on the call to config--

 if (pruio_config(io, samp, mask, tmr, 0))


Is that expected? Should I just adjust the samp var? or is something I 
using out-of-date?





On Saturday, August 22, 2015 at 11:24:02 AM UTC-6, TJF wrote:
>
> Hi!
>
> To sample as fast as possible you've to configure your steps first, using 
> function AdcUdt::setStep:
>
>- Avaraging = 0
>- SaD = 0
>- OpD = 0
>
> Then you call PruIo::config()
>
>- Samp is the number of samples to fetch. In MM mode it's the size of 
>the buffer, libpruio stops when the buffer is full. In RB mode the buffer 
>is used as a ring buffer an sampling continues. Samp <= 1 means single 
> mode 
>(no accurate timing = variable sampling rate).
>- Tmr is the number of ns between the samples (MM and RB mode only), 
>so that's the parameter to specify the sampling rate.
>
> io_input.c uses single mode. Better start with rb_file.c example:
>
> /** \file rb_file.c 
> \brief Example: fetch ADC samples in a ring buffer and save to file. 
>  
> This file contains an example on how to use the ring buffer mode of 
> libpruio. A fixed step mask of AIN-0, AIN-1 and AIN-2 get configured 
> for maximum speed, sampled in to the ring buffer and from there saved 
> as raw data to some files. 
>  
> Licence: GPLv3 
>  
> Copyright 2014-2015 by Thomas{ dOt ]Freiherr[ At ]gmx[ DoT }net 
>  
> Thanks for C code translation: Nils Kohrs (nils.kohrs [at] gmail.com) 
>  
> Compile by: `gcc -Wall -o rb_file rb_file.c -lpruio -lprussdrv` 
>  
> \since 0.2.0.2 
> */ 
>  
> #include "unistd.h" 
> #include "time.h" 
> #include "stdio.h" 
> #include "../c_include/pruio.h" 
>  
> //! The main function. 
> int main(int argc, char **argv) 
> { 
>   const uint32 tSamp = 123401;  //!< The number of samples in the files 
> (per step). 
>   const uint32 tmr = 5000;  //!< The sampling rate in ns (5000 -> 200 
> kHz). 
>   const uint32 NoStep = 3;  //!< The number of active steps (must 
> match setStep calls and mask). 
>   const uint32 NoFile = 2;  //!< The number of files to write. 
>   const char *NamFil = "output.%u"; //!< The output file names. 
>   struct timespec mSec; 
>   mSec.tv_nsec=100; 
>   pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new 
> driver 
>   if (io->Errr){ 
>printf("constructor failed (%s)\n", io->Errr); return 1;} 
>  
>   do { 
> if (pruio_adc_setStep(io, 9, 0, 0, 0, 0)){ //  step 9, AIN-0 
> printf("step 9 configuration failed: (%s)\n", io->Errr); break;} 
> if (pruio_adc_setStep(io,10, 1, 0, 0, 0)){ // step 10, AIN-1 
>printf("step 10 configuration failed: (%s)\n", io->Errr); break;} 
> if (pruio_adc_setStep(io,11, 2, 0, 0, 0)){ // step 11, AIN-2 
>printf("step 11 configuration failed: (%s)\n", io->Errr); break;} 
>  
> uint32 mask = 7 << 9; //!< The active steps (9 to 11). 
> uint32 tInd = tSamp * NoStep; //!< The maximum total index. 
> uint32 half = ((io->ESize >> 2) / NoStep) * NoStep; //!< The maximum 
> index of the half ring buffer. 
>  
> if (half > tInd){ half = tInd;}  //   adapt size for small files 
> uint32 samp = (half << 1) / NoStep; //!< The number of samples (per 
> step). 
>  
> if (pruio_config(io, samp, mask, tmr, 0)){ //   configure driver 
>printf("config failed (%s)\n", io->Errr); break;} 
>  
> if (pruio_rb_start(io)){ 
>  printf("rb_start failed (%s)\n", io->Errr); break;} 
>  
> uint16 *p0 = io->Adc->Value;  //!< A pointer to the start of the ring 
> buffer. 
> uint16 *p1 = p0 + half;   //!< A pointer to the middle of the 
> ring buffer. 
> uint32 n;  //!< File counter. 
> char fName[20]; 
> for(n = 0; n < NoFile; n++){ 
>   sprintf(fName, NamFil, n); 
>   printf("Creating file %s\n", fName); 
>   FILE *oFile = fopen(fName, "wb"); 
>   uint32 i = 0;   //!< Start index. 
>   while(i < tInd){ 
> i += half; 
> if(i > tInd){ // fetch the rest(no complete chunk) 
>   uint32 rest = tInd + half - i; 
>   uint32 iEnd = p1 >= p0 ? rest : rest + half; 
>   while(io->DRam[0] < iEnd) nanosleep(&mSec, NULL); 
>   printf("  writing samples %u-%u\n", tInd -rest, tInd-1); 
>   fwrite(p0, sizeof(uint16), rest, oFile); 
>   uint16 *swap = p0; 
>   p0 = p1; 
>   p1 = swap; 
> } 
> if(p1 > p0) while(io->DRam[0] < half) nanosleep(&mSec, NULL); 
> elsewhile(io->DRam[0] > half) nanosleep(&mSec, NULL); 
> printf("  writing samples %u-%u\n", i-half, i-1); 
> fwrite(p0, sizeof(uint16), half, oFile); 
> uint16 *swap =

Re: [beagleboard] Uncompressing Linux... done, booting the kernel.

[thecajun]

On Saturday, August 22, 2015 at 1:13:39 PM UTC-6, RobertCNelson wrote:
>
> As you seem to ignore the replies to this exact same question you asked 
> before..
>
> On Aug 21, 2015 6:50 PM, > wrote:
> >
> > Below is the text from console.  I used this image for a file system.
> >
> > Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11
> >
> > This image boots and I have network.  I then built 3.0.14 I downloaded 
> from https://www.kernel.org/pub/linux/kernel/.  I used 
> beagleboard_defconfig.  I made no changes.  I copied uImage to the second 
> partition under /boot (where the working kernel is).  So I now have in the 
> directory uImage-3.0.14+ (Angstrom's uImage) and my uImage-3.0.14.
>
> 3.0.14+ is NOT the same as 3.0.14, you need to add 'ALL' patches that made 
> it a '+'
>
> Regards,
>

This post 

 
references a link which I did check out.  But it does not have 
TIDSPBRIDGE.  That is why I am trying to use 3.0.14+ image with 3.0.14 
source (which does have TIDSPBRIDGE).  Now if the source or patches for 
3.0.14+ exist, I have not been able to find it.

-- 
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] Possible to run PRU while CPU and OS are powered down to reduce energie consumption?

[st . staudacher]

Hi there!

First of all: Thanks for Beaglebone Black! It's so amazing I learned so 
many things with and from it.


I have a question, and because of my low skills I wasn't able to find an 
answere.

Is it possible to run the PRU while the main system and processor are not 
consuming any energy?

And would it further be possible to power up the main system by the PRU 
when certain GPIO states occur?

And of course if, how? What should I read to understand this?

Thank you very much,

Stefan 

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

[beagleboard] How can I connect between BBB and Web by using 4g LTE modem??

[elliotyun96]

How can I connect between BBB and Web by using 4g LTE modem??



I want send some data (including videos and pictures) from BBB to the Web 
directly.

By using 4g LTE modem, how can I show videos and pictures without wire 
connection

If this is impossible, then how can I send data to my computer instead 
directly to the Web??

please HELP me 


I'm using 'ALCATEL 4g usb modem'

-- 
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] Want to connect webcam to BBB, but have some problems

[elliotyun96]

I want to connect webcam to BBB

So I put the webcam's USB into the BBB's port,

and checked the connection with bash of cloud9ide by 'lsusb'.

then it says


Bus 001 Device 002: ID 1b71:0056  
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


also I checked the connection by 'ls',

and there was video0.

But if I try to do something with 'v4l2-ctl' command,

it doesn't work and always says


bash: v4l2-ctl: command not found


How can I solve this problem??

And I want to know the way to show video from the webcam on website

Help me plz

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

[beagleboard] how to export display environment in root user ?

[parthmodi206]

Hi,



When I am login with the root user in beagle bone black, I can't* export 
display **environmen*t variable and also not able to use* xset  dpms force 
off* command.

I am getting* No protocol specified xset  and   unable to open display 
":0.0" error.*


*But I* am not getting  this error in the with debian login.


Thanks


Regards

Parth 

-- 
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: shutdown procedure required for beaglebone black ??

[lmjeung0]

Hi Gerald,

Do you mean the Linux *umount* command to *un*-mount the drive(s)?  In an 
earlier post, you said, "Assuming that the SW supports the power button 
function."  Were you saying that the *umount* command is assumed to support 
the function of the power button?

Lawrence

On Friday, August 21, 2015 at 4:52:30 PM UTC-7, Gerald wrote:
>
> It is a standard linux command to mount the drive.
>
> Gerald
>
>
> On Fri, Aug 21, 2015 at 5:02 PM, > wrote:
>
>> Hi Gerald,
>>
>> Oops, by "may not necessary work", I mean, "may not necessarily work." 
>>  Will I need to develop SW that supports the power button function - that 
>> is, will I need to develop SW to enable the button?  We are refraining from 
>> powering up the BBB until we know for sure.
>>
>> Best regards,
>> Lawrence
>>
>>
>> On Monday, August 10, 2015 at 6:46:51 AM UTC-7, lmje...@gmail.com wrote:
>>>
>>> Hi Gerald,
>>>
>>> Do you mean that the power button function may not necessary work?  Is 
>>> the SW that supports it SW that I will need to develop, like the C++ SW 
>>> that arunbarn...@gmail.com was developing?
>>>
>>> Lawrence
>>>
>>> On Wednesday, August 5, 2015 at 9:07:57 AM UTC-7, Gerald wrote:

 Assuming that the SW supports the power button function.

 Gerald


 On Wed, Aug 5, 2015 at 8:34 AM, Chad Baker  wrote:

> Section 5.10 in the SRM Rev C.1 recommends using the power button to 
> power down the board and prevent contamination of the SD card or the 
> eMMC. 
> This section gives a brief explanation of why also.
> Chad
>
>
> On 8/5/2015 4:07 AM, lmje...@gmail.com wrote:
>
> Hi Gerald,
>
> Following the instructions on the BeagleBoard.org - getting-started 
>  webpage, my team lead and I 
> have been powering up the BBB by using the provided USB cable to plug our 
> Beagle into our computers.  We didn't find instructions on powering it 
> down.  So, we have been powering it down by simply pulling the cable out. 
>  
> By doing this, can we also get corruption?  If so, where is the shutdown 
> procedure documented?
>
> Lawrence
>
> On Sunday, October 13, 2013 at 12:19:54 PM UTC-7, Gerald wrote: 
>>
>> Nope. If you do it the way I just said, the board is powered off 
>> after it is done. Then you can pull the power.  
>>
>> Pull the power without letting the kernel unmount the eMMC or SD 
>> card, and you can get corruption. 
>>
>> Gerald
>>
>>
>>
>> On Sun, Oct 13, 2013 at 1:31 PM,  wrote:
>>
>>> So pulling out the power with properly shutting down the system 
>>> could corrupt the eMMC ??? 
>>>
>>>
>>> On Sunday, October 13, 2013 4:39:05 PM UTC+5:30, 
>>> arunbarn...@gmail.com wrote: 

 Hi,

 I am trying to use the beaglebone black (in factory default 
 settings) in a control application, where the BBB interfaces to a 20x4 
 character LCD, 18 button keypad, and a RS 232 connection using ttyO4 
 port 
 (connects to RS 485 network using appropriate drivers).

 I have almost developed the hardware and the software using Eclispe 
 C++ IDE. 

 As I am not using any batteries or other power backup devices for 
 the BBB, Do I have to implement a shutdown procedure for my users ?? 

 I have made a procedure in which the user presses a combination of 
 keys to get the shutdown option on the LCD, selecting the shutdown 
 option 
 runs the system("shutdown -h now") command in my C++ program.

 Is a shutdown procedure required for the BBB or will just pulling 
 out the +5V power jack be sufficient. 

 I have read in some sites that the eMMC could get corrupted causing 
 startup issues

 Please advise

 thanks
 a

 -- 
>>> 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.
>>>
>>
>> -- 
> 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/d/optout.
>
>
>
> -- 
> Chad Baker Memphis, TN
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> Yo

[beagleboard] my metal detector development for beaglebone black

[cosieranthony]

hi guys i am wanting to build a new type of metal detector  which in it 
self is quite complex task starting with little bits c/c++ code and tying 
to keep it simple i need to wirite 7 values of either on or off to 1 gpio 
but infact need to a total of 7 gpio's all as one cycle so i have set 
patern of  on or off values across the 7 gpios  after that patern is 
executed is anthoner fixed pattern is done 7 times which the whole thing 
keeps repeating the pattern below shows the state of the switches s57-s64 
the gpio's need to be turn on in that order to turn the transistors on if 
some could hep i would be greatful


S57 S58 S59 S60 S61 S62 S63 S64 onoffoffonn/aonn/aoff


onoffoffonn/aoffn/aon
offononoffonn/aoffn/a−








offononoffoffn/aonn/a








offoffononononoffoff
offoffonononoffoffon
offoffononoffononoff+

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

Re: [beagleboard] How to Erase the eMMC

[morgancrawford6]

how can you mark the uSD as bootable?

On Monday, May 13, 2013 at 1:25:29 PM UTC-5, RobertCNelson wrote:
>
> On Mon, May 13, 2013 at 1:22 PM, Robert P. J. Day  > wrote: 
> > On Mon, 13 May 2013, Robert Nelson wrote: 
> > 
> >> On Mon, May 13, 2013 at 1:13 PM, Robert P. J. Day <
> rpj...@crashcourse.ca > wrote: 
> >> > On Mon, 13 May 2013, Gerald Coley wrote: 
> >> > 
> >> >> Basically. But if the fingers can't handle repeatedly holding the 
> >> >> button every time they boot, all they have to do is rename the MLO 
> >> >> file to something like MMM. 
> >> > 
> >> >   and that's the fundamental test, is it? the existence of a file 
> >> > called "MLO" in the eMMC FAT partition? i thought as much, just 
> wanted 
> >> > to be sure. 
> >> 
> >> You could also toggle the 'boot flag' on the eMMC.. Then it'll default 
> >> to microSD over eMMC.. 
> >> 
> >> fdisk ${DISK} <<-__EOF__ 
> >> a 
> >> 1 
> >> w 
> >> __EOF__ 
> > 
> >   ah, that's handy to know -- if the boot process does not find a 
> > bootable partition in eMMC, it *automatically* switches to boot from 
> > uSD? 
>
> Correct.. uSD is search after eMMC, so if eMMC fails, uSD is next... 
>
> > does the uSD FAT partition need to be marked bootable? 
>
> Yeap it does, otherwise it'll fail too.. ;) 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.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] BeagleBone Black GPIO a bit slow via /dev/mem and mmap?

[Andrew P. Lentvorski]

On Monday, August 24, 2015 at 7:27:35 AM UTC-7, Charles Steinkuehler wrote:
>
>
> Optimal would be a sequence of successive stores to the set and clear 
> register, with the addresses pre-calculated and sitting in registers 
> (or with a base address and use the str instruction with an immediate 
> offset).


Good point.  I can beat the compiler into submission if I want to, but it's 
probably not worth the effort as I need to do other logic anyway.
 

> You might also need to 
> move the volatile on the variable definitions.  I'm not a "C" guru, 
> but I think: 
>
>   uint32_t volatile * gpio_setdataout_addr 
>
> ...is different from: 
>
>   volatile uint32_t * gpio_setdataout_addr 
>
> ...you want the uint32_t to be volatile, not the pointer to it.



This is one of those C quirks.  It's actually a habit from "const" but it 
applies to "volatile" as well.  Oddly, the qualifiers generally apply to 
the *left* except under certain circumstances where they can apply right. 
 This gets people into trouble when they specify:

volatile uint32_t volatile * blah;

Which is actually a *redundant* specifier as opposed to what they wanted:

volatile uint32_t * volatile blah;

Not every compiler (*especially* embedded ones) will eject a warning on the 
duplicate declaration specifier.  So, I personally always put them on the 
right to avoid the issue. 

...but I write C code like a hardware guy who programs in VHDL.  :) 
>

Not a damn thing wrong with that, thank you very much.  Software-only 
people tend to be amazed that you can write a state machine that is 
*readable* in code.  A very experienced programmer once told me: "Your code 
is the most straightforward code I have ever read."

Of course, I have to condemn you as a dirty apostate for not using Verilog. 
 :)  (Seriously, though, when is somebody going to produce an open-source 
VHDL simulator/compiler so that I can actually use it on projects?)

 

> Regardless, note that the maximum toggle rate of a GPIO pin using the 
> PRU is about 12.5 MHz, dictated by the ~40 nS required to execute a 
> write by the on-chip communication fabric (which means 80 nS period 
> for a high/low toggle of the pin).  This assumes the CPU and the PRU 
> have similar bandwidth to the L4 fabric, which may or may not be the 
> case (but I suspect is true).
>

Do you have a pointer to the reference manual for this (if not, don't waste 
a lot of time, I'll dig it out)?  Given that this seems to be *very* 
fundamental about understanding the architecture, I really probably need to 
chase this down exactly.

Thanks for the advice.  I appreciate your taking the time on this.

-- 
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 doesn't sometimes start. Only Power LED is on

[evilwulfie]

IF not using USB ground Vusb been working for me.


On 8/24/2015 11:33 AM, Dr. Michael J. Chudobiak wrote:
> On 08/13/2015 07:28 PM, Andrew Glen wrote:
>> For what it's worth, I run hundreds of 24/7 unattended systems with the
>> BBB. We have tested reboots into the tens of thousands, and with some
>> work we are able to achieve zero failures.
>>
>> Off the top of my head here are the key platform specific things I do
>> that you might want to look at:
>>
>> 1) Mod the h/w to avoid the Ethernet issue (from another post) (this may
>> be fixed in the latest kernel, but we locked the s/w down a while back.
>
> Andrew,
>
> Could you elaborate on what hardware changes you made to fix the
> ethernet issue?
>
> - Mike
>

-- 
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 doesn't sometimes start. Only Power LED is on

[Dr. Michael J. Chudobiak]

On 08/13/2015 07:28 PM, Andrew Glen wrote:

For what it's worth, I run hundreds of 24/7 unattended systems with the
BBB. We have tested reboots into the tens of thousands, and with some
work we are able to achieve zero failures.

Off the top of my head here are the key platform specific things I do
that you might want to look at:

1) Mod the h/w to avoid the Ethernet issue (from another post) (this may
be fixed in the latest kernel, but we locked the s/w down a while back.


Andrew,

Could you elaborate on what hardware changes you made to fix the 
ethernet issue?


- Mike

--
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] Additional Cape pins in diagram Fig 70 in the SRM?

[Gerald Coley]

What board do you have?

Gerald


On Sat, Aug 22, 2015 at 8:48 PM, Rick Mann  wrote:

> In Figure 70, it shows the mechanical dimensions of the Cape, as well as
> the locations of the mounting holes and headers P8 and P9. But it also
> shows a set of 10 pins near the Ethernet jack notch. What are those
> intended to be?
>
> There are also four test points (TP5 - 8) that I believe connect to the
> PMIC. What are the mechanical locations of those relative to the Cape
> origin, and what hole size are they? I'd like to add battery backup to my
> Cape, and putting pins right through these would be easiest.
>
> Lastly, what are the positions of the console port pins relative to the
> origin? It would be easier for me to pass those up through my Cape than to
> try to connect to them with a Cape attached.
>
> BTW, I looked online for this information and couldn't find it via Google
> searches.
>
> Thanks!
>
> --
> Rick Mann
> rm...@latencyzero.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.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/

-- 
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: BeagleBoard-X15 - seriously? :)

[Gerald Coley]

It is called the BeagleBoard-X15. Not BeagleboneX15.

Gerald


On Sun, Aug 23, 2015 at 11:46 PM, bharat gohil  wrote:

> Find following patch to run two different OS on beagleboneX15 in AMP mode,
> http://lists.denx.de/pipermail/u-boot/2015-August/222339.html
>
> Best Regards,
> Bharat Gohil
>
>
>
> On Monday, March 30, 2015 at 7:09:24 PM UTC+5:30, bharat gohil wrote:
>>
>>
>> 1) FreeRTOS on one Cortex-A15, GNU/Linux on the other
>> I am trying to run this combination in AMP mode.
>> I have successfully run Linux one and other core running barematal
>> application.
>> Possibly Run FreeRTOS instead of barematal application.
>>
>> 2)Running hypervisor in SMP mode
>> Run Linux and FreeRTOS on hypervisor.
>>
>> 3) FreeRTOS on one Cortex-M4, GNU/Linux on the Cortex-A15 cores,...
>> After completing "FreeRTOS on one Cortex-A15, GNU/Linux on the other" I
>> will move to this.
>>
>> I will update you.
>>
>> Regards,
>> Bharat Gohil
>> ghl.b...@gmail.com
>>
>>
>> On Sunday, November 9, 2014 at 10:46:09 AM UTC+5:30, robert.berger wrote:
>>>
>>> Hi,
>>>
>>> On Saturday, November 8, 2014 6:31:25 PM UTC+2, sixvolts wrote:

 Any ideas how this compares to the wandboard quad? 4x Cortex-A9 vs 2x
 Cortex-A15

>>>
>>> Well the Cortex-A15 includes full hardware visualization, which the
>>> Cortex-A9 lacks. If this new board with multiple Cortex-A15 and dual
>>> Cortex-M4 is reasonably priced it might used as a references board for an
>>> open source Linux/RTOS solution.
>>>
>>> *) FreeRTOS on one Cortex-A15, GNU/Linux on the other
>>> *) FreeRTOS on one Cortex-M4, GNU/Linux on the Cortex-A15 cores,...
>>>
>>> anyone interested in something like this?
>>>
>>> Regards,
>>>
>>> Robert
>>>
>>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/

-- 
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: Booting issue with a cape - servo input load

[Frédéric]

Le Monday 24 August 2015, Graham a écrit :

> There is a compromise between the value of the resistors used for boot 
> programming, 
> and the permanent load they put on the I/O system during operational I/O.
> 
> So, yes, you can lower the value of the programming resistors, if it
> both solves your
> boot problem, and does not disturb the way the I/O works when the system
> is in normal 
> operation.  At some point it will.  The output drive capability of the
> GPIO on the Sitara 
> is limited. Make sure you understand it.
> 
> And make sure you are allowing for noise margin on both the boot logic 
> signals and your 
> operating logic signals.  A battery powered motor and servo system can
> have a lot of 
> electrical noise, both on the power and the ground system.  If you have 
> system noise
> getting into the boot and control logic, you end up with intermittent 
> problems that
> are extremely hard to debug.

Thanks for the advices! I'll make some tests.

-- 
Frédéric

-- 
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: Booting issue with a cape - servo input load

[Graham]

There is a compromise between the value of the resistors used for boot 
programming, 
and the permanent load they put on the I/O system during operational I/O.

So, yes, you can lower the value of the programming resistors, if it both 
solves your
boot problem, and does not disturb the way the I/O works when the system is 
in normal 
operation.  At some point it will.  The output drive capability of the GPIO 
on the Sitara 
is limited. Make sure you understand it.

And make sure you are allowing for noise margin on both the boot logic 
signals and your 
operating logic signals.  A battery powered motor and servo system can have 
a lot of 
electrical noise, both on the power and the ground system.  If you have 
system noise
getting into the boot and control logic, you end up with intermittent 
problems that
are extremely hard to debug.

--- Graham

==

On Monday, August 24, 2015 at 6:41:35 AM UTC-5, Frédéric wrote:
>
> Le 11/08/2015, Graham a écrit : 
>
> > If you look at the diagrams in the System Reference Manual, the BBB uses 
> > 100K Ohm pull up and pull down resistors to tell the processor how to 
> > boot.  So any load low enough to cause a line with 100K Ohm pull up or 
> > pull down to change logic state will cause boot problems.  I would 
> > estimate that any load, less than 200 K Ohms can cause this problem, 
> > even though it is an "Input". 
>
> I guess that only pull-up boot pins are concerned by a too low load? 
>
> Do you think I could add another resistor in // with the 100k of the BBB, 
> to try to avoir it? 
>
> -- 
> Frédéric 
>

-- 
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] Uncompressing Linux... done, booting the kernel.

[Robert Nelson]

On Sun, Aug 23, 2015 at 10:11 PM, TheCajun  wrote:
> On 2015-08-22 13:13, Robert Nelson wrote:
>>
>> As you seem to ignore the replies to this exact same question you asked
>> before..
>>
>> On Aug 21, 2015 6:50 PM,  wrote:
>>>
>>>
>>> Below is the text from console.  I used this image for a file system.
>>>
>>> Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11
>>>
>>> This image boots and I have network.  I then built 3.0.14 I downloaded
>>
>> from https://www.kernel.org/pub/linux/kernel/.  I used
>> beagleboard_defconfig.  I made no changes.  I copied uImage to the second
>> partition under /boot (where the working kernel is).  So I now have in the
>> directory uImage-3.0.14+ (Angstrom's uImage) and my uImage-3.0.14.
>>
>> 3.0.14+ is NOT the same as 3.0.14, you need to add 'ALL' patches that made
>> it a '+'
>
>
> I tried to get the source for 3.0.14+.  The image that was create does not
> have any source that I can find (or patches).  Which is why I went to
> kernel.org
> Does anyone know where I can find source/patches for 3.0.14+?

https://github.com/Angstrom-distribution/meta-ti/blob/master/recipes-kernel/linux/linux_3.0.bb

&

https://github.com/Angstrom-distribution/meta-ti/tree/master/recipes-kernel/linux/linux-3.0

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: Booting issue with a cape - servo input load

[Graham]

This switch is required to be powered from 5V, but then can handle 3.3 V 
bus, so probably OK.
Just make sure you have enough noise margin on the control signals, so 
motor and ground noise does not cause false control switching.
--- Graham

==

On Monday, August 24, 2015 at 3:13:31 AM UTC-5, Frédéric wrote:
>
> Le 18/08/2015, Graham a écrit : 
>
> > I was thinking more of something like the 74CBTLV3126 bus switch which 
>
> Is the SN74CBT3245 (8 channels) OK too? 
>
> http://www.farnell.com/datasheets/1857534.pdf 
>
> -- 
> Frédéric 
>

-- 
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 GPIO a bit slow via /dev/mem and mmap?

[Charles Steinkuehler]

On 8/24/2015 9:02 AM, Andrew P. Lentvorski wrote:
> 
> The assembly code looks optimal at 4 instructions per toggle (I'm using 
> clang):
> .loc2 80 2  @ gpi.c:80:2
> ldr r1, [sp, #28]
> str r0, [r1]
> .loc2 81 9  @ gpi.c:81:9
> ldr r1, [sp, #32]
> str r0, [r1]
> .loc2 82 2  @ gpi.c:82:2
> ldr r1, [sp, #28]
> str r0, [r1]
> .loc2 83 9  @ gpi.c:83:9
> ldr r1, [sp, #32]
> str r0, [r1]

That is not optimal, loads are expensive (although I would have
thought the stack would be cached).

Optimal would be a sequence of successive stores to the set and clear
register, with the addresses pre-calculated and sitting in registers
(or with a base address and use the str instruction with an immediate
offset).  You can probably coerce the C compiler into doing this for
you if you setup a struct or array pointer for the set/clear registers
instead of using the two volatile pointers.  You might also need to
move the volatile on the variable definitions.  I'm not a "C" guru,
but I think:

  uint32_t volatile * gpio_setdataout_addr

...is different from:

  volatile uint32_t * gpio_setdataout_addr

...you want the uint32_t to be volatile, not the pointer to it.

I'd still set this up more like:

  struct reg {
clr uint32_t;
set uint32_t;
  }

  volatile reg * gpio_reg = NULL;
  ...
  gpio_reg.set = PIN_17;
  gpio_reg.clr = PIN_17;

...but I write C code like a hardware guy who programs in VHDL.  :)

Regardless, note that the maximum toggle rate of a GPIO pin using the
PRU is about 12.5 MHz, dictated by the ~40 nS required to execute a
write by the on-chip communication fabric (which means 80 nS period
for a high/low toggle of the pin).  This assumes the CPU and the PRU
have similar bandwidth to the L4 fabric, which may or may not be the
case (but I suspect is true).

So it looks like you've got some room for improvement, but you're not
off by an order of magnitude or anything.

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

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

[beagleboard] BeagleBone Black GPIO a bit slow via /dev/mem and mmap?

[Andrew P. Lentvorski]

Hi, folks,

I have been trying to bit bang an interface on the GPIO pins.  I looked at 
a bunch of the tutorials on the web and managed to build something that 
worked.  However, the speed seems to be a bit slower than I would expect.

My scope shows that I am running at about 2.95MHz (It also roughly matches 
the result from here--http://chiragnagpal.com/examples.html of 2.78MHz). 
 That seems slow--I would have expected closer to 25MHz--so I think I'm an 
order of magnitude off somewhere  The assembly code seems to be as 
expected, so my question is:

What is slowing things down?

Since the assembly is basically ldr/str in a chain, something must be 
stalling the pipeline, but I don't know what.

Suggestions would be appreciated.

I'm running Debian Jessie Linux arm 4.1.6-ti-r11 #1 SMP PREEMPT Tue Aug 18 
21:36:11 UTC 2015 armv7l GNU/Linux

Thanks.


The assembly code looks optimal at 4 instructions per toggle (I'm using 
clang):
.loc2 80 2  @ gpi.c:80:2
ldr r1, [sp, #28]
str r0, [r1]
.loc2 81 9  @ gpi.c:81:9
ldr r1, [sp, #32]
str r0, [r1]
.loc2 82 2  @ gpi.c:82:2
ldr r1, [sp, #28]
str r0, [r1]
.loc2 83 9  @ gpi.c:83:9
ldr r1, [sp, #32]
str r0, [r1]



The C Code I used to toggle the pin P9_23 (GPIO1_17):


#include 
#include 
#include 
#include 
#include 
#include  

#include 
#include 

#define GPIO_OE 0x134
#define GPIO_SETDATAOUT 0x194
#define GPIO_CLEARDATAOUT 0x190


// Hunt these addresses down from ls -al /sys/devices/platform/ocp | grep 
gpio
// You can also pull them from the TI manual (spruh73l.pdf)
#define GPIO0_BASE 0x44E07000
#define GPIO1_BASE 0x4804C000
#define GPIO2_BASE 0x481AC000
#define GPIO3_BASE 0x481AE000

#define GPIO_SIZE  0x1000


#define PIN_17 ((uint32_t)1<<17)


uint32_t ui32Base[] = {GPIO0_BASE, GPIO1_BASE, GPIO2_BASE, GPIO3_BASE};
uint8_t volatile * bbGPIOMap[] = {0, 0, 0, 0};


int main(int argc, char *argv[])
{
unsigned int ui;

uint32_t volatile * gpio_oe_addr = NULL;
uint32_t volatile * gpio_setdataout_addr = NULL;
uint32_t volatile * gpio_cleardataout_addr = NULL;


int fd = open("/dev/mem", O_RDWR);

for(ui=0; ui<4; ++ui) {
bbGPIOMap[ui] = mmap(0, GPIO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 
ui32Base[ui]);
assert(bbGPIOMap[ui] != MAP_FAILED);
}


gpio_oe_addr = (uint32_t volatile *)(bbGPIOMap[1] + GPIO_OE);
gpio_setdataout_addr = (uint32_t volatile *)(bbGPIOMap[1] + 
GPIO_SETDATAOUT);
gpio_cleardataout_addr = (uint32_t volatile *)(bbGPIOMap[1] + 
GPIO_CLEARDATAOUT);



*gpio_oe_addr = *gpio_oe_addr & ~PIN_17;

while(1) {
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
}

//*(uint32_t volatile *)(bbGPIOMap[3] + GPIO_SETDATAOUT) = (uint32_t)1 
<< 14;
//*(uint32_t volatile *)(bbGPIOMap[3] + GPIO_CLEARDATAOUT) = 
(uint32_t)1 << 14;

close(fd);
return 0;
}



-- 
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] Running a BBB from batteries

[Frédéric]

Le 06/08/2015, Frédéric a écrit :

> I received my 32 channels servo cape 
>  PCB (from 
> SeeedStudio), and started to make some tests with my little hexapod 
> .
> 
> Now comes the problem of powering up the BBB. My first idea was to use 2 
> Ni-Mh batteries: a big one for the servos, and a smaller one for the BBB.
> 
> I then found this very interesting topic: BBB - Rechargeable on-board 
> battery system 
> .
>  
> So, I plan to do this: connect a tiny LiPo battery to the PMIC, and
> connect the big battery (6V Ni-Mh) to both servos supply and to the BBB
> (through a 5V regulator, which I can put on the cape).
> 
> My next Hexapod will use TowerPro MG996R servos, which are much biger
> than the 9g of the prototype. When moving, the voltage of the battery
> can fall, and may not be enough to power the BBB. So, the tiny LiPo will
> take over, and continue to power the BBB.
> 
> But this may happen very often, while the hexapod walk; so the BBB may 
> quickly switches from on battery to the other. Is it a problem?

No idea?

Also, is the LiPo battery still charging while the BBB is off (after a
halt)?

-- 
Frédéric

-- 
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: Booting issue with a cape - servo input load

[Frédéric]

Le 11/08/2015, Graham a écrit :

> If you look at the diagrams in the System Reference Manual, the BBB uses 
> 100K Ohm pull up and pull down resistors to tell the processor how to 
> boot.  So any load low enough to cause a line with 100K Ohm pull up or
> pull down to change logic state will cause boot problems.  I would
> estimate that any load, less than 200 K Ohms can cause this problem,
> even though it is an "Input".

I guess that only pull-up boot pins are concerned by a too low load?

Do you think I could add another resistor in // with the 100k of the BBB,
to try to avoir it?

-- 
Frédéric

-- 
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] BeagleBone Black GPIO access via mmap is slow

[Andrew P. Lentvorski]

Hi, folks,

I've been poking around to get GPIO to work via /dev/mem and mmap.  After 
finally pushing a lot of things around, I finally managed to pull the 
various flavors of tutorials together into something I now understand 
(mostly).

However, what I *don't* understand is that when I put my scope on the pin, 
I see it toggle at 2.95MHz.  That seems slow.  This is the same frequency 
as here: http://chiragnagpal.com/examples.html

The question is: Why?

I could understand if it was something like 30MHz, but 3MHz seems off by an 
order of magnitude.  And when something seems off in embedded programming, 
it's usually a bug waiting to bite you when you least need it.

I'm on a BeagleBoard Black with Debian Jessie Linux arm 4.1.6-ti-r11 #1 SMP 
PREEMPT Tue Aug 18 21:36:11 UTC 2015 armv7l GNU/Linux

Any suggestions?  Given that the assembly seems to be spot on, *something* 
appears to be stalling the pipeline.

Is the core being throttled?  Is the peripheral bus at some strange 
frequency?  Is the memory mapping hardware inserting cycles?  I'm 
completely at a loss.

Thanks for any advice.


The assembly looks exactly optimal with a ldr/str sequence at maximum 
density (I'm using clang):

.loc 2 83 9  @ gpi.c:83:9
ldr r1, [sp, #32]
str r0, [r1]
.loc 2 84 2  @ gpi.c:84:2
ldr r1, [sp, #28]
str r0, [r1]
.loc 2 85 9  @ gpi.c:85:9
ldr r1, [sp, #32]
str r0, [r1]
.loc 2 86 2  @ gpi.c:86:2
ldr r1, [sp, #28]
str r0, [r1]



And here's the C code I used to generate the pulse train on P9 Pin23 
(GPIO1[17])



#include 
#include 
#include 
#include 
#include 
#include  

#include 
#include 

#define GPIO_OE 0x134
#define GPIO_SETDATAOUT 0x194
#define GPIO_CLEARDATAOUT 0x190


// Hunt these addresses down from ls -al /sys/devices/platform/ocp | grep 
gpio
// You can also pull them from the TI manual (spruh73l.pdf)
#define GPIO0_BASE 0x44E07000
#define GPIO1_BASE 0x4804C000
#define GPIO2_BASE 0x481AC000
#define GPIO3_BASE 0x481AE000

#define GPIO_SIZE  0x1000


#define PIN_17 ((uint32_t)1<<17)


uint32_t ui32Base[] = {GPIO0_BASE, GPIO1_BASE, GPIO2_BASE, GPIO3_BASE};
uint8_t volatile * bbGPIOMap[] = {0, 0, 0, 0};


int main(int argc, char *argv[])
{
unsigned int ui;

uint32_t volatile * gpio_oe_addr = NULL;
uint32_t volatile * gpio_setdataout_addr = NULL;
uint32_t volatile * gpio_cleardataout_addr = NULL;


int fd = open("/dev/mem", O_RDWR);

for(ui=0; ui<4; ++ui) {
bbGPIOMap[ui] = mmap(0, GPIO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 
ui32Base[ui]);
assert(bbGPIOMap[ui] != MAP_FAILED);
}


gpio_oe_addr = (uint32_t volatile *)(bbGPIOMap[1] + GPIO_OE);
gpio_setdataout_addr = (uint32_t volatile *)(bbGPIOMap[1] + 
GPIO_SETDATAOUT);
gpio_cleardataout_addr = (uint32_t volatile *)(bbGPIOMap[1] + 
GPIO_CLEARDATAOUT);



*gpio_oe_addr = *gpio_oe_addr & ~PIN_17;

while(1) {
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
}

close(fd);
return 0;
}



-- 
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: [chrony-users] Fwd: Chrony malfunctioning at beaglebones

[Nuno Gonçalves]

It seems there is a serious problem with the clock system since Kernel 3.16.

Robert: is there someone from TI that could take a look at this before
we start another wonderful bisect?

Thanks,
Nuno

On Mon, Aug 24, 2015 at 10:46 AM, Miroslav Lichvar  wrote:
> On Fri, Aug 21, 2015 at 07:05:38PM +0100, Nuno Gonçalves wrote:
>> Thank you so much. I've sent you the hostnames of a beaglebone white
>> and a beaglebone black that are set with your public key.
>>
>> I took a few days while I confirmed what I could. In fact I've tried
>> several kernel versions and I see that up to 3.15.10-bone8 the clock
>> is working properly. After 3.16 and until the most recent 4.2 RC, it
>> is malfunctioning.
>>
>> If you have a minute to login at the machines and are able to narrow
>> in any way which part of the kernel clocks is at fault it might be
>> easier have it fixed at the Linux level.
>
> I did some tests with the adjtimex utility while chronyd was just
> reporting measured offset and not controlling the clock. It looks like
> there is a problem with large frequency offsets. There seems to be a
> maximum offset the kernel is willing to apply to the clock (about 1000
> ppm) and any attempts to slow down or speed up the clock more are
> ignored. This breaks the chrony control loop badly.
>
> As a workaround, I set the maxslewrate option to 100 ppm and started
> chronyd with "0.0 1.0" in the driftfile to avoid large frequency
> adjustments and it seems it was able to settle down.
>
> I'm not sure where the problem could be. Looking at the log for the
> linux/kernel/time directory between 3.15 and 3.16 I don't see anything
> suspicious. Could be something in the arch-specific code.
>
> You could try to add the nohz option to the kernel command line, that
> would suggest it's a problem with the internal timekeeping loop.
>
> I think this is a serious bug that needs to be fixed. If you file any
> bug reports, please let us know.
>
> Thanks,
>
> --
> Miroslav Lichvar
>
> --
> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
> with "unsubscribe" in the subject.
> For help email chrony-users-requ...@chrony.tuxfamily.org
> with "help" in the subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>

-- 
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: Booting issue with a cape - servo input load

[Frédéric]

Le 18/08/2015, Graham a écrit :

> I was thinking more of something like the 74CBTLV3126 bus switch which

Is the SN74CBT3245 (8 channels) OK too?

http://www.farnell.com/datasheets/1857534.pdf

-- 
Frédéric

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