Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Mark Lazarewicz]

 basically the control logic has already been written in C on the ARM side.  
> Now, I just need to get it ported to the PRUs and create the communications 
> between the PRUs and a new ARM app that supervises everything from the 
> user's point of view.  Meaning, taking inputs like start, stop and giving 
> feedback by turning LEDs on and off.  And it needs to take in some basic 
> system configuration data from the cloud periodically that the PRU will 
> consume to adjust it's operation.  
>
> I am making progress.  Part of my problem was using Cloud9 for 
> development.  That's where all my ARM development has been so far.  I have 
> CCS installed on my Windows 10 machine and started working through TI's PRU 
> Hands On Labs.  Unfortunately, the very first one doesn't work because 
> their document is written for CCS running on Linux.   Step 6 says to delete 
> the linker file and add it back with Project->Add Files but that's grayed 
> out.  I've asked TI about that.   But I got it to compile by writing on the 
> Beagle using nano and compiling it there.   I've ready a lot of TI 
> documentation today and learned a lot. 
>
> Here's one more thing I am struggling with though.  It's a mental block I 
> think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
> appears that on the PRU, we use __R30 instead but I don't understand how 
> that works.  I read through it this morning and it still isn't sinking in.  
> If anyone can help make this clearer, I'd appreciate it.
>
> On Tuesday, April 13, 2021 at 11:25:08 AM UTC-4 lazarman wrote:
>
>> Walter
>>
>> Your best bet.
>>
>> Run your whole control loop on the PRU that's as realtime as you get. Use 
>> a foreground background loop. Use the ARM like a PC with Linux to access 
>> the system via ethernet.
>>
>> You could also run control on ARM without linux but this way you have all 
>> the resources of Linux to access the system.
>>
>> This assumes your output's from control loop are accessable from PRU.
>>
>> The point is Linux can only run slow control loops and this way you don't 
>> have to debug the delay.
>>
>> This wasn't obvious to me before as all the hard realtime systems I work 
>> on run an RTOS on ARM it has all the resources of Linux but cost $.
>>
>> In our system we did that on the DSP the PID did the math on a fast DSP.
>>
>> ARM is just a gateway to outside world.
>>
>> Myself I'd debug the PRU with JTAG and CCS you can see exactly what's 
>> going on and dump these registers from CCS.
>>
>> Some people like printf but with a PRU based system you are essentially 
>> doing barebones.
>>
>> There's videos on PRU development doing this online.
>>
>> Loading code via rproc and using  printf is like burning and erasing an 
>> eeprom to test your changes. You wait 45 minutes for it to erase try your 
>> code and do it again.
>>
>> Not for me.
>>
>> Mark
>>
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Tue, Apr 13, 2021 at 9:54 AM, Dennis Lee Bieber
>>  wrote:
>>
>> On Mon, 12 Apr 2021 13:08:48 -0700 (PDT), in
>> gmane.comp.hardware.beagleboard.user Walter Cromer
>>  wrote:
>>
>> >What's really throwing me is the + between what looks like two macro 
>> >values.  Normally, we see the + on the right sign of the equals, right?  
>> >Or am I forgetting something I used to know!?
>> >
>>
>> Why? Take into account the ()s.
>>
>> From what I can tell, this is adding the ADC register offset to the
>> base address of the (?) wakeup register block, which is passed as 
>> parameter
>> to HWREG (no doubt some macro that sets up actual access to the SoC
>> registers and returns a pointer or some such), and then assigns 0x02 into
>> the register so indicated.
>>
>>
>> -- 
>> Dennis L Bieber
>>
>> -- 
>> 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+unsub...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/44cb7gtf6pl4d4j3e6oqo57g5n0hobi29c%404ax.com
>> .
>>
>>

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

[beagleboard] rtcwake support on BeagleBone Blue

[Mykolas Juraitis]

Hello,

I am experimenting with rtcwake on BeagleBone Blue. Running command:

sudo rtcwake -d /dev/rtc0 -m standby -s 20

does make board to switch off but it doesn't come back online by itself. 
Pressing power button brings board online very fast (in few seconds) and 
even keeps original ssh connection so I assume standby mode works but clock 
might be an issue. I have synchronised hardware clock with system clock by 
running:

sudo hwclock -w

and I see clocks are in sync.

I am powering BBB from 2S LiPo as my barrel connector is fried by 
accidentally attaching laptop charger (19V).

I tried to check time before and after standby by running:

