Re: [Emc-users] Rpi Pico

[Dave Cole]

I see that Sparkfun now has them on backorder.

Sparkfun shipped my order today.   So that's good.
Ironically Sparkfun had a limit of 100 per customer.
I suspect you might find them being resold on Ebay.

Yep.
https://www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=raspberry+pi+pico&_sacat=0

Oh well.

Dave


On 1/23/2021 1:49 PM, Chris Albertson wrote:

They seem to have done an excellent job of getting the word out about this
new product.  I think that it will be the "new Arduino" but the current
problem is actually buying them.   I've signed up to be notified when more
are available but you have to be quick and lucky as they sell out in
minutes.

This is not really a bad thing.  It means they have something people want
and at $4 the price is right.  In a month they will be generally available
in quantity with Amazon-prime 2-day shipping.

In the meantime, there is a ton of documentation to download and read.



On Fri, Jan 22, 2021 at 1:28 PM Frank Tkalcevic 
wrote:


I just received an advertising email from SparkFun.  They sell the Pi Pico
as well as 3 of their own variants with the RP2040 chip...


Thing Plus - https://www.sparkfun.com/products/17745
MicroMod - https://www.sparkfun.com/products/17720
Pro Micro - https://www.sparkfun.com/products/17717

I just noticed, they are for pre-order.


-Original Message-
From: Chris Albertson [mailto:albertson.ch...@gmail.com]
Sent: Friday, 22 January 2021 4:05 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi Pico

On Thu, Jan 21, 2021 at 7:56 PM Dave Cole  wrote:


I was thinking multiple RPi Picos to one RPi4, but for just one, that is
probably the way to go.


The Pico is a dual-core M0.   So it is faster than I had originally
thought.   Micro-Python is ported to it so it might be very easy for many
people to program.   I'm got my name in to be notified when they are back
in stock. I still think USB is the simplest way to connect while
experimenting.

One advantage of USB is that you need USB to program the Pico.   You would
run the development system on the Pi4 and change the firmware by copying
files or drag/drop.  If the Pico is SPI connected then you need to hunt
down a USB cable then walk out to the shop to change the firmware.




I'll try that first!

The Pi Hat as the carrier board is also a good idea.

On 1/21/2021 7:46 PM, Chris Albertson wrote:

I'd bet SPI would work well but even easier would be to connect them to

the

Pi4 with USB.  Both sides have software that makes the USB look like a
serial port and the physical connection is done with off the shelf

cable.

I've used M0 boards this way in the past and using USB lets you also

cnet

them to a Linux PC

What I like about the Pico is that it can be SMT hand soldered.  I can

make

a simple passive carrier board that has connectors and it is not hard

to

hand solder 0.1 inch pitch.  The carrier board could be a Pi-hat

On Thu, Jan 21, 2021 at 4:30 PM Dave Cole 

wrote:

I wonder if these could act as SPI slaves to the RPI 4?

I've been trying to buy two from Adafruit and they keep selling out

and

then coming back in stock, and then selling out again!

Dave

On 1/21/2021 6:36 PM, andy pugh wrote:

On Thu, 21 Jan 2021 at 21:52, Chris Albertson <

albertson.ch...@gmail.com>

wrote:

This is an STM32 microcontroller.

Are you sure? It is an ARM Cortex M0, like the STM32, but is it made

by

ST?

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



--

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users






___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Chris Albertson]

They seem to have done an excellent job of getting the word out about this
new product.  I think that it will be the "new Arduino" but the current
problem is actually buying them.   I've signed up to be notified when more
are available but you have to be quick and lucky as they sell out in
minutes.

This is not really a bad thing.  It means they have something people want
and at $4 the price is right.  In a month they will be generally available
in quantity with Amazon-prime 2-day shipping.

In the meantime, there is a ton of documentation to download and read.



On Fri, Jan 22, 2021 at 1:28 PM Frank Tkalcevic 
wrote:

> I just received an advertising email from SparkFun.  They sell the Pi Pico
> as well as 3 of their own variants with the RP2040 chip...
>
>
> Thing Plus - https://www.sparkfun.com/products/17745
> MicroMod - https://www.sparkfun.com/products/17720
> Pro Micro - https://www.sparkfun.com/products/17717
>
> I just noticed, they are for pre-order.
>
>
> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> Sent: Friday, 22 January 2021 4:05 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Rpi Pico
>
> On Thu, Jan 21, 2021 at 7:56 PM Dave Cole  wrote:
>
> > I was thinking multiple RPi Picos to one RPi4, but for just one, that is
> > probably the way to go.
> >
>
> The Pico is a dual-core M0.   So it is faster than I had originally
> thought.   Micro-Python is ported to it so it might be very easy for many
> people to program.   I'm got my name in to be notified when they are back
> in stock. I still think USB is the simplest way to connect while
> experimenting.
>
> One advantage of USB is that you need USB to program the Pico.   You would
> run the development system on the Pi4 and change the firmware by copying
> files or drag/drop.  If the Pico is SPI connected then you need to hunt
> down a USB cable then walk out to the shop to change the firmware.
>
>
>
> > I'll try that first!
> >
> > The Pi Hat as the carrier board is also a good idea.
> >
> > On 1/21/2021 7:46 PM, Chris Albertson wrote:
> > > I'd bet SPI would work well but even easier would be to connect them to
> > the
> > > Pi4 with USB.  Both sides have software that makes the USB look like a
> > > serial port and the physical connection is done with off the shelf
> cable.
> > >
> > > I've used M0 boards this way in the past and using USB lets you also
> cnet
> > > them to a Linux PC
> > >
> > > What I like about the Pico is that it can be SMT hand soldered.  I can
> > make
> > > a simple passive carrier board that has connectors and it is not hard
> to
> > > hand solder 0.1 inch pitch.  The carrier board could be a Pi-hat
> > >
> > > On Thu, Jan 21, 2021 at 4:30 PM Dave Cole 
> > wrote:
> > >
> > >> I wonder if these could act as SPI slaves to the RPI 4?
> > >>
> > >> I've been trying to buy two from Adafruit and they keep selling out
> and
> > >> then coming back in stock, and then selling out again!
> > >>
> > >> Dave
> > >>
> > >> On 1/21/2021 6:36 PM, andy pugh wrote:
> > >>> On Thu, 21 Jan 2021 at 21:52, Chris Albertson <
> > albertson.ch...@gmail.com>
> > >> wrote:
> > >>>> This is an STM32 microcontroller.
> > >>> Are you sure? It is an ARM Cortex M0, like the STM32, but is it made
> by
> > >> ST?
> > >>
> > >> ___
> > >> Emc-users mailing list
> > >> Emc-users@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/emc-users
> > >>
> > >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Frank Tkalcevic]

I just received an advertising email from SparkFun.  They sell the Pi Pico
as well as 3 of their own variants with the RP2040 chip...


Thing Plus - https://www.sparkfun.com/products/17745
MicroMod - https://www.sparkfun.com/products/17720
Pro Micro - https://www.sparkfun.com/products/17717

I just noticed, they are for pre-order.


-Original Message-
From: Chris Albertson [mailto:albertson.ch...@gmail.com] 
Sent: Friday, 22 January 2021 4:05 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi Pico

On Thu, Jan 21, 2021 at 7:56 PM Dave Cole  wrote:

> I was thinking multiple RPi Picos to one RPi4, but for just one, that is
> probably the way to go.
>

The Pico is a dual-core M0.   So it is faster than I had originally
thought.   Micro-Python is ported to it so it might be very easy for many
people to program.   I'm got my name in to be notified when they are back
in stock. I still think USB is the simplest way to connect while
experimenting.

One advantage of USB is that you need USB to program the Pico.   You would
run the development system on the Pi4 and change the firmware by copying
files or drag/drop.  If the Pico is SPI connected then you need to hunt
down a USB cable then walk out to the shop to change the firmware.



> I'll try that first!
>
> The Pi Hat as the carrier board is also a good idea.
>
> On 1/21/2021 7:46 PM, Chris Albertson wrote:
> > I'd bet SPI would work well but even easier would be to connect them to
> the
> > Pi4 with USB.  Both sides have software that makes the USB look like a
> > serial port and the physical connection is done with off the shelf
cable.
> >
> > I've used M0 boards this way in the past and using USB lets you also
cnet
> > them to a Linux PC
> >
> > What I like about the Pico is that it can be SMT hand soldered.  I can
> make
> > a simple passive carrier board that has connectors and it is not hard to
> > hand solder 0.1 inch pitch.  The carrier board could be a Pi-hat
> >
> > On Thu, Jan 21, 2021 at 4:30 PM Dave Cole 
> wrote:
> >
> >> I wonder if these could act as SPI slaves to the RPI 4?
> >>
> >> I've been trying to buy two from Adafruit and they keep selling out and
> >> then coming back in stock, and then selling out again!
> >>
> >> Dave
> >>
> >> On 1/21/2021 6:36 PM, andy pugh wrote:
> >>> On Thu, 21 Jan 2021 at 21:52, Chris Albertson <
> albertson.ch...@gmail.com>
> >> wrote:
> >>>> This is an STM32 microcontroller.
> >>> Are you sure? It is an ARM Cortex M0, like the STM32, but is it made
by
> >> ST?
> >>
> >> ___
> >> Emc-users mailing list
> >> Emc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-users
> >>
> >
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Chris Albertson]

On Thu, Jan 21, 2021 at 7:56 PM Dave Cole  wrote:

> I was thinking multiple RPi Picos to one RPi4, but for just one, that is
> probably the way to go.
>

The Pico is a dual-core M0.   So it is faster than I had originally
thought.   Micro-Python is ported to it so it might be very easy for many
people to program.   I'm got my name in to be notified when they are back
in stock. I still think USB is the simplest way to connect while
experimenting.

One advantage of USB is that you need USB to program the Pico.   You would
run the development system on the Pi4 and change the firmware by copying
files or drag/drop.  If the Pico is SPI connected then you need to hunt
down a USB cable then walk out to the shop to change the firmware.



> I'll try that first!
>
> The Pi Hat as the carrier board is also a good idea.
>
> On 1/21/2021 7:46 PM, Chris Albertson wrote:
> > I'd bet SPI would work well but even easier would be to connect them to
> the
> > Pi4 with USB.  Both sides have software that makes the USB look like a
> > serial port and the physical connection is done with off the shelf cable.
> >
> > I've used M0 boards this way in the past and using USB lets you also cnet
> > them to a Linux PC
> >
> > What I like about the Pico is that it can be SMT hand soldered.  I can
> make
> > a simple passive carrier board that has connectors and it is not hard to
> > hand solder 0.1 inch pitch.  The carrier board could be a Pi-hat
> >
> > On Thu, Jan 21, 2021 at 4:30 PM Dave Cole 
> wrote:
> >
> >> I wonder if these could act as SPI slaves to the RPI 4?
> >>
> >> I've been trying to buy two from Adafruit and they keep selling out and
> >> then coming back in stock, and then selling out again!
> >>
> >> Dave
> >>
> >> On 1/21/2021 6:36 PM, andy pugh wrote:
> >>> On Thu, 21 Jan 2021 at 21:52, Chris Albertson <
> albertson.ch...@gmail.com>
> >> wrote:
>  This is an STM32 microcontroller.
> >>> Are you sure? It is an ARM Cortex M0, like the STM32, but is it made by
> >> ST?
> >>
> >> ___
> >> Emc-users mailing list
> >> Emc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-users
> >>
> >
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Dave Cole]

I was thinking multiple RPi Picos to one RPi4, but for just one, that is 
probably the way to go.

I'll try that first!

The Pi Hat as the carrier board is also a good idea.

On 1/21/2021 7:46 PM, Chris Albertson wrote:

I'd bet SPI would work well but even easier would be to connect them to the
Pi4 with USB.  Both sides have software that makes the USB look like a
serial port and the physical connection is done with off the shelf cable.

I've used M0 boards this way in the past and using USB lets you also cnet
them to a Linux PC

What I like about the Pico is that it can be SMT hand soldered.  I can make
a simple passive carrier board that has connectors and it is not hard to
hand solder 0.1 inch pitch.  The carrier board could be a Pi-hat

On Thu, Jan 21, 2021 at 4:30 PM Dave Cole  wrote:


I wonder if these could act as SPI slaves to the RPI 4?

I've been trying to buy two from Adafruit and they keep selling out and
then coming back in stock, and then selling out again!

Dave

On 1/21/2021 6:36 PM, andy pugh wrote:

On Thu, 21 Jan 2021 at 21:52, Chris Albertson 

wrote:

This is an STM32 microcontroller.

Are you sure? It is an ARM Cortex M0, like the STM32, but is it made by

ST?

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users






___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Chris Albertson]

I'd bet SPI would work well but even easier would be to connect them to the
Pi4 with USB.  Both sides have software that makes the USB look like a
serial port and the physical connection is done with off the shelf cable.

I've used M0 boards this way in the past and using USB lets you also cnet
them to a Linux PC

What I like about the Pico is that it can be SMT hand soldered.  I can make
a simple passive carrier board that has connectors and it is not hard to
hand solder 0.1 inch pitch.  The carrier board could be a Pi-hat

On Thu, Jan 21, 2021 at 4:30 PM Dave Cole  wrote:

> I wonder if these could act as SPI slaves to the RPI 4?
>
> I've been trying to buy two from Adafruit and they keep selling out and
> then coming back in stock, and then selling out again!
>
> Dave
>
> On 1/21/2021 6:36 PM, andy pugh wrote:
> > On Thu, 21 Jan 2021 at 21:52, Chris Albertson 
> wrote:
> >
> >> This is an STM32 microcontroller.
> > Are you sure? It is an ARM Cortex M0, like the STM32, but is it made by
> ST?
> >
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Dave Cole]

Sparkfun had them in stock.

On 1/21/2021 7:30 PM, Dave Cole wrote:

I wonder if these could act as SPI slaves to the RPI 4?

I've been trying to buy two from Adafruit and they keep selling out 
and then coming back in stock, and then selling out again!


Dave

On 1/21/2021 6:36 PM, andy pugh wrote:
On Thu, 21 Jan 2021 at 21:52, Chris Albertson 
 wrote:



This is an STM32 microcontroller.
Are you sure? It is an ARM Cortex M0, like the STM32, but is it made 
by ST?





___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Chris Albertson]

On Thu, Jan 21, 2021 at 3:39 PM andy pugh  wrote:

> On Thu, 21 Jan 2021 at 21:52, Chris Albertson 
> wrote:
>
> Are you sure? It is an ARM Cortex M0, like the STM32, but is it made by ST?
>

Sorry,  It is much better than that.  My mistake.

It is a RP2040 microcontroller chip designed by Raspberry Pi in the UK
Dual-core Arm Cortex-M0+ processor, flexible clock running up to 133 MHz






>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Dave Cole]

I wonder if these could act as SPI slaves to the RPI 4?

I've been trying to buy two from Adafruit and they keep selling out and 
then coming back in stock, and then selling out again!


Dave

On 1/21/2021 6:36 PM, andy pugh wrote:

On Thu, 21 Jan 2021 at 21:52, Chris Albertson  wrote:


This is an STM32 microcontroller.

Are you sure? It is an ARM Cortex M0, like the STM32, but is it made by ST?




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[andy pugh]

On Thu, 21 Jan 2021 at 21:52, Chris Albertson  wrote:

> This is an STM32 microcontroller.

Are you sure? It is an ARM Cortex M0, like the STM32, but is it made by ST?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Chris Albertson]

To answer some questions I looked it up...

This is an STM32 microcontroller.   The firmware makes it enumerate to a
PC/Mac/Linux machine as a USB storage device.   You program this this be
drag-and-drop the binary file to the storage.   (or do a "cp" from
the command line)

What software environment?   You seem to have a wide choice.   The Arduino
IDE could work or you could use Gcc from the command line or STM' "STM
Cube" but my favorite is Mbed from ARM. Some of the RTOS' would work
too, like FreeRTOS.

Supported input power 1.8–5.5V DC.  Most pins are "5 volt tolerant" some
are 3.3 volt only.

This is basically a replacement fro the $3 "Blue pill" but I think this is
done better and has MUCH better documentation.   Read everything here
https://datasheets.raspberrypi.org/pico/pico_datasheet.pdf

What to do with these?   I'm thinking they will have much more use on robot
projects then on machine tool projects.But in the machine tool world
they could be sued are a kind of "standard" that performs the same
functions we see done by Mesa cards today but at a much lower cost.At
$4 we can afford to place one on each axis.

My experience with the M0 is that it is powerful enough to run PID
controllers for two motors with the encoders are running at about 10,000
less per second and the motors are being controlled with PWM. You can
to up to ~10 Mhz pule rates if you use the built-in hardware quadrature
decoders.  These do the encoder reading in hardware and a re much faster
than software interrupts.   But I think the M0 has only one channel of this.

The main advantage of these vs. others is (1) good documentation, (2)
trusted source, (3) low cost.

About the cost.  $4 is low but look also at the Raspberry Pi Zero.  It
costs only $5 and runs Linux.  It is dramatically more powerful then this
"pico" but Linux is just poor at "real-time" and the Pico is outstandingly
good at "real-time".So they are complementary.It would be fun to
build a $9 robot controller using both.   I think I will.


On Thu, Jan 21, 2021 at 8:04 AM Matthew Herd  wrote:

> Agreed.  It looks promising, but no more so than a "Blue Pill" or similar
> boards.  Also, what voltages does it operate on?  I wasn’t able to find
> that in the literature but I didn’t dig into their documentation that
> deeply.  Nonetheless, it seems like info that should be part of the specs.
>
> > On Jan 21, 2021, at 10:41 AM, Jon Elson  wrote:
> >
> > On 01/21/2021 02:43 AM, Sven Wesley wrote:
> >> For you people out there who use an Arduino or RPi to communicate with
> >> parts of the machine (tool changers, doors etc). Here's a cute and
> really
> >> low priced alternative.
> >> https://www.raspberrypi.org/products/raspberry-pi-pico/
> >>
> >>
> > The blurb is pretty sketchy on details.  What is the programming
> environment like?
> >
> > Thanks,
> >
> > Jon
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Kirk Wallace]

I haven't been too keen on the Raspberry Pi products due to being 
partially closed source. It looks like that issue has been addressed. 
I'll be watching this space.



http://linuxgizmos.com/raspberry-pi-goes-mcu-with-open-spec-pico/




On 1/21/21 12:43 AM, Sven Wesley wrote:

For you people out there who use an Arduino or RPi to communicate with
parts of the machine (tool changers, doors etc). Here's a cute and really
low priced alternative.
https://www.raspberrypi.org/products/raspberry-pi-pico/

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users






___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[John Dammeyer]

> From: Sven Wesley [mailto:svenne.d...@gmail.com]
> Den tors 21 jan. 2021 kl 17:51 skrev John Dammeyer :
> 
> > No CAN bus port.  No USB port.
> >
> > I guess it depends on how deep one wants to go into C programming as to
> > what you might choose for independently controlled things like a tool
> > changer.  I have PIC32 development boards and processors that support
> > quadrature encoders.  Same dsPIC series with quadrature and CAN bus.
> >
> > The latest interesting and although a lot more money is:
> > https://www.ti.com/tool/LAUNCHXL-F28379D
> >
> > With dual processors and a lot of other pretty cool features this could be
> > made into a wicked pendant.
> >
> > John Dammeyer
> >
> 
> You load the code over USB. The Pico doc has code examples for REPL over
> USB, UART, I2C and SPI.
> *3.2. UART*
> *USB  serial  is  available  from  MicroPython,  but  the  REPL  is  also
>  available  over  UART0  by  default.*
> Isn't that USB communication?

Stand corrected.  Only looked at the pin definitions.  Not the board itself and 
there is a USB cable plugged into it.  



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Sven Wesley]

Den tors 21 jan. 2021 kl 17:51 skrev John Dammeyer :

> No CAN bus port.  No USB port.
>
> I guess it depends on how deep one wants to go into C programming as to
> what you might choose for independently controlled things like a tool
> changer.  I have PIC32 development boards and processors that support
> quadrature encoders.  Same dsPIC series with quadrature and CAN bus.
>
> The latest interesting and although a lot more money is:
> https://www.ti.com/tool/LAUNCHXL-F28379D
>
> With dual processors and a lot of other pretty cool features this could be
> made into a wicked pendant.
>
> John Dammeyer
>

You load the code over USB. The Pico doc has code examples for REPL over
USB, UART, I2C and SPI.
*3.2. UART*
*USB  serial  is  available  from  MicroPython,  but  the  REPL  is  also
 available  over  UART0  by  default.*
Isn't that USB communication?

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Matthew Herd]

Just looked again and can confirm it’s in one of their spec listings 
(1.8-5.5V), but not in another one.

