Nano isn't best choice for polyglot applications. I'm using Geany (on PC
exchanging source files via virtual file system), while I compile and test
under LINUX on the BB.
wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um 20:25:06
UTC+2:
> Here's one more thing I am struggling w
We're designing it the way you suggested. The nice thing is that 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
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 Cromer
>
Thank you Robert for the information.
On Tuesday, April 13, 2021 at 8:13:13 PM UTC+5:30 RobertCNelson wrote:
> On Tue, Apr 13, 2021 at 9:37 AM Murugesh M wrote:
> >
> > Thanks Robert Nelson.
> >
> > 1. In the getting started page, except Step 1, all other steps are not
> turning to green. Still
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 ac
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!?
On Tue, Apr 13, 2021 at 9:37 AM Murugesh M wrote:
>
> Thanks Robert Nelson.
>
> 1. In the getting started page, except Step 1, all other steps are not
> turning to green. Still after updated the image to latest "Debian Buster IoT
> Image 2020-04-06", Enabled the network connection through USB a
After posting this, I realized this was a macro and that it was passing the
sum of the two values. That seemed weird to me.
Thanks for the confirmations! It is coming back slowly!
On Tuesday, April 13, 2021 at 9:40:59 AM UTC-4 pierric...@gadz.org wrote:
> To complete on TJF answer, you can
To complete on TJF answer, you can find the address defined
by CM_WKUP_ADC_TSC_CLKCTRL in *hw_cm_wkup.h *line 101value (0xbc) and in
*soc_AM335x.h
* line 139.
Le mardi 13 avril 2021 à 05:16:58 UTC-4, TJF a écrit :
> I'm not a C guy (but prefering FreeBASIC for ligh-level and ASM for PRU
>
HWREG: is a macro that lets you write directly to the register of the bone;
I think it is defined in the hw_type.h header.
From a quick look, I would say that is the base address of the TSC ADC on
the chip and TSC_ADC_SS_IRQSTATUS is the register's address.
SOC_ADC_TSC_0_REGS is defined i
I'm not a C guy (but prefering FreeBASIC for ligh-level and ASM for PRU
code). Just guessing:
As lazarman mentioned HWREG is a preprocessor macro (perhaps using ARM in
supervisor mode?)
SOC_CM_WKUP_REGS is the base adress of the wakeup registers in the control
module
CM_WKUP_ADC_TSC_CLKCTRL is
11 matches
Mail list logo
