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

2021-04-18 Thread TJF
Hi Mark,

let me first point out that this discussion isn't in my mother tongue. 
Sometimes I read your statements several times still not understanding what 
exactly you mean.

Mark Lazarewicz schrieb am Sonntag, 18. April 2021 um 16:49:22 UTC+2:

> who you want to believe Texas Instrumentr or TJF?


I believe none of them. The hardware is reality. I make experiments (ask 
the hardware) to find out what's really correct.

There isn't one great TI company. Hardware engineers made a great AM335x 
CPU design. It's not bug free, but well usable. And software engineers do 
everything to block the hardware benefits.

So the question should be: blinking a led, do you want to follow an CCS 
example (changing with each new kernel version) or an libpruio example 
published years before (2014, still working)? Do you want to learn from 
coders making small examples only, or are you interested in hands-on 
experience form people who did already fill up the IRam of both PRUSS?

You're lucky, I'm waiting for feedback before starting my next project. So 
I've time to waste of good mojo. 

-- 
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/0646b780-3ac1-41fe-8c7d-3ee2b2156b66n%40googlegroups.com.


Re: [beagleboard] Re: rtcwake support on BeagleBone Blue

2021-04-18 Thread Mykolas Juraitis
Thank you for a comprehensive answer. I will look into external clocks.

On Sun, Apr 18, 2021 at 5:05 PM Dennis Lee Bieber 
wrote:

> On Sat, 17 Apr 2021 14:14:03 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Mykolas Juraitis
>  wrote:
>
> >Hello,
> >
> >I am experimenting with rtcwake on BeagleBone Blue. Running command:
> >
>
> Note that there is no REAL RTC on most BeagleBone variants (I don't
> know if the Blue has an add-on RTC). cf:
>
> https://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/overview
>
>
> >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.
> >
>
> Beaglebones periodically save the system clock value, and use that
> to
> reload the system clock on startup. The value you are seeing is likely that
> of the last time this fake hwclock was written... cf:
> https://manpages.debian.org/jessie/fake-hwclock/fake-hwclock.8.en.html
>
> Also...
>
> https://unix.stackexchange.com/questions/187261/automatically-update-hwclock-at-boot
> https://groups.google.com/g/beagleboard/c/n1noGnM30sQ
>
>
>
> --
> Dennis L Bieber
>
> --
> 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/qPoSZk2XStA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/a3mo7gls3hp901pi4r91rfvkkq7q7g2nti%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/CAKVuKxgb%3DQM4ek_D_zwqRzBugNAD3JhS7KYLBO_w5YmvADPhwg%40mail.gmail.com.


[beagleboard] Re: rtcwake support on BeagleBone Blue

2021-04-18 Thread Dennis Lee Bieber
On Sat, 17 Apr 2021 14:14:03 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Mykolas Juraitis
 wrote:

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

Note that there is no REAL RTC on most BeagleBone variants (I don't
know if the Blue has an add-on RTC). cf:
https://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/overview


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

Beaglebones periodically save the system clock value, and use that to
reload the system clock on startup. The value you are seeing is likely that
of the last time this fake hwclock was written... cf:
https://manpages.debian.org/jessie/fake-hwclock/fake-hwclock.8.en.html

Also...
https://unix.stackexchange.com/questions/187261/automatically-update-hwclock-at-boot
https://groups.google.com/g/beagleboard/c/n1noGnM30sQ



-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a3mo7gls3hp901pi4r91rfvkkq7q7g2nti%404ax.com.


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

2021-04-18 Thread Mark Lazarewicz
TJF* I Dont* agree and neither do companies that have sold 10k products 
that sounds finished to me 

unfortunately CCS doesnt support Basic language so I can see why your 
worried and I wish you the best of luck getting libpruio inluded in the 
kernel sincerely.

Linux is great I just dont use it for hard realtime I an in line with TI 
marketing see below link. The reason the PRU is there is to allow linux as 
a gateway and hard realtime is done on the PRU. The original poster's 
project IS NOT hard REAL Time perhaps you can help him get his project 
working on ARM since thats all you understand.

*  Ensuring real-time predictability*  
https://www.ti.com/lit/pdf/spry264
 
The fact that TI also supports QNX , Intergrity and Nucleeus see 
here https://www.ti.com/tool/TMDSSK3358
shows TI knows what real customers want besides Linux 

I wont insult you like you attempted  to do to me as I consider the source 
someone who does not develop just pays for solutions you have zero 
credibility.

Anyway my code is up and running and for the group I will offer another 
path the AM335X has touch screen and onboard FTDI jtag and isntructions for 
using CCS on it and Beagle Bone Black. Add up the cost of a JTAG and touch 
screen its actually reasonable its here

https://www.ti.com/lit/ug/sprw236b/sprw236b.pdf

I repeat again from TI a great company with great engineers read this its 
actually related to the posters original question unlike this angry 
uncalled for  post . who you want to believe Texas Instrumentr or TJF? 

BTW Rproc and RPMsg is supported by TI in Linux kernel and TI RTTOS its 
also documented well not Doxygen comments lifted from code 

Some real latencies and exact access times in block diagram no snake oil 

https://www.ti.com/lit/ug/sprw236b/sprw236b.pdf

CCS/JTAG is an option not for everyone but recommended for board bring up 
you know the real work that engineers do. not some bean counter who 
doesn't actually do the work 

The user can make his own choices I'm just trying to be helpful

Mark

On Sunday, April 18, 2021 at 1:09:43 AM UTC-5 TJF wrote:

> Hi Mark,
>
> you're the master of reversed order! You want to code a main loop before 
> IO is working. You want to CCS/JTAG variables before your first LOC is 
> running. Did you ever finish a project?
>
> When a subsystem is off (not clocked) the PRU can still read or write its 
> registers. Readings are always zero and writings go to Nirvana, no error 
> message, no exeption. How should a debugger help in this case?
>
> Mark Lazarewicz schrieb am Sonntag, 18. April 2021 um 03:13:10 UTC+2:
>
>> Anyway Linux is not required for CCS and its slow and inferior to Windows 
>> 10 version
>
>
> LINUX is stable and reliable. Anyway, CSS is not required for PRU 
> development. Since I aim to open up the full PRUSS power (I've payed for), 
> I continue ignoring all that CSS bloat (!! a linker for a 2k instruction 
> space !!).
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/60fb316a-c523-4d88-a3b1-afc598e8af83n%40googlegroups.com.


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

2021-04-18 Thread TJF
Hi Mark,

you're the master of reversed order! You want to code a main loop before IO 
is working. You want to CCS/JTAG variables before your first LOC is 
running. Did you ever finish a project?

When a subsystem is off (not clocked) the PRU can still read or write its 
registers. Readings are always zero and writings go to Nirvana, no error 
message, no exeption. How should a debugger help in this case?

Mark Lazarewicz schrieb am Sonntag, 18. April 2021 um 03:13:10 UTC+2:

> Anyway Linux is not required for CCS and its slow and inferior to Windows 
> 10 version


LINUX is stable and reliable. Anyway, CSS is not required for PRU 
development. Since I aim to open up the full PRUSS power (I've payed for), 
I continue ignoring all that CSS bloat (!! a linker for a 2k instruction 
space !!).

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4caa73f5-e1a9-4342-b0c0-0b4fdf9ef98bn%40googlegroups.com.