> On Jan 21, 2021, at 11:41 AM, Dave Cole  wrote:
> 
> It has some interesting sub processors to handle I/O.   Reminds me of the sub 
> processors on the Beagle Board Black.
> https://hackspace.raspberrypi.org/articles/what-is-programmable-i-o-on-raspberry-pi-pico
> 
> Here are some docs:
> https://www.raspberrypi.org/documentation/pico/getting-started/
> 
> It has a lot in a very small package for $4.00
> 
> Dave
> 
> On 1/21/2021 10:41 AM, Jon Elson wrote:
>> On 01/21/2021 02:43 AM, Sven Wesley wrote:
>>> For you people out there who use an Arduino or RPi to communicate with
>>> parts of the machine (tool changers, doors etc). Here's a cute and really
>>> low priced alternative.
>>> https://www.raspberrypi.org/products/raspberry-pi-pico/
>>> 
>>> 
>> The blurb is pretty sketchy on details.  What is the programming environment 
>> like?
>> 
>> Thanks,
>> 
>> Jon
>> 
>> 
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Jon Elson]

On 01/21/2021 10:02 AM, Matthew Herd wrote:

Agreed.  It looks promising, but no more so than a "Blue Pill" or similar 
boards.  Also, what voltages does it operate on?  I wasn’t able to find that in the 
literature but I didn’t dig into their documentation that deeply.

3.3 - 5 V.  That WAS in the specs.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[John Dammeyer]

No CAN bus port.  No USB port. 

I guess it depends on how deep one wants to go into C programming as to what 
you might choose for independently controlled things like a tool changer.  I 
have PIC32 development boards and processors that support quadrature encoders.  
Same dsPIC series with quadrature and CAN bus.

The latest interesting and although a lot more money is:
https://www.ti.com/tool/LAUNCHXL-F28379D

With dual processors and a lot of other pretty cool features this could be made 
into a wicked pendant. 

John Dammeyer

> -Original Message-
> From: Sven Wesley [mailto:svenne.d...@gmail.com]
> Sent: January-21-21 12:43 AM
> To: Enhanced Machine Controller (EMC)
> Subject: [Emc-users] Rpi Pico
> 
> For you people out there who use an Arduino or RPi to communicate with
> parts of the machine (tool changers, doors etc). Here's a cute and really
> low priced alternative.
> https://www.raspberrypi.org/products/raspberry-pi-pico/
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Dave Cole]

It has some interesting sub processors to handle I/O.   Reminds me of 
the sub processors on the Beagle Board Black.

https://hackspace.raspberrypi.org/articles/what-is-programmable-i-o-on-raspberry-pi-pico

Here are some docs:
https://www.raspberrypi.org/documentation/pico/getting-started/

It has a lot in a very small package for $4.00

Dave

On 1/21/2021 10:41 AM, Jon Elson wrote:

On 01/21/2021 02:43 AM, Sven Wesley wrote:

For you people out there who use an Arduino or RPi to communicate with
parts of the machine (tool changers, doors etc). Here's a cute and 
really

low priced alternative.
https://www.raspberrypi.org/products/raspberry-pi-pico/


The blurb is pretty sketchy on details.  What is the programming 
environment like?


Thanks,

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Matthew Herd]

Agreed.  It looks promising, but no more so than a "Blue Pill" or similar 
boards.  Also, what voltages does it operate on?  I wasn’t able to find that in 
the literature but I didn’t dig into their documentation that deeply.  
Nonetheless, it seems like info that should be part of the specs.

> On Jan 21, 2021, at 10:41 AM, Jon Elson  wrote:
> 
> On 01/21/2021 02:43 AM, Sven Wesley wrote:
>> For you people out there who use an Arduino or RPi to communicate with
>> parts of the machine (tool changers, doors etc). Here's a cute and really
>> low priced alternative.
>> https://www.raspberrypi.org/products/raspberry-pi-pico/
>> 
>> 
> The blurb is pretty sketchy on details.  What is the programming environment 
> like?
> 
> Thanks,
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi Pico

[Jon Elson]

On 01/21/2021 02:43 AM, Sven Wesley wrote:

For you people out there who use an Arduino or RPi to communicate with
parts of the machine (tool changers, doors etc). Here's a cute and really
low priced alternative.
https://www.raspberrypi.org/products/raspberry-pi-pico/


The blurb is pretty sketchy on details.  What is the 
programming environment like?


Thanks,

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Rpi Pico

[Sven Wesley]

For you people out there who use an Arduino or RPi to communicate with
parts of the machine (tool changers, doors etc). Here's a cute and really
low priced alternative.
https://www.raspberrypi.org/products/raspberry-pi-pico/

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Jon Elson]

On 01/13/2021 10:40 AM, Ralph Stirling wrote:

I played around with sd on my RPi after I got things
going with the USB flash.  After dd copying the same
image to the sd card, booting the pi successfully, and
killing power, I never got a successful second boot.
I would have to mount the sd card on my laptop and
copy over the /boot partition each time before it would
boot again.  I was unimpressed.  The BBB may have
better protection from glitching the sd card during
power fail, but I had troubles from the RPi 1 to the RPi 3B+.


I have one Beagle Bone Black that won't boot from SD, but 
will boot from on-board MMI.
I never diagnosed the issue, it could be corrupt parameters 
in the boot code on the MMI.


I've never had an SD card harmed on the Beagle, and I do 
have to just kill power to it
once in a while when it won't shutdown or get on the net.  I 
do try to do a graceful shutdown

when possible.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

I played around with sd on my RPi after I got things
going with the USB flash.  After dd copying the same
image to the sd card, booting the pi successfully, and
killing power, I never got a successful second boot.
I would have to mount the sd card on my laptop and
copy over the /boot partition each time before it would
boot again.  I was unimpressed.  The BBB may have
better protection from glitching the sd card during
power fail, but I had troubles from the RPi 1 to the RPi 3B+.

I'll stick with the usb drives that stick out of the socket
less than 1/4" and cost the same as an sd card.

-- Ralph

From: Jon Elson [el...@pico-systems.com]
Sent: Wednesday, January 13, 2021 8:30 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

On 01/12/2021 10:48 PM, Thaddeus Waldner wrote:
> I’m wondering what you plan to use for flash memory on the Pi. Is the SD card 
> a viable solution in this application? Would the Pi compute module with 
> onboard flash memory be a workable solution?
>
> One issue with onboard flash memory is that swapping out a pi in the case of 
> a processor failure would be more difficult. Is there anything else that 
> makes the compute modules a worse choice than the standard pi?
>
I've used the SD as the main "disk" storage on a Beagle Bone
for years.  The advantage is you can pull it out, put it in
a USB card reader and transfer files.  Mostly I use that to
initially load the OS, LinuxCNC (Machinekit fork) and etc.,
and once it is on the network that isn't needed again.
Modern SD cards just work fine, and especially if you set a
couple options like noatime in the file system, they are
quite robust.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7Cb5fd931ac27c4fb378b008d8b7e0ad66%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637461522916963401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nqqqOV1P6xVwgC0agk3HitsmhgKNZwxZRPdpzdV9UWs%3Dreserved=0


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Jon Elson]

On 01/12/2021 10:48 PM, Thaddeus Waldner wrote:

I’m wondering what you plan to use for flash memory on the Pi. Is the SD card a 
viable solution in this application? Would the Pi compute module with onboard 
flash memory be a workable solution?

One issue with onboard flash memory is that swapping out a pi in the case of a 
processor failure would be more difficult. Is there anything else that makes 
the compute modules a worse choice than the standard pi?

I've used the SD as the main "disk" storage on a Beagle Bone 
for years.  The advantage is you can pull it out, put it in 
a USB card reader and transfer files.  Mostly I use that to 
initially load the OS, LinuxCNC (Machinekit fork) and etc., 
and once it is on the network that isn't needed again.  
Modern SD cards just work fine, and especially if you set a 
couple options like noatime in the file system, they are 
quite robust.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

I'm using the 3B+ and a tiny usb flash.  It handles unexpected power cycles 
fine, unlike the sd card.  Booting a 4B off usb is more difficult I believe, 
but my only 4B seems to be dead, so I'm progressing with the 3B+.

-- Ralph

On Jan 12, 2021 8:49 PM, Thaddeus Waldner  wrote:
CAUTION: This email originated from outside the Walla Walla University email 
system.


I’m wondering what you plan to use for flash memory on the Pi. Is the SD card a 
viable solution in this application? Would the Pi compute module with onboard 
flash memory be a workable solution?

One issue with onboard flash memory is that swapping out a pi in the case of a 
processor failure would be more difficult. Is there anything else that makes 
the compute modules a worse choice than the standard pi?

Of course this is just me wishing someone would hook up a basic MESA card with 
the Pi4 compute module headers.


> On Jan 12, 2021, at 2:33 PM, Ralph Stirling  
> wrote:
>
> Success at last!
>
> To summarize everything I've learned:
> - I was missing one ground (RPi pin 14)
> - mesaflash doesn't tell me that I have to
>  use --device 7i90, not 7i90hd.  I had to
>  look at the mesaflash source to figure that out.
> - my Fluke 179 dvm diode check does not
>   give me ~0.7v readings for fpga pins
> - I have to load the spi bit file with jtag
>
> I now have native RPi jtag using openocd
> working, so don't need the $50 Digilent
> HS2 dongle any more.  I edited the
> raspberrypi-native.cfg file to move the
> gpio pins from 11,25,10,9 to 17,27,22,5
> to avoid conflict with the 7i90's SPI pins.
>
> I will spin another version of my little adapter
> shim pcb to include the jtag header.  I'll be
> happy to share that design with the group
> when I get them back and tested.
>
> Thank you again!
> -- Ralph
>
>
>> Is there anything that needs to be done
>> differently on the RPi 3b+ to communicate
>> with the 7i90 via spi versus the 7c81?
>
> It should be identical, and AFAIK the mesaflash interface
> should be less picky since it runs at a lower clock speed
> than the default hm2-rpspi driver
>
> Are all RPI grounds connected to all 7I90 26 pin
> header grounds?
>
>
>>
>> Is the next step to cobble up some vhdl to
>> verify all the pins on the spi interface side
>> are functioning?  I suppose somewhere along
>> the line I might have blown a pin.
>
>
> If you blow a  pin, it will usually show as the
> protection diode being damaged. You can check
> this with a DVMs diode check function. Connect
> the DVMs positive lead to 7I90 ground and check
> the diode voltage drop on the SPI leads, they should
> all be ~.7V
>
>>
>
>> I'd really like to get this working, as I'm putting
>> together a standard package I can use for all
>> our custom controllers for machines and instruments.
>> Bioprinters, syringe pumps, bioreactors, routers,
>> pick & place, hotwire foam cutters.  I'm tired of
>> random castoff pc's.
>>
>> Thanks again,
>> -- Ralph
>> 
>> From: Peter C. Wallace [p...@mesanet.com]
>> Sent: Monday, January 11, 2021 4:34 PM
>> To: Enhanced Machine Controller (EMC)
>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>
>> CAUTION: This email originated from outside the Walla Walla University email 
>> system.
>>
>>
>>> On Mon, 11 Jan 2021, Ralph Stirling wrote:
>>>
>>> Date: Mon, 11 Jan 2021 23:48:56 +
>>> From: Ralph Stirling 
>>> Reply-To: "Enhanced Machine Controller (EMC)"
>>>
>>> To: "Enhanced Machine Controller (EMC)" 
>>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>>
>>> I've made a bit of progress now.  I found a Digilent HS2
>>> jtag dongle, and got to the point of (apparently) successfully
>>> loading an SPI bitstream to the 7I90 (chose 7i90_spi_svst4_8.bit).
>>>
>>> Running:
>>>
>>> $ mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid
>>>
>>> gives me the same "no 7I90HD board found" error though.  I tried
>>> adding a pullup resistor to the SDO pin, without change, which
>>> would seem to indicate the 7I90HD is actively driving it low.
>>>
>>> Is there a very simple blinky bitstream I can try loading to
>>> be sure the jtag loading is successful?  The /INIT yellow led
>>> flashes briefly, and /DONE red led does go on during the load
>>> and goes off afterward.
>>>
>>> Thanks again.
>>> -- Ralph
>>
>>
>> Theres no blinky light test bitfile but if you load the sserial
>&g

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Thaddeus Waldner]

I’m wondering what you plan to use for flash memory on the Pi. Is the SD card a 
viable solution in this application? Would the Pi compute module with onboard 
flash memory be a workable solution?

One issue with onboard flash memory is that swapping out a pi in the case of a 
processor failure would be more difficult. Is there anything else that makes 
the compute modules a worse choice than the standard pi?
 
Of course this is just me wishing someone would hook up a basic MESA card with 
the Pi4 compute module headers. 


> On Jan 12, 2021, at 2:33 PM, Ralph Stirling  
> wrote:
> 
> Success at last!
> 
> To summarize everything I've learned:
> - I was missing one ground (RPi pin 14)
> - mesaflash doesn't tell me that I have to 
>  use --device 7i90, not 7i90hd.  I had to
>  look at the mesaflash source to figure that out.
> - my Fluke 179 dvm diode check does not
>   give me ~0.7v readings for fpga pins
> - I have to load the spi bit file with jtag
> 
> I now have native RPi jtag using openocd
> working, so don't need the $50 Digilent
> HS2 dongle any more.  I edited the
> raspberrypi-native.cfg file to move the
> gpio pins from 11,25,10,9 to 17,27,22,5
> to avoid conflict with the 7i90's SPI pins.
> 
> I will spin another version of my little adapter
> shim pcb to include the jtag header.  I'll be
> happy to share that design with the group
> when I get them back and tested.
> 
> Thank you again!
> -- Ralph
> 
> 
>> Is there anything that needs to be done
>> differently on the RPi 3b+ to communicate
>> with the 7i90 via spi versus the 7c81?
> 
> It should be identical, and AFAIK the mesaflash interface
> should be less picky since it runs at a lower clock speed
> than the default hm2-rpspi driver
> 
> Are all RPI grounds connected to all 7I90 26 pin
> header grounds?
> 
> 
>> 
>> Is the next step to cobble up some vhdl to
>> verify all the pins on the spi interface side
>> are functioning?  I suppose somewhere along
>> the line I might have blown a pin.
> 
> 
> If you blow a  pin, it will usually show as the
> protection diode being damaged. You can check
> this with a DVMs diode check function. Connect
> the DVMs positive lead to 7I90 ground and check
> the diode voltage drop on the SPI leads, they should
> all be ~.7V
> 
>> 
> 
>> I'd really like to get this working, as I'm putting
>> together a standard package I can use for all
>> our custom controllers for machines and instruments.
>> Bioprinters, syringe pumps, bioreactors, routers,
>> pick & place, hotwire foam cutters.  I'm tired of
>> random castoff pc's.
>> 
>> Thanks again,
>> -- Ralph
>> 
>> From: Peter C. Wallace [p...@mesanet.com]
>> Sent: Monday, January 11, 2021 4:34 PM
>> To: Enhanced Machine Controller (EMC)
>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>> 
>> CAUTION: This email originated from outside the Walla Walla University email 
>> system.
>> 
>> 
>>> On Mon, 11 Jan 2021, Ralph Stirling wrote:
>>> 
>>> Date: Mon, 11 Jan 2021 23:48:56 +
>>> From: Ralph Stirling 
>>> Reply-To: "Enhanced Machine Controller (EMC)"
>>>
>>> To: "Enhanced Machine Controller (EMC)" 
>>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>> 
>>> I've made a bit of progress now.  I found a Digilent HS2
>>> jtag dongle, and got to the point of (apparently) successfully
>>> loading an SPI bitstream to the 7I90 (chose 7i90_spi_svst4_8.bit).
>>> 
>>> Running:
>>> 
>>> $ mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid
>>> 
>>> gives me the same "no 7I90HD board found" error though.  I tried
>>> adding a pullup resistor to the SDO pin, without change, which
>>> would seem to indicate the 7I90HD is actively driving it low.
>>> 
>>> Is there a very simple blinky bitstream I can try loading to
>>> be sure the jtag loading is successful?  The /INIT yellow led
>>> flashes briefly, and /DONE red led does go on during the load
>>> and goes off afterward.
>>> 
>>> Thanks again.
>>> -- Ralph
>> 
>> 
>> Theres no blinky light test bitfile but if you load the sserial
>> remote bitfile 7i90_ssremote.bit, The init LED should light once
>> configured (well 50 ms after configured indicating a watchdog timeout)
>> 
>>> 
>>> From: Peter C. Wallace [p...@mesanet.com]
>>> Sent: Friday, January 8, 2021 1:22 PM
>>> To: Enh

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

Success at last!

To summarize everything I've learned:
- I was missing one ground (RPi pin 14)
- mesaflash doesn't tell me that I have to 
  use --device 7i90, not 7i90hd.  I had to
  look at the mesaflash source to figure that out.
- my Fluke 179 dvm diode check does not
   give me ~0.7v readings for fpga pins
- I have to load the spi bit file with jtag

I now have native RPi jtag using openocd
working, so don't need the $50 Digilent
HS2 dongle any more.  I edited the
raspberrypi-native.cfg file to move the
gpio pins from 11,25,10,9 to 17,27,22,5
to avoid conflict with the 7i90's SPI pins.

I will spin another version of my little adapter
shim pcb to include the jtag header.  I'll be
happy to share that design with the group
when I get them back and tested.

Thank you again!
-- Ralph


> Is there anything that needs to be done
> differently on the RPi 3b+ to communicate
> with the 7i90 via spi versus the 7c81?

It should be identical, and AFAIK the mesaflash interface
should be less picky since it runs at a lower clock speed
than the default hm2-rpspi driver

Are all RPI grounds connected to all 7I90 26 pin
header grounds?


>
> Is the next step to cobble up some vhdl to
> verify all the pins on the spi interface side
> are functioning?  I suppose somewhere along
> the line I might have blown a pin.


If you blow a  pin, it will usually show as the
protection diode being damaged. You can check
this with a DVMs diode check function. Connect
the DVMs positive lead to 7I90 ground and check
the diode voltage drop on the SPI leads, they should
all be ~.7V

>

> I'd really like to get this working, as I'm putting
> together a standard package I can use for all
> our custom controllers for machines and instruments.
> Bioprinters, syringe pumps, bioreactors, routers,
> pick & place, hotwire foam cutters.  I'm tired of
> random castoff pc's.
>
> Thanks again,
> -- Ralph
> 
> From: Peter C. Wallace [p...@mesanet.com]
> Sent: Monday, January 11, 2021 4:34 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
> CAUTION: This email originated from outside the Walla Walla University email 
> system.
>
>
> On Mon, 11 Jan 2021, Ralph Stirling wrote:
>
>> Date: Mon, 11 Jan 2021 23:48:56 +
>> From: Ralph Stirling 
>> Reply-To: "Enhanced Machine Controller (EMC)"
>> 
>> To: "Enhanced Machine Controller (EMC)" 
>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>
>> I've made a bit of progress now.  I found a Digilent HS2
>> jtag dongle, and got to the point of (apparently) successfully
>> loading an SPI bitstream to the 7I90 (chose 7i90_spi_svst4_8.bit).
>>
>> Running:
>>
>> $ mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid
>>
>> gives me the same "no 7I90HD board found" error though.  I tried
>> adding a pullup resistor to the SDO pin, without change, which
>> would seem to indicate the 7I90HD is actively driving it low.
>>
>> Is there a very simple blinky bitstream I can try loading to
>> be sure the jtag loading is successful?  The /INIT yellow led
>> flashes briefly, and /DONE red led does go on during the load
>> and goes off afterward.
>>
>> Thanks again.
>> -- Ralph
>
>
> Theres no blinky light test bitfile but if you load the sserial
> remote bitfile 7i90_ssremote.bit, The init LED should light once
> configured (well 50 ms after configured indicating a watchdog timeout)
>
>> 
>> From: Peter C. Wallace [p...@mesanet.com]
>> Sent: Friday, January 8, 2021 1:22 PM
>> To: Enhanced Machine Controller (EMC)
>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>
>> CAUTION: This email originated from outside the Walla Walla University email 
>> system.
>>
>>
>> On Fri, 8 Jan 2021, Ralph Stirling wrote:
>>
>>> Date: Fri, 8 Jan 2021 21:08:55 +
>>> From: Ralph Stirling 
>>> Reply-To: "Enhanced Machine Controller (EMC)"
>>> 
>>> To: "Enhanced Machine Controller (EMC)" 
>>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>>
>>> Not having Xilinx Impact tool on the Rpi (or anywhere
>>> at the moment), I found a tutorial on setting up
>>> OpenOCD for jtag on the Rpi.  I have installed OpenOCD
>>> on my RPi 3B+ and connected the gpio to the JTAG pins
>>> on the 7i90HD, following this tutorial:
>>>
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmovr0.com%2F2016%2F09%2F02%2Fuse-raspberry-pi-23-as-a-jtagswd-adapter%2Fdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C4feb8

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Peter C. Wallace]

On Tue, 12 Jan 2021, Ralph Stirling wrote:


Date: Tue, 12 Jan 2021 01:10:47 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

Ok, 7i90_ssremote.bit lights the red led after
configuration, so it appears I can successfully
load bitstreams over jtag.  Mesaflash still does
not recognize the board over spi with an spi
config loaded though (all  cookies).