sudo hwclock && date && sudo rtcwake -d /dev/rtc0 -m standby -s 20 && date 
&& sudo hwclock
2021-04-17 21:42:40.123908+00:00
Sat 17 Apr 2021 09:42:40 PM UTC
rtcwake: wakeup from "standby" using /dev/rtc0 at Sat Apr 17 21:43:02 2021
Sat 17 Apr 2021 09:43:06 PM UTC
2021-04-17 21:43:07.802256+00:00

Last 2 time lines are printed after manual wake up by pressing power 
button. They seem to be showing that only twenty some seconds passed but 
actually much more time passed until I pressed power button. Which is weird 
because if RTC doesn't work then I would expect time to be reset. If it 
does work it should be correct time.

I wanted to ask if anyone managed rtcwake working or it is not even 
supposed to work on BeagleBone Blue? This 
thread https://groups.google.com/g/beagleboard/c/wJln2crGaFA indicates that 
it should be possible but I am not sure which board it is about. BeagleBone 
Black seems to be not supported (see 
https://groups.google.com/g/beagleboard/c/bZFcV4y9QWQ).

Best regards,
Mykolas

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

Re: [beagleboard] versioning beaglebone images with OSTree

[Robert Nelson]

On Sat, Apr 17, 2021 at 8:35 AM John Allwine  wrote:
>
> I noticed that adding ostree to deb_includes causes problems. What’s 
> different about adding it to deb_additional_pkgs?

So, deb_includes get directly passed to debootstrap in the first phase
of debootstrap, so if it's requirements are little too complex it will
fail, the deb_additional_pkgs get added during the second pass, where
most of the debian initial base is already setup..

So, when adding a new package, i always add it to deb_includes first,
then test.. If it fails i bump it to deb_additional_pkgs..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] versioning beaglebone images with OSTree

[John Allwine]

I noticed that adding ostree to deb_includes causes problems. What’s different 
about adding it to deb_additional_pkgs?

> On Apr 17, 2021, at 7:27 AM, John Allwine  wrote:
> 
> What is the biggest image currently?
> 
> OSTree is smart about space, so if updated incrementally and old images get 
> pruned, it could work. But I agree it’s a big limitation. Using a microSD 
> card in that case would be better.
> 
>>> On Apr 16, 2021, at 6:04 PM, Robert Nelson  wrote:
>>> 
>>> On Fri, Apr 16, 2021 at 4:19 PM John Allwine  wrote:
>>> 
>>> I'd like to start a discussion about creating complete Beaglebone images 
>>> that leverage OSTree to be able to atomically update the system as a whole. 
>>> The scripts in https://github.com/beagleboard/image-builder generate 
>>> complete images for the Beaglebone that include specific kernel, apt 
>>> packages, boot settings, git repositories, etc. Updating a deployed 
>>> Beaglebone without reflashing a new image involves piecemeal updating of 
>>> those various components. Improperly updating can leave the system in a 
>>> broken state and can be difficult to get back into a good state. It would 
>>> be great to be able to leverage those image-builder scripts to construct 
>>> the rootfs, add that tree as a commit to an OSTree repository and properly 
>>> configured Beaglebones could download that commit and atomically switch to 
>>> it to update the whole system while preserving portions of the system such 
>>> as home directories and other key directories (/etc, /var?). If something 
>>> did break, rolling back is easy as well.
>>> 
>>> Configuring a Beaglebone this way would make most of the system read-only 
>>> so using apt-get to install new packages wouldn't work without altering its 
>>> implementation, but that seems like a worthy trade off. This would be for 
>>> someone who has a Beaglebone with an out-of-the-box image and some 
>>> scripts/servers set up in their home directory who doesn't want to worry 
>>> too much about the system as a whole, but wants to be able to easily update 
>>> it without reflashing or doing piecemeal updates. People who develop 
>>> software for Beaglebones in their customers' devices could host their own 
>>> OSTree repository and make their own modifications to the image-builder 
>>> scripts if they have their own set of system dependencies (this is what I'd 
>>> like to do).
>>> 
>>> Does anyone else think this would be useful? Is there anyone with the 
>>> expertise to know what details would need to be taken into account to make 
>>> this work properly?
>>> 
>>> OSTree documentation is here: https://ostreedev.github.io/ostree/
>>> It lists a number of examples of it being used in various Linux 
>>> distributions.
>> 
>> I remember seeing one of Peter Robinson's demo of Fedora IoT a few
>> years back at ELC, that used OSTree+btrfs. It worked pretty well.  At
>> that time, I made sure btrfs worked well for us, to possibly look down
>> that road.  My biggest issue, the 4gb eMMC, was too limited for the
>> out of box images to do something like that.  For an iot/console image
>> the idea would still work well..   While working on bullseye images
>> this week, i noticed we still have the "--no-merged-usr" flag for
>> debootstrap, we should try with that removed in 'bullseye', as ostree
>> needs that..
>> 
>> We did have ostree installed on the lxqt images:
>> 
>> https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-lxqt-v5.4.conf#L138
>> 
>> --no-merged-usr (due to bugs in stretch/buster..)
>> https://github.com/beagleboard/image-builder/blob/master/scripts/debootstrap.sh#L138
>> 
>> Regards,
>> 
>> -- 
>> Robert Nelson
>> https://rcn-ee.com/
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgHJiESN2df7jVbUErSwL5mcoPva-woQXR91t%3D0nCJJDQ%40mail.gmail.com.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/971CF81E-884F-43BD-8125-7A25803AA891%40pocketnc.com.

