Kirk Wallace wrote: > That's one of my problems. I only know enough to create a component that > fits in a realtime thread. (Dangerous is my middle name.)
User components are actually easier. You create pins and parameters exactly the same as for a realtime component, but then you skip the function export step, and just drop right into doing whatever your component does. You need to install a signal handler for shutdown - most user space components run until killed. > >> Realtime HAL components export functions, and those functions are linked >> into realtime thresds. Each function in a HAL thread runs one after >> another, and all of them _must_ be complete before the next time the >> thread is due to run. Reading this after I sent it, I realized that I didn't go into the list of things that you can't do in a realtime component. Basically, you can't do anything that might block, and you can't use most of the standard library functions. >> Non-realtime HAL components do not export functions. A non-realtime HAL >> component is an ordinary Linux process. It has its own memory space and >> runs just like any other user space program. It has no restrictions >> about calling blocking functions. It can use read(2) and write(2) to >> access files (including /dev files). It can use select(2) with or >> without timeouts. It can use sleep(3) if it wants to poll HAL pins >> periodically. And it can use normal Linux drivers for things like the >> serial port. Such a component will _usually_ be quite responsive, but >> response times are not guaranteed. > > I need to learn more about non-realtime. It has been a while since I > have read the documentation, it might be a good time to go through it > again. > >> Spindle control was mentioned as a use case - that would be fine for >> normal milling, but I wound not use it for rigid tapping. EMC issues a >> command to reverse the spindle as the tap approaches the bottom of the >> hole. A user space HAL component would probably send that command to >> the spindle drive quickly 99% of the time, but it only takes one time >> with a half-second delay to break a tap. > > So maybe having my component inserted to an RT thread isn't a bad thing? > If it works it must be timely? The problem with Modbus in realtime is that your component needs to interact with the hardware without Linux's help. In userspace, you can just use the normal Linux serial port driver, by way of /dev/serial or something along those lines. That isn't available when you are writing a realtime component. You basically have to talk to the UART directly, which can be tricky when you don't know anything about the UART. Things like USB-to-serial converters are completely useless from realtime, but perfectly acceptable in user space (if Linux understands it, a user space HAL component can use it). Regards, John Kasunich ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