Is there anything that needs to be done
differently on the RPi 3b+ to communicate
with the 7i90 via spi versus the 7c81?


It should be identical, and AFAIK the mesaflash interface
should be less picky since it runs at a lower clock speed
than the default hm2-rpspi driver

Are all RPI grounds connected to all 7I90 26 pin
header grounds?




Is the next step to cobble up some vhdl to
verify all the pins on the spi interface side
are functioning?  I suppose somewhere along
the line I might have blown a pin.



If you blow a  pin, it will usually show as the
protection diode being damaged. You can check
this with a DVMs diode check function. Connect
the DVMs positive lead to 7I90 ground and check
the diode voltage drop on the SPI leads, they should
all be ~.7V






I'd really like to get this working, as I'm putting
together a standard package I can use for all
our custom controllers for machines and instruments.
Bioprinters, syringe pumps, bioreactors, routers,
pick & place, hotwire foam cutters.  I'm tired of
random castoff pc's.

Thanks again,
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Monday, January 11, 2021 4:34 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

CAUTION: This email originated from outside the Walla Walla University email 
system.


On Mon, 11 Jan 2021, Ralph Stirling wrote:


Date: Mon, 11 Jan 2021 23:48:56 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

I've made a bit of progress now.  I found a Digilent HS2
jtag dongle, and got to the point of (apparently) successfully
loading an SPI bitstream to the 7I90 (chose 7i90_spi_svst4_8.bit).

Running:

$ mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid

gives me the same "no 7I90HD board found" error though.  I tried
adding a pullup resistor to the SDO pin, without change, which
would seem to indicate the 7I90HD is actively driving it low.

Is there a very simple blinky bitstream I can try loading to
be sure the jtag loading is successful?  The /INIT yellow led
flashes briefly, and /DONE red led does go on during the load
and goes off afterward.

Thanks again.
-- Ralph



Theres no blinky light test bitfile but if you load the sserial
remote bitfile 7i90_ssremote.bit, The init LED should light once
configured (well 50 ms after configured indicating a watchdog timeout)



From: Peter C. Wallace [p...@mesanet.com]
Sent: Friday, January 8, 2021 1:22 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

CAUTION: This email originated from outside the Walla Walla University email 
system.


On Fri, 8 Jan 2021, Ralph Stirling wrote:


Date: Fri, 8 Jan 2021 21:08:55 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

Not having Xilinx Impact tool on the Rpi (or anywhere
at the moment), I found a tutorial on setting up
OpenOCD for jtag on the Rpi.  I have installed OpenOCD
on my RPi 3B+ and connected the gpio to the JTAG pins
on the 7i90HD, following this tutorial:

https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmovr0.com%2F2016%2F09%2F02%2Fuse-raspberry-pi-23-as-a-jtagswd-adapter%2Fdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7Ca6b208efa1e04d60413b08d8b691d2fb%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637460084714990924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kGU9s6afPWfk9ojmZVO7CbY4DVNPM%2F6rgwAFTrJsqT8%3Dreserved=0

The last step seems to be to make a configuration
file for the target device.  The EEPROMs are WInbond
25Q16JVNIQ as best I can read the chip labels.  OpenOCD
doesn't have anything that looks directly applicable.
I also don't know where the two chips are in the jtag
chain.


You dont need to do this if you can program the FPGA
(and JTAG programming large EEPROMS is glacially slow)

If you can program the FPGA via JTAG, you program the FPGA with a SPI
configuration, and then run mesaflash from the RPI to write the
flash memory




Am I heading down a rat hole, or getting close to success?

Thanks again.
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Thursday,

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

Ok, 7i90_ssremote.bit lights the red led after
configuration, so it appears I can successfully
load bitstreams over jtag.  Mesaflash still does
not recognize the board over spi with an spi
config loaded though (all  cookies).

Is there anything that needs to be done
differently on the RPi 3b+ to communicate
with the 7i90 via spi versus the 7c81?

Is the next step to cobble up some vhdl to
verify all the pins on the spi interface side
are functioning?  I suppose somewhere along
the line I might have blown a pin.

I'd really like to get this working, as I'm putting
together a standard package I can use for all 
our custom controllers for machines and instruments.
Bioprinters, syringe pumps, bioreactors, routers, 
pick & place, hotwire foam cutters.  I'm tired of 
random castoff pc's.

Thanks again,
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Monday, January 11, 2021 4:34 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

CAUTION: This email originated from outside the Walla Walla University email 
system.


On Mon, 11 Jan 2021, Ralph Stirling wrote:

> Date: Mon, 11 Jan 2021 23:48:56 +
> From: Ralph Stirling 
> Reply-To: "Enhanced Machine Controller (EMC)"
> 
> To: "Enhanced Machine Controller (EMC)" 
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
> I've made a bit of progress now.  I found a Digilent HS2
> jtag dongle, and got to the point of (apparently) successfully
> loading an SPI bitstream to the 7I90 (chose 7i90_spi_svst4_8.bit).
>
> Running:
>
> $ mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid
>
> gives me the same "no 7I90HD board found" error though.  I tried
> adding a pullup resistor to the SDO pin, without change, which
> would seem to indicate the 7I90HD is actively driving it low.
>
> Is there a very simple blinky bitstream I can try loading to
> be sure the jtag loading is successful?  The /INIT yellow led
> flashes briefly, and /DONE red led does go on during the load
> and goes off afterward.
>
> Thanks again.
> -- Ralph


Theres no blinky light test bitfile but if you load the sserial
remote bitfile 7i90_ssremote.bit, The init LED should light once
configured (well 50 ms after configured indicating a watchdog timeout)

> 
> From: Peter C. Wallace [p...@mesanet.com]
> Sent: Friday, January 8, 2021 1:22 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
> CAUTION: This email originated from outside the Walla Walla University email 
> system.
>
>
> On Fri, 8 Jan 2021, Ralph Stirling wrote:
>
>> Date: Fri, 8 Jan 2021 21:08:55 +0000
>> From: Ralph Stirling 
>> Reply-To: "Enhanced Machine Controller (EMC)"
>> 
>> To: "Enhanced Machine Controller (EMC)" 
>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>
>> Not having Xilinx Impact tool on the Rpi (or anywhere
>> at the moment), I found a tutorial on setting up
>> OpenOCD for jtag on the Rpi.  I have installed OpenOCD
>> on my RPi 3B+ and connected the gpio to the JTAG pins
>> on the 7i90HD, following this tutorial:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmovr0.com%2F2016%2F09%2F02%2Fuse-raspberry-pi-23-as-a-jtagswd-adapter%2Fdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7Ca6b208efa1e04d60413b08d8b691d2fb%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637460084714990924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kGU9s6afPWfk9ojmZVO7CbY4DVNPM%2F6rgwAFTrJsqT8%3Dreserved=0
>>
>> The last step seems to be to make a configuration
>> file for the target device.  The EEPROMs are WInbond
>> 25Q16JVNIQ as best I can read the chip labels.  OpenOCD
>> doesn't have anything that looks directly applicable.
>> I also don't know where the two chips are in the jtag
>> chain.
>
> You dont need to do this if you can program the FPGA
> (and JTAG programming large EEPROMS is glacially slow)
>
> If you can program the FPGA via JTAG, you program the FPGA with a SPI
> configuration, and then run mesaflash from the RPI to write the
> flash memory
>
>
>>
>> Am I heading down a rat hole, or getting close to success?
>>
>> Thanks again.
>> -- Ralph
>> 
>> From: Peter C. Wallace [p...@mesanet.com]
>> Sent: Thursday, January 7, 2021 3:47 PM
>> To: Enhanced Machine Controller (EMC)
>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>
>> CAUTION: This email originated from outside the Walla Walla University email 
>> system.
>>
>>
>> O

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Peter C. Wallace]

On Mon, 11 Jan 2021, Ralph Stirling wrote:


Date: Mon, 11 Jan 2021 23:48:56 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

I've made a bit of progress now.  I found a Digilent HS2
jtag dongle, and got to the point of (apparently) successfully
loading an SPI bitstream to the 7I90 (chose 7i90_spi_svst4_8.bit).

Running:

$ mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid

gives me the same "no 7I90HD board found" error though.  I tried
adding a pullup resistor to the SDO pin, without change, which
would seem to indicate the 7I90HD is actively driving it low.

Is there a very simple blinky bitstream I can try loading to
be sure the jtag loading is successful?  The /INIT yellow led
flashes briefly, and /DONE red led does go on during the load
and goes off afterward.

Thanks again.
-- Ralph



Theres no blinky light test bitfile but if you load the sserial
remote bitfile 7i90_ssremote.bit, The init LED should light once
configured (well 50 ms after configured indicating a watchdog timeout)



From: Peter C. Wallace [p...@mesanet.com]
Sent: Friday, January 8, 2021 1:22 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

CAUTION: This email originated from outside the Walla Walla University email 
system.


On Fri, 8 Jan 2021, Ralph Stirling wrote:


Date: Fri, 8 Jan 2021 21:08:55 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

Not having Xilinx Impact tool on the Rpi (or anywhere
at the moment), I found a tutorial on setting up
OpenOCD for jtag on the Rpi.  I have installed OpenOCD
on my RPi 3B+ and connected the gpio to the JTAG pins
on the 7i90HD, following this tutorial:

https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmovr0.com%2F2016%2F09%2F02%2Fuse-raspberry-pi-23-as-a-jtagswd-adapter%2Fdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C0e816ca3cbad4d7d899008d8b41b9984%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637457377919675638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6NnpSk67I%2FpHEaLUmq1Fmg0%2FX6XH2KpNqNghMfBq6lk%3Dreserved=0

The last step seems to be to make a configuration
file for the target device.  The EEPROMs are WInbond
25Q16JVNIQ as best I can read the chip labels.  OpenOCD
doesn't have anything that looks directly applicable.
I also don't know where the two chips are in the jtag
chain.


You dont need to do this if you can program the FPGA
(and JTAG programming large EEPROMS is glacially slow)

If you can program the FPGA via JTAG, you program the FPGA with a SPI
configuration, and then run mesaflash from the RPI to write the
flash memory




Am I heading down a rat hole, or getting close to success?

Thanks again.
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Thursday, January 7, 2021 3:47 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

CAUTION: This email originated from outside the Walla Walla University email 
system.


On Thu, 7 Jan 2021, Ralph Stirling wrote:


Date: Thu, 7 Jan 2021 23:37:03 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"
    
To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

I assumed that the 7i90hd would recognize SPI
directly, like the 7c81 does.  Do I have to go
dig up a parallel port computer from somewhere
and get at least mesaflash running on it just
so I can get spi working for the pi?  That is an
unfortunate hurdle.  I don't see anything in the
manual about needing to load the correct bitstream
over parallel in order to use spi.  In fact, I read
this in the manual:


Yep, you need to have SPI firmware loaded in the 7I90HD
default 7I90HD firmware is EPP, so a device with a EPP
interface is needed to load the SPI configuration
I would suggest loading the SPI interface into the
secondary flash leaving the primary as EPP for a fallback

That is, power the 7I90 with the flash jumper in the "P" position
them move the jumper to "S" before loadin the SPI firmware




"Linux and Windows utility programs mesaflash and mesaflash.exe are provided to
write configuration files to the 7I90HD EEPROM via the RS-422 interface and 
LBP16. The
linux utility can also write configuration files via the EPP interface. These 
files depend on
a simple SPI interface built into both the standard user FPGA bitfiles and the 
fallback
bitfile."



