On 21-11-2012 19:45, Michael Haberler wrote: > 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.
Michael, I didn't read over that line at all, I was referring to the "€35 CNC platform". Seems rather penny wise, pound foolish to me. >> 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;) Yeah, so development is dead. And IMHO it has been for a long time. Of course that doesn't mean you can't use it, but not with recent or future hardware. I think it's time to work on a next generation instead of spending all effort on keeping the current generation in the air. > 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. Exactly, I'm well aware of that. And as I said, I've been hoping/waiting for a while for that to happen. > ---- > > 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? The AM335X has the A8 ARM code, but also two PRU units, rather simple processors, running at 200 MHz, no pipe-lining, one clock - one instruction, 32-bit. Good for predictable timing. uio_pruss is a very simple kernel module to access the PRUs (basicly it exports the memory maps and allows some interrupt generation). A PRU is indeed programmed in assembly. The resulting binary firmware blob must be loaded into the PRU's program memory before use. > > > 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) Depends on your definition of 'interesting', but it's no secret that the code for the PRU processor is not on GitHub. Nor are the schematics of the BeBoPr available online. For the moment I think that publishing this information will not benefit the project. > 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. I'm not sure I understand what you're saying. The touchy community bit I understand: Since I introduced the loadable kernel modules in the Linux kernel in the early nineties (kernel 0.98?) there have been discussions about pros and cons of binary-only modules. But everybody is using not open sourced parts in their system: Are there people who refuse to work with a system because the BIOS is not open source? Probably not. Has anyone seen complaints about the lack of availability of the VHDL design of e.g. a network chip? I haven't! Furthermore: A PRU is a separate processor, connected via busses with the ARM A8 core of the BeagleBone. The code that runs on a PRU has no relationship with Linux at all. There's no linking, no library issues, whatever. And if I would abandon this project, there will be another smart guy who writes a better stepper driver for the PRU. Or another one who doesn't mind copyrights or similar issues and disassembles my code to be able to make changes. Or maybe someone will write code to emulate an ECP or EPP for a cape with a parallel port, allowing old hardware to be interfaced. I've been using FPGAs for this purpose, but for me the PRU is something between an FPGA with softcore and a classic software solution. > >> 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. I'll look into this when time permits. But there's a huge gap between getting the code to compile and a reliable system. I've been experimenting with a RT_PREEMPT kernel on the bone a while back, but that would fail eventually. > > 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. There are lot of other things for me to do, that's why I was looking for a volunteer (with stamina) : ) > > 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. I'm not the right person to answer that question, I'm not interested in the package of the day ; ) Maybe you could ask on comp.hardware.beagleboard.user or one of the other lists. -- Bas > > - 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 ------------------------------------------------------------------------------ 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
