ruhi
-
Постов
567 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Блоги
Весь контент ruhi
-
вы пишите какой то бред (с точки зрения математики), потому что остаток бывает от деления, а у вас, похоже подразумевается вычитание, а зачем он вам нужен этот остаток, который: где то "УЖЕ находится", совсем не понятно, и не понятно зачем вы про него пишете если он не нужен. Нет никакой конкретики в вашем вопросе, бред какой то (смотри замечания выше)! Так что ваши эмоции не обоснованы. Если что, после этого значение "а" не обязательно <255, потому, что бы это значило? У меня только одна версия: "бред какой то!"
-
Нет, не правильно! Надо формулировать и решать реальные задачи, а не придумывать абстрактные. И это в любом случае: если хотите кого то удивить, и если хотите что то сделать работающее.
-
"на скорую руку" вместе с "оригинальную" звучит, действительно, очень захватывающе ! Рядом лучше не стоять ! Шарахнет!
-
Для чайников, наверно, звучит красиво, а с профессиональной точки зрения маразм! ВСЕ ассемблеры ВСЕХ процессоров очень похожи, все делятся на одни и те же группы команд, все команды подчиняются жесткой логике, поэтому для их запоминания достаточно помнить очень ограниченный набор правил этой логики. Практически всегда (в любом ассемблере) существует около 20-50 базовых команд которые очень легко запомнить потому что это производные от элементарных математических операций с числами(регистрами) и/или с адресами. Интересно кто вам оплачивает эту достаточно ресурсоемкую работу??? Неужели вы миллионер и от нечего делать рисуете процессоры??? - Сложно поверить. У вас определленно талант в вешании высокотехнологичной чепухи на уши ! Похоже в этом заключается секрет! Вы навешали какому то милионеру - он выделил вам бюджет, и здесь мы видим ваш отчет по проделанной работе. Правильно? Нарисовать процессор уже давным давно не проблема, проблемма его изготовить по доступной цене.
-
Обработчик ДМА это прерывание? А почему флаг нельзя поднять в другом месте, и не поднимать его при каком то условии? И что, оно засыпает по этому флагу? ... Вы бы сначала разобрались с логикой работы вашей системы, может и вопросы не пришлось бы задавать!
-
Вот и получается что вы пытаетесь решать какие то свои задачи, а у вас есть планировщик которому на эти ваши задачи начихать, он делает то что ему надо и когда ЕМУ надо. Зачем вам ОС уровня приложений когда вы на уровне драйверов работаете??? Выкинте нафик вашу РТОС и все станет на свои места. Кстати планировщик обычно сидит в прерывании какого то таймера, и что у вас с этим прерыванием?
-
интересный подход: я не знаю что надо делать, но знаю сколько стоит это сделать! очень похоже на: я начальник - ты дурак!
-
А какой вы файл то открываете, С-шный? я не вижу у вас там файла проекта или мейк файла - без одного из них проект не построить! В таких файлах обычно есть некоторые общие настройки - их тоже надо анализировать! У вас ничего этого нет: как строить, подо что, с какими настройками - непонятно! Может вы какой-то файл-каталог пропустили-потеряли?
-
У вас там в ридми написано: Note: This is Work In Progress design. To make it work for you you'll most probably need to modify it in one way or another. Говорят что нужно как то модифицировать этот проект для собственного использования, и он, вообще, не закончен. А компилировать там непонятно что - там мейк-файла нет, не обижайтесь.
-
Так вам надо копать в сторону поиска того кто умеет компилировать! Через форум это в общем то невозможно! А как вы привлекательность определили, интересно? Кому нужно повторять чужие поделки? Для Чего? У вас видимо есть куда прилепить эту поделку, а остальным она совершенно не к чему.
-
А почему кейс для TRANSMIT, а структура передается для receiveI2C??? Перепутано??? И если это ошибка то могу объяснить почему в дебаге видно значение - потому что в кейс заходим когда его нет, а поскольку вы прерываете работу программы в дебаге, а железо продолжает работать, значение в регистре появляется уже(!), когда вы его смотрите в дебаге.
-
Так I2c и слейв здесь не при чем! это проблема или с ДМА или с С-кодом, надо разбираться почему у вас значение из регистра не читается или не сохраняется, возможно переменная sst зануляется каким то образом. Весь код функции надо смотреть где вы добавляете строчку с которой работает. а почему сдесь hi2c, а здесь: hi2c1 ????????????
-
кнопку надо поставить в крайних положениях, которую будет нажимать стекло при полном закрытии-открытии, все остальное различай по току! Наверно, после нажатия кнопки алгоритм слежения по току отключить и через пол-секунды двигатель отключать - эксперементально надо проверить время. эти кнопки можно использовать для калибровки системы слежения за током, думаю!
-
тут не совсем понятно что вы хотите, даже(!), потому что количество переданных мастером байт и количество принятых Слейвом байт, вообще говоря может отличаться! И Слейв может посчитать только количество принятых байт, как оно считается и/или в каком регистре его взять после окончания приема ищите в документации на переферию процессора. Если вы про Мастера, то как может быть неизвестно сколько он собственных байт отослал я вообще понять не могу!
-
Наверно не "затем", а в "зависимости от чего-то", а вот от чего вам и надо понять! и наверно с какой дискретностью, и как это конфигурировать. Если вы сам не разберетесь за вас это никто не с<З>делает (для вашей задачи)! Так что разбирайтесь - у вас нет другого выхода.
-
Это то что вы создаете на форуме своими бессодержательными вопросами: У меня ЛСД - кнопка не работает - как обойти? Я бы ответил: обойдите лесом!
-
поставьте 4-ре прошивателя которые читают одну и ту же прошивку, это ж элементарно!
-
вот вам в предыдущем посте правильно посоветовали, могу добавить что лучше в бинарнике исполняемого кода тщательно проверить таблицу переходов по прерываниям, что они соответствуют таблице событий прерываний из документации и укзывают правильную процедуру в коде.
-
Я с компилятором ПИКа для которого поддерживается функция КЕШирования памяти не работал, и вообще сомневаюсь что в этой линейке есть такие процессоры, поэтому я думаю вы не совсем понимаете о чем идет речь, по крайней мере, возможность КЕШирования обычно определяется на уровне линкера в скрипте описания карты памяти, обычно + специальные аппаратные настройки регистров в коде (MMU-memory managment unit там был, кажется, по крайней мере там где я с этим работал, это были АРМ7-е). То есть, как минимум, только расширения описания массива для объявления и РАЗМЕЩЕНИЯ его в неКешируемой памяти вроде как не достаточно, нужно еще эту область памяти правильно объявить для линкера, хотя... в принципе там может быть предопределенная область памяти... - не знаю, читайте описание процессора, ищите по ключевому слову КЕШ. С СТМ-мами с КЕШем я не разбирался.
-
К чему тогда этот код? надо разбираться сначала почему она ребутится и сделать чтоб не ребутилась!
-
это ж легко проверить - подайте напряжение на ногу и снимите напряжение - посмотрите как меняются биты из программы (на другую ногу их вывести например). В любом случае надо проверять свое понимание описания микросхемы в таких деталях, по крайней мере на этапе первого знакомства с любой конкретной микросхемой.
-
Вы какую то малоизвестную микросхему выбрали для экспериментов. Хоть таймеры везде примерно одинаковый - тут надо в детали описания влезать, в других микросхемах можно настроить захват по обоим фронтам, в этой не знаю, вообще первый раз вижу упоминание 8-битного СТМ-а применительно к таким экспериментам! И еще главная проблема не посчитать период, а куда вы его собрались выводить-показывать!
-
Так эта чужая электроника поддерживает какой то диагностический протокол для передачи данных в УАРТ? Тогда, конечно, лучше с полноценного компа за всем следить. На чем писать приложение на ПК это дело опыта, ресурсов (времени), планируемых возможностей логирования-анализа к реализации, ... Я например на С# пишу с WPF теперь, очень оказывается удобно после пары недель изучения-экспериментов, хотя кое что остается в консоли конечно. Ну и надо помнить что оборудование (в том числе ПО) для контроля (проверок, измерений, диагностики) всегда на порядок сложнее контролируемого оборудования по определению! Ведь предполагается что контролируемое оборудование допускает сбои-ошибки (иначе зачем его контролировать?), а в контролирующем оборудовании они не допустимы (иначе оно будет не способно контролировать, потому что его тоже надо будет контролировать!) - это аксиома. Поэтому часто возникает дилема: создавать высоко надежную систему контроля, или глубоко проанализировать и оптимизировать используемые алгоритмы-логику работы устройства (системы устройств) что бы обеспечить минимальный поток диагностической информации о текущей работоспособности системы по всем аспектам ее функционирования.
-
За более чем 20 лет работы по этому направлению я ничего подобного (в смысле "почитать") не встречал! Из собственного опыта могу рассказать что разработчик ембедед программы ДОЛЖЕН сам уметь объяснить КАК его программу тестировать, собственно он и должен провести это тестирование которое убедит НЕ-специалиста в ембедед программировании что разработанная программа: а. выполняет-реализует заданные функции б. эти функции адекватны назначению целевого устройства (проще говоря что устройство работает) Моя работа в этой области обычно начинается с того что я определяю некоторую общую идею (набор взаимосвязанных идей) функционирования программы управления и объясняю (как минимум для себя, что бы не работать впустую!) как мы сможем убедиться в адекватности результатов реализации идеи заданным параметрам функционирования устройства (требуемым диапазонам значений этих параметров, ...)
-
Так вы что за программу шьете? какую то операционку реального времени с терминалами??? - она вполне может убить процессор с некоторой вероятностью! Вы напишите 10 строчек поморгать светодиодом и зашейте! Если будут проблемы сразу поймете где они.