Well there are 2 SPI interfaces, the HM2 compatible host interface (which needs
specific SPI firmware) and the SPI Flash memory interface (which is in HM2
memory space and allows access to the SPI flas

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

Additional discovery.  If I run mesaflash with /dev/spidev0.1 and
my pullup resistor, I get unexpected cookies of .  So it
appears that the 7i90 is driving SDO when I attempt communication
at /dev/spidev0.0.

-- Ralph

From: Ralph Stirling
Sent: Monday, January 11, 2021 3:48 PM
To: Enhanced Machine Controller (EMC)
Subject: RE: [Emc-users] Rpi 3b+ to 7i90hd

I've made a bit of progress now.  I found a Digilent HS2
jtag dongle, and got to the point of (apparently) successfully
loading an SPI bitstream to the 7I90 (chose 7i90_spi_svst4_8.bit).

Running:

$ mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid

gives me the same "no 7I90HD board found" error though.  I tried
adding a pullup resistor to the SDO pin, without change, which
would seem to indicate the 7I90HD is actively driving it low.

Is there a very simple blinky bitstream I can try loading to
be sure the jtag loading is successful?  The /INIT yellow led
flashes briefly, and /DONE red led does go on during the load
and goes off afterward.

Thanks again.
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Friday, January 8, 2021 1:22 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

CAUTION: This email originated from outside the Walla Walla University email 
system.


On Fri, 8 Jan 2021, Ralph Stirling wrote:

> Date: Fri, 8 Jan 2021 21:08:55 +
> From: Ralph Stirling 
> Reply-To: "Enhanced Machine Controller (EMC)"
> 
> To: "Enhanced Machine Controller (EMC)" 
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
> Not having Xilinx Impact tool on the Rpi (or anywhere
> at the moment), I found a tutorial on setting up
> OpenOCD for jtag on the Rpi.  I have installed OpenOCD
> on my RPi 3B+ and connected the gpio to the JTAG pins
> on the 7i90HD, following this tutorial:
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmovr0.com%2F2016%2F09%2F02%2Fuse-raspberry-pi-23-as-a-jtagswd-adapter%2Fdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C0e816ca3cbad4d7d899008d8b41b9984%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637457377919675638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6NnpSk67I%2FpHEaLUmq1Fmg0%2FX6XH2KpNqNghMfBq6lk%3Dreserved=0
>
> The last step seems to be to make a configuration
> file for the target device.  The EEPROMs are WInbond
> 25Q16JVNIQ as best I can read the chip labels.  OpenOCD
> doesn't have anything that looks directly applicable.
> I also don't know where the two chips are in the jtag
> chain.

You dont need to do this if you can program the FPGA
(and JTAG programming large EEPROMS is glacially slow)

If you can program the FPGA via JTAG, you program the FPGA with a SPI
configuration, and then run mesaflash from the RPI to write the
flash memory


>
> Am I heading down a rat hole, or getting close to success?
>
> Thanks again.
> -- Ralph
> 
> From: Peter C. Wallace [p...@mesanet.com]
> Sent: Thursday, January 7, 2021 3:47 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
> CAUTION: This email originated from outside the Walla Walla University email 
> system.
>
>
> On Thu, 7 Jan 2021, Ralph Stirling wrote:
>
>> Date: Thu, 7 Jan 2021 23:37:03 +0000
>> From: Ralph Stirling 
>> Reply-To: "Enhanced Machine Controller (EMC)"
>> 
>> To: "Enhanced Machine Controller (EMC)" 
>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>
>> I assumed that the 7i90hd would recognize SPI
>> directly, like the 7c81 does.  Do I have to go
>> dig up a parallel port computer from somewhere
>> and get at least mesaflash running on it just
>> so I can get spi working for the pi?  That is an
>> unfortunate hurdle.  I don't see anything in the
>> manual about needing to load the correct bitstream
>> over parallel in order to use spi.  In fact, I read
>> this in the manual:
>
> Yep, you need to have SPI firmware loaded in the 7I90HD
> default 7I90HD firmware is EPP, so a device with a EPP
> interface is needed to load the SPI configuration
> I would suggest loading the SPI interface into the
> secondary flash leaving the primary as EPP for a fallback
>
> That is, power the 7I90 with the flash jumper in the "P" position
> them move the jumper to "S" before loadin the SPI firmware
>
>
>>
>> "Linux and Windows utility programs mesaflash and mesaflash.exe are provided 
>> to
>> write configuration files to the 7I90HD EEPROM via the RS-422 interface and 
>> LBP16. The
>> linux utility can also write con

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

I've made a bit of progress now.  I found a Digilent HS2
jtag dongle, and got to the point of (apparently) successfully
loading an SPI bitstream to the 7I90 (chose 7i90_spi_svst4_8.bit).

Running:

$ mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid

gives me the same "no 7I90HD board found" error though.  I tried
adding a pullup resistor to the SDO pin, without change, which
would seem to indicate the 7I90HD is actively driving it low.

Is there a very simple blinky bitstream I can try loading to
be sure the jtag loading is successful?  The /INIT yellow led
flashes briefly, and /DONE red led does go on during the load 
and goes off afterward.

Thanks again.
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Friday, January 8, 2021 1:22 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

CAUTION: This email originated from outside the Walla Walla University email 
system.


On Fri, 8 Jan 2021, Ralph Stirling wrote:

> Date: Fri, 8 Jan 2021 21:08:55 +
> From: Ralph Stirling 
> Reply-To: "Enhanced Machine Controller (EMC)"
> 
> To: "Enhanced Machine Controller (EMC)" 
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
> Not having Xilinx Impact tool on the Rpi (or anywhere
> at the moment), I found a tutorial on setting up
> OpenOCD for jtag on the Rpi.  I have installed OpenOCD
> on my RPi 3B+ and connected the gpio to the JTAG pins
> on the 7i90HD, following this tutorial:
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmovr0.com%2F2016%2F09%2F02%2Fuse-raspberry-pi-23-as-a-jtagswd-adapter%2Fdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C0e816ca3cbad4d7d899008d8b41b9984%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637457377919675638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6NnpSk67I%2FpHEaLUmq1Fmg0%2FX6XH2KpNqNghMfBq6lk%3Dreserved=0
>
> The last step seems to be to make a configuration
> file for the target device.  The EEPROMs are WInbond
> 25Q16JVNIQ as best I can read the chip labels.  OpenOCD
> doesn't have anything that looks directly applicable.
> I also don't know where the two chips are in the jtag
> chain.

You dont need to do this if you can program the FPGA
(and JTAG programming large EEPROMS is glacially slow)

If you can program the FPGA via JTAG, you program the FPGA with a SPI
configuration, and then run mesaflash from the RPI to write the
flash memory


>
> Am I heading down a rat hole, or getting close to success?
>
> Thanks again.
> -- Ralph
> 
> From: Peter C. Wallace [p...@mesanet.com]
> Sent: Thursday, January 7, 2021 3:47 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
> CAUTION: This email originated from outside the Walla Walla University email 
> system.
>
>
> On Thu, 7 Jan 2021, Ralph Stirling wrote:
>
>> Date: Thu, 7 Jan 2021 23:37:03 +0000
>> From: Ralph Stirling 
>> Reply-To: "Enhanced Machine Controller (EMC)"
>> 
>> To: "Enhanced Machine Controller (EMC)" 
>> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>>
>> I assumed that the 7i90hd would recognize SPI
>> directly, like the 7c81 does.  Do I have to go
>> dig up a parallel port computer from somewhere
>> and get at least mesaflash running on it just
>> so I can get spi working for the pi?  That is an
>> unfortunate hurdle.  I don't see anything in the
>> manual about needing to load the correct bitstream
>> over parallel in order to use spi.  In fact, I read
>> this in the manual:
>
> Yep, you need to have SPI firmware loaded in the 7I90HD
> default 7I90HD firmware is EPP, so a device with a EPP
> interface is needed to load the SPI configuration
> I would suggest loading the SPI interface into the
> secondary flash leaving the primary as EPP for a fallback
>
> That is, power the 7I90 with the flash jumper in the "P" position
> them move the jumper to "S" before loadin the SPI firmware
>
>
>>
>> "Linux and Windows utility programs mesaflash and mesaflash.exe are provided 
>> to
>> write configuration files to the 7I90HD EEPROM via the RS-422 interface and 
>> LBP16. The
>> linux utility can also write configuration files via the EPP interface. 
>> These files depend on
>> a simple SPI interface built into both the standard user FPGA bitfiles and 
>> the fallback
>> bitfile."
>
>
> Well there are 2 SPI interfaces, the HM2 compatible host interface (which 
> needs
> specific SPI firmware) and the SPI Flash memory interface (which is in HM2
> memory space and allows acc

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Peter C. Wallace]

On Fri, 8 Jan 2021, Ralph Stirling wrote:


Date: Fri, 8 Jan 2021 21:08:55 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

Not having Xilinx Impact tool on the Rpi (or anywhere
at the moment), I found a tutorial on setting up
OpenOCD for jtag on the Rpi.  I have installed OpenOCD
on my RPi 3B+ and connected the gpio to the JTAG pins
on the 7i90HD, following this tutorial:

https://movr0.com/2016/09/02/use-raspberry-pi-23-as-a-jtagswd-adapter/

The last step seems to be to make a configuration
file for the target device.  The EEPROMs are WInbond
25Q16JVNIQ as best I can read the chip labels.  OpenOCD
doesn't have anything that looks directly applicable.
I also don't know where the two chips are in the jtag
chain.


You dont need to do this if you can program the FPGA
(and JTAG programming large EEPROMS is glacially slow)

If you can program the FPGA via JTAG, you program the FPGA with a SPI 
configuration, and then run mesaflash from the RPI to write the

flash memory




Am I heading down a rat hole, or getting close to success?

Thanks again.
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Thursday, January 7, 2021 3:47 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

CAUTION: This email originated from outside the Walla Walla University email 
system.


On Thu, 7 Jan 2021, Ralph Stirling wrote:


Date: Thu, 7 Jan 2021 23:37:03 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

I assumed that the 7i90hd would recognize SPI
directly, like the 7c81 does.  Do I have to go
dig up a parallel port computer from somewhere
and get at least mesaflash running on it just
so I can get spi working for the pi?  That is an
unfortunate hurdle.  I don't see anything in the
manual about needing to load the correct bitstream
over parallel in order to use spi.  In fact, I read
this in the manual:


Yep, you need to have SPI firmware loaded in the 7I90HD
default 7I90HD firmware is EPP, so a device with a EPP
interface is needed to load the SPI configuration
I would suggest loading the SPI interface into the
secondary flash leaving the primary as EPP for a fallback

That is, power the 7I90 with the flash jumper in the "P" position
them move the jumper to "S" before loadin the SPI firmware




"Linux and Windows utility programs mesaflash and mesaflash.exe are provided to
write configuration files to the 7I90HD EEPROM via the RS-422 interface and 
LBP16. The
linux utility can also write configuration files via the EPP interface. These 
files depend on
a simple SPI interface built into both the standard user FPGA bitfiles and the 
fallback
bitfile."



Well there are 2 SPI interfaces, the HM2 compatible host interface (which needs
specific SPI firmware) and the SPI Flash memory interface (which is in HM2
memory space and allows access to the SPI flash chip)



I can tack on a pullup to SDO.  I have put four
scope probes on the four signals, and see data
when interrogating the 7c81, but not the 7i90hd.
The clock from the pi is correct.

Thanks again.
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Thursday, January 7, 2021 3:18 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd


Looks right

2 layer should be fine as long as the ground is solid (wide)
between the 7I90 and the RPI (and lo longer than a couple of
inches

You might try adding a pullup to SDO (7I90 15) to see if you read
0x which would indicate the the 7I90 is not driving SDO

Sure you have a SPI config in the 7I90?


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C5c8bbaf5f3984eec51d008d8b366a9bc%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637456600811311135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=m8smz8GxQR83SZ5IKfEacp6Rr12LQnmpghFS5H0l1JM%3Dreserved=0


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C5c8bbaf5f3984eec51d008d8b366a9bc%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637456600811311135%7CUnknown%7CTWFpbGZsb3

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

Not having Xilinx Impact tool on the Rpi (or anywhere
at the moment), I found a tutorial on setting up
OpenOCD for jtag on the Rpi.  I have installed OpenOCD 
on my RPi 3B+ and connected the gpio to the JTAG pins 
on the 7i90HD, following this tutorial:

https://movr0.com/2016/09/02/use-raspberry-pi-23-as-a-jtagswd-adapter/

The last step seems to be to make a configuration
file for the target device.  The EEPROMs are WInbond
25Q16JVNIQ as best I can read the chip labels.  OpenOCD
doesn't have anything that looks directly applicable.
I also don't know where the two chips are in the jtag
chain.

Am I heading down a rat hole, or getting close to success?

Thanks again.
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Thursday, January 7, 2021 3:47 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

CAUTION: This email originated from outside the Walla Walla University email 
system.


On Thu, 7 Jan 2021, Ralph Stirling wrote:

> Date: Thu, 7 Jan 2021 23:37:03 +
> From: Ralph Stirling 
> Reply-To: "Enhanced Machine Controller (EMC)"
> 
> To: "Enhanced Machine Controller (EMC)" 
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
> I assumed that the 7i90hd would recognize SPI
> directly, like the 7c81 does.  Do I have to go
> dig up a parallel port computer from somewhere
> and get at least mesaflash running on it just
> so I can get spi working for the pi?  That is an
> unfortunate hurdle.  I don't see anything in the
> manual about needing to load the correct bitstream
> over parallel in order to use spi.  In fact, I read
> this in the manual:

Yep, you need to have SPI firmware loaded in the 7I90HD
default 7I90HD firmware is EPP, so a device with a EPP
interface is needed to load the SPI configuration
I would suggest loading the SPI interface into the
secondary flash leaving the primary as EPP for a fallback

That is, power the 7I90 with the flash jumper in the "P" position
them move the jumper to "S" before loadin the SPI firmware


>
> "Linux and Windows utility programs mesaflash and mesaflash.exe are provided 
> to
> write configuration files to the 7I90HD EEPROM via the RS-422 interface and 
> LBP16. The
> linux utility can also write configuration files via the EPP interface. These 
> files depend on
> a simple SPI interface built into both the standard user FPGA bitfiles and 
> the fallback
> bitfile."


Well there are 2 SPI interfaces, the HM2 compatible host interface (which needs
specific SPI firmware) and the SPI Flash memory interface (which is in HM2
memory space and allows access to the SPI flash chip)

>
> I can tack on a pullup to SDO.  I have put four
> scope probes on the four signals, and see data
> when interrogating the 7c81, but not the 7i90hd.
> The clock from the pi is correct.
>
> Thanks again.
> -- Ralph
> ________
> From: Peter C. Wallace [p...@mesanet.com]
> Sent: Thursday, January 7, 2021 3:18 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
>
> Looks right
>
> 2 layer should be fine as long as the ground is solid (wide)
> between the 7I90 and the RPI (and lo longer than a couple of
> inches
>
> You might try adding a pullup to SDO (7I90 15) to see if you read
> 0x which would indicate the the 7I90 is not driving SDO
>
> Sure you have a SPI config in the 7I90?
>
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C5c8bbaf5f3984eec51d008d8b366a9bc%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637456600811311135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=m8smz8GxQR83SZ5IKfEacp6Rr12LQnmpghFS5H0l1JM%3Dreserved=0
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C5c8bbaf5f3984eec51d008d8b366a9bc%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637456600811311135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=m8smz8GxQR83SZ5IKfEacp6Rr12LQnmpghFS5H0l1JM%3Dreserved=0
>

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

A jtag driver for mesaflash would be a nice way
to program the 7i90hd, since setting up an epp 
machine just for loading the bitstream is a real pain.
The RPi gpio should be able to do jtag without
trouble, even if it is a little slow.

-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Thursday, January 7, 2021 3:47 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

Yep, you need to have SPI firmware loaded in the 7I90HD
default 7I90HD firmware is EPP, so a device with a EPP
interface is needed to load the SPI configuration
I would suggest loading the SPI interface into the
secondary flash leaving the primary as EPP for a fallback

That is, power the 7I90 with the flash jumper in the "P" position
them move the jumper to "S" before loadin the SPI firmware


>
> "Linux and Windows utility programs mesaflash and mesaflash.exe are provided 
> to
> write configuration files to the 7I90HD EEPROM via the RS-422 interface and 
> LBP16. The
> linux utility can also write configuration files via the EPP interface. These 
> files depend on
> a simple SPI interface built into both the standard user FPGA bitfiles and 
> the fallback
> bitfile."


Well there are 2 SPI interfaces, the HM2 compatible host interface (which needs
specific SPI firmware) and the SPI Flash memory interface (which is in HM2
memory space and allows access to the SPI flash chip)

>
> I can tack on a pullup to SDO.  I have put four
> scope probes on the four signals, and see data
> when interrogating the 7c81, but not the 7i90hd.
> The clock from the pi is correct.
>
> Thanks again.
> -- Ralph
> 
> From: Peter C. Wallace [p...@mesanet.com]
> Sent: Thursday, January 7, 2021 3:18 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd
>
>
> Looks right
>
> 2 layer should be fine as long as the ground is solid (wide)
> between the 7I90 and the RPI (and lo longer than a couple of
> inches
>
> You might try adding a pullup to SDO (7I90 15) to see if you read
> 0x which would indicate the the 7I90 is not driving SDO
>
> Sure you have a SPI config in the 7I90?
>
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C5c8bbaf5f3984eec51d008d8b366a9bc%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637456600811311135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=m8smz8GxQR83SZ5IKfEacp6Rr12LQnmpghFS5H0l1JM%3Dreserved=0
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C5c8bbaf5f3984eec51d008d8b366a9bc%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637456600811311135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=m8smz8GxQR83SZ5IKfEacp6Rr12LQnmpghFS5H0l1JM%3Dreserved=0
>

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C5c8bbaf5f3984eec51d008d8b366a9bc%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637456600811311135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=m8smz8GxQR83SZ5IKfEacp6Rr12LQnmpghFS5H0l1JM%3Dreserved=0


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Gene Heskett]

On Thursday 07 January 2021 18:58:27 Gene Heskett wrote:

> On Thursday 07 January 2021 18:18:52 Peter C. Wallace wrote:
> > On Thu, 7 Jan 2021, Ralph Stirling wrote:
> > > Date: Thu, 7 Jan 2021 22:05:32 +
> > > From: Ralph Stirling 
> > > Reply-To: "Enhanced Machine Controller (EMC)"
> > > 
> > > To: "emc-users@lists.sourceforge.net"
> > >  Subject: [Emc-users] Rpi 3b+ to
> > > 7i90hd
> > >
> > > I have a Raspberry Pi 3b+ successfully talking to a
> > > Mesa 7c81, but am now trying to get it working with
> > > a 7i90hd.  I have a very compact pcb made to go
> > > from the 2x20 header on the pi to the 2x13 header
> > > on the 7i90hd.  It is wired:
> > >
> > > Signal   Rpi7i90hd
> > > SDI19 13
> > > SDO   21 15
> > > SCK   23  11
> > > SCS   24  17
> > >
> > > +5V   2,4 26
> > > GND6,9,20,25,30,34,39 10,12,14,16,18,20,22,24
> > >
> > > My test is:
> > > $  mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi
> > > --readhmid
> > >
> > > Response is:
> > > unable to set bpw32, fallback to bpw8
> > > Unexpected cookie at 0100..0110:
> > >   
> > > No 7I90HD board found
> > >
> > > Since a 7c81 works, it would seem my software setup is ok.
> > > The problem would seem to lie with either my little adapter
> > > board or with the 7i90hd.  I have a bypass cap right between
> > > pins 4 and 6 on the RPi connector (22uF 0805 ceramic).  Do
> > > I need to use a four layer board to have sufficient ground
> > > plane?  I have copper pour on the top and bottom of the board,
> > > but it did not go between pins of the connectors.
> > >
> > > Any suggestions?
> > >
> > > Thanks,
> > > -- Ralph
> >
> > Looks right
> >
> > 2 layer should be fine as long as the ground is solid (wide)
> > between the 7I90 and the RPI (and lo longer than a couple of
> > inches
> >
> > You might try adding a pullup to SDO (7I90 15) to see if you read
> > 0x which would indicate the the 7I90 is not driving SDO
> >
> > Sure you have a SPI config in the 7I90?
>
> The rpspi driver should handle that.
>
But I missead the question, yes, he will need to install the spi version 
of the firmware with mesaflash.

> > Peter Wallace
> > Mesa Electronics
> >
> > (\__/)
> > (='.'=) This is Bunny. Copy and paste bunny into your
> > (")_(") signature to help him gain world domination.
> >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Gene Heskett]

On Thursday 07 January 2021 18:18:52 Peter C. Wallace wrote:

> On Thu, 7 Jan 2021, Ralph Stirling wrote:
> > Date: Thu, 7 Jan 2021 22:05:32 +
> > From: Ralph Stirling 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: "emc-users@lists.sourceforge.net"
> >  Subject: [Emc-users] Rpi 3b+ to
> > 7i90hd
> >
> > I have a Raspberry Pi 3b+ successfully talking to a
> > Mesa 7c81, but am now trying to get it working with
> > a 7i90hd.  I have a very compact pcb made to go
> > from the 2x20 header on the pi to the 2x13 header
> > on the 7i90hd.  It is wired:
> >
> > Signal   Rpi7i90hd
> > SDI19 13
> > SDO   21 15
> > SCK   23  11
> > SCS   24  17
> >
> > +5V   2,4 26
> > GND6,9,20,25,30,34,39 10,12,14,16,18,20,22,24
> >
> > My test is:
> > $  mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid
> >
> > Response is:
> > unable to set bpw32, fallback to bpw8
> > Unexpected cookie at 0100..0110:
> >   
> > No 7I90HD board found
> >
> > Since a 7c81 works, it would seem my software setup is ok.
> > The problem would seem to lie with either my little adapter
> > board or with the 7i90hd.  I have a bypass cap right between
> > pins 4 and 6 on the RPi connector (22uF 0805 ceramic).  Do
> > I need to use a four layer board to have sufficient ground
> > plane?  I have copper pour on the top and bottom of the board,
> > but it did not go between pins of the connectors.
> >
> > Any suggestions?
> >
> > Thanks,
> > -- Ralph
>
> Looks right
>
> 2 layer should be fine as long as the ground is solid (wide)
> between the 7I90 and the RPI (and lo longer than a couple of
> inches
>
> You might try adding a pullup to SDO (7I90 15) to see if you read
> 0x which would indicate the the 7I90 is not driving SDO
>
> Sure you have a SPI config in the 7I90?
>
The rpspi driver should handle that.
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Peter C. Wallace]

On Thu, 7 Jan 2021, Ralph Stirling wrote:


Date: Thu, 7 Jan 2021 23:37:03 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd

I assumed that the 7i90hd would recognize SPI
directly, like the 7c81 does.  Do I have to go
dig up a parallel port computer from somewhere
and get at least mesaflash running on it just
so I can get spi working for the pi?  That is an
unfortunate hurdle.  I don't see anything in the
manual about needing to load the correct bitstream
over parallel in order to use spi.  In fact, I read
this in the manual:


Yep, you need to have SPI firmware loaded in the 7I90HD
default 7I90HD firmware is EPP, so a device with a EPP
interface is needed to load the SPI configuration
I would suggest loading the SPI interface into the
secondary flash leaving the primary as EPP for a fallback

That is, power the 7I90 with the flash jumper in the "P" position
them move the jumper to "S" before loadin the SPI firmware




"Linux and Windows utility programs mesaflash and mesaflash.exe are provided to
write configuration files to the 7I90HD EEPROM via the RS-422 interface and 
LBP16. The
linux utility can also write configuration files via the EPP interface. These 
files depend on
a simple SPI interface built into both the standard user FPGA bitfiles and the 
fallback
bitfile."



Well there are 2 SPI interfaces, the HM2 compatible host interface (which needs 
specific SPI firmware) and the SPI Flash memory interface (which is in HM2 
memory space and allows access to the SPI flash chip)




I can tack on a pullup to SDO.  I have put four
scope probes on the four signals, and see data
when interrogating the 7c81, but not the 7i90hd.
The clock from the pi is correct.

Thanks again.
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Thursday, January 7, 2021 3:18 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd


Looks right

2 layer should be fine as long as the ground is solid (wide)
between the 7I90 and the RPI (and lo longer than a couple of
inches

You might try adding a pullup to SDO (7I90 15) to see if you read
0x which would indicate the the 7I90 is not driving SDO

Sure you have a SPI config in the 7I90?


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C2f1545841f8d4543ae6508d8b362a7cb%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637456583593747863%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=N92UNNqfvDYhsmSGI4EAkbQ9%2F8guRn8JkuXRyMbez3Y%3Dreserved=0


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

I assumed that the 7i90hd would recognize SPI
directly, like the 7c81 does.  Do I have to go
dig up a parallel port computer from somewhere
and get at least mesaflash running on it just
so I can get spi working for the pi?  That is an
unfortunate hurdle.  I don't see anything in the
manual about needing to load the correct bitstream
over parallel in order to use spi.  In fact, I read
this in the manual:

"Linux and Windows utility programs mesaflash and mesaflash.exe are provided to
write configuration files to the 7I90HD EEPROM via the RS-422 interface and 
LBP16. The
linux utility can also write configuration files via the EPP interface. These 
files depend on
a simple SPI interface built into both the standard user FPGA bitfiles and the 
fallback
bitfile."

I can tack on a pullup to SDO.  I have put four
scope probes on the four signals, and see data
when interrogating the 7c81, but not the 7i90hd.
The clock from the pi is correct.

Thanks again.
-- Ralph

From: Peter C. Wallace [p...@mesanet.com]
Sent: Thursday, January 7, 2021 3:18 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi 3b+ to 7i90hd


Looks right

2 layer should be fine as long as the ground is solid (wide)
between the 7I90 and the RPI (and lo longer than a couple of
inches

You might try adding a pullup to SDO (7I90 15) to see if you read
0x which would indicate the the 7I90 is not driving SDO

Sure you have a SPI config in the 7I90?


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C2f1545841f8d4543ae6508d8b362a7cb%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637456583593747863%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=N92UNNqfvDYhsmSGI4EAkbQ9%2F8guRn8JkuXRyMbez3Y%3Dreserved=0


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi 3b+ to 7i90hd

[Peter C. Wallace]

On Thu, 7 Jan 2021, Ralph Stirling wrote:


Date: Thu, 7 Jan 2021 22:05:32 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "emc-users@lists.sourceforge.net" 
Subject: [Emc-users] Rpi 3b+ to 7i90hd

I have a Raspberry Pi 3b+ successfully talking to a
Mesa 7c81, but am now trying to get it working with
a 7i90hd.  I have a very compact pcb made to go
from the 2x20 header on the pi to the 2x13 header
on the 7i90hd.  It is wired:

Signal   Rpi7i90hd
SDI19 13
SDO   21 15
SCK   23  11
SCS   24  17

+5V   2,4 26
GND6,9,20,25,30,34,39 10,12,14,16,18,20,22,24

My test is:
$  mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid

Response is:
unable to set bpw32, fallback to bpw8
Unexpected cookie at 0100..0110:
  
No 7I90HD board found

Since a 7c81 works, it would seem my software setup is ok.
The problem would seem to lie with either my little adapter
board or with the 7i90hd.  I have a bypass cap right between
pins 4 and 6 on the RPi connector (22uF 0805 ceramic).  Do
I need to use a four layer board to have sufficient ground
plane?  I have copper pour on the top and bottom of the board,
but it did not go between pins of the connectors.

Any suggestions?

Thanks,
-- Ralph




Looks right

2 layer should be fine as long as the ground is solid (wide)
between the 7I90 and the RPI (and lo longer than a couple of
inches

You might try adding a pullup to SDO (7I90 15) to see if you read
0x which would indicate the the 7I90 is not driving SDO

Sure you have a SPI config in the 7I90?


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Rpi 3b+ to 7i90hd

[Ralph Stirling]

I have a Raspberry Pi 3b+ successfully talking to a
Mesa 7c81, but am now trying to get it working with
a 7i90hd.  I have a very compact pcb made to go
from the 2x20 header on the pi to the 2x13 header
on the 7i90hd.  It is wired:

Signal   Rpi7i90hd
SDI19 13
SDO   21 15
SCK   23  11
SCS   24  17

+5V   2,4 26
GND6,9,20,25,30,34,39 10,12,14,16,18,20,22,24

My test is:
$  mesaflash --device 7i90hd --addr /dev/spidev0.0 --spi --readhmid

Response is:
unable to set bpw32, fallback to bpw8
Unexpected cookie at 0100..0110:
  
No 7I90HD board found

Since a 7c81 works, it would seem my software setup is ok.
The problem would seem to lie with either my little adapter
board or with the 7i90hd.  I have a bypass cap right between
pins 4 and 6 on the RPi connector (22uF 0805 ceramic).  Do
I need to use a four layer board to have sufficient ground
plane?  I have copper pour on the top and bottom of the board,
but it did not go between pins of the connectors.

Any suggestions?

Thanks,
-- Ralph
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[Gene Heskett]

On Monday 28 May 2018 12:17:55 jeremy youngs wrote:

> So Gene, essentially an HDMI monitor is the sure bet. I think I will
> find one of them

That seems to be the best bet today. Tomorrow of coarse they have a new 
connector thats cheaper. The connector cost is likely the driving force, 
and an hdmi connector thats a 1 step crimp, probably costs 10% of what a 
db15 costs.  And I believe its mechanically superior to boot, I've seen 
a boat load of db's wrecked because the outer shell is the same shell 
for both the db9 and the db15, so you spend at least 15 minutes 
re-straightening the pins, and hoping the socket survives because the 
db15's pins and sockets are smaller. HDMI seems to have eliminated that 
hassle.

> --
> Check out the vibrant tech community on one of the world's
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[jeremy youngs]

So Gene, essentially an HDMI monitor is the sure bet. I think I will find
one of them
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[Gene Heskett]

On Monday 28 May 2018 01:04:10 jeremy youngs wrote:

> I'm about to purchase the rpi 3 b to convert my other mill. I'm going
> to use the steppers I took off this matson . Probably 7i90 as well. I
> have a couple VGA monitor so I figured I'd get a HDMI to VGA cable .
> Is there any reason not to get this?
> eBay item number 323251929837

I needed another monitor anyway, and it came with an hdmi input. So I'm 
using a plain hdmi both ends cable.

One thing I've been cautioned about is there are lots of this type of 
adapters that aren't 2-way, so an EDID query is not replied to. This 
makes getting x started in the proper scan rates the subject of writing 
your own xinit stuff. I am using on the rock64, a similar but all in the 
plug adaptor. It works at the monitors native scan rate when jessie is 
booted, but not in stretch, so the pix is just a hair fuzzy in stretch 
due to the pixel size miss-match. That particular monitor is not a 1080P 
but a 1366x768, a bit of an oddball, ultra cheap AOC from Wallies. I use 
both inputs on it, with a dell I use for mesaflashing on the other 
input.

That links to 2 versions that look alike, but the bottom one says 
hdmi-1.4. I think I'd gamble on the bottom one since they are both the 
same cost.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Rpi

[jeremy youngs]

I'm about to purchase the rpi 3 b to convert my other mill. I'm going to
use the steppers I took off this matson . Probably 7i90 as well. I have a
couple VGA monitor so I figured I'd get a HDMI to VGA cable . Is there any
reason not to get this?
eBay item number 323251929837
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[Jon Elson]

On 05/02/2018 11:56 PM, Chris Albertson wrote:

Yes, the Begal Board Black (BBB) has much lower general CPU performance
compared to the Raspberry Pibut MUCH better IO performance especially with
those on-chip PRUs.
Well, I use this to test the CRAMPS boards, and also run my 
laser photoplotter and just set up a
one-axis positioner at work.  While it is not QUITE as 
snappy to update the display as a fast X86 CPU, is is 
TOTALLY adequate for most purposes.  Especially when using 
the PRU to handle the step generation task.


But still if you have a garage to store the computer and AC mains available
for power why care about a few cubic inches and 20 watts of power?   Gene
suggested an Intel Atom based PC.  Those work.   But I find that one can
buy Dell server that has come off lease.   These can come in 1U size
chassis which is very compact.   Prices are very low and you get a full
computer with power, chassis and so on.  Smaller than a tower but still
typically space for a PCIe card.  Newegg.com is a reliable source, a top
their retailer but eBay might have lower prices.  I've seen a usable rack
mount server go for $100.

If you go with rack-mount servers, note that there usually 
are NO expansion slots.  So, you can't add a video or 
parport card.  If you go with the small form factor (SFF) or 
ultra-small (USFF) boxes, you will be limited to no, or only 
half-height PCI slots.  This can be a problem with some add-ons.


The Intel (and clone) mini-ITX boards can be put in the 7" 
cube boxes and make a very compact system that can hold 
full-height cards.  I've built up a few of them.


Jon


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[Gene Heskett]

On Thursday 03 May 2018 00:56:41 Chris Albertson wrote:

> Yes, the Begal Board Black (BBB) has much lower general CPU
> performance compared to the Raspberry Pibut MUCH better IO performance
> especially with those on-chip PRUs.
>
> But still if you have a garage to store the computer and AC mains
> available for power why care about a few cubic inches and 20 watts of
> power?   Gene suggested an Intel Atom based PC.  Those work.   But I
> find that one can buy Dell server that has come off lease.   These can
> come in 1U size chassis which is very compact.   Prices are very low
> and you get a full computer with power, chassis and so on.  Smaller
> than a tower but still typically space for a PCIe card.  Newegg.com is
> a reliable source, a top their retailer but eBay might have lower
> prices.  I've seen a usable rack mount server go for $100.

I've bought a couple old dell optiplex's, both desktops that can stand on 
end, that have run LinuxCNC very well, for under a hundred dollar bill 
from pcliquidaters.com, who are now showing stuff as low as $55.
Plenty of power, good video, and with a $40 64G SSD for a drive, its 
quite a bit faster than it was with a 2T spinning rust drive in it. Only 
64GB doesn't cramp it, df says 29% used. Neither does the only 2GB of 
ddr2. Works fine. Dual core Pentium D running at 3.4GHz.

> My main development PC is a used HP workstation, 12-core Xeon, 64GB
> RAM Nvidia GPU for about $550.  The leasing companies have thousand of
> these and they have to dump them into a market where world wide PC
> sales is declining year to year.
>
> On Wed, May 2, 2018 at 7:17 PM, Jon Elson  
wrote:
> > On Wednesday 02 May 2018 11:16:29 jeremy youngs wrote:
> > Given my issues with this computer I have decided to stop
> > beating a dead horse. I'm going to rpi 3 this thing.
> 
>  Oh, one other option is the Beagle Bone.  This has the option of
>  using
> >
> > the PRU (programmable Realtime Unit) which is a 32-bit 200 MIPS
> > microcontroller to do step generation.  The Machinekit fork of
> > LinuxCNC supports this.  There is the CRAMPS board (disclaimer - I
> > sell these) that puts 6 small stepper drivers and other I/O right on
> > top of the Beagle Bone for a VERY compact system.  You can net into
> > the Bone with either Ethernet or USB, or connect a keyboard and
> > mouse via USB and a monitor via mini-HDMI.
> >
> > Jon
> >
> >
> >
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[Chris Albertson]

Yes, the Begal Board Black (BBB) has much lower general CPU performance
compared to the Raspberry Pibut MUCH better IO performance especially with
those on-chip PRUs.

But still if you have a garage to store the computer and AC mains available
for power why care about a few cubic inches and 20 watts of power?   Gene
suggested an Intel Atom based PC.  Those work.   But I find that one can
buy Dell server that has come off lease.   These can come in 1U size
chassis which is very compact.   Prices are very low and you get a full
computer with power, chassis and so on.  Smaller than a tower but still
typically space for a PCIe card.  Newegg.com is a reliable source, a top
their retailer but eBay might have lower prices.  I've seen a usable rack
mount server go for $100.

My main development PC is a used HP workstation, 12-core Xeon, 64GB RAM
Nvidia GPU for about $550.  The leasing companies have thousand of these
and they have to dump them into a market where world wide PC sales is
declining year to year.





On Wed, May 2, 2018 at 7:17 PM, Jon Elson  wrote:

>
> On Wednesday 02 May 2018 11:16:29 jeremy youngs wrote:

> Given my issues with this computer I have decided to stop beating a
> dead horse. I'm going to rpi 3 this thing.
>
 Oh, one other option is the Beagle Bone.  This has the option of using
> the PRU (programmable Realtime Unit) which is a 32-bit 200 MIPS
> microcontroller to do step generation.  The Machinekit fork of LinuxCNC
> supports this.  There is the CRAMPS board (disclaimer - I sell these) that
> puts 6 small stepper drivers and other I/O right on top of the Beagle Bone
> for a VERY compact system.  You can net into the Bone with either Ethernet
> or USB, or connect a keyboard and mouse via USB and a monitor via mini-HDMI.
>
> Jon
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



-- 

Chris Albertson
Redondo Beach, California
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[Jon Elson]

On Wednesday 02 May 2018 11:16:29 jeremy youngs wrote:

Given my issues with this computer I have decided to stop beating a
dead horse. I'm going to rpi 3 this thing.
Oh, one other option is the Beagle Bone.  This has the 
option of using the PRU (programmable Realtime Unit) which 
is a 32-bit 200 MIPS microcontroller to do step generation.  
The Machinekit fork of LinuxCNC supports this.  There is the 
CRAMPS board (disclaimer - I sell these) that puts 6 small 
stepper drivers and other I/O right on top of the Beagle 
Bone for a VERY compact system.  You can net into the Bone 
with either Ethernet or USB, or connect a keyboard and mouse 
via USB and a monitor via mini-HDMI.


Jon


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[Gene Heskett]

On Wednesday 02 May 2018 21:30:32 Jon Elson wrote:

> > On Wednesday 02 May 2018 11:16:29 jeremy youngs wrote:
> >> Given my issues with this computer I have decided to stop beating a
> >> dead horse. I'm going to rpi 3 this thing.
>
> Yes, I agree with Gene, there are a number of decent X86
> motherboards that are known to work well with LinuxCNC.  I
> use old Dell Optiplex boxes.  Pentium 4 CPUs seem to work
> great with the rt-preempt kernel.
> I sell step generator and PWM boards, so these do not
> require the best latency.  With RTAI, you can get the jitter
> down to about 10 us, with rt-preempt it is more like 20 us.
> That is still FINE for systems with hardware motion
> controllers.  I just install from the live DVD and it all
> works.  (There is one gotcha, the Intel i810 on-board
> graphics is flaky with certain Linux drivers, so I had to
> put in an nvidia graphics board.
> So, make sure you have a PCI slot for that.)
>
> Jon

That is not a problem with either of my D525MW motherboards with dual 
core intel atoms on them as I think those boards are i915 gfx.
One of them is even doing sw stepping. Runs well at up to 10 ipm, not bad 
since its the teeny mill from HF about 20 years ago. I like to use it 
for the occasions when I need to rig up to do some EDM. And I've found 
distilled water is a better electrolyte than K2 for that.

That particular family of boards has been disco'ed for several years now 
and word that its a good board seems to have gotten around, I saw one on 
fleabay 6 months back being offered for 2x what it sold for new. Latency 
is great and its power is well matched to what LCNC needs to run well.

And its not been a problem ever with the off lease dell optiplex I'm 
running the G0704 with. It Just Works, and much faster with a 64GB SSD 
in it for a drive.
>
> --
> Check out the vibrant tech community on one of the world's
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[Jon Elson]

On Wednesday 02 May 2018 11:16:29 jeremy youngs wrote:


Given my issues with this computer I have decided to stop beating a
dead horse. I'm going to rpi 3 this thing.


Yes, I agree with Gene, there are a number of decent X86 
motherboards that are known to work well with LinuxCNC.  I 
use old Dell Optiplex boxes.  Pentium 4 CPUs seem to work 
great with the rt-preempt kernel.
I sell step generator and PWM boards, so these do not 
require the best latency.  With RTAI, you can get the jitter 
down to about 10 us, with rt-preempt it is more like 20 us.  
That is still FINE for systems with hardware motion 
controllers.  I just install from the live DVD and it all 
works.  (There is one gotcha, the Intel i810 on-board 
graphics is flaky with certain Linux drivers, so I had to 
put in an nvidia graphics board.

So, make sure you have a PCI slot for that.)

Jon



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[Gene Heskett]

On Wednesday 02 May 2018 11:16:29 jeremy youngs wrote:

> Given my issues with this computer I have decided to stop beating a
> dead horse. I'm going to rpi 3 this thing.

Now I may rain on your parade. Based on my experience trying to find a 
decent pre-emptible kernel, I'm not sure I'd recommend a r-pi for a 
beginner.  Shop ebay for a D525mW intel motherboard.  The best r-pi 
kernel I have tried, still needs multople reboots before it gets a 
solid, usable comm path from its mouse or keyboard. The worse 
manifestation is seen by the use of the keyboard arrow keys to jog the 
machine, but the mouse response can be equally flaky. It throws away 
keyboard and mouse events, most often noticeable by the jog continuing 
when your finger is removed from the key. Rebooting it when that is 
noticed changes this behaviour and eventually  you hit a bootup that 
Just Works(tm). And it will usually work fine until the next reboot. 
Mine has an uptime of:

 17:56:28 up 35 days, 22:14,  3 users,  load average: 0.84, 0.83, 0.85

Right now.

> Gene I am addressing this 
> to you, what is my build requirements? 

When ready to move machinery, I'll send you a shrunken head version of 
debian jessie you can burn to a u-sd card, 32 and 64GB GB Samsung's seem 
to be rock solid. The shrunken head version means its a disk image that 
has a resize2fs in its initial bootup, so when you've rebooted it a 
second time it has recognized the card and expanded the filesystem to 
use the full cards size, which makes the cards wear leveling work for a 
lng time. Up to then, the image is perhaps 500 megs more than the 
occupied stuff on the disk.

> I.e. what hardware is needed 
> essential? . I have the 7i90, an svga monitor, USB keyboard and mouse.
> The rpi has WiFi so it can network with my phone.

I have too many neighbors with wifi, and they love to use my bandwidth, 
so the wifi on the pi is turned off. I only turn it on in the router 
when my kids are here for a weekend, which gives them a hotspot for 
their smartphones, but they still cannot see my home network. dd-wrt 
gives you total control.

> 7i42 will come as 
> soon as I get a few things out of the shop.

You'll need 3 of them, and 3 50 pin scsi-ii style cables for 
interconnects between the 7i90 and the machinery. Buy the cable, 2 feet 
is 2x what you'll need, a 6 pack of the 50 pin connectors and make your 
own jumpers in the shop vice for a lot less money.

Theres a board on the oshpark site that is the basis for the spi 
connection between the pi and the 7i90. I think Jon drew it, so he might 
be able to supply that number. You'll need 3 teeny little chip r's of 
120 ohms to source terminate the cable from the pi to the 7i90. Thats a 
fast bus.

If you insist on servo's intead of steppers, you'll need a couple mesanet 
spinx1's to interface between the pwm signals and the servo's analog 
control inputs.  Or use Jon's (Pico Systems) pwm-servo amps, which are a 
great product for around $130 a motor. I am using 2 of them to handle 
the 1 horse rated PMDC motors, one hanging off the back of my 7x12, and 
the OEM 1 horse of a Grizzly G0704, probably tapping it for close to 2 
hp when its at full song.

> A couple pics of interim servo motor mounts , I slapped together. The
> y axis motor mount needs a bit more work.
> https://drive.google.com/file/d/1hGnhYLYiY-NIqw9cBkR92UlNIlIJzKuG/view
>?usp=drivesdk

On a lathe version of LCNC, thats an x axis, y is skipped and carriage 
left<->right is z.

With steppers, on the r-pi, no PID's are needed, and they double the 
computing the pi has to do, and you'll need them to control the servo's 
well.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rpi

[jeremy youngs]

I just made these links public, sorry .
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Rpi

[jeremy youngs]

Given my issues with this computer I have decided to stop beating a dead
horse. I'm going to rpi 3 this thing. Gene I am addressing this to you,
what is my build requirements? I.e. what hardware is needed essential? . I
have the 7i90, an svga monitor, USB keyboard and mouse. The rpi has WiFi so
it can network with my phone. 7i42 will come as soon as I get a few things
out of the shop.

A couple pics of interim servo motor mounts , I slapped together. The y
axis motor mount needs a bit more work.
https://drive.google.com/file/d/1hGnhYLYiY-NIqw9cBkR92UlNIlIJzKuG/view?usp=drivesdk

https://drive.google.com/file/d/1dOogfatNs5W6y7YBJhmSgGV56hp1FyFr/view?usp=drivesdk
Have a great day.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] RPI stable kernel

[Bertho Stultiens]

Hi all,

Can anybody suggest the most recent stable kernel for the RPI 3 with
functional preempt rt patches?

I've been runnning 4.9.30-rt20-v7+, but I've been seeing crashes
(lockups) very often. The CPU(s) seems to be spinning at 100% because
the SoC gets really warm.

-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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) from the mailing list (or the forum).
>
> Login as pi user and put them in
> ~/linuxcnc-git/src/hal/drivers/mesa-hostmot2/
>
> Then do:
> $ cd ~/linuxcnc-git/src
> $ make
I am ready to do the make. I've crashed it at least a dozen times so far 
today, but we'll see if it can actually get thru a make. Did, building 
only the hm2_rpspi.so

> $ sudo make setuid
did this too.

Now print this so I don't have any typo's when I goto the machine for the 
test run.

> $ ../scripts/linuxcnc -v
> ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
>
> That should run your sheldon lathe config. You may need to update the
> config as needed.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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) from the mailing list (or the forum).
>
> Login as pi user and put them in
> ~/linuxcnc-git/src/hal/drivers/mesa-hostmot2/
>
Since I saved them on this  machine and have not made sshfs live yet, 
Thats best done by bringing the card in, plugging it into a reader to do 
the transfers.

I have had it working a time or three with the buildbots old 2.8.0-pre, 
but its quite fragile, never crashing at the same point twice.

> Then do:
> $ cd ~/linuxcnc-git/src
> $ make
> $ sudo make setuid
> $ ../scripts/linuxcnc -v
> ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
>
> That should run your sheldon lathe config. You may need to update the
> config as needed.

I've rsync'd that out to a backup drive from the card that was in it for 
the last 4 or so days, then when this new finally booted to a usable 
screen, rsynced it back in order to get the most recent edits in place. 
ANAICT, everything works, but its very, very fragile, freezing up at the 
drop of a 4-40 screw 10 feet away.

I was going to print the README.md, and build according to that, but 
found that while the package manager says cups-client and friends is 
installed, its not usable as there is no /etc/cups/cups-client.conf.

I haven't sorted that basket of rattlesnakes yet, been sitting on the 
rider, trying to find my yard.  That, by the time I loaded the 3x5x1 
foot deep 2 wheeled wagon full of hedge trimmings stacked about 3 feet 
high, to haul it to the burn pit wrote a ~30~ to my back for the day, so 
the weedeating around the edges will wait till another dry day.

And its time (17:45) to round up something for dinner. So thats the 
status for today.  Thank you Bertho.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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 them in
~/linuxcnc-git/src/hal/drivers/mesa-hostmot2/

Then do:
$ cd ~/linuxcnc-git/src
$ make
$ sudo make setuid
$ ../scripts/linuxcnc -v ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini

That should run your sheldon lathe config. You may need to update the
config as needed.

-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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 endianness, which I did
> wrong in the previous versions. This implementation is hard-coded to
> use the RPI hardware peripherals. Also, you can now attach to SPI0 or
> SPI1 ports on the 40-pin header and you may choose any CE line you
> wish (updated man page also attached).
>
> My tests so far have seen stable results, timing wise, although I
> cannot test functionally on a real system (lacking a 7i90 in my
> inventory). Though, the timing has improved with respect to the
> original version.
>
> Read and write SPI clock frequencies may be different now. This will
> help to overcome the SPI round-trip delay while reading (just lower
> the read frequency setting), or when you want buffers on the SPI
> lines.
>
> So, if anybody wants to have a go and test this, please do so and tell
> me how it goes. In the meantime... need to get my hands on a 7i90 (and
> upgrade the mill at the local hackerspace).

Does the image I downloaded Saturday and wrote to an sd card yesterday 
have this stuff in it? I got sidetracked today, doing a poor man's 
set-true to the chuck, and getting it under a thou. Can't go any farther 
w/o reaming the bolt holes in the backing plate a wee bit. Thats pretty 
close, and I've no reamer kit.  Yet. Just one of several items I need to 
acquire, like a live center which I didn't get with it.  And of course 
more tooling, never have enough.

Back when I bought the ER-40 kit, someone said I couldn't use long 
workpieces with it, but it clears several feet of nominally 7/8" OD 
stock, so as long as the OD is no more than that, I don't see a problem, 
but I'll have to make a spider for the left end of the spindle, easily 
done if I can find some brass acorn nuts.

I'll see if I can pull the cover tomorrow and try the new sd card, 
Bertho.  Depends on the weather.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Peter C. Wallace]

On Mon, 5 Jun 2017, Bertho Stultiens wrote:


Date: Mon, 5 Jun 2017 16:20:03 +0200
From: Bertho Stultiens <ber...@vagrearg.org>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@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 couple of things, like endianness, which I did
wrong in the previous versions. This implementation is hard-coded to use
the RPI hardware peripherals. Also, you can now attach to SPI0 or SPI1
ports on the 40-pin header and you may choose any CE line you wish
(updated man page also attached).

My tests so far have seen stable results, timing wise, although I cannot
test functionally on a real system (lacking a 7i90 in my inventory).
Though, the timing has improved with respect to the original version.

Read and write SPI clock frequencies may be different now. This will
help to overcome the SPI round-trip delay while reading (just lower the
read frequency setting), or when you want buffers on the SPI lines.

So, if anybody wants to have a go and test this, please do so and tell
me how it goes. In the meantime... need to get my hands on a 7i90 (and
upgrade the mill at the local hackerspace).

--
Greetings Bertho

(disclaimers are disclaimed)



Thank you for working on this! The ability to set the clock speed should be 
especially valuable. It means I can make a Async SPI interface version of the 
firmware (as opposed to the current hardware clocked version), that 
oversamples/digital filters the input data and clock for better noise 
resistance. This will probably require lowering the SPI clock to say 16 MHz

to accomodate the increased turnaround delays from the digital filtering.

Peter Wallace
Mesa Electronics


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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 implementation is hard-coded to use
the RPI hardware peripherals. Also, you can now attach to SPI0 or SPI1
ports on the 40-pin header and you may choose any CE line you wish
(updated man page also attached).

My tests so far have seen stable results, timing wise, although I cannot
test functionally on a real system (lacking a 7i90 in my inventory).
Though, the timing has improved with respect to the original version.

Read and write SPI clock frequencies may be different now. This will
help to overcome the SPI round-trip delay while reading (just lower the
read frequency setting), or when you want buffers on the SPI lines.

So, if anybody wants to have a go and test this, please do so and tell
me how it goes. In the meantime... need to get my hands on a 7i90 (and
upgrade the mill at the local hackerspace).

-- 
Greetings Bertho

(disclaimers are disclaimed)
/*This is a component for RaspberryPi to hostmot2 over SPI for linuxcnc.
 *Copyright 2016 Matsche 
 *Copyright 2017 B.Stultiens 
 *
 *This program is free software; you can redistribute it and/or modify
 *it under the terms of the GNU General Public License as published by
 *the Free Software Foundation; either version 2 of the License, or
 *(at your option) any later version.
 *
 *This program is distributed in the hope that it will be useful,
 *but WITHOUT ANY WARRANTY; without even the implied warranty of
 *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *GNU General Public License for more details.
 *
 *You should have received a copy of the GNU General Public License
 *along with this program; if not, write to the Free Software
 *Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

/* Without Source Tree */
#undef WOST

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include "hal.h"
#include "rtapi.h"
#include "rtapi_app.h"

#include "rtapi_stdint.h"
#include "rtapi_bool.h"
#include "rtapi_gfp.h"
#include "rtapi_slab.h"

#include "rtapi_bool.h"

#if defined (WOST)
#include "include/hostmot2-lowlevel.h"
#include "include/hostmot2.h"
#else
#include "hostmot2-lowlevel.h"
#include "hostmot2.h"
#endif

#include "spi_common_rpspi.h"

//#define RPSPI_DEBUG		1	// Uncomment for debugging
#define RPSPI_DEBUG_WRITE	1	// Debug write command before cookie probe

#if defined(RPSPI_DEBUG)
#define RPSPI_DEBUG_PIN		23	// Debug timing on GPIO 23
#endif

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Matsche");
MODULE_DESCRIPTION("Driver for HostMot2 devices connected via SPI to RaspberryPi");
MODULE_SUPPORTED_DEVICE("Mesa-AnythingIO-7i90");

#define MAX_BOARDS	5
#define MAX_MSG		512		// FIXME: The 7i90 docs say that the max. burstlen == 127 (i.e. cmd+message <= 1+127)

// GPIO pin definitions
#define SPI0_PIN_CE_1	7
#define SPI0_PIN_CE_0	8
#define SPI0_PIN_MISO	9
#define SPI0_PIN_MOSI	10
#define SPI0_PIN_SCLK	11
#define SPI1_PIN_CE_2	16		// AUX SPI0 in docs
#define SPI1_PIN_CE_1	17
#define SPI1_PIN_CE_0	18
#define SPI1_PIN_MISO	19
#define SPI1_PIN_MOSI	20
#define SPI1_PIN_SCLK	21

typedef struct hm2_rpspi_struct {
	hm2_lowlevel_io_t llio;		// Upstream container
	int		nr;		// Board number
	uint32_t	spiclkratew;	// SPI write clock for divider calculation
	uint32_t	spiclkrater;	// SPI read clock for divider calculation
	uint32_t	spiclkbase;	// SPI base clock for divider calculation
	uint32_t	spice;		// Chip enable mask for this board
	int		spidevid;	// The SPI device id [01]
	int		spiceid;	// The SPI CE id [012]
} hm2_rpspi_t;

typedef enum {
	RPI_UNSUPPORTED,
	RPI_1,		// Version 1
	RPI_2		// Version 2 and 3
} platform_t;

static uint32_t *peripheralmem = (uint32_t *)MAP_FAILED;	// mmap'ed peripheral memory
static size_t peripheralsize;	// Size of the mmap'ed block
static bcm2835_gpio_t *gpio;	// GPIO peripheral structure in mmap'ed address space
static bcm2835_spi_t *spi;	// SPI peripheral structure in mmap'ed address space
static bcm2835_aux_t *aux;	// AUX peripheral structure in mmap'ed address space
static uint32_t aux_enables;	// Previous state of SPI1 enable
static platform_t platform;	// The RPI version

static hm2_rpspi_t boards[MAX_BOARDS];	// Connected boards
static int comp_id;			// Upstream assigned component ID

/*
 * Configuration parameters
 */
static char *config[MAX_BOARDS];
RTAPI_MP_ARRAY_STRING(config, MAX_BOARDS, "config string for the AnyIO boards (see hostmot2(9) manpage)")

/*
 * RPI3 NOTE:
 * The SPI frequency is wildly variable when the ondemand cpufreq governor is
 * active. This may result in changing SPI frequencies depending on the system

Re: [Emc-users] RPI saga continues - SPI probably solved

[john mcintyre]

Good day Gene ,

Your saga continues, you must be related to a bulldog ,once locked on  it 
cannot let go.

All the best john



From: Gene Heskett <ghesk...@shentel.net>
Sent: Sunday, 4 June 2017 9:47 AM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-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?
> >
> > 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 the cpu you have isolated is found and used
> > automatically, however the use cannot be detected by the various cpu
> > monitoring utilities such as htop.  I had originally set that up to
> > reserve core 3, on the 4 core pi, and on core 3 of the athlons I
> > don't know who corrected me, but it was said that was no longer a
> > useful item, so I took it back out of /boot/cmdline.txt and out of
> > some of the x86 machines too, but I see its still in as an =1 on the
> > two atom boards out in the shop.  The one I removed it from hasn't
> > indicated any unhappiness with that turn of events.
> >
> > Perhaps Sebastian or someone more familiar with it can shine a light
> > on us here? As in has it been deprecated on all arches. I still have
> > 2 D525MW's with it in effect. And htop cannot see any usage of cpu-1
> > on either of those 2 boxes.
>
> Yes, isolcpus=X is the way to do that. However, doing so means that
> the kernel never schedules anything on the core automatically. You
> must set the thread/process affinity in the running code, using a
> syscall, to move a specific thread/process onto that isolated core.
> Otherwise, it will be idle all the time.

When I awoke about sunup, I had a message from amanda. I gad left lcnc
running when I came in for the and the pi apparently crashed very
quickly when amanda tried to access it.

So when I ran down at restoring it today, with 8 wires yet to hook up
verify I have them right, and I'll be at the same place I was,
everything running nicely, the morning of May 2, but I shut lcnc down
before hitting the light switch and closing the garage door for the
night. On my feet a good share of the day, I'll pay for it in the night
with leg cramps. I'll take an extra big b12 pill, which sometimes helps
because metformin flushes b12 out into a big white bowl. :)

I did write the new image to a card, but have not had the time to go into
it, setting hostnames, hosts etc, yadda, yadda yet.  And killing
anything that can over-write /etc/resolv.conf thereby keeping my local
network running on the pi like it runs on everything else.

I did plug in that terabyte HD and had mc update the linuxcnc tree
already on that drive from a couple weeks ago, and its still plugged in.

And I'm bushed, but progress has been made.  Curious, before I quit, I
fired up the scope and looked at everything I had hooked up the last 3
days, and was amazed!  Whereas the old lashup was attacking the 7i90
with switching noises up in the 90+ mhz range, at peak voltages of 30+
volts before it hit any wire by wire filtering I'd been building, if
there is any noise there now, its well under 50 millivolts and I can't
see it on the analog scope at all. This was with the vfd up and running,
spinning the chuck at about 225 rpms.  And yet every cable I am hooking
up is coming into the bottom of the motor drivers box, thru it just as
before. The cpu/controller box is insulated from the power box, and only
connected to the single point ground by one braided strap, which I had
to cover with shrink tubing because it was touching the spinx1 which I'd
remounted on the inside of the door.  Didn't blow anything but the vfd
was going crazy when I moved the boxes door, which now has the pi &
controller box on the outside of the door.

Thanks Bertho, a lot.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
[http://geneslinuxbox.net:6309/gene/pix/EasterSundayCropped2004-1.jpg]<http://geneslinuxbox.net:6309/gene>

Gene's Web pages<http://geneslinuxbox.net:6309/gene>
geneslinuxbox.net
Welcome to Gene's web pages. Here you will find some of the things that make me 
tick, and that help keep me out of the bars. That is me & the missus, Dee 
(Elladene) I ...




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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 core) as a kernel argument at kernel load time.
> >
> > On x86 stuff the cpu you have isolated is found and used
> > automatically, however the use cannot be detected by the various cpu
> > monitoring utilities such as htop.  I had originally set that up to
> > reserve core 3, on the 4 core pi, and on core 3 of the athlons I
> > don't know who corrected me, but it was said that was no longer a
> > useful item, so I took it back out of /boot/cmdline.txt and out of
> > some of the x86 machines too, but I see its still in as an =1 on the
> > two atom boards out in the shop.  The one I removed it from hasn't
> > indicated any unhappiness with that turn of events.
> >
> > Perhaps Sebastian or someone more familiar with it can shine a light
> > on us here? As in has it been deprecated on all arches. I still have
> > 2 D525MW's with it in effect. And htop cannot see any usage of cpu-1
> > on either of those 2 boxes.
>
> Yes, isolcpus=X is the way to do that. However, doing so means that
> the kernel never schedules anything on the core automatically. You
> must set the thread/process affinity in the running code, using a
> syscall, to move a specific thread/process onto that isolated core.
> Otherwise, it will be idle all the time.

When I awoke about sunup, I had a message from amanda. I gad left lcnc 
running when I came in for the and the pi apparently crashed very 
quickly when amanda tried to access it.

So when I ran down at restoring it today, with 8 wires yet to hook up 
verify I have them right, and I'll be at the same place I was, 
everything running nicely, the morning of May 2, but I shut lcnc down 
before hitting the light switch and closing the garage door for the 
night. On my feet a good share of the day, I'll pay for it in the night 
with leg cramps. I'll take an extra big b12 pill, which sometimes helps 
because metformin flushes b12 out into a big white bowl. :)

I did write the new image to a card, but have not had the time to go into 
it, setting hostnames, hosts etc, yadda, yadda yet.  And killing 
anything that can over-write /etc/resolv.conf thereby keeping my local 
network running on the pi like it runs on everything else.

I did plug in that terabyte HD and had mc update the linuxcnc tree 
already on that drive from a couple weeks ago, and its still plugged in.

And I'm bushed, but progress has been made.  Curious, before I quit, I 
fired up the scope and looked at everything I had hooked up the last 3 
days, and was amazed!  Whereas the old lashup was attacking the 7i90 
with switching noises up in the 90+ mhz range, at peak voltages of 30+ 
volts before it hit any wire by wire filtering I'd been building, if 
there is any noise there now, its well under 50 millivolts and I can't 
see it on the analog scope at all. This was with the vfd up and running, 
spinning the chuck at about 225 rpms.  And yet every cable I am hooking 
up is coming into the bottom of the motor drivers box, thru it just as 
before. The cpu/controller box is insulated from the power box, and only 
connected to the single point ground by one braided strap, which I had 
to cover with shrink tubing because it was touching the spinx1 which I'd 
remounted on the inside of the door.  Didn't blow anything but the vfd 
was going crazy when I moved the boxes door, which now has the pi & 
controller box on the outside of the door.

Thanks Bertho, a lot.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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 the cpu you have isolated is found and used automatically, 
> however the use cannot be detected by the various cpu monitoring 
> utilities such as htop.  I had originally set that up to reserve core 3, 
> on the 4 core pi, and on core 3 of the athlons I don't know who 
> corrected me, but it was said that was no longer a useful item, so I 
> took it back out of /boot/cmdline.txt and out of some of the x86 
> machines too, but I see its still in as an =1 on the two atom boards out 
> in the shop.  The one I removed it from hasn't indicated any unhappiness 
> with that turn of events.
> 
> Perhaps Sebastian or someone more familiar with it can shine a light on 
> us here? As in has it been deprecated on all arches. I still have 2 
> D525MW's with it in effect. And htop cannot see any usage of cpu-1 on 
> either of those 2 boxes.

Yes, isolcpus=X is the way to do that. However, doing so means that the
kernel never schedules anything on the core automatically. You must set
the thread/process affinity in the running code, using a syscall, to
move a specific thread/process onto that isolated core. Otherwise, it
will be idle all the time.


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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 should be fine then.
>
>
> Something different:
> I see that the hm2_rpspi module is added to the servo-thread. I am
> wondering if the control-loop will be more stable if one of the ARM
> cores is isolated and assigned specifically to the servo-thread.
>
> I do not know the rtapi internals too well, so I'm wondering if CPU
> affinity has been implemented in the code. For the Pi, it would
> probably be a real-time advantage to have the servo-thread isolated on
> one core and have the core for itself the whole time.
>
> 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 the cpu you have isolated is found and used automatically, 
however the use cannot be detected by the various cpu monitoring 
utilities such as htop.  I had originally set that up to reserve core 3, 
on the 4 core pi, and on core 3 of the athlons I don't know who 
corrected me, but it was said that was no longer a useful item, so I 
took it back out of /boot/cmdline.txt and out of some of the x86 
machines too, but I see its still in as an =1 on the two atom boards out 
in the shop.  The one I removed it from hasn't indicated any unhappiness 
with that turn of events.

Perhaps Sebastian or someone more familiar with it can shine a light on 
us here? As in has it been deprecated on all arches. I still have 2 
D525MW's with it in effect. And htop cannot see any usage of cpu-1 on 
either of those 2 boxes.

Cheers Bertho, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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 added to the servo-thread. I am
wondering if the control-loop will be more stable if one of the ARM
cores is isolated and assigned specifically to the servo-thread.

I do not know the rtapi internals too well, so I'm wondering if CPU
affinity has been implemented in the code. For the Pi, it would probably
be a real-time advantage to have the servo-thread isolated on one core
and have the core for itself the whole time.

Has anybody done an implementation of affinity in linuxcnc already? If
yes, how is it setup?

-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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 LED still was blinking
> >> once in a while (probably indicating too much noise on the power
> >> line with my long wires without decoupling capacitor on the end).
> >>
> >> It may be worth checking the actual 5V line for noise too.
> >
> > 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.
>
> [snip]
>
> > One thing I've noted is that in one switch starts both the monitor
> > and the pi, the monitor isn't ready I assume to respond to an EDID
> > query by the time the pi issues it.  So I've had to pull the pi's
> > power plug for about 2 or 3 seconds mid-boot. Then plug in the teeny
> > usb plug again, and I get video on that reboot.
> >
> > Is there quick and likely dirty way to make the pi wait 2 or 3
> > seconds before loading things up?
>
> See:
> https://www.raspberrypi.org/documentation/configuration/config-txt/boo
>t.md
>
> - bootcode_delay - seems the one you are looking for.

Absolutely Bertho. I just set a 3 second delay & we'll see how the next 
reboot works.

> From the docs: "This is particularly useful to insert a delay before
> reading the EDID of the monitor, for example if the Pi and monitor are
> powered from the same source, but the monitor takes longer to start up
> than the Pi."

Thank you Bertho.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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 much noise on the power line with my long
>> wires without decoupling capacitor on the end).
>>
>> It may be worth checking the actual 5V line for noise too.
> 
> 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.


[snip]
> One thing I've noted is that in one switch starts both the monitor and 
> the pi, the monitor isn't ready I assume to respond to an EDID query by 
> the time the pi issues it.  So I've had to pull the pi's power plug for 
> about 2 or 3 seconds mid-boot. Then plug in the teeny usb plug again, 
> and I get video on that reboot.
> 
> Is there quick and likely dirty way to make the pi wait 2 or 3 seconds 
> before loading things up?

See:
https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md

- bootcode_delay - seems the one you are looking for.
>From the docs: "This is particularly useful to insert a delay before
reading the EDID of the monitor, for example if the Pi and monitor are
powered from the same source, but the monitor takes longer to start up
than the Pi."


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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 makes realtime rather
> > unpredictable.
>
> There are actually two lines that must be added to rc.local:
> echo -n 120 >
> /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq

Added also.

> echo -n performance >
> /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
>
> The first one forces to hop to 1.2GHz. The current cpu frequency,
> apparently, may otherwise hang onto the 600MHz value (in
> .../cpu0/cpufreq/cpuinfo_cur_freq).
>
> > Problem 2:
> > The SPI peripheral input frequency appears to be hopping between
> > 400MHz and about 250MHz. This probably originates somewhere in the
> > Linux kernel as the kernel is in charge of clock-generation.
>
> There may be an interaction with the power supply and the
> frequency-lock of one of the BCM283[567] PLLs.
>
> Several power-glitches caused the system to crash after I installed a
> full graphical desktop version. It turned out I was using a cheapo usb
> supply with bad regulation.
>
> 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 much noise on the power line with my long
> wires without decoupling capacitor on the end).
>
> It may be worth checking the actual 5V line for noise too.

5mv? 4 amp box, haven't had a problem.

Thanks Bertho.

One thing I've noted is that in one switch starts both the monitor and 
the pi, the monitor isn't ready I assume to respond to an EDID query by 
the time the pi issues it.  So I've had to pull the pi's power plug for 
about 2 or 3 seconds mid-boot. Then plug in the teeny usb plug again, 
and I get video on that reboot.

Is there quick and likely dirty way to make the pi wait 2 or 3 seconds 
before loading things up?

Thank you Bertho.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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 that must be added to rc.local:
echo -n 120 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo -n performance >
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor

The first one forces to hop to 1.2GHz. The current cpu frequency,
apparently, may otherwise hang onto the 600MHz value (in
.../cpu0/cpufreq/cpuinfo_cur_freq).


> Problem 2:
> The SPI peripheral input frequency appears to be hopping between
> 400MHz and about 250MHz. This probably originates somewhere in the
> Linux kernel as the kernel is in charge of clock-generation.

There may be an interaction with the power supply and the frequency-lock
of one of the BCM283[567] PLLs.

Several power-glitches caused the system to crash after I installed a
full graphical desktop version. It turned out I was using a cheapo usb
supply with bad regulation.

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 much noise on the power line with my long wires
without decoupling capacitor on the end).

It may be worth checking the actual 5V line for noise too.


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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 that play a role. Not all are solved or maybe
> solvable, but the timing is much more stable, and very fast most of
> the time.
>
>
> 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.
>
> Add a line to /etc/rc.local:
>   echo -n performance >
> /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
>
> This will disable the frequency hopping on boot and lock the cores to
> 1.2GHz.
>
Done but not rebooted for effect.
>
> Problem 2:
> The SPI peripheral input frequency appears to be hopping between
> 400MHz and about 250MHz. This probably originates somewhere in the
> Linux kernel as the kernel is in charge of clock-generation.
>
> Changing the cpu's frequency scaling governor to "performance" makes
> the clock more stable, hanging out at 400MHz most of the time, but
> I've seen lower frequencies once in a while. The spidev driver
> actually reads the (peripheral) clock frequency before a transfer
> starts and sets the divider for each transfer. However, I have, at
> this moment, no clue how to read the clock setting in userspace. This
> is a currently a minor issue and should not give rise to major
> problems.
>
>
> Problem 3:
> The hm2_rpspi driver was miscalculating the clock-divider by
> statically setting it to 8. This results in 50MHz SPI clock (400/8),
> which is what we've been seeing. The 32MHz clock is the also explained
> by the peripheral clock switching to ~250MHz.
>
> The code is now changed to do the calculation correct and is
> configurable with a module parameter "spiclk_rate" to set the clock
> (in kHz) and defaults to 33000kHz.
>
> It should be noted that the clock divider must be an even number,
> resulting in frequencies of 200MHz, 100MHz, 66.6MHz, 50MHz, 40MHz,
> 33.3MHz, 28.5MHz, 25MHz, etc.. down to 6.1kHz.
>
>
> Problem 4:
> The hm2_rpspi driver was missing memory barriers in the peripheral
> write/read operations. This resulted in inconsistencies. The code now
> uses memory barrier instructions to ensure consistency.
>
Sounds for sure like it ought to be more stable.
>
> I also unified the driver-code a bit and fixed some other problems I
> could see. It should be functional. The SPI transfers are faster now
> too. I've removed the inter-word delays by using the device's FIFO
> properly. The chip-select latency is also minimal (factor 2..3 better
> than spidev), but it can vary a bit if a (scheduling) interrupt delays
> ending the transfer. The cookie-read is done in 5.7us versus 16.5us
> using spidev.
>
>
> Attached are the changed files. The .c and .h file are the modified
> driver. These go in the source-tree at
> "~/linuxcnc-git/src/hal/drivers/mesa-hostmot2/" (after copy do cd into
> src and do make etc). The .hal and .ini files are the modified configs
> for the sheldon lathe, adding the frequency configuration parameter,
> and go in "~/linuxcnc/configs/sheldon-lathe/".
>
> Try the changes if you will.
I'll take a look. But when I had assembled the board stack and was 
checking it out while sitting on the table saws table, I had to spend a 
day sorting the .hal file out, it looked like I had last edited it with 
gedit, and I am glad I had a printout dated the 10th so I could restore 
it. gedit is a major screwup looking for a place to happen. I 
blacklisted it over a year ago as it scrambles the contents of a file 
around pretty reliably, so I've been using geany ever since.  Yeah, it 
has some warts, but  nothing to compare to gedits open boils.  Kate or 
Kwrite might be ok, but I could never fall in love with either.

ATM, I have hit a bad path thru the 7i90 to the direction output from the 
pwmgen.0 on gpio-21 to pin p1-43, thence thru the 7i42TA, its stuck on 
ground, meaning if I had power on the vfd, it would be running the motor 
backwards, so first thing tomorrow I have to remove at least 2 of the 
7i42TA's to get under them, and after putting a bad card marker on it  
try another 7i90 as I must have built it with a bad card I had 
previously blown.

I need to ask Peter if he repairs them, and if so how much $.  Seems I am 
doing it in wholesale qty's, or I picked up the wrong card, I have 4 
here, and I know for sure 3 are damaged.  Power on the vfd & stepper 
drivers is next. 

But I'm hoping the 7i42TA's will solve the blown 7i90 problem.

> I'm trying to build a new SD card with X 
> installed, but you should not stay awake for it to be finished (upload
> alone of the compressed images takes already 3..4 hours).

Ouch.

Thank you Bertho.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense 

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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 is much more stable, and very fast most of the time.


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.

Add a line to /etc/rc.local:
  echo -n performance >
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor

This will disable the frequency hopping on boot and lock the cores to
1.2GHz.


Problem 2:
The SPI peripheral input frequency appears to be hopping between 400MHz
and about 250MHz. This probably originates somewhere in the Linux kernel
as the kernel is in charge of clock-generation.

Changing the cpu's frequency scaling governor to "performance" makes the
clock more stable, hanging out at 400MHz most of the time, but I've seen
lower frequencies once in a while. The spidev driver actually reads the
(peripheral) clock frequency before a transfer starts and sets the
divider for each transfer. However, I have, at this moment, no clue how
to read the clock setting in userspace. This is a currently a minor
issue and should not give rise to major problems.


Problem 3:
The hm2_rpspi driver was miscalculating the clock-divider by statically
setting it to 8. This results in 50MHz SPI clock (400/8), which is what
we've been seeing. The 32MHz clock is the also explained by the
peripheral clock switching to ~250MHz.

The code is now changed to do the calculation correct and is
configurable with a module parameter "spiclk_rate" to set the clock (in
kHz) and defaults to 33000kHz.

It should be noted that the clock divider must be an even number,
resulting in frequencies of 200MHz, 100MHz, 66.6MHz, 50MHz, 40MHz,
33.3MHz, 28.5MHz, 25MHz, etc.. down to 6.1kHz.


Problem 4:
The hm2_rpspi driver was missing memory barriers in the peripheral
write/read operations. This resulted in inconsistencies. The code now
uses memory barrier instructions to ensure consistency.


I also unified the driver-code a bit and fixed some other problems I
could see. It should be functional. The SPI transfers are faster now
too. I've removed the inter-word delays by using the device's FIFO
properly. The chip-select latency is also minimal (factor 2..3 better
than spidev), but it can vary a bit if a (scheduling) interrupt delays
ending the transfer. The cookie-read is done in 5.7us versus 16.5us
using spidev.


Attached are the changed files. The .c and .h file are the modified
driver. These go in the source-tree at
"~/linuxcnc-git/src/hal/drivers/mesa-hostmot2/" (after copy do cd into
src and do make etc). The .hal and .ini files are the modified configs
for the sheldon lathe, adding the frequency configuration parameter, and
go in "~/linuxcnc/configs/sheldon-lathe/".

Try the changes if you will. I'm trying to build a new SD card with X
installed, but you should not stay awake for it to be finished (upload
alone of the compressed images takes already 3..4 hours).

-- 
Greetings Bertho

(disclaimers are disclaimed)
/*This is a component for RaspberryPi to hostmot2 over SPI for linuxcnc.
 *Copyright 2016 Matsche 
 *Copyright 2017 B.Stultiens 
 *
 *This program is free software; you can redistribute it and/or modify
 *it under the terms of the GNU General Public License as published by
 *the Free Software Foundation; either version 2 of the License, or
 *(at your option) any later version.
 *
 *This program is distributed in the hope that it will be useful,
 *but WITHOUT ANY WARRANTY; without even the implied warranty of
 *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *GNU General Public License for more details.
 *
 *You should have received a copy of the GNU General Public License
 *along with this program; if not, write to the Free Software
 *Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

/* Without Source Tree */
#undef WOST

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include "hal.h"
#include "rtapi.h"
#include "rtapi_app.h"

#include "rtapi_stdint.h"
#include "rtapi_bool.h"
#include "rtapi_gfp.h"

#include "rtapi_bool.h"

#if defined (WOST)
#include "include/hostmot2-lowlevel.h"
#include "include/hostmot2.h"
#else
#include "hostmot2-lowlevel.h"
#include "hostmot2.h"
#endif

#include "spi_common_rpspi.h"

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Matsche");
MODULE_DESCRIPTION("Driver for HostMot2 devices connected via SPI to RaspberryPi");
MODULE_SUPPORTED_DEVICE("Mesa-AnythingIO-7i90");

#define MAX_BOARDS	1		// FIXME: Cannot be other than 1; need CE_0/CE_1 

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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 minimum attention
from my side. The least I owe my students is to have read their work.


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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) to insert DMB
> > (data-memory-barrier) instructions when you need to guarantee
> > ordering. Inserting DMB made things worse, such that sometimes the
> > setup is 32MHz and sometimes 50MHz. Well, actually, it exposes a
> > deeper problem.
>
> 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 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.
>
> So, drop userspace access to the hardware and use the kernel
> interface.
>
> 1 - run raspi-config and enable the kernel SPI driver -> reboot
> 2 - you should now have /dev/spidev0.[01]
> 3 - replace the hm2_rpspi.c file in src/hal/drivers/mesa-hostmot2/
> with the one attached
> 4 - recompile
> 5 - run
>
> Gene, with my (4GB) SD image do (you know the cmdline):
> - run raspi-config to enable the kernel SPI driver and reboot
> - save attached file on SD card as hm2_rpspi.c.new
> $ cp hm2_rpspi.c.new
> linuxcnc-git/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c $ cd
> linuxcnc-git/src
> $ make
> $ sudo make setuid
> $ ../scripts/linuxcnc -v
> ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
>
> I get the result as shown in the images. The advantage is that there
> are no inter-word delays anymore. The time for chip select to be
> active varies a bit (16.5 us in image 8 vs. 6.3 us data transfer in
> image 6). This variability is inherent to the driver how it handles
> chip select asynchronously. Still, it is an improvement, especially
> for large transfers.
>
> I did add a rtapi module parameter - spiclk - which should set the
> clock upon load. However, I've not been able to get that to work.
> Probably something trivial I did wrong. Ah well, at least it runs at a
> good speed now, also after reboots.
>
> My hm2_rpspi driver hack is fixed to /dev/spidev0.0 (CE0 pin). This
> should be a configurable parameter (features for the future).

Hi Bertho; I haven't heard any more, so I am wondering if you've found 
any more "magic beans"?

I managed to get the box with the rebuilt controller mounted on the 
outside of the motor drivers box door today, but nothing is wired up 
yet. This is with the pi with the teeny capacitor (about 14 pf) loading 
the clocking line, which seems to be about bulletproof in that so far it 
has worked every time. This is with the new hm2_rpspi.c you had me 
build.

So tomorrow, I'll start wiring this one back into the system.  It will 
take some time though as I either have to splice & extend the cables, or 
start from scratch with longer cabling.  I'll have to take inventory as 
finding really suitable cabling is a bit of a chore out here in the 
puckerbrush of West Virginia. 

This box is ground isolated as I mounted it on insulation strips, except 
for its power cord, so the first thing will be to extend the single 
point ground to include this box, and cut the static ground in the power 
cord off the back of the socket.  Details, details.  Boring.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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 been running continuously now for about a month.   When
> I log in from my iMac I get a graphic session.
>
> If you are god with Google.   Stop reading here and just Goole "VNC".

I've thought of that, and the 2nd or 3rd message I read is squawking 
about the lag.
>
> The down side of VNC is the lag.   It's very noticeable .  VNC is the
> same technology Both Microsoft and Apple use for their remote desktop
> products. There are a number of implementations of VNC both server and
> client some open source, some closed but zero cost and some
> commercial.  Some Windows versions ship with it installed.
>
You are talking windows Chris. Only ones I have here are made of glass. 
M$ products are verboten at the coyote.den.

> It does not depend on X11, so you can do tricks like have the Windows
> 10 desktop showing in the Pi or vice versa and it works even over the
> Internet.  Technical support people use it to debug user problems   In
> fact if you have VNC server running on the Pi, some expert 1,000 miles
> away could look at your Pi, even while you were logged on.
>
> But did I warn you about lag?  It's so bad VNC uses a double cursor,
> one moves in real time the other shows what the remote computer
> thinks, they seem to be connected by a bungee cord.

I don't know as I could tolerate that.
>
> One other good thing:   I have VNC client on  my iPad.   So I can walk
> around and access the Pi3 with no wires.  Works for simple things
> within limits of 7 inch screen and glass keyboard.   Works on iPhone
> too but tiny screen is useless.
>
> Google for details but steps are to (1) install VNC server on one
> computer, make sure it runs at boot timed (2) install client on
> computer #2 then from menu select first computer or type in IP address
> if not on menu.   I suggest the first experiments be done on two
> computers you are comfortable with, maybe you Linux desktop and your
> Windows box.  THEN try on there Pi.
>
> Al that said, for me, ssh works perfect with zero lag.   Also I can
> export ONE app from Pi to iMac (not the entire desktop session) and it
> work lag-free also.   My Pi is using a wired Ethernet connection.

So is mine. And I've  not figured out yet how to stop whatever it is 
thats bringing wlan0 up at boot.  I'd remove its execute rights.  This 
one is not behind alu siding, so its attackable, successfully, by a 
neighbor that I've not been able to ident.

> On Tue, May 30, 2017 at 10:07 AM, Gene Heskett  
wrote:
> > 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) to
> > > > insert DMB (data-memory-barrier) instructions when you need to
> > > > guarantee ordering. Inserting DMB made things worse, such that
> > > > sometimes the setup is 32MHz and sometimes 50MHz. Well,
> > > > actually, it exposes a deeper problem.
> > >
> > > 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
> > > 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.
> > >
> > > So, drop userspace access to the hardware and use the kernel
> > > interface.
> > >
> > > 1 - run raspi-config and enable the kernel SPI driver -> reboot
> > > 2 - you should now have /dev/spidev0.[01]
> > > 3 - replace the hm2_rpspi.c file in src/hal/drivers/mesa-hostmot2/
> > > with the one attached
> > > 4 - recompile
> > > 5 - run
> > >
> > > Gene, with my (4GB) SD image do (you know the cmdline):
> > > - run raspi-config to enable the kernel SPI driver and reboot
> > > - save attached file on SD card as hm2_rpspi.c.new
> > > $ cp hm2_rpspi.c.new
> > > linuxcnc-git/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c $ cd
> > > linuxcnc-git/src
> > > $ make
> > > $ sudo make setuid
> > > $ ../scripts/linuxcnc -v
> > > ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
> >
> > Well, I am still trying to figure out how to run linuxcnc w/o a gfx
> > screen.
> >
> > I followed the above instructions when it wouldn't run the first
> > time, and now I get a somewhat different message, so lemme see if I
> > can log in from here and duplicate the results, at least to the
> > interesting part.
> >
> > pi@pionsheldon:~/linuxcnc-git/scripts
> > $ ./linuxcnc -v 

