sub3=EmailSignature>
>
> On Fri, Jun 11, 2021 at 12:33 PM, Dennis Lee Bieber
> wrote:
>
> On Fri, 11 Jun 2021 09:44:27 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> wrote:
>
> >I can have PRU1 do all the ADC configuration including se
Good info. I'm going to set up some testing. Thank you!
On Monday, June 14, 2021 at 3:23:29 AM UTC-4 lazarman wrote:
> #The question is can PRU0 read FIFO0 while PRU1 #might try to read FIFO1
> at the same time?
>
> If these FIFOS are in Data RAM it's recommended to use shared memory.
>
I am thinking that I'll have PRU0 do all the configuration and enabling of
the TSC and have the values for the two sensors that I want PRU1 to monitor
put in FIFO1. I'll have PRU0 only read from FIFO0 and let PRU1 only read
from FIFO1.
I will set up the three I want to read in one-shot mode
PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> wrote:
>
> >I can have PRU1 do all the ADC configuration including setting up steps
> 1,
> >2 and 3 to read three analog lines in one-shot mode while steps 4 & are
> set
> >up to read the other two analog lines in continous mode. I
I have asked this of TI but haven't really gotten a firm answer and I can't
seem to find a clear discussion in the Technical Reference Manual.
I would like to set up PRU1 to monitor two analog input lines and take an
action on two GPIOs depending on the values it reads. It would just be
PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> wrote:
>
>
> >Here's the code snippet with the two variables in bold. If those lines of
> >code do not exist, the host doesn't hear from the PRU.
>
> Such formatting does not get through the gmane list<>newsgrou
gt;> is.
>>
>> Walter
>>
>> On Tue, May 18, 2021 at 8:14 PM Dennis Lee Bieber
>> wrote:
>>
>>> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
>>> gmane.comp.hardware.beagleboard.user Walter Cromer
>>> wrote:
>>>
>>>
>>> >Here's the code snipp
:
> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> wrote:
>
>
> >Here's the code snippet with the two variables in bold. If those lines
> of
> >code do not exist, the host doesn't hear from the PRU.
>
>
ried it.
>>
>> Mark
>>
>>
>>
>> Sent from Yahoo Mail on Android
>> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>>
>> On Tue, May 18, 2021 at 1:30 PM, Walter Cromer
>>
ernal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, May 18, 2021 at 1:30 PM, Walter Cromer
> wrote:
>
> I've been pulling my hair out over a really weird problem and after trying
> everything I know to try, I'm posting it here in hopes of someone seeing
> the pro
Regardless of the timing, you want to store 20,000 values but I think
you've calculated correctly that you can only store 7,168 values in the 28k
of combined PRU memory and that would only be true if some of the PRU
memory wasn't used by your PRU program when it's loaded.
So are you trying to
I've been pulling my hair out over a really weird problem and after trying
everything I know to try, I'm posting it here in hopes of someone seeing
the problem.
I am running a Beaglebone Black. The output of version.sh is at the end
of this post.
Linux beaglebone 4.19.94-ti-r61 #1buster
gt; @echo "-Starting PRU $(PRUN)"
> @echo start > $(PRU_DIR)/state
> else ifeq ($(PROC),tidl)
> ti-mct-heap-check -c
> sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v
> vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ &
Remoteproc is working fine in our application. I made a stupid mistake that
was causing my problem. It's fixed and working fine now. I'm sure it
won't be the last issue I have because I'm human and I make mistakes.
My stupid mistake was that I had declared another variable in the same
t;
> Em 4 de mai. de 2021, à(s) 13:16, Walter Cromer <
> wal...@edenconceptsllc.com> escreveu:
>
> I'm on a BBB Wireless running
>
>
> Linux beaglebone 4.19.94-ti-r61 #1buster SMP PREEMPT Wed Mar 31 15:23:20
> UTC 2021 armv7l GNU/Linux
>
> The version.sh outp
I am glad to have helped a little bit. Stick with it. When it clicks and
you start really moving forward I think you'll be pleased.
Can you share the changes to the Makefile that you made? I'm curious if it
might help me.
Right now I am reading the ADC every 2.7ms. I'm reading three
I'm on a BBB Wireless running
Linux beaglebone 4.19.94-ti-r61 #1buster SMP PREEMPT Wed Mar 31 15:23:20
UTC 2021 armv7l GNU/Linux
The version.sh output is at the end of this post.
I need to put readings from two analog inputs into two arrays so I can do
some calculations on them. Basically,
I'm getting this same message on a BBB Wireless now and I agree its
annoying. Any suggestions to get this fixed would be greatly appreciated.
I've recently upgraded and here's the output of version.sh
debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
er thread was what I was referring to.
> Does the E2E forum support cloud 9 dev on BBB???
>
>
> I'm also curious how you actually build/modify your Linux kernel with no
> Linux box.
>
> Walter Cromer
> wrote:
> changed the code to this and get the same error.
>
>
ailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, May 3, 2021 at 2:35 PM, Walter Cromer
> wrote:
>
> It was disappointing, to say the least that they said there wasn't an easy
> way to transfer the firmware but I believe that's what they me
;
>
>
>
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, May 3, 2021 at 10:24 AM, Walter Cromer
> wrote:
i, 30 Apr 2021 08:22:10 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> wrote:
>
>
> >I checked with ls -ls /dev/mem logged in as debian and it's there.
> >
> debian@beaglebone:~$ ls -ls /dev/mem
> 0 crw-r- 1 root kmem 1, 1 Apr 30 12:06 /dev
I just went through this pain and the people in this group were awesome
help.
I needed to read three analog inputs and it was a bear but once I got it,
it has been going well.
You don't mention the OS of your development platform or I may have missed
it. I'm on a Windows 10 box and using a
:
MODEL=TI_AM335x_BeagleBone_Black_Wireless,TARGET=,COMMON=/var/lib/cloud9/common
make: 'pwm-test' is up to date.
Servo tester
ERROR: could not open /dev/mem.
I checked with ls -ls /dev/mem logged in as debian and it's there.
Any ideas?
On Friday, April 30, 2021 at 10:06:42 AM UTC-4 Walter Cromer
.\n");
>>
>> fd = open ("/dev/mem", O_RDWR | O_SYNC);
>> if (fd == -1) {
>> printf ("ERROR: could not open /dev/mem.\n\n");
>> return 1;
>> }
>>
>>
>> When I look for /dev/mem it doesn't
I look for /dev/mem it doesn't exist whether logged in as debian or
root
On Thursday, April 29, 2021 at 3:15:10 PM UTC-4 Walter Cromer wrote:
> Mark - I'm integrating the concepts from the PRUCookbook so I can send
> some control parameters entered by the user in the host side progr
Mark - I'm integrating the concepts from the PRUCookbook so I can send some
control parameters entered by the user in the host side program and pass
them over to the PRU0 firmware.
I'm getting this error when I try to compile the code.
Setting up pru0 memory access.
ERROR: could not open
You are correct to mention this TJF. In production, I won't bother to do
convert it to a human-readable number. It helps with debugging right now
though.
On Thursday, April 22, 2021 at 3:26:12 AM UTC-4 TJF wrote:
> For all who want to learn:
>
> Walter is formating a human readable number
ink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Wed, Apr 21, 2021 at 2:55 PM, Walter Cromer
> wrote:
>
> Well the solution to the overflow was actually simple. I had used some
> examp
and not
before. So when I issued the overflow event reset, the counter was still
at 0x which caused an immediate overflow event.
Ugh. Live and learn.
On Wednesday, April 21, 2021 at 12:28:14 PM UTC-4 Walter Cromer wrote:
> I'm attempting something very similar to what you were working on. If
I'm attempting something very similar to what you were working on. If you
are willing, please share how you eventually did this. Did you use the IEP
clock or the PRU's cycle counter? I have IEP working with the iep_clk
(although I'm having terrible RPMSG problems right now).
Also, I can't
. I
> think you will see that it is an address in the PRU address space.
>
>
>
> Graham
>
>
>
> *From:* beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] *On
> Behalf Of *Walter Cromer
> *Sent:* Tuesday, April 20, 2021 10:34 AM
> *To:* BeagleBo
roid
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, Apr 20, 2021 at 12:33 PM, Walter Cromer
> wrote:
>
> I am using a Beaglebone Black and C
I am using a Beaglebone Black and C to read analog inputs with PRU0 and
return the data to a host program using RPMSG.
Basically, I read the data from FIFO0 fine, strip the step id from it and
copy it into an element of a character array in the PRU code.
Data = HWREG(SOC_ADC_TSC_0_REGS +
PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> wrote:
>
>
> >So if I had an application that had a sensor A that needs to be read
> every
> >10ms and sensor B that only needs to be read every minute, I could wire
> >channel 1 to sensor A and as
/devices/platform/ocp/ocp:P9_31_pinmux/state failed,
No such file or directory
I get the same error when I execute this as root.
On Friday, April 16, 2021 at 6:43:46 AM UTC-4 Walter Cromer wrote:
> Yes. It’s throwing an error when I do that. I don’t think it was before
> but I could be mi
As I get a better understanding and experience this may change, but right
now I don't think it can handle the volume of data we need to move between
systems. And, that volume is only needed during R The production
system will not need to keep that data.
So, my plan is to instance arrays on
:00 PM Darren Freed wrote:
> Have you set the pins with config-pin to pruout or pruin? This caught me
> out a few times when I was learning PRU.
>
>
> On Thu, Apr 15, 2021 at 7:15 AM Walter Cromer
> wrote:
>
>> I'm sticking with remoteproc for now. I spent most o
read.
BTW - I don't have a real-world application like this but I guess someday I
could.
This is a very flexible system!
On Wednesday, April 14, 2021 at 11:03:30 AM UTC-4 Walter Cromer wrote:
> The TSC_ADC only has 8 channels. So why are there 16 STEP registers?
>
> On Wednesday, April 1
s can you share a link
>
> Thanks
>
> Mark
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Thu, Apr 1
from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Thu, Apr 15, 2021 at 8:15 AM, Walter Cromer
> wrote:
>
> I'm sticking with rem
I'm sticking with remoteproc for now. I spent most of yesterday reading
TI's documentation and the Beaglebone Black SRM in detail and believe I
have a much better handle on how this works now.
My plan is to allocate memory space in pru0's RAM for the data storage and
then have an ARM program
72968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Wed, Apr 14, 2021 at 10:58 AM, Walter Cromer
> wrote:
>
> So I looked over the libpruio page and it looks great. My head's spinning
> a bit
So I looked over the libpruio page and it looks great. My head's spinning
a bit between remoteproc, uio, and libpruio options but I'd like to try
libpruio.
I don't want to break remoteproc if I set up to use libpruio. Will that
happen?
Also, I'm running Buster (version.sh) at the bottom of
The TSC_ADC only has 8 channels. So why are there 16 STEP registers?
On Wednesday, April 14, 2021 at 11:02:56 AM UTC-4 Walter Cromer wrote:
> My setup is a Windows 10 PC with a Black connected via USB or a Black
> wireless connected via wi-fi. So far I have done all the C devel
My setup is a Windows 10 PC with a Black connected via USB or a Black
wireless connected via wi-fi. So far I have done all the C development on
the ARM side with Cloud9 and only occasionally use Nano. It's met my needs
just fine so far but this is getting more complex. I installed TI's CCS
t; Not for me.
>
> Mark
>
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, Apr 13, 2021 at 9:54 AM, Dennis Lee Bieber
> wrote:
>
> On Mo
Yeah, I woke up realizing what a dunce I was reading it the way I was.
HWREG equates to (*((volatile unsigned int *) (x)))
On Tuesday, April 13, 2021 at 10:54:36 AM UTC-4 Dennis Bieber wrote:
> On Mon, 12 Apr 2021 13:08:48 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter
ARM timings are important. I
>>>> see you asked me about rproc that I don't use Linux that was TJ comments.
>>>>
>>>> I'm afraid the PRU was marketed to you as the answer by people that
>>>> don't understand your timing requirement. Lot's of script kiddies an
hoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, Apr 12, 2021 at 3:08 PM, Walter Cromer
> wrote:
>
> I'm working through this and learning a lot. But a
UTC-4 Walter Cromer wrote:
> I'll look at that. I thought remoteproc was the way of the future so I
> was heading down that path. And if in production I don't need to do a lot
> of data transfer, does it make sense to use uio_pruss/libpruio ( I don't
> know much about these, i
I'll look at that. I thought remoteproc was the way of the future so I was
heading down that path. And if in production I don't need to do a lot of
data transfer, does it make sense to use uio_pruss/libpruio ( I don't know
much about these, it's probably evident that I don't know much about
Thanks, TJF! This sounds like good advice but tough tricks to learn! The
more I think through the architecture of my solution, the more I realize
the PRU code needs to do. In our lab evaluation setup, I need the voltages
measured by the ADC for analysis to develop base algorithms for
's most excellent PRU cookbook
> <https://markayoder.github.io/PRUCookbook/#_pru_cookbook>. With those
> two resources, you should be able to do what you're hoping to do.
>
> Good luck!
> df
>
> On Fri, Apr 9, 2021 at 1:00 PM Walter Cromer
> wrote:
>
>> I
Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Fri, Apr 9, 2021 at 1:16 PM, Walter Cromer
> wrote:
>
> Thanks Dennis. That is in sync with my
When I try to run this in Cloud9, I'm getting this error. I'm not sure
where type __far is defined but apparently I'm missing that definition. I
have to copy pru_cfg.h over to /usr/include manually to get this far.
Maybe there are other include files that are missing that it hasn't warned
Thanks Dennis. That is in sync with my research.
On Friday, April 9, 2021 at 2:00:07 PM UTC-4 Dennis Bieber wrote:
> On Fri, 9 Apr 2021 09:30:53 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> wrote:
>
> >We are still experimenting but our preliminary
transfer rate between PRU and ARM us determistic if linux
> is used .
>
> Hopefully this makes sense if not ask but I'd follow up with more detail
>
> Mark
>
>
> *From: *"beagl...@googlegroups.com" on behalf
> of Walter Cromer
> *Reply-To: *"beagl...@
We are still experimenting but our preliminary calculations lead us to
believe a reading every 50 microseconds will be sufficient. We can probably
get by with 100 microseconds if we have to but I think the BBBw can easily
sample at this rate, right?
WC
On Friday, April 9, 2021 at 11:58:29 AM
Thanks, I'll check that out!
On Friday, April 9, 2021 at 11:19:47 AM UTC-4 pierric...@gadz.org wrote:
> Hi,
> I believe there are some simple ADC-read example directly in the image
> under /var/lib/cloud9/Techlab/.challenges, or here:
>
Understood. Our application won't require FAA or FDA approval but it
definitely needs the more deterministic performance of a bare bones app so
I'm heading in the direction of the ADC being read by a PRU program and
communicating back to the ARM for other processes (UI, reading other
Thanks! I believe you are right and I've already started working with
this. I will check out libpruio. I'm starting to believe it isn't quite
as difficult as a I thought it might be.
Maybe you can answer a quick, related question.
I'm looking at some example code and there references
I'm running a BBB Wireless. The OS version, version.sh output, etc. are
below.
We're sensor outputs on AIN4 and AIN0 with C using the code below. The
intervals between readings is fairly constant at about 350 uS but there is
periodically, about every 25 readings, a reading interval of
_us > TimeToRead) KeepReading = 0;
}
}
}
On Thursday, February 18, 2021 at 2:36:45 PM UTC-5 Walter Cromer wrote:
> Yes I did and it did not work on my system. I don't remember why now.
>
> On Thursday, February 18, 2021 at 1:47:29 PM UTC-5 Dennis Bieber wrote:
>
>
Yes I did and it did not work on my system. I don't remember why now.
On Thursday, February 18, 2021 at 1:47:29 PM UTC-5 Dennis Bieber wrote:
> On Thu, 18 Feb 2021 08:27:48 -0800 (PST), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> wrote:
>
> >I think if I c
> milliseconds can, and will likely, change depending on what we are
>>>>>> processing with these valves. I get that input at the start of the
>>>>>> main
>>>>>> program.
>>>>>>
>>>>>> My
;>> of time it should read the sensors. Then it will return to the main
>>>> program.
>>>>
>>>> I just don't know how to read the PRU's clock to get the time values.
>>>> I don't think I saw an example in the cookbook for 'bra
gt;> of time it should read the sensors. Then it will return to the main
>>>> program.
>>>>
>>>> I just don't know how to read the PRU's clock to get the time values.
>>>> I don't think I saw an example in the cookbook for 'bra
should read the sensors. Then it will return to the main program.
>>
>> I just don't know how to read the PRU's clock to get the time values. I
>> don't think I saw an example in the cookbook for 'branching' out from a
>> main program to use the PRUs for this type of pro
clock to get the time values. I
don't think I saw an example in the cookbook for 'branching' out from a
main program to use the PRUs for this type of processing. Just point me in
the right direction, please.
Walter
On Thursday, February 18, 2021 at 9:27:34 AM UTC-5 Walter Cromer wrote
Mark ,
It is working with the updated OS. Thanks so much!
Now I will explore how to get the simple timing that I need using the PRU.
On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer wrote:
> Mark,
>
> With the current OS there isn't a /dev/remoteproc even.
>
Mark,
With the current OS there isn't a /dev/remoteproc even.
I'm going to try the updated OS build this morning.
Walter
On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder wrote:
> I fired up the Beagle at home it the PRU works out of the box.
>
> What do you get running
I'll get this one onto an SD card and give it a try. If I can just get
this configured I think I can make quick work of this problem!
On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder wrote:
> Good point, it should work I'm running a newer test image[1], but I
> took
I asked because the ones on the page @ the link are older than the one I
have installed.
On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:
> On newer versions of the SD card image /var/lib/cloud9 is a git repo which
> you can do a git pull to update. Your version is
So you are saying that this version is too old?
Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT *Tue Aug 25
01:48:39 UTC 2020* armv7l GNU/Linux
On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:
> On newer versions of the SD card image /var/lib/cloud9 is a git
Mark,
git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository (or any
of the parent directories): .git
I'm such a neophyte on git. What do I need to do?
And, what do you mean by updating to a new version of the SD card? The OS
is booting from the SD card and the version.sh
Mark,
I got the latest PRUCookbook downloaded and when trying to make the
hello.pru0.c program in 1.6, I got this error.
*debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ make
TARGET=hello.pru0*
*/var/lib/cloud9/common/Makefile:29:
he
> RCL (http://strawsondesign.com/docs/librobotcontrol/group__time.html).
>
> Best,
> Michele
>
> On Wed, Feb 17, 2021 at 6:25 PM Walter Cromer
> wrote:
>
>> I really don't need ns. The valve 'on time' is going to be in the range
>> of 500 ms to 2 seconds proba
I really don't need ns. The valve 'on time' is going to be in the range of
500 ms to 2 seconds probably.
I will review the PRUCookbook! Thanks!
Walter
On Wednesday, February 17, 2021 at 10:10:53 AM UTC-5 Mark A. Yoder wrote:
> The PRUs can give you 10's of ns timing, which is more than
I have a BBB Wireless running Linux beaglebone 4.14.108-ti-r106 #1 SMP
PREEMPT Fri May 24 22:12:34 UTC 2019 armv7l GNU/Linux
I am writing in C.
I turn a valve on and then need to read some sensors for N milliseconds and
then turn the valve off.
What's the best way to read milliseconds on the
John Dyson - did you ever get this to work? I have had the same problem
and can't get it to work...
On Friday, October 16, 2020 at 3:18:40 AM UTC-4 jonn...@gmail.com wrote:
> Typically, Windows disables the response to ping. I would leave it that
> way.
>
> To get the Beaglebone to talk to
o write your temperature
> sensor software? If you are doing it from the PRU then you can just code up
> your own i2c read function and access the registers directly though the
> memory map, just like any standard MCU.
>
> On Thursday, 16 May 2019 20:34:58 UTC+1, Walter Cromer wrote:
&
I would really appreciate this information too. I see examples of device
trees online and in books but nothing so far explains what any of the
syntax really means and without understanding that I'm just copying
something without learning anything. I could really use some help here,
please!
st.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Thu, May 16, 2019 at 6:50 PM Robert Nelson
wrote:
> On Thu, May 16, 2019 at 2:37 PM Walter Cromer
> wrote
My BBB used to boot just fine from the eMMC but most of the time I held the
user button down and booted from the SD card. All that was working great.
I'd never (to my knowledge) flashed the eMMC either. I started to not be
able to get to the internet via USB so I thought I'd go back and just
Thanks, Robert! This is for the x15 though, right? I'm running a BB
Black. I'm assuming that this isn't compatible with the Black, right?
Walter
On Thursday, May 16, 2019 at 3:26:45 PM UTC-4, RobertCNelson wrote:
>
> On Thu, May 16, 2019 at 2:11 PM Walter Cromer
> > wrote:
ike to trim this 13 seconds
> of work out of my bootup if possible. Perhaps you could make a post in the
> uBoot section?
>
> Hugh
>
> On Thursday, 16 May 2019 01:27:36 UTC+1, Walter Cromer wrote:
>>
>> Hugh - I'm a real newbie. I compiled a device tree overlay with no
etween the two is, though we only use it for a single
> sensor. Maybe I'll try that out tomorrow.
>
> Jim
>
> On Wed, May 15, 2019, 8:13 PM Walter Cromer wrote:
>
>> I've made a lot of progress thanks to the Exploring Beaglebone book. I
>> am turning AC pumps and motors
n tell you about. Not sure
> what the difference between the two is, though we only use it for a single
> sensor. Maybe I'll try that out tomorrow.
>
> Jim
>
> On Wed, May 15, 2019, 8:13 PM Walter Cromer wrote:
>
>> I've made a lot of progress thanks to the Exploring Beaglebo
Hugh - I'm a real newbie. I compiled a device tree overlay with not errors
and have a dtbo file now. I just don't know how to get it into the boot
process. Where do I put it, do I need to change a file like env.txt
somewhere to get it to load and if so what syntax do i use? Where did you
I've made a lot of progress thanks to the Exploring Beaglebone book. I am
turning AC pumps and motors on with relays that I control from the digital
outputs through opto-isolators. But when I needed to read a water proof
temperature probe, I got stuck. I bought the DS18B20 and didn't
I bought my copy as a Kindle book from Amazon. It shows a publlication
date of December 2018 and says Second Edition on the cover. But I have the
same learning curve and problem. And, I can't seem to find the
information about using UBoot in the book. Would you be so kind as to
share
92 matches
Mail list logo
