steves_logging is now known as steve_stallings
I have been sort of following a project called USB4RT. It aims to provide USB services that work with RTAI, but seems to use an abstraction layer called RTDM. Anyone know more about USB4RT or RTDM?
I remember someone mentioned it on one of the emc lists, but I don't know anything about it
[13:20:03] <steve_stallings> http://developer.berlios.de/projects/usb4rt/
Seems from the mailing list that it may be still alive... 8-)
They mention using RTDM as an abstraction layer into the RTOS.
Was wondering if RTDM was a known standard for use with RTAI. My seach on RTDM has too many hits to analyze.
RTDM (Real Time Driver Model)
Ahhh, found something meaningful. RTDM = real time driver model. See: http://www.captain.at/rtai-rtdm-serial-port-example.php
steve_stallings: it seems to me RTDM is xenomai specific
So RTDM and the abstraction used by EMC2 are not quite equavilent.
xenomai ?? kernal version ??
no, xenomai is another RT OS
it was part of RTAI as a branch initially, but the parted
it was called RTAI/fusion initially
steve_stallings: no, not equivalent
"RTDM has been merged into Xenomai (former RTAI/fusion branch) on 2005-07-20 and comes with official releases since 2.0 (actually, since fusion-0.9). There is currently ongoing work to integrate it in RTAI as well (upcoming release 3.3). The RTDM layer for Xenomai is implemented as a skin. Xenomai also comes with a full-featured serial devices driver for RTDM (see 16550A in the drivers directory). Further information can be found in the API documenat
steve_stallings: by the first looks at it, it's not really usefull for emc2 :)
Not even if emc2 wants to talk to USB devices?
That is talk to USB devices in real time...
not usefull for emc2 drivers
it's usefull for traditional drivers (like serial. USB, ethernet, etc)
so it's only partly interesting for emc2 (to be used as an existing medium), but not something to integrate into emc2
OK, I need a roadmap. There was recently talk of adding ethernet via RT-Net interfaced to HAL. I am hoping for similar for USB.
steve_stallings: it's easy to add a new interface
the problem with interfaces is that you need some protocol
Like ethernet, USB will require non-network, standalone message handling.
and parts talking the same language :)
for RT-Net, there will be 2 HAL modules talking to each other over the RT-net
each one on a different PC
thus linking 2 HAL's together
USB hardware is quite complicated, more so than ethernet, and I was hoping to have that hard part done already.
It will also have the same issue as the parallel port. The OS will have to not use the USB so as to not interfere with real time.
probably you need to deactivate a full controller (more than one port)
and that would be a bummer if keyboard and mouse were USB
usually there are 2-3 controllers in one PC
in a modern one at least
but what are you trying to accomplish?
why do you need RT USB?
external stepper/servo interface for slotless PC or laptop use
I can see that.. but why RT?
you won't get packets faster than 1msec I think, but for a servo loop that's enough
depends, RT needed if PID remains in PC, maybe not if PC sends splines to external
USB would be limited to 500 Hz PID is everything works right using ISO mode
500 Hz may be ok for "hobby" use but serious machines are already using 2K and above
right, so that means PID on the device, and only canon calls through the USB
that is one way to skin the cat 8-)
but I don't see that needing RT USB, it can go through normal USB
as it is now, you could probably connect the G101 to emc through a stadard USB
yes, normal USB is fast enough for canon calls, but now device has to support a much more comples command set
and the interface to canon calls does not yet pass thru HAL does it?
no, and it will probably never do
will I can say the same for NML, not going to be implemented in any external device that I feel like tackling
that is probably a bit too much overhead I agree
although a small ARM board with linux on it might be great
we were seriously considering ARM, but at the chip level inside our device
running Linux, even embedded, is more that I had in mind though
steve_stallings: you can always use a 'simple' OS with net support
the ARM version of NutOS might be ok, like BSD vs. GNU license for this case, need to see if using free NutOS without buying hardware is ok
well.... it looks like the ARM stuff is still beta....
oops, time to hide, the AVR lover is here....
nope, pushing ARM this time 8-P
hey - thanks for that lathe pointer - the machines are sweeeet!
do PICs have uarts yet?
the PIC doesn't have a functional carry bit
but they do have UARTS
I've waded through bit-banging pic code one too many times
some PIC have UARTs and even other magic things, but they remain strange beasts
I'd go with the Atmel AT91RM7X128 or 256 for ARMs
can you program modern pics with gcc now?
still easier to use than Lab View (bait !!!)
at least you can tellwhat a PIC is doing
oops - AT91SAM7X128/256
like ARM because of advanced hardware support for trace using Keil IDE/debugger
I think that's what I'll base my G-Rex CPU module on
SAM7 is sweet
my devkit should have been here by now :(
it even has DMA ;)
I also like the looks of the AVR32, but it's a bit expensive compared to the ARMs
ST and Philips also do some real nice ARM stuff
the SAM7x is pretty amazing - $12 in single quantity, and it has USB2, 10/100 ethernet, and a lot of other stuff (such as 128k flash)
shame that SAM7 and the ST device include the MAC but not the PHY
yeah - just about nobody includes the PHY
cradek, that's why I like it for a motion controller :)
PHY is almost as big and expensive as the CPU
or the AVR32, which also has ethernet (dual, actually), plus an LCD controller (2kx2k max resolution)
but it's $25 or so
hmmm - the cheapest PHY I can find (at digikey) is $4.73 in singles, $2.74/100, made by NS (and a 48-LQFP ;) )
[14:50:28] <alex_joni> http://oss.kernelconcepts.de/maemo/
<- that's nice ;)
hmmm - wlan, bluetooth and USB2 device connectivity
The processor in the device is a 220-MHz, ARM9-based Texas Instruments (TI) OMAP 1710.
no RT capable interfaces ;)
there is RTAI for ARM
RTAI supports several architectures:
x86 (with and without FPU and TSC)
ARM (StrongARM; ARM7: clps711x-family, Cirrus Logic EP7xxx, CS89712, PXA25x)
RTAI for welan, bluetooth, or USB2 would be the issue ;)
wlan, that is
hmmm - $359.99
a bit much ;)
I agree (though it is nice and small)
I like this one better: http://www.olimex.com/dev/sam7-ex256.html
the display isn't quite as nice ;)
the price is right though
SAM7-EX256 development board with AT91SAM7X256, LCD, Audio, CAN, USB, Ethernet 10/100 USD $115.95
I like this one better: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3918
but the price is worse ;)
but you can get it from DigiKey for $544
dual ethernet, QVGA display, 256M SD card, and Linux devkit :)
plus a binch of other stuff
still kinda much
you can get 2 PC's for that money
or a good one + display
I may need to make a 12-camera synchronizer this week. I'm toying with the idea of using a smallPC and HAL
small PC, that is
I'd like 10-microsecond accuracy, bit I think I could get away with 100 microseconds
you can do 10 usec easily
how do you want to output the stuff ?
I'd think so. it's just two byte reads and two byte writes, plus a very little math
read/write from where?
parport or MESA card
I need 24 I/Os for the cameras, plus one or two for other stuff (like a trigger)
so either 2-3 parports
or a MESA
parport sounds way cheaper ;)
and MESA may have output modules that can trigger cameras as well (though a parport may be able to do it also)
"relay racks" :)
but very small ones - just transistors
actually, the mesa card would be ideal anyway, since it could do all the timin gitself, with an appropriate FPGA core
steve_stallings is now known as steves_logging
well I'm back .. what did I miss?
err - microcontroller discussions
I see a bit of that in my scrollback
I missed anything else before that
(I actually left this computer off for the night, for the first time in a long time)
the real gasp part is that this is a Windows 2000 machine, and I usually leave it on ;)
back from the trip?
nice, you've been missed :D
have I really?
so I heard ;)
how was it?
oh it was fine
and because they bumped us from our flight last night we now have a pair of free round-trip tickets, so we get to think about our next trip already
oh.. sweet.. whereto?
I want to go back to new mexico to see the sandhill cranes this winter
oh, any location basicly?
or limited to US ?
you guys around?
I am, but leaving really soon
same here.. just wanted to remind us of the upcoming release ;)
wanted to know what others think of the schedule?
I'm looking at http://sourceforge.net/pm/task.php?group_project_id=46285&group_id=6744&func=browse
I don't want to think about it right now...
quick question: to create the /dev/rtf nodes, is the command mknod -c 150 3 /dev/rtf3 ?
without the -
ah - thanks
I just installed dapper on my opteron, with emc2 and the magma kernel (it's a 32-bit install)
SWPadnos: it's also in the wiki
SWPadnos: any issues?
wanted to run the testsuite stuff
I mean any problems so far?
during the install..
only getting the nvidia driver to work, but it actually seems to work now (dual screen and all)
it might cause big problems with RT though
that's what I wanted to check :)
I use nvidia too, ok as long as you don't run a machine
it'll be bad, trust me
I'll take a look with the testsuite, then with a scope
run some opengl stuff and watch it suck
mknod says "invalid device type '150'"
mknod /dev/rtf3 c 150 3
* cradek gently urges SWP toward the man page
duh - i kant reed!
that's better - thanks
[21:21:57] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting
wow, are those numbers small!
just wait :-)
I have to run, might be back in a few hours
cradek: see you ..
cradek: maybe you get around at putting those debs in the repo?
when I ran glxgears, I got one sample at 199000 or so
with it running (at 13400 fps), I get 8000-9000 consistently
one should be enough they say :D
well - the idea there is "don't start 3D apps when a machine is running" ;)
I'm sure the numbers will suck if I maximize glxgears though :)
I happen to know of a nicer emc GUI, but it uses 3D :)
somehow I don't think axis would bog this machine down much :)
unless I load a multi-megabyte NC file
with glxgears maximized, the latencies were still averaging ~3000
the user test is a little worse, ~3300 average (with glxgears at 1920x1200 on one screen)
durr - there seems to be no realtime script (at least not in the path)
should I be reading a manual again? :)
try /etc/init.d/realtime start ;)
good night all