Re: [Emc-users] RPI saga continues - SPI probably solved

[Chris Albertson]

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 from
my iMac I get a graphic session.

If you are god with Google.   Stop reading here and just Goole "VNC".



The down side of VNC is the lag.   It's very noticeable .  VNC is the same
technology Both Microsoft and Apple use for their remote desktop products.
There are a number of implementations of VNC both server and client some
open source, some closed but zero cost and some commercial.  Some Windows
versions ship with it installed.

It does not depend on X11, so you can do tricks like have the Windows 10
desktop showing in the Pi or vice versa and it works even over the
Internet.  Technical support people use it to debug user problems   In fact
if you have VNC server running on the Pi, some expert 1,000 miles away
could look at your Pi, even while you were logged on.

But did I warn you about lag?  It's so bad VNC uses a double cursor, one
moves in real time the other shows what the remote computer thinks, they
seem to be connected by a bungee cord.

One other good thing:   I have VNC client on  my iPad.   So I can walk
around and access the Pi3 with no wires.  Works for simple things within
limits of 7 inch screen and glass keyboard.   Works on iPhone too but tiny
screen is useless.

Google for details but steps are to (1) install VNC server on one computer,
make sure it runs at boot timed (2) install client on computer #2 then from
menu select first computer or type in IP address if not on menu.   I
suggest the first experiments be done on two computers you are comfortable
with, maybe you Linux desktop and your Windows box.  THEN try on there Pi.

