нужно внешнее устройство отлаживать напрямую через x86/x64 машину с помощью моста, тем самым "вылизывать" управление им до блеска, правда необходимо уметь программировать под Win32. Ведь GUI винды гораздо удобнее, какого-то там UART, JTAG ... от слабенького MCU типа ARM
Редкостная чушь. Трава была забористая, сразу видно. GUI винды сама по себе реализует управление внешними устройствами через драйверы винды. А писать драйверы для винды ничем не отличается от писания драйверов для ARM-ов или Атмег. И УАРТ тут вообще не причем. Как и житаг. Тут разговор шел не о скорости обмена, а о возможности управлять интерфейсом связи с целевым внешним устройством. И чем тогда легче бессмысленное усложнение этой процедуры через софт ПК против нативного для задачи прямого управления периферией МК? Задача - настроить периферию МК, а не заниматься с "резиновой женщиной" рукоблудом.
А когда нужно что-то записать и прочитать во внешнее устройство, разработчик которого ленивая скотина и документацию писал левой ногой (а они через одного такие), тут порой отладочная информация на несколько метров ниже уровня земли уходит, при том что я на втором этаже работаю.
Нормальный режим... Вот когда назначение каких-то странных битов в загадочных регистрах будете угадывать методом тыка, тогда нам про "нормальный режим" расскажете.
А что - бы не гадать, нужно внешнее устройство отлаживать напрямую через x86/x64 машину с помощью моста, тем самым "вылизывать" управление им до блеска, правда необходимо уметь программировать под Win32. Ведь GUI винды гораздо удобнее, какого-то там UART, JTAG ... от слабенького MCU типа ARM или Atmega
Чесслово, не понял прелестей отладки из под винды и с последующей отладкой в связке с МК...
_________________ Астролябия-сама меряет, было бы что мерять!!!
Если писать код так, чтобы он собирался и на этих контроллерах, и под Виндой, то почти всю отладку ПО получается выполнить под Виндой, а не через СОМ-порт этого контроллера. Теоретически, существует Turbo Debugger для удалённой отладки, но лично я его не нашёл. Плюс загрузка программы в такой контроллер отнимает заметное время, ибо идёт через СОМ-порт на скорости 115200, а сама программа будет не меньше 80-90К из-за библиотек, которые линкуются к ней.
Ещё случай отладки под Виндой это ПЛК, которые много общаются с IDE. Тоже очень удобно соединить ПЛК через пару виртуальных СОМ-портов с IDE, чтобы провести отладку и выполнить тестирование ПЛК и программ для ПЛК. Кстати, если кто не в курсе, то есть версия FreeRTOS для Винды, так что удаётся проверить довольно большие куски кода.
// Превышено время ожидания окончания операции TIMEOUT = 11 };
//---------- // Связывает объект SerialPort с физическим портом port, // устанавливая для порта параметры приёма-передачи. // Возвращает номер порта. Зачение UNKNOWNPORT указывает на ошибку. virtual ComPort open ( ComPort port, uint32 baudRate, uint8 dataBits, Parity parity, StopBits stopBits );
//---------- // Отвязывает физический порт от объекта SerialPort. // Возвращает номер отвязанного порта. Значение UNKNOWNPORT // указывает на ошибку. virtual ComPort close( void );
//---------- // Возвращает номер физического порта, к которому выполнена // привязка. Если привязка не выполнена или завершилась неудачей, // то вернёт UNKNOWNPORT. ComPort getPort( void );
//---------- // Возвращает код ошибки последнего вызова метода класса. // 0 - нет ошибки, любое другое значение указывает на ошибку, код // которой зависит от платформы. virtual int32 getLastError( void );
//---------- // Принудительная очистка буферов. Количество байт для приёма- // передачи обнуляется! Оставшиеся в передатчике байты не передаются!
//---------- // Читает в буфер buff размером buffSize байты из буфера приёмника. // Работает в неблокирующем режиме! // Возвращает количество прочитанных байт или ноль в случае // отсутствия доступных для чтения данных. virtual int16 receive ( void* buff, int16 buffSize, MODE mode = NON_BLOCK ) = 0;
//---------- // Записывает buffSize байт из буфера buff в буфера передатчика. // Работает в неблокирующем режиме! // Возвращает количество записанных байт или ноль в случае // невозможности записи. lastError указывает на ошибку. // Перед вызовом send(..) во избежании склеивания отправляемых // посылок, необходимо вызывать getAvailableTxBytes(..) для проверки // того, что буфер передатчика пуст. virtual int16 send ( void* buff, int16 buffSize, MODE mode = NON_BLOCK ) = 0;
//---------- // Возвращает количество байт, находящихся в буфере передатчика. virtual int16 getAvailableTxBytes( void ) = 0; virtual int16 getAvailableRxBytes( void ) = 0;
//---------- // Сервисные функции для мониторинга и диагностики. virtual ostream& print( ostream& os );
protected:
//---------- // Создаёт объект, через который будет осуществляться работа // с последовательным портом. Может создаваться различная // обвязка для удобства работы: очереди, семафоры и т.п. UART_base ( const char* name );
//---------- // Уничтожает объект с высвобождением всех занятых ресурсов. virtual ~UART_base( void );
//----------
ComPort port; // Привязаный порт. int lastError; // Код ошибки последнего вызова.
//---------- // Устанавливает события, по которым будет формироваться прерывания. // Не забудь установить UE и определись с RE и TE! virtual void setEvents( void ) = 0;
Чесслово, не понял прелестей отладки из под винды и с последующей отладкой в связке с МК...
А прелесть следующая, к примеру имеется чип, но с кривым даташитом, пишем софт, управляем чипом, смотрим и получаем результаты (запись/чтение) в живую, без ограничения объема памяти и задач.
У тех кто пишет на регистрах, дефицита памяти и недостатка производительности как правило не возникает. Ресурсов МК хватает с избытком, в том числе и на отладочные вставки в код. Недостаток всего и вся, это проблема библиотекарей.
_________________ Астролябия-сама меряет, было бы что мерять!!!
У тех кто пишет на регистрах, дефицита памяти и недостатка производительности как правило не возникает. Ресурсов МК хватает с избытком, в том числе и на отладочные вставки в код. Недостаток всего и вся, это проблема библиотекарей.
Ресурсы МК это ничто по сравнению с ресурсами x86/x64 машины А выявить подводные камни без участия программиста / разработчика ( разраб может откинутся на спинку стула и отдыхать) гораздо быстрее на x86/x64, чем шариться в регистрах МК В случае изучения конкретного раба - чипа с кривым даташитом с помощью x86/x64, никакие отладочные вставки ненужны, достаточно отслеживать программным путем результаты, необходимые результаты и протоколировать их в отладочный файл, потом отпарсировать нужное, ну или забагованное
я так писал библиотечку для микроплейера мп3 с сд-карты: китайский даташит процентов на 60 был правдив, а остальное уточнял экспериментально. собственно, даташит просто переведен был хреново и многие моменты были просто непонятны.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
А выявить подводные камни без участия программиста / разработчика ( разраб может откинутся на спинку стула и отдыхать) гораздо быстрее на x86/x64, чем шариться в регистрах МК В случае изучения конкретного раба - чипа с кривым даташитом с помощью x86/x64, никакие отладочные вставки ненужны, достаточно отслеживать программным путем результаты
Бред. Рассуждения диванного теоретика, никогда не работавшего с живым МК. Либо "работавшего" только посредством чужих "либ". Что, по большому счёту, то же самое.
Не совсем. Если работа МК сводится к математическим расчётам и обмену данными по, например, EIA-485, то такая ситуация имеет право быть. В таком случае почти всё можно отладить на ПК, а потом перекомпилировать для МК. Но написать программу и драйверы так, чтобы они собирались и на ПК, и на МК- это надо уметь. И всё равно работа с регистрами периферии на МК никуда не денется, хотя есть ведь, например для STM32, небезызвестный HAL, который может скрыть и работу с регистрами. Хм, но всё равно, такой подход требует серьёзных знаний ПК с его ОС, и МК с его примочками.
Если работа МК сводится к математическим расчётам и обмену данными по, например, EIA-485, то такая ситуация имеет право быть.
Никто с этим и не спорит. Вопрос совершенно в другом: В ЧЕМ ПРОФИТ от такого подхода? Мало того, что нужно писать свой софт на ПК, так еще потом нужно его "вклеить" с драйверами на МК. Кому нужна эта лишняя работа? Расчеты вообще не рассматривались в обсуждении этой темы. А если и рассматривались, то в их взаимодействии с режимом реального времени, которое не симулируется на ПК в предлагаемом варианте. Да и не может симулироваться из за совершенно другой платформы. ОСРВ на ПК - это иная история. Я сразу сказал - это редкостная чушь.
Чел, походу, свои хрустальные мечты озвучил. У мну подобные были в 3 классе: реактивный ранец, бесконечная батарейка, очки со встроенным телевизором, роликовые коньки с электромоторчиками, радиоуправляемая модель самолета с телевизионной камерой на борту и радиусом полета не менее 100 км. Одно хорошо - интернетов тогда не было, и надо мной хихикали только мои одноклассники. Нынешние третьеклассники брыжжут влажными мечтами как минимум в границах целой страны.
_________________ Астролябия-сама меряет, было бы что мерять!!!
В скорости разработки, хоть звучит неожиданно. Просто когда скорость загрузки программы для исполнения измеряется десятками секунд-минутами, плюс нет внутрисхемной отладки, а есть только printf(), то такой подход себя окупает. А если ещё и несколько проектов, то тем более.
КРАМ писал(а):
Да и не может симулироваться из за совершенно другой платформы. ОСРВ на ПК - это иная история.
Не совсем так: https://www.freertos.org/FreeRTOS-Windo ... MingW.html Тут даже речь не о симуляции идёт. Если оборудование общается через 485-ый и Эзернет, то нет разницы, кто спрашивают и кому отвечают, МК или Винде. Лишь бы ответы укладывались в установленный предел.
Разработки ЧЕГО? Если разговор идет об алгоритме расчетов, то для этого есть MATLAB. А если речь идет об интерфейсах или драйверах внешних устройств, то все повязано на железе связи с этими устройствами конкретно в этом МК. Причем тут вообще обсуждаемая тема? Напомню, что разговор шел о ВНУТРИСХЕМНОЙ отладке и инструментах для ее осуществления. А методы макетирования алгоритмов на сторонних платформах - это совершенно другая история. ЗЫ. Намекну. Трансформер пропагандирует свои методы управления некими чипами через интерфейсы и софт ПК. Например, он тут хвалился управлением RGB-лентами. Вот о чем он ведет разговор. А совсем не о вычислительных алгоритмах.
Если оборудование общается через 485-ый и Эзернет, то нет разницы, кто спрашивают и кому отвечают, МК или Винде.
Если протокол обмена (верхнего уровня, конечно) не имеет документации, то совершенно фиолетово на чем с ним трахаться. Дело вкуса и привычек. Время там не сэкономишь. Ну вывалит, например, сниффер MIPI CSI тонну листов загрузки видеосенсора. Без внятной документации там все равно ничего не восстановишь. А если и восстановишь, то фиолетово чем снифферили - МК или ПК. Времени уйдет одинаково.
Очень часто, мне гораздо интереснее отладить до "блеска" работу чипа на x86/x64, потом наработки перевести в MCU (Atmel и т.д.) ну или на платформу с Z80 или 6809
Transformer-V, а что, существуют полноценные эмуляторы, скажем, тех же STM32? Может, они еще и свободные и под линуксом работают?
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
КРАМ, он говорил, что "до блеска" отлаживает МКшный код на ПК. И вот интересно, как он это делает, если добрая половина кода для МК завязана на его регистрах? Всякую вычислительную чушь, понятное дело, на ПК можно отладить. Но сколько ее? Нет уж, коль пишешь под МК, так и отлаживаешь непосредственно на МК. Самым простым диагностическим выхлопом. У меня в режиме DEBUG прошивка вполне может килобайт на 10 пухлее быть. И выхлопа спокойно в сотню килобайт в секунду производить в терминал. А в release-сборке все эти DBG просто не раскрываются. Совершенно аналогично отлаживаю софт под ПК, только там логи валятся в отдельный файл + stderr.
А насчет матлаба (только матлаба для людей — Octave) поддержу. Сам в октаве очень много чего намоделирую, а потом алгоритм переношу в сишный код и использую на ПК или МК. Особенно с обработкой изображений помогает, пока я не добил свою библиотечку для этих дел (использовать openCV — нужно совсем быть поехавшим головой, т.к. она жирная, тормозная и говно вообще).
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 51
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения