by limor » Thu Jan 31, 2008 3:47 am
by limor
Thu Jan 31, 2008 3:47 am
Hi Dimitris,
This method and thsi S-function is designed for Real-time-windows-target which runs at such high priority in XP that most drivers dont work.
The rational was to allow hard realtime frame rates for the control loop. If you need hard real-time, this is your best development environment.
the serial driver implemented in the S-function uses very backwards compatible windows system calls that assume the serial chipset on the motherboard and memory mapped to the CPU.
look at the code and google some of the words there, you will find references to similar serial driver code dated 10 years ago. If your serial port is on a PCI card, it may not have the same programming interface (memory mapped addresses etc) as the old serial chip. definitely the FTDI USB chips have totally different drivers then the old serial chip.
You may want to consider not using the Real-time simulink but instead use the normal simulink mode. If you computer is powerful enough, you may be able to get good pseudo real-time frame rate and you will be able to use your PCI serial interface and the FTDI based USB2Dynamixel module.
In normal mode you can write the S-function using a standard windows COM interface to serial ports. you wont have to deal with strange race conditions and dead-locks and have to reboot the system on every bug. You will also have considerably more ready-made boxes/functions to choose from including if i'm not mistaken a generic serial toolbox.
And another idea.. We have done some experiments generating "Generic Linux C code output" from Simulink, cross compiling and running the code on Gumstix connected to the Bioloid bus. Again this is pseudo real-time but the Gumstix hardly runs any other process except for the simulink controller.
Hi Dimitris,
This method and thsi S-function is designed for Real-time-windows-target which runs at such high priority in XP that most drivers dont work.
The rational was to allow hard realtime frame rates for the control loop. If you need hard real-time, this is your best development environment.
the serial driver implemented in the S-function uses very backwards compatible windows system calls that assume the serial chipset on the motherboard and memory mapped to the CPU.
look at the code and google some of the words there, you will find references to similar serial driver code dated 10 years ago. If your serial port is on a PCI card, it may not have the same programming interface (memory mapped addresses etc) as the old serial chip. definitely the FTDI USB chips have totally different drivers then the old serial chip.
You may want to consider not using the Real-time simulink but instead use the normal simulink mode. If you computer is powerful enough, you may be able to get good pseudo real-time frame rate and you will be able to use your PCI serial interface and the FTDI based USB2Dynamixel module.
In normal mode you can write the S-function using a standard windows COM interface to serial ports. you wont have to deal with strange race conditions and dead-locks and have to reboot the system on every bug. You will also have considerably more ready-made boxes/functions to choose from including if i'm not mistaken a generic serial toolbox.
And another idea.. We have done some experiments generating "Generic Linux C code output" from Simulink, cross compiling and running the code on Gumstix connected to the Bioloid bus. Again this is pseudo real-time but the Gumstix hardly runs any other process except for the simulink controller.