Al that said, for me, ssh works perfect with zero lag.   Also I can export
ONE app from Pi to iMac (not the entire desktop session) and it work
lag-free also.   My Pi is using a wired Ethernet connection.



On Tue, May 30, 2017 at 10:07 AM, Gene Heskett  wrote:

> 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) to insert DMB
> > > (data-memory-barrier) instructions when you need to guarantee
> > > ordering. Inserting DMB made things worse, such that sometimes the
> > > setup is 32MHz and sometimes 50MHz. Well, actually, it exposes a
> > > deeper problem.
> >
> > 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 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.
> >
> > So, drop userspace access to the hardware and use the kernel
> > interface.
> >
> > 1 - run raspi-config and enable the kernel SPI driver -> reboot
> > 2 - you should now have /dev/spidev0.[01]
> > 3 - replace the hm2_rpspi.c file in src/hal/drivers/mesa-hostmot2/
> > with the one attached
> > 4 - recompile
> > 5 - run
> >
> > Gene, with my (4GB) SD image do (you know the cmdline):
> > - run raspi-config to enable the kernel SPI driver and reboot
> > - save attached file on SD card as hm2_rpspi.c.new
> > $ cp hm2_rpspi.c.new
> > linuxcnc-git/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c $ cd
> > linuxcnc-git/src
> > $ make
> > $ sudo make setuid
> > $ ../scripts/linuxcnc -v
> > ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
> >
> Well, I am still trying to figure out how to run linuxcnc w/o a gfx
> screen.
>
> I followed the above instructions when it wouldn't run the first time,
> and now I get a somewhat different message, so lemme see if I can log in
> from here and duplicate the results, at least to the interesting part.
>
> pi@pionsheldon:~/linuxcnc-git/scripts
> $ ./linuxcnc -v ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
> Verbose mode on
> RUN_IN_PLACE=yes
> LINUXCNC_DIR=
> LINUXCNC_BIN_DIR=/home/pi/linuxcnc-git/bin
> LINUXCNC_TCL_DIR=/home/pi/linuxcnc-git/tcl
> LINUXCNC_SCRIPT_DIR=
> LINUXCNC_RTLIB_DIR=/home/pi/linuxcnc-git/rtlib
> LINUXCNC_CONFIG_DIR=
> LINUXCNC_LANG_DIR=/home/pi/linuxcnc-git/src/objects
> INIVAR=inivar
> HALCMD=halcmd
> LINUXCNC_EMCSH=/usr/bin/wish8.6
> LINUXCNC - 2.8.0~pre1
> Machine configuration directory
> is '/home/pi/linuxcnc-git/scripts/../../linuxcnc/configs/sheldon-lathe'
> Machine configuration file is '7i90-axis.ini'
> INIFILE=/home/pi/linuxcnc-git/scripts/../../linuxcnc/
> configs/sheldon-lathe/7i90-axis.ini
> VERSION=1.0
> PARAMETER_FILE=hm2-stepper.var
> 

