On Tuesday 06 June 2017 11:46:27 Bertho Stultiens wrote:
> On 06/06/2017 03:30 AM, Gene Heskett wrote:
> > Does the image I downloaded Saturday and wrote to an sd card
> > yesterday have this stuff in it?
>
> No, you need to pull the most recent source-files (hm2_rpspi.c and
> spi_common_rpspi.h)
On Tuesday 06 June 2017 11:46:27 Bertho Stultiens wrote:
> On 06/06/2017 03:30 AM, Gene Heskett wrote:
> > Does the image I downloaded Saturday and wrote to an sd card
> > yesterday have this stuff in it?
>
> No, you need to pull the most recent source-files (hm2_rpspi.c and
> spi_common_rpspi.h)
On 06/06/2017 03:30 AM, Gene Heskett wrote:
> Does the image I downloaded Saturday and wrote to an sd card yesterday
> have this stuff in it?
No, you need to pull the most recent source-files (hm2_rpspi.c and
spi_common_rpspi.h) from the mailing list (or the forum).
Login as pi user and put
On Monday 05 June 2017 10:20:03 Bertho Stultiens wrote:
> On 06/04/2017 06:15 AM, john mcintyre wrote:
> > Your saga continues, you must be related to a bulldog ,once locked
> > on it cannot let go.
>
> Isn't this what you call a challenge?
>
>
> Anyway, I've fixed a couple of things, like
@lists.sourceforge.net>
Subject: Re: [Emc-users] RPI saga continues - SPI probably solved
On 06/04/2017 06:15 AM, john mcintyre wrote:
Your saga continues, you must be related to a bulldog? ,once locked
on it cannot let go.
Isn't this what you call a challenge?
Anyway, I've fixed a coup
On 06/04/2017 06:15 AM, john mcintyre wrote:
> Your saga continues, you must be related to a bulldog ,once locked
> on it cannot let go.
Isn't this what you call a challenge?
Anyway, I've fixed a couple of things, like endianness, which I did
wrong in the previous versions. This
-users] RPI saga continues - SPI probably solved
On Friday 02 June 2017 21:50:13 Bertho Stultiens wrote:
> On 06/03/2017 03:36 AM, Gene Heskett wrote:
> >> Has anybody done an implementation of affinity in linuxcnc already?
> >> If yes, how is it setup?
> >
> > O
On Friday 02 June 2017 21:50:13 Bertho Stultiens wrote:
> On 06/03/2017 03:36 AM, Gene Heskett wrote:
> >> Has anybody done an implementation of affinity in linuxcnc already?
> >> If yes, how is it setup?
> >
> > On the x86 stuff, in years past, we used "isolcpus"=3 (or whatever
> > was the last
On 06/03/2017 03:36 AM, Gene Heskett wrote:
>> Has anybody done an implementation of affinity in linuxcnc already? If
>> yes, how is it setup?
>
> On the x86 stuff, in years past, we used "isolcpus"=3 (or whatever was
> the last core) as a kernel argument at kernel load time.
>
> On x86 stuff
On Friday 02 June 2017 19:59:52 Bertho Stultiens wrote:
> On 06/03/2017 01:08 AM, Gene Heskett wrote:
> >>> 5mv? 4 amp box, haven't had a problem.
> >>
> >> And you do not see any red led on the pi blink then?
> >> If yes, then you man need to add decoupling.
> >
> > Solid as a rock.
>
> That
On 06/03/2017 01:08 AM, Gene Heskett wrote:
>>> 5mv? 4 amp box, haven't had a problem.
>> And you do not see any red led on the pi blink then?
>> If yes, then you man need to add decoupling.
> Solid as a rock.
That should be fine then.
Something different:
I see that the hm2_rpspi module is
On Friday 02 June 2017 18:35:32 Bertho Stultiens wrote:
> On 06/03/2017 12:20 AM, Gene Heskett wrote:
> [snip]
>
> >> The problems seem to stop now that I have attached a bench-PSU set
> >> to 5V directly on the 40-pin header's 5V input. I needed to
> >> increase the voltage to 5.1V after the red
On 06/03/2017 12:20 AM, Gene Heskett wrote:
[snip]
>> The problems seem to stop now that I have attached a bench-PSU set to
>> 5V directly on the 40-pin header's 5V input. I needed to increase the
>> voltage to 5.1V after the red LED still was blinking once in a while
>> (probably indicating too
On Friday 02 June 2017 17:29:24 Bertho Stultiens wrote:
> On 06/02/2017 01:46 AM, Bertho Stultiens wrote:
> > Problem 1:
> > The RPI3 has dynamic frequency scaling activated by default
> > (ondemand governor). This makes the Pi hop between 600MHz and 1.2GHz
> > core frequency. Very annoying and
On 06/02/2017 01:46 AM, Bertho Stultiens wrote:
> Problem 1:
> The RPI3 has dynamic frequency scaling activated by default
> (ondemand governor). This makes the Pi hop between 600MHz and 1.2GHz
> core frequency. Very annoying and makes realtime rather
> unpredictable.
There are actually two lines
On Thursday 01 June 2017 19:46:29 Bertho Stultiens wrote:
> On 06/01/2017 02:13 AM, Gene Heskett wrote:
> > Hi Bertho; I haven't heard any more, so I am wondering if you've
> > found any more "magic beans"?
>
> Yes, I think I've tracked down (most of) the problem(s). There are
> several factors
On 06/01/2017 02:13 AM, Gene Heskett wrote:
> Hi Bertho; I haven't heard any more, so I am wondering if you've found
> any more "magic beans"?
Yes, I think I've tracked down (most of) the problem(s). There are
several factors that play a role. Not all are solved or maybe solvable,
but the timing
On 06/01/2017 02:13 AM, Gene Heskett wrote:
> Hi Bertho; I haven't heard any more, so I am wondering if you've found
> any more "magic beans"?
Still looking into options.
There is that persy dayjob taking away attention from the real work ;-)
Seriously, it is exams-period and that requires some
On Tuesday 30 May 2017 08:20:38 Bertho Stultiens wrote:
> On 05/30/2017 02:32 AM, Bertho Stultiens wrote:
> > After some digging I noticed that there might be a data-barrier
> > problem, where peripheral register access can become out-of-order.
> > The ARM has the __sync_synchronize() (via gcc)
On Tuesday 30 May 2017 15:00:31 Chris Albertson wrote:
> Gene,
>
> So many words here I can't see the problem. If if you are trying to
> reliably export the P's screen to your "your computer" You might just
> skip trying to use X11 and go with VNC.I run a VNC server on my
> Pi3 and it has
Gene,
So many words here I can't see the problem. If if you are trying to
reliably export the P's screen to your "your computer" You might just skip
trying to use X11 and go with VNC.I run a VNC server on my Pi3 and it
has been running continuously now for about a month. When I log in
On Tuesday 30 May 2017 08:20:38 Bertho Stultiens wrote:
> On 05/30/2017 02:32 AM, Bertho Stultiens wrote:
> > After some digging I noticed that there might be a data-barrier
> > problem, where peripheral register access can become out-of-order.
> > The ARM has the __sync_synchronize() (via gcc)
On 05/30/2017 02:28 PM, Jeff Epler wrote:
> We already have a driver for hostmot2 that uses /dev/spidev*,
> hm2_spi. hm2_rpspi exists because its contributor stated that on
> their system, hm2_spi did not perform adequately.
That reminds me of setting scheduling/cpu affinity. Maybe the solution
On 05/30/2017 02:28 PM, Jeff Epler wrote:
>> However, there already is a solution for this! The linux kernel has a
>> SPI driver, which is quite good (used it before). It solves all the
>> userspace problems and, to say the least, some very clever people have
>> had a crack at this problem before.
On Tue, May 30, 2017 at 02:20:38PM +0200, Bertho Stultiens wrote:
> I suddenly realized that the SPI peripheral is configured and accessed
> in userspace. That will fail miserably if not extremely careful,
> especially on SMP.
>
> However, there already is a solution for this! The linux kernel
On 05/30/2017 02:32 AM, Bertho Stultiens wrote:
> After some digging I noticed that there might be a data-barrier problem,
> where peripheral register access can become out-of-order. The ARM has
> the __sync_synchronize() (via gcc) to insert DMB (data-memory-barrier)
> instructions when you need
Hi all,
Too happy too soon. That is what happens.
There seems to be one additional problem when configuring the SPI port.
After a restart of the Pi everything went to bad again.
After some digging I noticed that there might be a data-barrier problem,
where peripheral register access can become
27 matches
Mail list logo
