Bas, Am 21.11.2012 um 18:49 schrieb Bas Laarhoven:
> On 20-11-2012 20:54, Michael Haberler wrote: >> I dont want to curb your hopes too much, but I said 'GladeVCP+HAL standalone >> applications' and meant to say 'HAL only' - i.e. no Gcode, no task, no >> motion - more loudly >> >> that works and I can recommend looking into especially if the application >> isnt very time critical (I get something like 45uS latency on the Pi with >> xenomai) >> >> I do use the Pi as an exemplary platform to test configure and build; I dont >> expect to use it for CNC purposes myself and I'm not investing effort >> >> dont waste too much time on seeing a Pi as €35 CNC platform just yet - it's >> pushing the limits (gut feeling, without having tried I'd say this is >> outside the Pi's capabilities, and the I/O interfacing capabilities arent >> that plush) >> >> I'd rather look into a BeagleBone or so for real I/O; still soft stepping is >> a bit meager on ARM's without resorting to tricks like Sergey did in >> miniemc2 - which is btw worth picking up, but not necessarily by me ;) in >> case of the BeagleBone it would mean 'program the RT hard stuff in the extra >> 'realtime RISC cores' which doesnt look like a weekend project either >> >> -m >> > > Michael, > Now you've got me interested! Not in the Pi part (that hype will probably > pass [let's start a good old flame war ; ) ]) but the BeagleBone part. I keep repeating.. this is a compile & unit test platform for me because 'its there'.. folks just read over this line. Aint no use. > If you look at my BeBoPr project (https://github.com/modmaker/BeBoPr), it's > doing what you suggest here: The hard real-time stuff (step generation) is > running on one of the PRU coprocessors and Linux is doing the non-real-time > stuff. In fact I think my stepper code is doing more than is needed for > LinuxCNC, but maybe some features are still missing. I haven't spent much > time investigating the possibility of running EMC on the BeagleBone, but it > has been one of the things on my todo list. The biggest obstacle until now > has been finding a proper real-time kernel. I've been waiting for a long time > for a Xenomai based kernel, and now that RTAI is (finally) declared dead, the > time might be right to jump the bandwagon ; ) re RTAI: well surely I'm not declaring RTAI dead and the integration branch of course continues to support it, everything else would be mad. RTAI will continue to run parport steppers as long as motherboards with same can be salvaged from Halted Specialities or other well-stocked junkyard sales;) the problem is more with RTAI directly its platform lock-in and some questionmarks on its future; overall it is more the fact that kernel-threads based RT Linux is heading for extinction as an architecture to start with, and I just cannot see how RTAI fits in when RT_PREEMPT hits mainline and Xenomai 3 folds into it. It's likely to be out on a limb. So its time to act on parallel alternatives, and that's what you're seeing. ---- what I'd be more interested in: give us a architecture rundown of your application; is the 'uio_pruss' this PRU stepper thing (where is that?) Assembly code? how does motion, trajectory planning, step generation fit together? what is the timing source for stepping? (I appreciate the code on github but somehow I feel theres something very interesting missing there) how do we have to read 'A license for the coprocessor code comes with the board.'? This community is a bit touchy on such issues, and the website is less than helpful on it. last time I checked manufacturers where happy if you just bought and used their hardware but that might have changed. > > As I'm interested in LinuxCNC myself (I've been using it for a while, years > back), I might volunteer for the PRUSS code once a working Xenomai based ARM > Linux kernel and EMC2 port is available. > Writing and debugging PRU assembly is not always fun and certainly not a > weekend project, but I've been doing it for longer than I dare to say, and > can re-use a lot. > > So, any volunteers (with stamina) for the Linux part? I would think Xenomai for the BeagleBone does work, see this thread: http://www.xenomai.org/pipermail/xenomai/2012-July/000496.html - maybe contact Stephan for the full story. If you really get Xenomai up on this board, I'd be interested in keeping a matching corresponding source tree in my repo; you never know.. maybe I should buy one of these to play with them. What is actually the status on a debian/ubuntu like package stream for this board? I mean the kernel is one story, but then there's whole lot of other packages required; I'm kinda loosing track what is running where on the board of the week. - Michael > > -- Bas > >> >> Am 20.11.2012 um 17:40 schrieb Anders Wallin: >> >>> Good news! >>> I've ordered a Pi (Farnell re-directs to a local distributor), but the >>> delivery-time seems to be 3 weeks right now(?) >>> >>> It seems that the SPI interface will be most useful for high-speed IO. If I >>> understood correctly the Pi supports only two separate chips on the >>> SPI-bus, but on IRC PCW mentioned that SPI is possible on the GPIO-pins >>> also? For a servo-controlled machine I guess a microcontroller and/or FPGA >>> on the SPI bus could read encoders, output PWM, and do IO. One would then >>> need a HAL-driver that is capable of communicating the relevant data over >>> SPI every servo period (1ms or so). Do you think this HAL2SPI driver will >>> be easy or hard to write? >>> What about stepper-machines? Is it enough to communicate a stepper velocity >>> over SPI to dedicated step-generation hardware? >>> >>> In addition to cnc use I'm also interested in stand-alone operation with a >>> touch-screen, for example this one (HDMI display, USB touchscreen): >>> http://www.lilliputuk.com/monitors/open-frame/of701-2/ >>> >>> Something that boots directly into a Touchy-like custom UI-panel and can >>> set/watch/plot/etc. HAL-signals would be really nice. >>> >>> Anders >>> >>> On Tue, Nov 20, 2012 at 4:47 PM, Michael Haberler <mai...@mah.priv.at> >>> wrote: >>> I just verified this combination works, for the standard Raspberry Raspbian >>> kernel 3.2.27+ with Posix threads (aka 'simulator'), and with Xenomai >>> 3.2.21 for somewhat better performance >>> >>> both remote X Display and local console work >>> >>> this is the rtos-integration-preview1 branch; the only part needed >>> disabling was the GladeVCP sourceview widget which is lacking the >>> underlying modules >>> >>> currently the only hardware driver supported is hal_gpio for wiggling some >>> pins; the serial, i2c and SPI interfaces would be possible further >>> candidates, mungkie did some initial work on these >>> >>> >>> I'll see whether I can come up with an SD card image ready to go with all >>> the parts (xenomai + userland support + linuxcnc prerequisites + linuxcnc >>> built) >>> >>> Axis, touchy and friends are still untested >>> >>> >>> - Michael >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