Re: [Emc-users] RPI saga continues - SPI probably solved

[Gene Heskett]

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) to insert DMB
> > (data-memory-barrier) instructions when you need to guarantee
> > ordering. Inserting DMB made things worse, such that sometimes the
> > setup is 32MHz and sometimes 50MHz. Well, actually, it exposes a
> > deeper problem.
>
> 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 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.
>
> So, drop userspace access to the hardware and use the kernel
> interface.
>
> 1 - run raspi-config and enable the kernel SPI driver -> reboot
> 2 - you should now have /dev/spidev0.[01]
> 3 - replace the hm2_rpspi.c file in src/hal/drivers/mesa-hostmot2/
> with the one attached
> 4 - recompile
> 5 - run
>
> Gene, with my (4GB) SD image do (you know the cmdline):
> - run raspi-config to enable the kernel SPI driver and reboot
> - save attached file on SD card as hm2_rpspi.c.new
> $ cp hm2_rpspi.c.new
> linuxcnc-git/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c $ cd
> linuxcnc-git/src
> $ make
> $ sudo make setuid
> $ ../scripts/linuxcnc -v
> ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
>
Well, I am still trying to figure out how to run linuxcnc w/o a gfx 
screen.

I followed the above instructions when it wouldn't run the first time, 
and now I get a somewhat different message, so lemme see if I can log in 
from here and duplicate the results, at least to the interesting part.

pi@pionsheldon:~/linuxcnc-git/scripts 
$ ./linuxcnc -v ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
Verbose mode on
RUN_IN_PLACE=yes
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/home/pi/linuxcnc-git/bin
LINUXCNC_TCL_DIR=/home/pi/linuxcnc-git/tcl
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/home/pi/linuxcnc-git/rtlib
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/home/pi/linuxcnc-git/src/objects
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.8.0~pre1
Machine configuration directory 
is '/home/pi/linuxcnc-git/scripts/../../linuxcnc/configs/sheldon-lathe'
Machine configuration file is '7i90-axis.ini'
INIFILE=/home/pi/linuxcnc-git/scripts/../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
VERSION=1.0
PARAMETER_FILE=hm2-stepper.var
TASK=milltask
HALUI=
DISPLAY=axis
COORDINATES=X Z
KINEMATICS=trivkins coordinates=XZ
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
hm2_rpspi: spiclk=3200 Hz
hm2_rpspi: Invalid cookie
hm2_rpspi: Read:    
hm2_rpspi: rtapi_app_main: No such device (-19)
./hm2-7i90-stepper.hal:32: waitpid 
failed /home/pi/linuxcnc-git/bin/rtapi_app hm2_rpspi
./hm2-7i90-stepper.hal:32: /home/pi/linuxcnc-git/bin/rtapi_app exited 
without becoming ready
./hm2-7i90-stepper.hal:32: insmod for hm2_rpspi failed, returned -1
Shutting down and cleaning up LinuxCNC...
Killing task linuxcncsvr, PID=690
hm2_rpspi: not loaded
:0: exit value: 255
:0: rmmod failed, returned -1
hm2: unloading
:0: unloadrt failed
Removing HAL_LIB, RTAPI, and Real Time OS modules
Note: Using POSIX realtime
Removing NML shared memory segments
LinuxCNC terminated with an error.  You can find more information in the 
log:
/home/pi/linuxcnc_debug.txt
and
/home/pi/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal
pi@pionsheldon:~/linuxcnc-git/scripts $ 

Is that 14 pf cap to ground on the spi-clk0 now screwing it up?

On the first attempt, the error wording seemed to indicate it couldn't 
find a display. I wish I'd have thought to capture it.

On the other card, I had 4 workspaces set up on the other card before I 
had increased the framebuffer depth to 24, and I found they were still 
there, just blank screens, and I could make my terminal session go away 
by rolling the mouse wheel, and if I kept rolling the same direction it 
wrapped and put me back on the 1st screen.  Shade tree engineering at 
its best. :)  Doesn't work now of course.

Your turn, should you choose to accept it.

I'm going to put the other card back in and see if I have a good 7i90 
under all those 7i42ta's. The one its running on now has some blown bus 
buffers according to Peter.  With 4 of them laying about, I may have 
grabbed a bad one. So I'd better check before I bury it any deeper.

> I get the result as shown in the images. The advantage is 

Re: [Emc-users] RPI saga continues - SPI probably [not] solved

[Bertho Stultiens]

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
can be simpler.

-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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.
> [snip]
> 
> 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.

My guess is that it was on a Pi2. The Pi3 should perform better. The
problem is that you cannot control the SMP behavior correctly from
userspace, unless all interrupts are disabled and caching is taken into
account.

The only performance issue I can see is the asynchronous chip select.
The original code in the hm2_rpspi is significantly slower in transfers
due to synchronous write/read sequences.

-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Jeff Epler]

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 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.
[snip]

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.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPI saga continues - SPI probably solved

[Bertho Stultiens]

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 to guarantee ordering. Inserting DMB made
> things worse, such that sometimes the setup is 32MHz and sometimes
> 50MHz. Well, actually, it exposes a deeper problem.

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

So, drop userspace access to the hardware and use the kernel interface.

1 - run raspi-config and enable the kernel SPI driver -> reboot
2 - you should now have /dev/spidev0.[01]
3 - replace the hm2_rpspi.c file in src/hal/drivers/mesa-hostmot2/ with
the one attached
4 - recompile
5 - run

Gene, with my (4GB) SD image do (you know the cmdline):
- run raspi-config to enable the kernel SPI driver and reboot
- save attached file on SD card as hm2_rpspi.c.new
$ cp hm2_rpspi.c.new linuxcnc-git/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c
$ cd linuxcnc-git/src
$ make
$ sudo make setuid
$ ../scripts/linuxcnc -v ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini

