roboforum.ru

ПК отсылает команду ПИК по USB (свой протокол).
PIC передает команду дальше на ДД по UART (протокол ДД).
ДД бывают разные, протокол команд стало быть тоже.
Надо смотреть даташит на конкретный ДД.
Прошивку для PIC делал сам, уникальная то есть
Я так думаю, тут у каждого второго, кто умеет работать с МК
есть своя прошивка. Протокол тоже свой, с подтверждениями приема,
чексуммами.

Понятно, а само управление происходит по какому алгоритму?
PC отправляет PWM для каждого двигателя и как долго работать на такой скорости?
Как я понимаю по UART вы передаёте не бинарные данные а текст?
И ДД наверное стоит воспринимать как (КД) контроллер двигателей (драйвером обычно называют схему которая коммутирует ключевые транзисторы)

AndreiSk, спасибо! Понял, у вас фиксированная ширина пакета, и данные только в одну сторону.
Да вы передаёте бинарные данные.
Текст это типа L80R34\n\r

linvinus писал(а):Понятно, а само управление происходит по какому алгоритму?
PC отправляет PWM для каждого двигателя и как долго работать на такой скорости?

ПК отправляет команду PIC условно так:
{левыймотор_направление, левыймотор_скорость, правыймотор_направление, правыймотор_скорость}
Сколько ему работать это не важно, просто PIC ждет команду, скажем 2 раза в секунду.
Если команды нет от ПК, а моторы работают, через полсекунды он их начинает плавно останавливать.

linvinus писал(а):Как я понимаю по UART вы передаёте не бинарные данные а текст?
И ДД наверное стоит воспринимать как (КД) контроллер двигателей (драйвером обычно называют схему которая коммутирует ключевые транзисторы)

Вообще, по UART я передаю байты. Не знаю когда байты являются бинарными, а когда байты уже текст, думаю зависит от точки зрения смотрящего
ну вот скажем такая команда для моторов: new Byte[]{1,25,1,25};

linvinus писал(а):AndreiSk, спасибо! Понял, у вас фиксированная ширина пакета, и данные только в одну сторону.
...

Вообще то пакет для посылки на PIC не имеет фикс. длины
Byte CommandLength;
Byte CommandID;
Byte[] Arguments;
UInt32 TimeStamp;
Byte CheckSum;
Аргументов для команды может быть много, например если надо двинуть несколько серв за раз, то можно указать все позиции
И от PIC я тоже забираю информацию, например напряжение бортовой сети.
Также в прошивке от прошлых лет осталась поддержка разных сенсовро (термометра ,
акселя, гироскопов, компаса, дальномеров, сонара).

Добавлено спустя 8 минут 58 секунд:
@Grem, я одну батарею использую. Зачем тебе две?
Рекомендую всеже Zippy 3S 5000/5800/8000. Turnigy тяжелее
http://www.hobbyking.com/hobbyking/stor ... duct=16225

AndreiSk писал(а):Вообще то пакет для посылки на PIC не имеет фикс. длины
Byte CommandLength;
Byte CommandID;
Byte[] Arguments;
UInt32 TimeStamp;
Byte CheckSum;
Аргументов для команды может быть много, например если надо двинуть несколько серв за раз, то можно указать все позиции
И от PIC я тоже забираю информацию, например напряжение бортовой сети.
Также в прошивке от прошлых лет осталась поддержка разных сенсовро (термометра ,
акселя, гироскопов, компаса, дальномеров, сонара).

А можно чуток подробнее? Как тогда pic парсит команды и данные?

Ну вот, допустим ПК приготовил команду для PIC.
В PIC крутится цикл

Код: Выделить всё

   while(led_toggle()) {
      RESTART_WDT();
      
      // No data? Skip
      if (!kbhit(HW_USART1)) continue;
      
      // Get command
      if (svs_command_get() == 0) continue;


      switch(SVS_Command[1]) {
....
         // Board ID get
         case 0xA7: {
            svs_command_start(); // BODY MCU PIC18F8722
            svs_command_add_bytes5('B', 'O', 'D', 'Y', ' ');
            svs_command_add_bytes4('M', 'C', 'U', ' ');
            svs_command_add_bytes5('P', 'I', 'C', '1', '8');
            svs_command_add_bytes5('F', '8', '7', '2', '2');
            
            svs_command_send(); break;
         }
....
      }
   }


Код: Выделить всё

BYTE svs_command_get() {
   BYTE i, checksum, count, databyte, result;

   disable_interrupts(GLOBAL);

   databyte = svs_byte_read();
   if (databyte == COMMAND_TEST_BYTE) {
      // Send answer: ready, send command
      svs_byte_send(COMMAND_READY);

      // Get the number of bytes in cmd + args + RTC (4 bytes)
      count = svs_byte_read(); SVS_Command[0] = count;
      checksum = count;
      for(i = 1; i <= count; i++) {
         databyte = svs_byte_read();
         SVS_Command[i] = databyte;
         checksum ^= databyte;
      }
      if (svs_byte_read() == checksum) {
         // Send answer: command arrived with valid checksum
         svs_byte_send(COMMAND_CHECKSUM_VALID);
         SVS_Time_Ms = MAKE32(SVS_Command[count], SVS_Command[count - 1], SVS_Command[count - 2], SVS_Command[count - 3]);
         result = 1;
      }
      else {
         // Send answer: command arrived with not valid checksum
         svs_byte_send(COMMAND_CHECKSUM_ERROR);
         result = 0;
      }      
   }
   else {
      // Send answer: something wrong arrived
      svs_byte_send(COMMAND_UNKNOWN_ERROR);
      result = 0;
   }
   
   enable_interrupts(GLOBAL);
   return result;
}


