On Monday 09 October 2017 13:55:37 John Dammeyer wrote:

But the rk3328 is the Rock64.

> Is this discussion that mentions rk3328 still about still BeagleBone
> Black or a different ARM based device.  Maybe for that the subject
> line should change?
>
> I looked at the Xylotex pin map and I can see only one SPI port that
> is available although the pin use is commented out in the HAL.
> For I/O expansion I'm interested in using the Homann Designs MODIO
> board since I have one.  Peter Homann tells me that several people
> have ported it to EMC2.
>
> I also have a CBB-Serial CAN/Serial 232/485 Cape from Logic Supply. 
> With Controller Area Network (CAN)  I'd have access to CANopen
> hardware.
>
> I found the site with the files and I've downloaded the various
> folders. The makefiles will need some work to change paths from EMC2/.
> . . etc. but it looks like it would work if UART1 P9-24, P9-26 are
> used.
>
> However, my CBB-Serial uses P9-24, P9-26 for CAN and P9-21, P9-22 for
> UART2.
>
>
> So it should be possible to use some of the cape except that P9-15,
> which is Z_Step, is use for RS485 direction which implies probably
> only RS232 MODBUS. Assuming those can be disabled in the CBB-Serial
> configuration.  That will be a set of questions for the BBB group
> since the EEROMs on each Cape select which device tree information to
> use.
>
> Still,  Effectively, unlimited within reason I/O expansion is easily
> available with a Beagle.

Thats one of the draws to the relatively inexpensive mesa 7i90, 72 gpio's 
minus whats used for the "canned" functions. I have quite a bit of stuff 
wired up on the Sheldon now and still have nearly 40 pins left to use.  
And it can be driven from a parport but the data rate is slower, 
estimated at 1/5th the speed of the spi. 

Interestingly, in trolling thru the 4.9 kernel sources withe a make 
menuconfig, I tripped over a driver that makes a parport out of some of 
the gpio pins on the arm64's. I may build it as a module and see if its 
fast enough the next time I make a new kernel.  Now that would be a 
hoot! Cobbling up a gpio to db 25 connection kit will be a chore and 
take a while though.

The what if's looking down this path are endless, John. I need more room 
to play (and time too) than I have, darn it.

Now, right now, I need the command line option to make "make" about 100x 
as verbose so I can trace an attempted build of a rock64 version of 
hm2_rpspi to see where its failing.

This is not a heck of a lot to go on:

rock64@rock64:~/linuxcnc-dev/src$ make
Reading 190/190 dependency files
Done reading dependencies
Reading 197/198 realtime dependency files
Done reading realtime dependencies
Linking ../rtlib/hm2_rkspi.so
ld: no input files
Makefile:997: recipe for target '../rtlib/hm2_rkspi.so' failed
make: *** [../rtlib/hm2_rkspi.so] Error 1

I need to see whats up that leads to the link error.