I get the result as shown in the images. The advantage is that there are
no inter-word delays anymore. The time for chip select to be active
varies a bit (16.5 us in image 8 vs. 6.3 us data transfer in image 6).
This variability is inherent to the driver how it handles chip select
asynchronously. Still, it is an improvement, especially for large transfers.

I did add a rtapi module parameter - spiclk - which should set the clock
upon load. However, I've not been able to get that to work. Probably
something trivial I did wrong. Ah well, at least it runs at a good speed
now, also after reboots.

My hm2_rpspi driver hack is fixed to /dev/spidev0.0 (CE0 pin). This
should be a configurable parameter (features for the future).

-- 
Greetings Bertho

(disclaimers are disclaimed)
/*This is a component for RaspberryPi to hostmot2 over SPI for linuxcnc.
 *Copyright 2016 Matsche 
 *Copyright 2017 B.Stultiens 
 *
 *This program is free software; you can redistribute it and/or modify
 *it under the terms of the GNU General Public License as published by
 *the Free Software Foundation; either version 2 of the License, or
 *(at your option) any later version.
 *
 *This program is distributed in the hope that it will be useful,
 *but WITHOUT ANY WARRANTY; without even the implied warranty of
 *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *GNU General Public License for more details.
 *
 *You should have received a copy of the GNU General Public License
 *along with this program; if not, write to the Free Software
 *Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

/* Without Source Tree */
#undef WOST

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include "hal.h"
#include "rtapi.h"
#include "rtapi_app.h"

#include "rtapi_stdint.h"
#include "rtapi_bool.h"
#include "rtapi_gfp.h"

#include "rtapi_bool.h"

#if defined (WOST)
#include "include/hostmot2-lowlevel.h"
#include "include/hostmot2.h"
#else
#include "hostmot2-lowlevel.h"
#include "hostmot2.h"
#endif

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Matsche");
MODULE_DESCRIPTION("Driver for HostMot2 devices connected via SPI to RaspberryPi");
MODULE_SUPPORTED_DEVICE("Mesa-AnythingIO-7i90");

#define MAX_BOARDS	1		// XXX: cannot be anything else than 1 at the moment
#define MAX_MSG		512

typedef struct hm2_rpspi_struct {
	hm2_lowlevel_io_t llio;
	int nr;
	uint32_t txBuf[MAX_MSG];
	uint32_t rxBuf[MAX_MSG];
	int spiclk;
	int spifd;
} hm2_rpspi_t;

static char *config[MAX_BOARDS];
static int spiclk = 3200;

RTAPI_MP_ARRAY_STRING(config, MAX_BOARDS, "config string for the AnyIO boards (see hostmot2(9) manpage)")
RTAPI_MP_INT(spiclk, "SPI clock frequency in Hz, default 3200 Hz)");

static hm2_rpspi_t boards[MAX_BOARDS];
static int comp_id;

static int spi_open(const char *dev, int mode, int speed, int wsize)
{
	int fd;

	if(-1 == (fd = open(dev, O_RDWR|O_NOCTTY))) {
		rtapi_print_msg(RTAPI_MSG_ERR, "hm2_rpspi: %s: open: %s", dev, strerror(errno));
		return -1;
	}

	if(-1 == ioctl(fd, SPI_IOC_WR_MODE, )) {
		rtapi_print_msg(RTAPI_MSG_ERR, "hm2_rpspi: %s: ioctl: SPI_IOC_WR_MODE: %s", dev, strerror(errno));
		close(fd);
		return -1;
	}

	if(-1 == ioctl(fd, SPI_IOC_WR_BITS_PER_WORD, )) {
		rtapi_print_msg(RTAPI_MSG_ERR, "hm2_rpspi: %s: ioctl: 

[Emc-users] RPi and the endless saga of SDcard grief.

[Greg Bentzinger]

List users;


I have been a RPI user since the first B version came out. I been through the 
"Oops the O/s is toast again" routine more than I care to count.

I blame it on very poor choices for the voltage regulator and the choices of 
the micro USB as a power connector. Arduino scroes an A for using the round 
type and allowing a higher voltage source (say 9VDC)that could take up slack 
and small line disturbances.

I now only do a minimalist O/S install on the SDcard and run apps and storage 
off a USB thumb drive.

However Gene appears to need many gigs (for the HAL files) and wants real Linux 
file system permissions. No I don't even own a Rpi 3, and documentation for 
this item is almost as sparse as Orange pi/ up boards etc.

I am suggestion even another Amazon shopping expedition. See 
https://www.amazon.com/dp/B06XJNN2MZ

The X800 PCB for RPi adds a 2.5" laptop HDD to the mix. I don't know if you can 
eliminate SDcards entirely or if you might still need to use one for a 
bootloader. Having a dozen 2GB sdcards with only a bootloader img will save 
your recovery times dramatically.

An yeah form what you have described adding this card will yet again cause the 
enclosure door to not want to close... Pick your preferred poisons.

Greg, Out yonder in Yoder CO.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] RPI saga continues

[Bertho Stultiens]

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 out-of-order. The ARM has
the __sync_synchronize() (via gcc) to insert DMB (data-memory-barrier)
instructions when you need to guarantee ordering. Inserting DMB made
things worse, such that sometimes the setup is 32MHz and sometimes
50MHz. Well, actually, it exposes a deeper problem.

This is a Pi3, a 4-core SMP machine. DMBs and peripheral setup probably
requires that no other cores are crossing peripherals while doing setup
(or the process/thread is rescheduled onto a different core). For the
Pi3 you probably need to lock this specific setup operation to one core
and one core only.

I noticed at startup that several interesting things happen, and I
assume that a lot of processes and threads are spawned while doing
startup. That also means that all bets are off in this sensitive time
period and could explain why SPI keeps hopping between different setup
states.

Anybody care to comment or suggest a way to lock that part of the code
to a core?

-- 
Greetings Bertho

(disclaimers are disclaimed)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPi alternatives (for detectives)

[Gene Heskett]

On Thursday 11 May 2017 14:22:49 Gene Heskett wrote:

> On Thursday 11 May 2017 13:24:08 TJoseph Powderly wrote:
> > gene
> > i was just reading about armbian preempt-rt sources
> >
> > look at https://github.com/armbian/build
> > look at https://github.com/armbian/build/tree/master/config/boards
> > for boards
> > look at rt patch at
> > https://github.com/armbian/build/tree/master/patch/kernel/sun8i-defa
> >ul t/30-real-time143-full-plus-rt-fixes.patch.disabled
> >
> > people have been trying to get a generic build for preempt-rt on
> > many of the raspi-esque boards
> > (orangepi bananapi cubieboard lime odroid pine64 tinkerboard udoo )
> > and people have been having trouble doing it
> >
> > https://forum.armbian.com/index.php?/topic/2881-realtime-patch-not-w
> >or king-with-orangepi-plus-2/
> >
> > this is pretty deep water!
> >
> > it MAY be possible
> > you'd need a build environment, and likely crosscompiling
> >
> > i am guessing here,
> > but i think that cloning that git repo, then renaming
> > 30-real-time143-full-plus-rt-fixes.patch.disabled
> > to
> > 30-real-time143-full-plus-rt-fixes.patch
> > and building, will get you a preempt-rt image
> >
> >
> > maybe ;-)
> >
> > regards
> > tomp tjtr33
>
> To me, the pi is a dead end. Its horrible keyboard response is killing
> any wish to actually use it standing in front of the machine. Biggest
> problem is that it ignores keyup events, so the auto-repeat kicks in,
> and if its the backspace that sticks,  half a line or more of a hal
> file is erased and the only thing you can do is kill the editor w/o a
> save and start over. A reboot will often fix it, for half a day maybe,
> or it could make it so bad you have to use the power switch to reboot
> it.
>
> I now have on this desk, and up-board with and intel atom cpu, 2G of
> ram, and 16Gm of eMMC memory built in. About $125 shipped by fedex
> from the Netherlands.  And a fresh copy of our hybrid install iso. And
> I have a terabyte backup disk by seagate, $65 with taxes at Staples,
> powered by a stock usb-2 cable.  Works nice
>
> That atom is now a quad core, running at about the same speed as the
> pair of D525MW hearted machines I've been running lcnc on for several
> years and happy as a pig in cool mud over how they've worked.  If this
> one will work as well I'll be a happy camper.  I just joined their
> forum because I need to get 2 things, first being the drill pattern it
> bolts to, and 2nd, is the gpio layout a clone of the pi's 40 pin
> header. In which case there may be a measureable chance of
> hm2_rpspi.so spi driver actually driving the SPI interface to a 7i90.
> On an intel powered board. Yeah, I  dream big. :)
>
The saga continues.

The intel powered board was bricked by my turning off the TCP chip in the 
bios.

So I am back to screwing with the pi's, plural as I bought spares. I had 
a spare that would boot hanging out in the air, and put a fresh install 
of an image dated Apeil 10th.  Booted right up as soon as I fixed the 
video and networking stuffs.  So I fired up synaptic, and had it update 
everything but the kernel.  Died on wolfram engine, server disappeared.

I took that out of the list and it completed the rest of the update AND 
REBOOTED JUST FINE.  Shut down, moved the sd card to the pi I'd been 
fighting with, no boot.  Swapped out the pi for another, booted right 
up.  So that one I took out is marked with an MM. Now I need to recover 
my lcnc configs I saved off a card that wouldn't boot. But first, some 
din-din, its past time I fed the missus, me too since all I've had is 
coffee so far.

Progress, I think. With a different pi, I'll re-test the OSHPark based 
interconnect cables before too long.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPi alternatives (for detectives)

[Gene Heskett]

On Thursday 11 May 2017 13:24:08 TJoseph Powderly wrote:

> gene
> i was just reading about armbian preempt-rt sources
>
> look at https://github.com/armbian/build
> look at https://github.com/armbian/build/tree/master/config/boards for
> boards
> look at rt patch at
> https://github.com/armbian/build/tree/master/patch/kernel/sun8i-defaul
>t/30-real-time143-full-plus-rt-fixes.patch.disabled
>
> people have been trying to get a generic build for preempt-rt on many
> of the raspi-esque boards
> (orangepi bananapi cubieboard lime odroid pine64 tinkerboard udoo )
> and people have been having trouble doing it
>
> https://forum.armbian.com/index.php?/topic/2881-realtime-patch-not-wor
>king-with-orangepi-plus-2/
>
> this is pretty deep water!
>
> it MAY be possible
> you'd need a build environment, and likely crosscompiling
>
> i am guessing here,
> but i think that cloning that git repo, then renaming
> 30-real-time143-full-plus-rt-fixes.patch.disabled
> to
> 30-real-time143-full-plus-rt-fixes.patch
> and building, will get you a preempt-rt image
>
>
> maybe ;-)
>
> regards
> tomp tjtr33
>
To me, the pi is a dead end. Its horrible keyboard response is killing 
any wish to actually use it standing in front of the machine. Biggest 
problem is that it ignores keyup events, so the auto-repeat kicks in, 
and if its the backspace that sticks,  half a line or more of a hal file 
is erased and the only thing you can do is kill the editor w/o a save 
and start over. A reboot will often fix it, for half a day maybe, or it 
could make it so bad you have to use the power switch to reboot it.

I now have on this desk, and up-board with and intel atom cpu, 2G of ram, 
and 16Gm of eMMC memory built in. About $125 shipped by fedex from the 
Netherlands.  And a fresh copy of our hybrid install iso. And I have a 
terabyte backup disk by seagate, $65 with taxes at Staples, powered by a 
stock usb-2 cable.  Works nice

That atom is now a quad core, running at about the same speed as the pair 
of D525MW hearted machines I've been running lcnc on for several years 
and happy as a pig in cool mud over how they've worked.  If this one 
will work as well I'll be a happy camper.  I just joined their forum 
because I need to get 2 things, first being the drill pattern it bolts 
to, and 2nd, is the gpio layout a clone of the pi's 40 pin header. In 
which case there may be a measureable chance of hm2_rpspi.so spi driver 
actually driving the SPI interface to a 7i90. On an intel powered board. 
Yeah, I  dream big. :)
>
> --
> Check out the vibrant tech community on one of the world's
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPi alternatives (for detectives)

[TJoseph Powderly]

gene
i was just reading about armbian preempt-rt sources

look at https://github.com/armbian/build
look at https://github.com/armbian/build/tree/master/config/boards for 
boards
look at rt patch at
https://github.com/armbian/build/tree/master/patch/kernel/sun8i-default/30-real-time143-full-plus-rt-fixes.patch.disabled

people have been trying to get a generic build for preempt-rt on many of 
the raspi-esque boards
(orangepi bananapi cubieboard lime odroid pine64 tinkerboard udoo )
and people have been having trouble doing it

https://forum.armbian.com/index.php?/topic/2881-realtime-patch-not-working-with-orangepi-plus-2/

this is pretty deep water!

it MAY be possible
you'd need a build environment, and likely crosscompiling

i am guessing here,
but i think that cloning that git repo, then renaming
30-real-time143-full-plus-rt-fixes.patch.disabled
to
30-real-time143-full-plus-rt-fixes.patch
and building, will get you a preempt-rt image


maybe ;-)

regards
tomp tjtr33


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPi alternatives (for detectives)

[Gene Heskett]

On Thursday 11 May 2017 10:45:12 TJoseph Powderly wrote:

> Erik hello
>
> On 05/11/17 14:01, Erik Christiansen wrote:
> > Gene, what I bought is a Udoo X86, and on their forum there's talk
> > of this and that not working too, at least until someone tells them
> > how to do it. My only issue so far is that I'm a bit down the
> > delivery list, and it may yet be a week or two before mine arrives.
> > (Still, it's better that they hauled up and fixed the PCB issue,
> > rather than ship substandard goods.)
> >
> > It ought to be able to boot from USB or SD card, so just do the same
> > vanilla stuff as in the Udoo howto, which is here?:
> >
> > https://www.udoo.org/tutorial/creating-a-bootable-micro-sd-card-with
> >-linux-ubuntu-from-image/
> >
> > You just grab any linux distro you fancy, off the intertubes. (I've
> > put a ubuntu-16.04.1-desktop-amd64.iso onto a flash drive, and am
> > impatient for the board to arrive.)
>
> i thought about the ud00 x86 for linuxcnc
>
> i read the 'use any linux x86 distro'
>
> but
>
> is there reason to think it can run the linuxcnc iso for x86?
>
> can it become a tiny realtime control?
>
>
> right now i'm trying to get preempt-rt onto an opi+2e for similar
> reasons
>
>
> these tiny boards can drive you nuts
>
> i get the impression that they're all built for settop boxes
>
> and rejects sold as the latest greatest linux microcontroller
>
>
> today i 'fixed' the SD block read fails with a paper shim ( not by
> buying class 10 sd )
>
> today i 'fixed' the 'cant enumerate device on...' by bending down the
> 2 tabs on the usb jack
>
> ( not by buying a new mouse )
>
> i am firm believer in 'things generally work'
>
> and in 'connections are 90% of electrical problems'
>
At least Tomp.

I just got a surprise, the up-board was shipped by Fedex this past Monday 
from a location in the Netherlands, and Fedex just made me sign for it. 
According to the very sparse docs (1 page), I need to find a 5.5-2.1 
plug to put on a 5v4a supply. So I'll have to swap supplies as I have a 
3a and a 4a and the 4a is currently running the pi, no biggie.  The 3 
can do as well, its been tried.

It says bootable usb drive with iso or os preloaded,
connect hdmi, net cable, keyboard and mouse.
connect power supply, wiat for the up bios logo.

For more info goto www.up-community.org.

I have a usb drive, a rotating media 1 terrabyte seagate, $60 at Staples.
I wonder if I can install our wheezy-iso, a fresh copy coming in now via 
zsync.  I'll put it on that drive, boot it and install back to that 
drive.  Or at least thats the plan. :)

This board has an alu baseplate, which seems to be in contact with the 
bottom of the cpu pad, contributing to the cooling by providing a path 
for some of that heat directly to the alu panel I will mount it on which 
is some north of a square foot of 3mm thick alu sheet. The top is also 
well covered with a heat sink. The 40 pin header is oriented the same as 
the pi's header. Looks promising and I saw a reference on the forum that 
its possible the gpio usage actually matches the pi!

Interesting times ahead. But maybe I should find an 8Gb usb keystick.  I 
will, if the drive actually boots.  News at 11. :)

> thanks
>
> Tomp tjtr33
>
>
> --
> Check out the vibrant tech community on one of the world's
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RPi alternatives (for detectives)

[TJoseph Powderly]

Erik hello

On 05/11/17 14:01, Erik Christiansen wrote:
> Gene, what I bought is a Udoo X86, and on their forum there's talk of
> this and that not working too, at least until someone tells them how to
> do it. My only issue so far is that I'm a bit down the delivery list,
> and it may yet be a week or two before mine arrives. (Still, it's better
> that they hauled up and fixed the PCB issue, rather than ship substandard
> goods.)

> It ought to be able to boot from USB or SD card, so just do the same
> vanilla stuff as in the Udoo howto, which is here?:
>
> https://www.udoo.org/tutorial/creating-a-bootable-micro-sd-card-with-linux-ubuntu-from-image/
>
> You just grab any linux distro you fancy, off the intertubes. (I've put
> a ubuntu-16.04.1-desktop-amd64.iso onto a flash drive, and am impatient
> for the board to arrive.)
i thought about the ud00 x86 for linuxcnc

i read the 'use any linux x86 distro'

but

is there reason to think it can run the linuxcnc iso for x86?

can it become a tiny realtime control?


right now i'm trying to get preempt-rt onto an opi+2e for similar reasons


these tiny boards can drive you nuts

i get the impression that they're all built for settop boxes

and rejects sold as the latest greatest linux microcontroller


today i 'fixed' the SD block read fails with a paper shim ( not by 
buying class 10 sd )

today i 'fixed' the 'cant enumerate device on...' by bending down the 2 
tabs on the usb jack

( not by buying a new mouse )

i am firm believer in 'things generally work'

and in 'connections are 90% of electrical problems'


thanks

Tomp tjtr33


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] RPi alternatives (for detectives)

[Erik Christiansen]

On 07.05.17 16:56, Gene Heskett wrote:
> I'm very impressed with the lack of data on the up-shop.net web site as 
> to just what these atom powered things have, they don't even say how 
> wide the gpio count is, so I may have bought a very lightweight 
> paperweight, but the card was accepted for one just like Erik said he 
> had bought. 2 gigs of ram, 16gigs of eMMC for a disk drive. $124 
> shipped.  With suitable drivers, all running x86/intel code, its 
> promising.  The forum is loaded with this and that don't work messages 
> though.

Gene, what I bought is a Udoo X86, and on their forum there's talk of
this and that not working too, at least until someone tells them how to
do it. My only issue so far is that I'm a bit down the delivery list,
and it may yet be a week or two before mine arrives. (Still, it's better
that they hauled up and fixed the PCB issue, rather than ship substandard
goods.)

> I don't see a debian for downloading but I'd prefer it, jessie 
> is close to EOL, and rumors are saying stretch is fairly stable now.  

It ought to be able to boot from USB or SD card, so just do the same
vanilla stuff as in the Udoo howto, which is here?:

https://www.udoo.org/tutorial/creating-a-bootable-micro-sd-card-with-linux-ubuntu-from-image/

You just grab any linux distro you fancy, off the intertubes. (I've put
a ubuntu-16.04.1-desktop-amd64.iso onto a flash drive, and am impatient
for the board to arrive.)

> Theres some sort of a ubuntu I never heard of, yocto (whats that?) and 
> whatever is running the fawncy phones these days.

Heard of it, but never seen it in action. I'd try debian or ubuntu first
- just google for "latest ubuntu iso" or similar.

And in the other post, On 10.05.17 23:42, Gene Heskett wrote:
> I've had the usb monitor thing running several times, and that got me to 
> throw away a usb extension cord that was picking up megabits of raw 
> noise so I plugged the rx buttons directly into the pi, and without too 
> much between the keyboard and the button but 25 feet of air, and it 
> never misses a keystroke.  Of course since the sd card is on the usb 
> stuff, I also see the "disk" traffic, but its not "busy".  Next reboot, 
> the usbtrace looks the same but no response to keyup events about 90% of 
> the time.  The events are getting thru the rx buttons, but the pi is 
> ignoring them.

Presumably the RPi will boot from USB or SD card, so you could grab
another ARMish linux distro off the net, and run that to see if it's
hardware or software that is the issue? At the very least, get away from
any RT kernel, and run a vanilla distro. Then you know where to direct
further energy.

...
> Were you getting an up-board? Or was that Erik?

Not too sure what the up-board is ... ah, it looks neat, but the site is
slow, and it's a bit of a dig to get past the waffle, to find what it
can do. I gave up. Please tell us what it's like once you have it home
from market.

I bought the Udoo thingy because it can handle 3 4K screens
simultaneously, and I need one mobo which can do a bit of video. What I
have stinks. (So the delivery delay is becoming annoying.) It also
looked like a fun bit of kit - but the waiting isn't so much fun. (Did I
mention that?)

Erik

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users