У меня стандартная скорость обмена с пиком для 20МГц кварца 230400 bps
#use delay(clock=20000000,restart_wdt)
#use rs232(baud=230400, xmit=PIN_C6, rcv=PIN_C7, UART1, stream=HW_USART, errors)

Просто так команду PIC не послать.
Сначала ПК посылает тестовый байт, PIC должен ответить.
Только затем пойдет команда, на которую PIC ответит принята или нет.
Потом ПК ждет когда PIC отработает и снова проверяет, готово ли или нет
На таких больших скоростях такое работало сутками без проблем,
некоторые PIC работали на 921600.

Потом ПК ждет когда PIC отработает и снова проверяет, готово ли или нет

А это каким образом происходит? Опять тестовый байт?

А что произойдёт если по ошибке придёт 255 в месте
// Get the number of bytes in cmd + args + RTC (4 bytes)
count = svs_byte_read(); SVS_Command[0] = count;
в то время когда PC передаст только 10ть байт и будет считать что всё правильно и будет ждать ответа.

Добавлено спустя 6 минут 55 секунд:
Только наверное тему нужно было перенести в раздел коммуникации?

linvinus писал(а):

Потом ПК ждет когда PIC отработает и снова проверяет, готово ли или нет

А это каким образом происходит? Опять тестовый байт?

Ага. ПК отдал команду, PIC сказал "команду принял все отлично"
ПК ждет 1секунду (я считаю это достаточно для всех дел у PIC).
Как только PIC завершил выполнение команды,
он отсылает ПК 1 байт (ТЕСТ-БАЙТ).


// Command arrived to uC
// Wait for "test" byte from uC; 1000 ms for command execution
если тестовый байт не пришел, то это проблемы пика, его watchdog перегрузит,
и ПК имеет пустой ответ.
Если тест байт пришел от PIC на ПК,
то ПК шлет READY-БАЙТ (=говорит "я готов, давай результат работы")
и PIC видя готовность ПК, шлет результат (тоже с длиной, чексуммой и т.д.)
ПК читает, проверяет сумму и выдает ответ в программу которая вызывала PIC.
Немножко мудрено, но такие переговоры своего рода искусственные паузы,
которые позволяют не засирать канал и не переспрашивать.
Сделал давно, работает без проблем. PIC никогда не перегружается по watchdog.

linvinus писал(а):А что произойдёт если по ошибке придёт 255 в месте
// Get the number of bytes in cmd + args + RTC (4 bytes)
count = svs_byte_read(); SVS_Command[0] = count;
в то время когда PC передаст только 10ть байт и будет считать что всё правильно и будет ждать ответа.
...

PIC будет читать 255 байт, но их не будет, сработает watchdog.

это CCS C

Код: Выделить всё

#include <18F2520.h>
#device      ADC=10
#fuses      HS,WDT256,NOPROTECT,NOLVP,NODEBUG,NOPUT,NOBROWNOUT,NOWRT

#use         delay(clock=20000000,restart_wdt)
#use         rs232(baud=38400, xmit=PIN_C4, rcv=PIN_B6, stream=SABERTOOTH_SS, bits=8, parity=N, stop=1, errors)
#use         rs232(baud=230400, xmit=PIN_C6, rcv=PIN_C7, UART1, stream=HW_USART, errors)

// It is Rover 20
// Robot with Core 2 Duo CPU P8800


Жаль они PIC32 не осваивают, я привык к CCS C

Понятно, спасибо что поделились опытом. Возможно ещё кому нибудь пригодится информация, будет от чего отталкиваться.

В качестве альтернативы я бы рассмотрел передачу информации импульсами. как в любительских сервах, только период уменьшить с 50Гц до 100-1000Гц.

Спорить какой си лучше не буду я привык к gcc. скоро arm буду осваивать тоже на gcc.
Я рассматривал два подхода в управлении, 1 простой, передача данных в одну сторону, тут лучше чем управление импульсами сложно что то придумать, просто и быстро.
А вот с универсальным интерфейсом сложнее, там где нужно отслеживать несколько параметрв в реальном масштабе времени, выбор интерфейсов не велик.
Вот и хотелось узнать кто что использует, в реальных условиях.

Я пока остановился на хардварном usb hi-speed, без промежуточных контроллеров.
С учётом DMA должно не плохо получиться.

Даже не знаю,
написал два или три года назад.
Работает как USB->UART (FTDI чип),
так и напрямую с USB на PIC (использую UBW)
Смысла менять не вижу совершенно

Я не говорил что нужно менять Это просто в качестве альтернативы.
Как я понял UBW создаёт виртуальный com порт, по сути то же самое что FTDI чип, только силами одного контроллера.

С FTDI чипом я через DLL работаю, не с COM портом.
Так для UBW пришлось переделать ПК часть на виртуальный COM порт,
и для PIC вместо чтения из HW_UART переделать на функции USB.
Учитываю сложность взаимодействия, ожидались грабли в отладке.
Но как оказалось, ничего не потребовалось, через полчаса
ПК общался с UBW напрямую через USB