Re: [beagleboard] versioning beaglebone images with OSTree

[John Allwine]

What is the biggest image currently?

OSTree is smart about space, so if updated incrementally and old images get 
pruned, it could work. But I agree it’s a big limitation. Using a microSD card 
in that case would be better.

> On Apr 16, 2021, at 6:04 PM, Robert Nelson  wrote:
> 
> On Fri, Apr 16, 2021 at 4:19 PM John Allwine  wrote:
>> 
>> I'd like to start a discussion about creating complete Beaglebone images 
>> that leverage OSTree to be able to atomically update the system as a whole. 
>> The scripts in https://github.com/beagleboard/image-builder generate 
>> complete images for the Beaglebone that include specific kernel, apt 
>> packages, boot settings, git repositories, etc. Updating a deployed 
>> Beaglebone without reflashing a new image involves piecemeal updating of 
>> those various components. Improperly updating can leave the system in a 
>> broken state and can be difficult to get back into a good state. It would be 
>> great to be able to leverage those image-builder scripts to construct the 
>> rootfs, add that tree as a commit to an OSTree repository and properly 
>> configured Beaglebones could download that commit and atomically switch to 
>> it to update the whole system while preserving portions of the system such 
>> as home directories and other key directories (/etc, /var?). If something 
>> did break, rolling back is easy as well.
>> 
>> Configuring a Beaglebone this way would make most of the system read-only so 
>> using apt-get to install new packages wouldn't work without altering its 
>> implementation, but that seems like a worthy trade off. This would be for 
>> someone who has a Beaglebone with an out-of-the-box image and some 
>> scripts/servers set up in their home directory who doesn't want to worry too 
>> much about the system as a whole, but wants to be able to easily update it 
>> without reflashing or doing piecemeal updates. People who develop software 
>> for Beaglebones in their customers' devices could host their own OSTree 
>> repository and make their own modifications to the image-builder scripts if 
>> they have their own set of system dependencies (this is what I'd like to do).
>> 
>> Does anyone else think this would be useful? Is there anyone with the 
>> expertise to know what details would need to be taken into account to make 
>> this work properly?
>> 
>> OSTree documentation is here: https://ostreedev.github.io/ostree/
>> It lists a number of examples of it being used in various Linux 
>> distributions.
> 
> I remember seeing one of Peter Robinson's demo of Fedora IoT a few
> years back at ELC, that used OSTree+btrfs. It worked pretty well.  At
> that time, I made sure btrfs worked well for us, to possibly look down
> that road.  My biggest issue, the 4gb eMMC, was too limited for the
> out of box images to do something like that.  For an iot/console image
> the idea would still work well..   While working on bullseye images
> this week, i noticed we still have the "--no-merged-usr" flag for
> debootstrap, we should try with that removed in 'bullseye', as ostree
> needs that..
> 
> We did have ostree installed on the lxqt images:
> 
> https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-lxqt-v5.4.conf#L138
> 
> --no-merged-usr (due to bugs in stretch/buster..)
> https://github.com/beagleboard/image-builder/blob/master/scripts/debootstrap.sh#L138
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgHJiESN2df7jVbUErSwL5mcoPva-woQXR91t%3D0nCJJDQ%40mail.gmail.com.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/DE7D0E98-7405-4FC7-85B2-339E53CC4837%40pocketnc.com.