dear.. All. I wish to create Stepper project, with command line controlled, i modified Traffic example on keil c51 sample, with like this:
#include <reg52.h> #include <stdio.h> #include <rtx51tny.h> /* RTX-51 tiny functions & defines */ #include <ctype.h> /* character functions */ #include <string.h> /* string and memory functions */ char code menu[] = "\n" "+***** STEPPER MOTOR CONTROLLER ******+\n" "+ S : Set Waktu Mulai +\n" "+ D : Tampilkan Waktu +\n" "+ E : Set Waktu Berakhir +\n" "+ T : Set Waktu +\n" "+ L : Ubah Arah Menjadi Ke Kiri +\n" "+ R : Ubah Arah Menjadi Ke Kanan +\n" "+ F : Mode FULL STEP +\n" "+ H : Mode HALF STEP +\n" "+-------+-----------------------------+\n"; unsigned char code ful_seq_pat[4] = {10,9,5,6};//{1,4,2,8}; //{1,2,4,8}; unsigned char code half_seq_pat[8] = {0xfa,0xf8,0xf9,0xf1,0xf5,0xf4,0xf6,0xf2}; // Half Step Pattern // 11111010,11111000,11111001,11110001,11110101,11110100,11110110,11110010 extern getline (char idata *, char); /* external function: input line */ extern serial_init (); /* external function: init serial UART */ #define INIT 0 /* task number of task: init */ #define COMMAND 1 /* task number of task: command */ #define CLOCK 2 /* task number of task: clock */ #define BLINKING 3 /* task number of task: blinking */ #define LIGHTS 4 /* task number of task: signal */ //#define KEYREAD 4 /* task number of task: keyread */ #define GET_ESC 5 /* task number of task: get_escape */ //#define COUNTER_TM 6 sfr dataport = 0x80;//0x90; bit direction; bit step_mode; bit timed_out; struct time { /* structure of the time record */ unsigned char hour; /* hour */ unsigned char min; /* minute */ unsigned char sec; /* second */ }; struct time ctime = { 12, 0, 0 }; /* storage for clock time values */ struct time start = { 7, 30, 0 }; /* storage for start time values */ struct time end = { 18, 30, 0 }; /* storage for end time values */ char idata inline[16]; /* storage for command input line */ unsigned char idata sequencer; //unsigned int idata timer_like,buf_timer_like; /******************************************************************************/ /* Task 0 'init': Initialize */ /******************************************************************************/ void init (void) _task_ INIT { /* program execution starts here */ serial_init (); /* initialize the serial interface */ sequencer = 0; direction = 0; step_mode = 0; //timed_out = 0; //buf_timer_like = 1; //timer_like = buf_timer_like; os_create_task (CLOCK); os_create_task (COMMAND); /* start command task */ os_create_task (LIGHTS); /* start lights task */ //os_create_task (COUNTER_TM); //os_create_task (KEYREAD); /* start keyread task */ os_delete_task (INIT); /* stop init task (no longer needed) */ } bit display_time = 0;
involving a RTOS on the '51 is first a mistake and second, when controlling a stepper a disaster. Erik The universal bolt Imagine for a minute that I've invented the Universal Bolt. This is a metal object for joining threaded holes that can extend or collapse to fit a variety of lengths. It can expand or contract to fit holes of different diameters. The really cool feature is that I have replaced the bolt's spiral ridge with a series of extendable probes that can accommodate different thread pitches. What a marvelous product! You no longer need to stock a variety of bolts of different sizes and lengths and thread spacings because my Universal Bolt can be used in place of any of them. Of course, with all this flexibility this bolt is admittedly far less solid than conventional bolts, but I have addressed this concern with super-high-strength metal and a clever micro-machined mechanism for locking it to the desired length, thickness, and threading. This introduces a lot of complications, and my Universal Bolt turns out to be more expensive than a conventional bolt. But no problem! Because it's able to change configurations extremely quickly, a single Universal Bolt can take the place of many conventional bolts simultaneously. What we do is rig up a clever and very fast dispatcher device that quickly moves the bolt from hole to hole. If the dispatcher is fast enough, my Universal Bolt can spend a moment in each hole in turn and get the whole way through your product so fast that it returns to each hole before the joint has had a chance to separate. Sure, the bigger the project, the more complex the dispatcher becomes, but if we keep boosting the dispatcher speed and the bolt reconfiguration speed, we can keep the whole thing together. Absolutely absurd, right? You'd have to be crazy to get into a car built along these lines. If anything caused the dispatcher to derail, the entire product would collapse in a second. Well, yes, it is absurd. But it also pretty accurately describes the function of several embedded systems I've worked on. A fast and complex thread dispatcher keeps moving one simple and stupid integer-computation unit all over a big system tending to tasks rapidly enough that they all get done. And if that dispatcher ever once leads the CPU into an invalid memory address the whole thing crashes to a halt. Does this sound familiar to any software developers out there?
Eric, I do not tend to agree. RTX51 Tiny is a very powerful RTOS for an 8051 and using it on an Infineon XC8xx device (that is designed for Motor control) makes perfectly sense. Important is a clean software architecture and several times an RTOS simplifies a software architecture a lot. Reinhard
I assume from the title that you need the stepper motor to spin at higher RPM? The limiting factor on speed will be how many instructions you have to execute before you can update the motor controller again. As nice as an RTOS can be, the task switching overhead might be getting in the way. As a test, you might create a single task waiting on its timeout event, and use a hardware timer to measure the latency. That would be your best-case step rate. How about a interrupt service routine that advances the stepper motor, driven by one of the hardware timers? The timer value would be calculated by the command task when it parses the command to set the motor speed, and picked up on the next reload of the timer by the ISR, or just set by the command task if you have an auto-reload timer to spare.
using it on an Infineon XC8xx device (that is designed for Motor control) makes perfectly sense. It MAY, but when the question is "more speed" it hardly does. Adding overhead will, by definition reduce speed and, convesely, removing it will increase speed. If the product is very complex and not time critical nature there may, even for the '51 (which is singularily unsuited), be an argument for using a RTOS. I have no problem whatsoever with using a RTOS on a suitable processor Erik