> John
>
>
> From CBB-Serial Cape:
> Signal name   Header Pin      Pin Mode                Comments
> UART4_RTS(1)  P8_33           output                  UART4
> request-to-send
> UART4_CTS(1)  P8_35           input                   UART4 clear-to-send
> UART2_CTS(1)  P8_37           input                   UART4 clear-to-send
> UART2_RTS(1)  P8_38           output                  UART2
> request-to-send
> ON_SW         P9_9            input                   Trigger power on
> UART4_RX(2)   P9_11           RS232 input             ±1.6 - ±12V on IDC10
> / screw terminal
> UART4_TX(2)   P9_13           RS232 output            ±5.4V out IDC10 /
> screw terminal
> UART4_RX(2)   P9_11           serial in from RS485    -7 - +12V
> common-mode voltage on receiver
> UART4_TX(2)   P9_13           serial out to RS485     Standard RS485 5V
> differential driver output
> GPIO1_6       P9_15           digital output          for software RS485
> RE/DE control
> UART2_TX      P9_21           RS232 output            ±5.4V out IDC10 /
> screw terminal
> UART2_RX      P9_22           RS232 input             ±1.6 - ±12V on IDC10
> / screw terminal
> DCAN1_RX      P9_24           serial in               from CAN bus -27 -
> +40V common-mode voltage on bus
> DCAN1_TX      P9_26           serial out              to CAN bus 3V max
> driver differential output voltage
> NOTES:
> 1. These pins are shared with the HDMI driver and are disabled by
> default. See ‘Enabling Flow Control’ below
> 2. UART4 is shared between the RS232 converter and the RS485 driver,
> its function is selected with jumper
>
> From DB-25/26 Cape:
> Enable System P8.07           out
> STOPin                P8.09           in
> XLIM          P8.10           in
> X_Dir         P8.11           out
> X_Step                P8.12           out
> PWM0/SPINDLE P8.13            out
> YLIM          P8.14           in
> Y_Dir         P8.15           out
> Y_Step                P8.16           out
> ZLIM          P8.18           in
> PWM1          P8.19           out
> PWM2          P9.14           out
> Z_Step                P9.15           out
> Z_Dir         P9.23           out
> #SCS          P9.17           out
> #SDI          P9.18           in
> #SDO          P9.21           out
> #SCK          P9.22           out
> A_Dir         P9.13           out
> A_Step                P9.11           out
>
> > -----Original Message-----
> > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > Sent: October-09-17 9:36 AM
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] MachineKit on the BeagleBone Black
> >
> > On Monday 09 October 2017 11:45:58 Nicklas Karlsson wrote:
> > > > > There ARM M is tiny and dirt cheap and is very good for
> > > > > real-time work.  I have a robot with four motors and encoders
> > > > > and get 44,000 interrupts per second
> > > > > and much better real time latencies then from any Linux based
> > > > > solution on any platform.
> > > > >
> > > > > My solution for robot control is a hierarchy with ARM M for
> > > > > the lowest level, then
> > > > > Raspberry Pi 3 connected by high speed serial.
> > >
> > > Right now I am at this point with high speed serial communication
> > > to ARM for the lowest level.
> > >
> > > > I did succeed in building a fully rt-preempt 4.9 kernel on it
> > > > today, took about 4 hours, but I've not yet attempted to boot it
> > > > as I saw some stuff go by during the build (when I wasn't
> > > > checking my eyelids for leaks :) that I yet need to turn off.  I
> > > > think, other than fine tuning the kernel build, that convincing
> > > > the hm2_rpspi driver that it should run on the rock's rk3328,
> > > > arm64 quad core SoC, running at up to 1.5GHz should be the last
> > > > major hurdle to making linuxcnc run on it, ...
> > >
> > > Happen to know how many SPI ports there may be?
> >
> > This driver that Bertho Stultans wrote, can do 5. Over 2 pin groups
> > IIRC. However since I was the lab rat, only the SPI1 set has been
> > extensively tested.
> >
> > From the bottom of the pi's 7i90-axis.ini file:
> > [HOSTMOT2]
> > DRIVER                          =       hm2_rpspi
> > BOARD                           =       7i90
> > CONFIG  =       "num_encoders=4 num_pwmgens=2 num_stepgens=4"
> > -----------------------------
> > and from the top of the .hal file:
> > # hostmot2 driver
> > loadrt hostmot2
> >
> > # load low-level driver
> > loadrt  [HOSTMOT2](DRIVER) config=[HOSTMOT2](CONFIG)
> > spiclk_rate=41666 spiclk_rate_rd=25000
> > -----------
> > The above is all one line
> > the "rates" are the write, and read, clock rates, corresponding IIRC
> > to a 41 megabaud write to the 7i90 rate, and a slower 25 megabaud
> > rate for reading back the data from the 7i90.
> >
> > Both of those rates could probably be improved with stronger, as in
> > faster rise and fall times in the pi's pin drivers, they are a tad
> > puny.
> >
> > The interconnect cable between the pi and the 7i90 is only about an
> > inch long, achieved by mounting the pi upside down on 1" tall nylon
> > standoffs and the header connections aligned with the 26 pin socket
> > on the 7i90. Just in case, an old video card fan is mounted under
> > the pi, running on the pi's 5 volt supply.
> >
> > The 7i90 is the bottom of the stack in that box as there's 3
> > 7i42TA's stacked over the 7i90, between the 7i90 and the real world.
> >  Stops all that noise & overvoltage BS that blew several 7i90's by
> > the time I understood that I just couldn't put it in the same box
> > with the stepper & vfd stuffs. In a separate box, the noise is quite
> > low, and not sufficient to effect operations in any way.
> >
> > > Regards Nicklas Karlsson
> >
> > Cheers Nicklas, 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>
>
> ----------------------------------------------------------------------
>------ --
>
> > 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
>
> ----------------------------------------------------------------------
>-------- 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


LCNC on Rock64Cheers, 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>

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

Reply via email to