[−][src]Crate linuxcnc_hal_sys
Structs
Constants
Statics
| _sys_siglist | |
| sys_siglist |
Functions
| __errno_location⚠ | |
| __libc_current_sigrtmax⚠ | |
| __libc_current_sigrtmin⚠ | |
| __sched_cpualloc⚠ | |
| __sched_cpucount⚠ | |
| __sched_cpufree⚠ | |
| __sysv_signal⚠ | |
| gnu_dev_major⚠ | |
| gnu_dev_makedev⚠ | |
| gnu_dev_minor⚠ | |
| gsignal⚠ | |
| hal_add_funct_to_thread⚠ | hal_add_funct_to_thread() adds a function exported by a realtime HAL component to a realtime thread. This determines how often and in what order functions are executed. 'funct_name' is the name of the function, as specified in a call to hal_export_funct(). 'thread_name' is the name of the thread to which the function should be added. When the thread runs, the functions will be executed in the order in which they were added to the thread. 'position' is the desired location within the thread. This determines when the function will run, in relation to other functions in the thread. A positive number indicates the desired location as measured from the beginning of the thread, and a negative is measured from the end. So +1 means this function will become the first one to run, +5 means it will be the fifth one to run, -2 means it will be next to last, and -1 means it will be last. Zero is illegal. Returns 0, or a negative error code. Call only from within user space or init code, not from realtime code. |
| hal_comp_name⚠ | hal_comp_name() returns the name of the given component, or NULL if comp_id is not a loaded component |
| hal_del_funct_from_thread⚠ | hal_del_funct_from_thread() removes a function from a thread. 'funct_name' is the name of the function, as specified in a call to hal_export_funct(). 'thread_name' is the name of a thread which currently calls the function. Returns 0, or a negative error code. Call only from within user space or init code, not from realtime code. |
| hal_exit⚠ | 'hal_exit()' must be called before a HAL component exits, to free resources associated with the component. 'comp_id' is the ID of the component as returned from its initial call to 'hal_init()'. 'hal_exit()' will remove the component's realtime functions (if any) from realtime threads. It also removes all pins and parameters exported by the component. If the component created any threads, when it exits all threads will be stopped, and the ones it created will be deleted. It is assumed that the system will no longer function correctly after a component is removed, but this cleanup will prevent crashes when the component's code and data is unmapped. 'hal_exit()' calls 'rtapi_exit()', so any rtapi reaources allocated should be discarded before calling hal_exit(), and rtapi functios should not be called afterwards. On success, hal_exit() returns 0, on failure it returns a negative error code. |
| hal_get_lock⚠ | The 'hal_get_lock()' function returns the current locking level locking types defined in hal.h HAL_LOCK_NONE -locks none HAL_LOCK_* - intermediate locking levels HAL_LOCK_ALL - locks everything |
| hal_init⚠ | 'hal_init()' is called by a HAL component before any other hal function is called, to open the HAL shared memory block and do other initialization. 'name' is the name of the component. It must be unique in the system. It must be no longer than HAL_NAME_LEN. On success, hal_init() returns a positive integer component ID, which is used for subsequent calls to hal_xxx_new() and hal_exit(). On failure, returns an error code (see above). 'hal_init()' calls rtapi_init(), so after calling hal_init(), a component can use any rtapi functions. The component ID returned by 'hal_init()' is also the RTAPI module ID for the associated module, and can be used when calling rtapi functions. Call only from within user space or init/cleanup code, not from realtime code. |
| hal_link⚠ | 'hal_link()' links a pin to a signal. 'pin_name' and 'sig_name' are strings containing the pin and signal names. If the pin is already linked to the desired signal, the command succeeds. If the pin is already linked to some other signal, it is an error. In either case, the existing connection is not modified. (Use 'hal_unlink' to break an existing connection.) If the signal already has other pins linked to it, they are unaffected - one signal can be linked to many pins, but a pin can be linked to only one signal. On success, hal_link() returns 0, on failure it returns a negative error code. |
| hal_malloc⚠ | hal_malloc() allocates a block of memory from the main HAL shared memory area. It should be used by all components to allocate memory for HAL pins and parameters. It allocates 'size' bytes, and returns a pointer to the allocated space, or NULL (0) on error. The returned pointer will be properly aligned for any variable HAL supports (see HAL_TYPE below.) The allocator is very simple, and there is no 'free'. It is assumed that a component will allocate all the memory it needs during initialization. The entire HAL shared memory area is freed when the last component calls hal_exit(). This means that if you continuously install and remove one component while other components are present, you eventually will fill up the shared memory and an install will fail. Removing all components completely clears memory and you start fresh. |
| hal_param_alias⚠ | 'hal_param_alias()' assigns an alternate name, aka an alias, to a parameter. Once assigned, the parameter can be referred to by either its original name or the alias. Calling this function with 'alias' set to NULL will remove any existing alias. |
| hal_param_bit_new⚠ | The 'hal_param_xxx_new()' functions create a new 'parameter' object. A parameter is a value that is only used inside a component, but may need to be initialized or adjusted from outside the component to set up the system properly. Once a parameter has been created, it's value can be changed using the 'hal_param_xxx_set()' functions. There are eight functions, one for each of the data types that the HAL supports. Pins may only be linked to signals of the same type. 'name' is the name of the new parameter. It must be no longer than .HAL_NAME_LEN. If there is already a parameter with the same name the call will fail. 'dir' is the parameter direction. HAL_RO parameters are read only from outside, and are written to by the component itself, typically to provide a view "into" the component for testing or troubleshooting. HAL_RW parameters are writable from outside and also sometimes modified by the component itself as well. 'data_addr' is the address where the value of the parameter is to be stored. 'data_addr' must point to memory allocated by hal_malloc(). Typically the component allocates space for a data structure with hal_malloc(), and 'data_addr' is the address of a member of that structure. Creating the paremeter does not initialize or modify the value at *data_addr - the component should load a reasonable default value. 'comp_id' is the ID of the component that will 'own' the parameter. Normally it should be the ID of the caller, but in some cases, a user mode component may be doing setup for a realtime component, so the ID should be that of the realtime component that will actually be using the parameter. If successful, the hal_param_xxx_new() functions return 0. On failure they return a negative error code. |
| hal_param_bit_newf⚠ | printf_style-style versions of hal_param_XXX_new |
| hal_param_bit_set⚠ | The 'hal_param_xxx_set()' functions modify the value of a parameter. 'name' is the name of the parameter that is to be set. The parameter type must match the function type, and the parameter must not be read-only. 'value' is the value to be loaded into the parameter. On success, the hal_param_xxx_set() functions return 0, and on failure they return a negative error code. |
| hal_param_float_new⚠ | |
| hal_param_float_newf⚠ | |
| hal_param_float_set⚠ | |
| hal_param_new⚠ | 'hal_param_new()' creates a new 'parameter' object. It is a generic version of the eight functions above. It is provided ONLY for those special cases where a generic function is needed. It is STRONGLY recommended that the functions above be used instead, because they check the type of 'data_addr' against the parameter type at compile time. Using this function requires a cast of the 'data_addr' argument that defeats type checking and can cause subtle bugs. 'name', 'data_addr' and 'comp_id' are the same as in the functions above. 'type' is the hal type of the new parameter - the type of data that will be stored in the parameter. 'dir' is the parameter direction. HAL_RO parameters are read only from outside, and are written to by the component itself, typically to provide a view "into" the component for testing or troubleshooting. HAL_RW parameters are writable from outside and also sometimes modified by the component itself as well. If successful, hal_param_new() returns 0. On failure it returns a negative error code. |
| hal_param_s32_new⚠ | |
| hal_param_s32_newf⚠ | |
| hal_param_s32_set⚠ | |
| hal_param_set⚠ | 'hal_param_set()' is a generic function that sets the value of a parameter. It is provided ONLY for those special cases where a generic function is needed. It is STRONGLY recommended that the functions above be used instead, because they are simpler and less prone to errors. 'name', is the same as in the functions above. 'type' is the hal type of the the data at *value_addr, and must match the type of the parameter. The parameter must not be read only. 'value_addr' is a pointer to the new value of the parameter. The data at that location will be interpreted according to the type of the parameter. If successful, hal_param_set() returns 0. On failure it returns a negative error code. |
| hal_param_u32_new⚠ | |
| hal_param_u32_newf⚠ | |
| hal_param_u32_set⚠ | |
| hal_pin_alias⚠ | 'hal_pin_alias()' assigns an alternate name, aka an alias, to a pin. Once assigned, the pin can be referred to by either its original name or the alias. Calling this function with 'alias' set to NULL will remove any existing alias. |
| hal_pin_bit_new⚠ | The 'hal_pin_xxx_new()' functions create a new 'pin' object. Once a pin has been created, it can be linked to a signal object using hal_link(). A pin contains a pointer, and the component that owns the pin can dereference the pointer to access whatever signal is linked to the pin. (If no signal is linked, it points to a dummy signal.) There are eight functions, one for each of the data types that the HAL supports. Pins may only be linked to signals of the same type. 'name' is the name of the new pin. It must be no longer than HAL_NAME_LEN. If there is already a pin with the same name the call will fail. 'dir' is the pin direction. It indicates whether the pin is an input or output from the component. 'data_ptr_addr' is the address of the pointer that the component will use for the pin. When the pin is linked to a signal, the pointer at 'data_ptr_addr' will be changed to point to the signal data location. 'data_ptr_addr' must point to memory allocated by hal_malloc(). Typically the component allocates space for a data structure with hal_malloc(), and 'data_ptr_addr' is the address of a member of that structure. 'comp_id' is the ID of the component that will 'own' the variable. Normally it should be the ID of the caller, but in some cases, a user mode component may be doing setup for a realtime component, so the ID should be that of the realtime component that will actually be using the pin. If successful, the hal_pin_xxx_new() functions return 0. On failure they return a negative error code. |
| hal_pin_bit_newf⚠ | The hal_pin_XXX_newf family of functions are similar to hal_pin_XXX_new except that they also do printf-style formatting to compute the pin name If successful, the hal_pin_xxx_newf() functions return 0. On failure they return a negative error code. |
| hal_pin_float_new⚠ | |
| hal_pin_float_newf⚠ | |
| hal_pin_new⚠ | 'hal_pin_new()' creates a new 'pin' object. It is a generic version of the eight functions above. It is provided ONLY for those special cases where a generic function is needed. It is STRONGLY recommended that the functions above be used instead, because they check the type of 'data_ptr_addr' against the pin type at compile time. Using this function requires a cast of the 'data_ptr_addr' argument that defeats type checking and can cause subtle bugs. 'name', 'dir', 'data_ptr_addr' and 'comp_id' are the same as in the functions above. 'type' is the hal type of the new pin - the type of data that will be passed in/out of the component through the new pin. If successful, hal_pin_new() returns 0. On failure it returns a negative error code. |
| hal_pin_port_new⚠ | |
| hal_pin_port_newf⚠ | |
| hal_pin_s32_new⚠ | |
| hal_pin_s32_newf⚠ | |
| hal_pin_u32_new⚠ | |
| hal_pin_u32_newf⚠ | |
| hal_port_buffer_size⚠ | hal_port_buffer_size returns the total number of bytes that a port can buffer |
| hal_port_clear⚠ | hal_port_clear emptys a given port of all data without consuming any of it. hal_port_clear should only be called by a reader |
| hal_port_peek⚠ | hal_port_peek operates the same as hal_port_read but no bytes are consumed from the input port. Repeated calls to hal_port_peek will return the same data. This function should only be called by the component that owns the IN PORT pin. returns true: count bytes were read into dest false: no bytes were read into dest |
| hal_port_peek_commit⚠ | hal_port_peek_commit advances the read position in the port buffer by count bytes. A hal_port_peek followed by a hal_port_peek_commit with the same count value would function equivalently to hal_port_read given the same count value. This function should only be called by the component that owns the IN PORT pin. returns: true: count readable bytes were skipped and are no longer accessible false: no bytes wer skipped |
| hal_port_read⚠ | hal_port_read reads count bytes from the port into dest. This function should only be called by the component that owns the IN PORT pin. returns true: count bytes were read into dest false: no bytes were read into dest |
| hal_port_readable⚠ | hal_port_readable returns the number of bytes available for reading from the port. |
| hal_port_wait_readable⚠ | hal_port_wait_readable spin waits on a port until it has at least count bytes available for reading, or *stop > 0 |
| hal_port_wait_writable⚠ | hal_port_wait_writable spin waits on a port until it has at least count bytes available for writing or *stop > 0 |
| hal_port_writable⚠ | hal_port_writable returns the number of bytes that can be written into the port |
| hal_port_write⚠ | hal_port_write writes count bytes from src into the port. This function should only be called by the component that owns the OUT PORT pin. returns: true: count bytes were written false: no bytes were written into dest |
| hal_ready⚠ | hal_ready() indicates that this component is ready. This allows halcmd 'loadusr -W hal_example' to wait until the userspace component 'hal_example' is ready before continuing. |
| hal_set_constructor⚠ | hal_set_constructor() sets the constructor function for this component |
| hal_set_lock⚠ | "LOCKING" FUNCTIONS * locking types defined in hal.h HAL_LOCK_NONE -locks none HAL_LOCK_* - intermediate locking levels HAL_LOCK_ALL - locks everything |
| hal_signal_delete⚠ | 'hal_signal_delete()' deletes a signal object. Any pins linked to the object are unlinked. 'name' is the name of the signal to be deleted. If successful, 'hal_signal_delete()' returns 0. On failure, it returns a negative error code. |
| hal_signal_new⚠ | 'hal_signal_new()' creates a new signal object. Once a signal has been created, pins can be linked to it with hal_link(). The signal object contains the actual storage for the signal data. Pin objects linked to the signal have pointers that point to the data. 'name' is the name of the new signal. It must be no longer than HAL_NAME_LEN. If there is already a signal with the same name the call will fail. 'type' is the data type handled by the signal. Pins can only be linked to a signal of the same type. Note that the actual address of the data storage for the signal is not accessible. The data can be accessed only by linking a pin to the signal. Also note that signals, unlike pins, do not have 'owners'. Once created, a signal remains in place until either it is deleted, or the last HAL component exits. If successful, 'hal_signal_new() returns 0. On failure it returns a negative error code. |
| hal_start_threads⚠ | hal_start_threads() starts all threads that have been created. This is the point at which realtime functions start being called. On success it returns 0, on failure a negative error code. |
| hal_stop_threads⚠ | hal_stop_threads() stops all threads that were previously started by hal_start_threads(). It should be called before any component that is part of a system exits. On success it returns 0, on failure a negative error code. |
| hal_stream_attach⚠ | attach to an existing stream |
| hal_stream_create⚠ | create and attach a stream |
| hal_stream_depth⚠ | |
| hal_stream_destroy⚠ | detach and destroy an open stream |
| hal_stream_detach⚠ | detach from an open stream |
| hal_stream_element_count⚠ | stream introspection |
| hal_stream_element_type⚠ | |
| hal_stream_maxdepth⚠ | |
| hal_stream_num_overruns⚠ | |
| hal_stream_num_underruns⚠ | |
| hal_stream_read⚠ | |
| hal_stream_readable⚠ | |
| hal_stream_wait_readable⚠ | |
| hal_stream_wait_writable⚠ | |
| hal_stream_writable⚠ | |
| hal_stream_write⚠ | |
| hal_unlink⚠ | 'hal_unlink()' unlinks any signal from the specified pin. 'pin_name' is a string containing the pin name. On success, hal_unlink() returns 0, on failure it returns a negative error code. |
| imaxabs⚠ | |
| imaxdiv⚠ | |
| kill⚠ | |
| killpg⚠ | |
| posix_spawn⚠ | |
| posix_spawn_file_actions_addclose⚠ | |
| posix_spawn_file_actions_adddup2⚠ | |
| posix_spawn_file_actions_addopen⚠ | |
| posix_spawn_file_actions_destroy⚠ | |
| posix_spawn_file_actions_init⚠ | |
| posix_spawnattr_destroy⚠ | |
| posix_spawnattr_getflags⚠ | |
| posix_spawnattr_getpgroup⚠ | |
| posix_spawnattr_getschedparam⚠ | |
| posix_spawnattr_getschedpolicy⚠ | |
| posix_spawnattr_getsigdefault⚠ | |
| posix_spawnattr_getsigmask⚠ | |
| posix_spawnattr_init⚠ | |
| posix_spawnattr_setflags⚠ | |
| posix_spawnattr_setpgroup⚠ | |
| posix_spawnattr_setschedparam⚠ | |
| posix_spawnattr_setschedpolicy⚠ | |
| posix_spawnattr_setsigdefault⚠ | |
| posix_spawnattr_setsigmask⚠ | |
| posix_spawnp⚠ | |
| pselect⚠ | |
| psiginfo⚠ | |
| psignal⚠ | |
| pthread_kill⚠ | |
| pthread_sigmask⚠ | |
| raise⚠ | |
| rtapi_delay⚠ | rtapi_delay() is a simple delay. It is intended only for short delays, since it simply loops, wasting CPU cycles. 'nsec' is the desired delay, in nano-seconds. 'rtapi_delay_max() returns the max delay permitted (usually approximately 1/4 of the clock period). Any call to 'rtapi_delay()' requesting a delay longer than the max will delay for the max time only. 'rtapi_delay_max()' should be called befure using 'rtapi_delay()' to make sure the required delays can be achieved. The actual resolution of the delay may be as good as one nano-second, or as bad as a several microseconds. May be called from init/cleanup code, and from within realtime tasks. |
| rtapi_delay_max⚠ | |
| rtapi_exit⚠ | 'rtapi_exit()' shuts down and cleans up the RTAPI. It must be called prior to exit by any module that called rtapi_init. 'module_id' is the ID code returned when that module called rtapi_init(). Returns a status code. rtapi_exit() may attempt to clean up any tasks, shared memory, and other resources allocated by the module, but should not be relied on to replace proper cleanup code within the module. Call only from within user or init/cleanup code, not from realtime tasks. |
| rtapi_fifo_delete⚠ | 'rtapi_fifo_delete()' is the counterpart to 'rtapi_fifo_new()'. It closes the fifo associated with 'fifo_ID'. 'module_id' is the ID of the calling module. Returns status code. Call only from within user or init/cleanup code, not from realtime tasks. |
| rtapi_fifo_new⚠ | 'rtapi_fifo_new()' creates a realtime fifo. 'key' identifies the fifo, all modules wishing to access the same fifo must use the same key. 'module_id' is the ID of the module making the call (see rtapi_init). 'size' is the depth of the fifo. 'mode' is either 'R' or 'W', to request either read or write access to the fifo. On success, it returns a positive integer ID, which is used for subsequent calls dealing with the fifo. On failure, returns a negative error code. Call only from within user or init/cleanup code, not from realtime tasks. |
| rtapi_fifo_read⚠ | |
| rtapi_fifo_write⚠ | |
| rtapi_get_clocks⚠ | rtapi_get_clocks returns the current time in CPU clocks. It is fast, since it just reads the TSC in the CPU instead of calling a kernel or RTOS function. Of course, times measured in CPU clocks are not as convenient, but for relative measurements this works fine. Its absolute value means nothing, but it is monotonically increasing* and can be used to schedule future events, or to time the duration of some activity. (* on SMP machines, the two TSC's may get out of sync, so if a task reads the TSC, gets swapped to the other CPU, and reads again, the value may decrease. RTAPI tries to force all RT tasks to run on one CPU.) Returns a 64 bit value. The resolution of the returned value is one CPU clock, which is usually a few nanoseconds to a fraction of a nanosecond. May be called from init/cleanup code, and from within realtime tasks. |
| rtapi_get_msg_level⚠ | Retrieve the message level set by the last call to rtapi_set_msg_level |
| rtapi_get_time⚠ | rtapi_get_time returns the current time in nanoseconds. Depending on the RTOS, this may be time since boot, or time since the clock period was set, or some other time. Its absolute value means nothing, but it is monotonically increasing and can be used to schedule future events, or to time the duration of some activity. Returns a 64 bit value. The resolution of the returned value may be as good as one nano-second, or as poor as several microseconds. May be called from init/cleanup code, and from within realtime tasks. |
| rtapi_inb⚠ | 'rtapi_inb() gets a byte from 'port'. Returns the byte. May be called from init/cleanup code, and from within realtime tasks. Note: This function always returns zero on the simulated RTOS. Note: Many platforms provide an inline inb() that is faster. |
| rtapi_init⚠ | 'rtapi_init() sets up the RTAPI. It must be called by any module that intends to use the API, before any other RTAPI calls. 'modname' can optionally point to a string that identifies the module. The string will be truncated at RTAPI_NAME_LEN characters. If 'modname' is NULL, the system will assign a name. On success, returns a positive integer module ID, which is used for subsequent calls to rtapi_xxx_new, rtapi_xxx_delete, and rtapi_exit. On failure, returns an error code as defined above. Call only from within user or init/cleanup code, not from realtime tasks. |
| rtapi_is_kernelspace⚠ | |
| rtapi_is_realtime⚠ | |
| rtapi_open_as_root⚠ | |
| rtapi_outb⚠ | 'rtapi_outb() writes 'byte' to 'port'. May be called from init/cleanup code, and from within realtime tasks. Note: This function does nothing on the simulated RTOS. Note: Many platforms provide an inline outb() that is faster. |
| rtapi_print⚠ | 'rtapi_print()' prints a printf style message. Depending on the RTOS and whether the program is being compiled for user space or realtime, the message may be printed to stdout, stderr, or to a kernel message log, etc. The calling syntax and format string is similar to printf except that floating point and longlongs are NOT supported in realtime and may not be supported in user space. For some RTOS's, a 80 byte buffer is used, so the format line and arguments should not produce a line more than 80 bytes long. (The buffer is protected against overflow.) Does not block, but can take a fairly long time, depending on the format string and OS. May be called from user, init/cleanup, and realtime code. |
| rtapi_print_msg⚠ | |
| rtapi_set_msg_level⚠ | Set the maximum level of message to print. In userspace code, each component has its own independent message level. In realtime code, all components share a single message level. Returns 0 for success or -EINVAL if the level is out of range. |
| rtapi_shmem_delete⚠ | 'rtapi_shmem_delete()' frees the shared memory block associated with 'shmem_id'. 'module_id' is the ID of the calling module. Returns a status code. Call only from within user or init/cleanup code, not from realtime tasks. |
| rtapi_shmem_getptr⚠ | 'rtapi_shmem_getptr()' sets '*ptr' to point to shared memory block associated with 'shmem_id'. Returns a status code. May be called from user code, init/cleanup code, or realtime tasks. |
| rtapi_shmem_new⚠ | 'rtapi_shmem_new()' allocates a block of shared memory. 'key' identifies the memory block, and must be non-zero. All modules wishing to access the same memory must use the same key. 'module_id' is the ID of the module that is making the call (see rtapi_init). The block will be at least 'size' bytes, and may be rounded up. Allocating many small blocks may be very wasteful. When a particular block is allocated for the first time, the first 4 bytes are zeroed. Subsequent allocations of the same block by other modules or processes will not touch the contents of the block. Applications can use those bytes to see if they need to initialize the block, or if another module already did so. On success, it returns a positive integer ID, which is used for all subsequent calls dealing with the block. On failure it returns a negative error code. Call only from within user or init/cleanup code, not from realtime tasks. |
| rtapi_snprintf⚠ | 'rtapi_snprintf()' works like 'snprintf()' from the normal C library, except that it may not handle long longs. It is provided here because some RTOS kernels don't provide a realtime safe version of the function, and those that do don't provide support for printing doubles. On systems with a good kernel snprintf(), or in user space, this function simply calls the normal snprintf(). May be called from user, init/cleanup, and realtime code. |
| rtapi_spawn_as_root⚠ | |
| rtapi_spawnp_as_root⚠ | |
| rtapi_vsnprintf⚠ | |
| sched_get_priority_max⚠ | |
| sched_get_priority_min⚠ | |
| sched_getparam⚠ | |
| sched_getscheduler⚠ | |
| sched_rr_get_interval⚠ | |
| sched_setparam⚠ | |
| sched_setscheduler⚠ | |
| sched_yield⚠ | |
| select⚠ | |
| sigaction⚠ | |
| sigaddset⚠ | |
| sigaltstack⚠ | |
| sigblock⚠ | |
| sigdelset⚠ | |
| sigemptyset⚠ | |
| sigfillset⚠ | |
| siggetmask⚠ | |
| siginterrupt⚠ | |
| sigismember⚠ | |
| signal⚠ | |
| sigpending⚠ | |
| sigprocmask⚠ | |
| sigqueue⚠ | |
| sigreturn⚠ | |
| sigsetmask⚠ | |
| sigstack⚠ | |
| sigsuspend⚠ | |
| sigtimedwait⚠ | |
| sigwait⚠ | |
| sigwaitinfo⚠ | |
| simple_strtol⚠ | |
| ssignal⚠ | |
| strtoimax⚠ | |
| strtoumax⚠ | |
| wcstoimax⚠ | |
| wcstoumax⚠ |
Type Definitions
| __blkcnt64_t | |
| __blkcnt_t | |
| __blksize_t | |
| __builtin_va_list | |
| __caddr_t | |
| __clock_t | |
| __clockid_t | |
| __cpu_mask | |
| __daddr_t | |
| __dev_t | |
| __fd_mask | |
| __fsblkcnt64_t | |
| __fsblkcnt_t | |
| __fsfilcnt64_t | |
| __fsfilcnt_t | |
| __fsword_t | |
| __gid_t | |
| __gnuc_va_list | |
| __gwchar_t | |
| __id_t | |
| __ino64_t | |
| __ino_t | |
| __int8_t | |
| __int16_t | |
| __int32_t | |
| __int64_t | |
| __intmax_t | |
| __intptr_t | |
| __key_t | |
| __loff_t | |
| __mode_t | |
| __nlink_t | |
| __off64_t | |
| __off_t | |
| __pid_t | |
| __pthread_list_t | |
| __quad_t | |
| __rlim64_t | |
| __rlim_t | |
| __sig_atomic_t | |
| __sighandler_t | |
| __sigval_t | |
| __socklen_t | |
| __ssize_t | |
| __suseconds_t | |
| __syscall_slong_t | |
| __syscall_ulong_t | |
| __time_t | |
| __timer_t | |
| __u_char | |
| __u_int | |
| __u_long | |
| __u_quad_t | |
| __u_short | |
| __uid_t | |
| __uint8_t | |
| __uint16_t | |
| __uint32_t | |
| __uint64_t | |
| __uintmax_t | |
| __useconds_t | |
| _bindgen_ty_1 | |
| _bindgen_ty_2 | |
| _bindgen_ty_3 | |
| _bindgen_ty_4 | |
| _bindgen_ty_5 | |
| _bindgen_ty_6 | |
| _bindgen_ty_7 | |
| _bindgen_ty_8 | |
| _bindgen_ty_9 | |
| blkcnt_t | |
| blksize_t | |
| caddr_t | |
| clock_t | |
| clockid_t | |
| constructor | HAL 'constructor' typedef If it is not NULL, this points to a function which can construct a new instance of its component. Return value is >=0 for success, <0 for error. |
| daddr_t | |
| dev_t | |
| fd_mask | |
| fpregset_t | |
| fsblkcnt_t | |
| fsfilcnt_t | |
| fsid_t | |
| gid_t | |
| greg_t | |
| gregset_t | |
| hal_bit_t | |
| hal_param_dir_t | HAL parameters also have a direction attribute. For parameters, the attribute determines whether the user can write the value of the parameter, or simply read it. HAL_RO parameters are read-only, and HAL_RW ones are writable with 'halcmd setp'. |
| hal_pin_dir_t | HAL pins have a direction attribute. A pin may be an input to the HAL component, an output, or it may be bidirectional. Any number of HAL_IN or HAL_IO pins may be connected to the same signal, but only one HAL_OUT pin is permitted. This is equivalent to connecting two output pins together in an electronic circuit. (HAL_IO pins can be thought of as tri-state outputs.) |
| hal_port_t | |
| hal_s32_t | |
| hal_type_t | HAL pins and signals are typed, and the HAL only allows pins to be attached to signals of the same type. All HAL types can be read or written atomically. (Read-modify- write operations are not atomic.) Note that when a component reads or writes one of its pins, it is actually reading or writing the signal linked to that pin, by way of the pointer. 'hal_type_t' is an enum used to identify the type of a pin, signal, or parameter. |
| hal_u32_t | |
| id_t | |
| ino_t | |
| int_fast8_t | |
| int_fast16_t | |
| int_fast32_t | |
| int_fast64_t | |
| int_least8_t | |
| int_least16_t | |
| int_least32_t | |
| int_least64_t | |
| intmax_t | |
| ireal_t | |
| key_t | |
| loff_t | |
| mode_t | |
| msg_level_t | 'rtapi_print_msg()' prints a printf-style message when the level is less than or equal to the current message level set by rtapi_set_msg_level(). May be called from user, init/cleanup, and realtime code. |
| nlink_t | |
| off_t | |
| pid_t | |
| pthread_key_t | |
| pthread_once_t | |
| pthread_spinlock_t | |
| pthread_t | |
| quad_t | |
| real_t | |
| register_t | |
| rtapi_intptr_t | |
| rtapi_msg_handler_t | 'rtapi_get_msg_handler' and 'rtapi_set_msg_handler' access the function pointer used by rtapi_print and rtapi_print_msg. By default, messages appear in the kernel log, but by replacing the handler a user of the rtapi library can send the messages to another destination. Calling rtapi_set_msg_handler with NULL restores the default handler. Call from real-time init/cleanup code only. When called from rtapi_print(), 'level' is RTAPI_MSG_ALL, a level which should not normally be used with rtapi_print_msg(). |
| rtapi_s8 | |
| rtapi_s16 | |
| rtapi_s32 | |
| rtapi_s64 | |
| rtapi_u8 | |
| rtapi_u16 | |
| rtapi_u32 | |
| rtapi_u64 | |
| rtapi_uintptr_t | |
| sig_atomic_t | |
| sig_t | |
| sigevent_t | |
| sigset_t | |
| sigval_t | |
| suseconds_t | |
| time_t | |
| timer_t | |
| u_char | |
| u_int | |
| u_int8_t | |
| u_int16_t | |
| u_int32_t | |
| u_int64_t | |
| u_long | |
| u_quad_t | |
| u_short | |
| uid_t | |
| uint | |
| uint_fast8_t | |
| uint_fast16_t | |
| uint_fast32_t | |
| uint_fast64_t | |
| uint_least8_t | |
| uint_least16_t | |
| uint_least32_t | |
| uint_least64_t | |
| uintmax_t | |
| ulong | |
| ushort | |
| va_list | |
| wchar_t |