Средства и методы разработки

Вообще жизненный опыт показал... что лучше поделить на ~64, например, микрошага (в 2 байта со знаком влазит и ладно) во-первых, во-вторых алгоритм управления двигателем строить не исходя из "шагов", а исходя из значений "синусной и косинусной" составляющей фазы на обмотках в данный момент времени (и обновлять, скажем, порядка сотен раз в сек). Для программы есть таблица косинуса (тока) от 0 до pi/2 (остальное всё симметрично и из неё же берётся), хотя можно и от 0 до 360, если память есть. Если физический драйвер не позволяет плавного задания тока, то всё ограничивается полушаговым режимом естесственным образом. Почему микрошаги (даже если их и нет физически): так проще с вычислениями, если есть привязка к физическим координатам, иначе ошибки в вычислениях связанные с округлением до целого числа шагов. Почему привязка к времени, а не шагам: вычислительный ресурс контроллера во-первых фиксирован, и при привязке к (микро)шагам всё равно не будет успевать пересчитывать на больших скоростях, во-вторых при управлении массивными объектами потребуется примерно линейное изменения скорости (постоянное ускорение), что проще сделать при фиксированной величине шага (по-времени). И ещё, в связке с датчиками положения, енкодерами и т.п., нужно (для программиста) представлять, что вал двигателя немножко "резиновый" и в движении всегда будет находиться где-то рядом (+- пол-шага, условно) от расчётного положения, догонит только на остановке. И что самодельный оптический датчик положения, например, может срабатывать в разных местах в зависимости от внешней засветки (если луч достаточно широкий) и температуры на улице...