SapegoAL

Нет нельзя. А что обычный резистивный делитель никак не поможет?

А какое отношение имеет PIC к ARM? Вы веткой ошиблись? А если брать в общем, то относительная адресация была изобретена задолго до PIC. В частности x51 позволяет писать таким образом. Да и во многих других тоже. AVR позволяет. Обычно используется мнемоника типа $+xx, что значит смещение относительно счётчика команд. В AVR ассемблере PC+xx. Это всё актуально для ассемблера. Для Си, тем более на железе, как правило неактуально. Компилятор сам раскладывает по адресам. Может быть актуально, если вы откомпилированный кусок впоследствии планируете переместить в другую область памяти. Ну, как бы возможно, но как-то не помню, чтобы использовалось. Для ПК есть 2 варианта решения такой задачи. Прямой способ, с перемещаемым кодом, и способ с таблицей переходов. То есть впереди проги размещена таблица адресов, которые указывают прямые переходы. ОС перед запуском проги корректирует прямые адреса на смещение относительно стартового адреса.

До 1Мб Озу, 14-битный АЦП, удвоенная плавучка если я всё правлильно понял. )) И это только 40 нм. Уже в ближайшем будущем нам обещают 28. А там 24...14...10... ))))) Относительно последнего, который я успел применить (407) четырёх кратный рост по DMIPS.

Ну да. Я же написал в первом посту. И объяснил почему так.

То ли вы не можете внятно описать что вас не устраивает, то ли мы понять. Я так точно не могу понять. Если вы опрашиваете узел, то могут быть биения. У вас асинхронный узел, по отношению к основному кварцу. Вы работаете на основном таймере при чтении RTC у вас будут биения. То есть раз в n число чтений либо проглатывать секунду либо удваивать.

Непонятно, что именно вы называете ошибкой. В таймере ошибки точно нет. Наверное она у вас в голове. Если вам непонятно почему при кварце 32768 задаётся 32767, то тут стандартный подход. При задании 0 = делит 1:1. Иначе получится как в MSP430FR433 к примеру. При задании 0 и 1 делит на 1. При задании 65535 делит на 65535. Поделить на 65536 не получается, хотя таймер 16-ти битный. Вопрос: так в каком CPU косяк? А реализуется эта фича просто. Сравнение производится после вычитания. Задаётся предделитель как правило так: TIM_PWM_LIGHT->PSC = FPWM_PSC-1; // Прескалер TIM_PWM_LIGHT->ARR = FPWM_MAX-1; // Частота ШИМ 200 Гц Там, насколько я помню частота таймера в 2 раза выше чем частота шины к которой он подключен. 32768 = 2^15. То есть по сути 16-тый разряд двоичного счётчика. Вот на что вам намекали.

Точнее 5. )) heap_1 - the very simplest, does not permit memory to be freed • heap_2 - permits memory to be freed, but not does coalescence adjacent free blocks. • heap_3 - simply wraps the standard malloc() and free() for thread safety • heap_4 - coalescences adjacent free blocks to avoid fragmentation. Includes absolute address placement option • heap_5 - as per heap_4, with the ability to span the heap across multiple non-adjacent memory areas

Тем более что там пять строчек кода. Вам надо тупо настроить 1 раз регистры (зачем вызывать для этого какие-то левые п/п, один бог знает) и всё. Далее вы просто обрабатываете сообщения поступающие в ваш ящик в прерывании.

Рассказывали как работает производственная линия филипс морис, по сигаретам. Там распределённая периферия. Передаются пакеты контрольные - получается ответ. Измеряется время между запросом и ответом. Таким образом определяется задержка на получение команды по всей линии. Далее процессор при работе отдаёт команды с учётом задержки. :rolleyes: Понятно, что это при синхронной работе. При асинхронной, или плавающей задержке такое невозможно. В Ethernet, как я понимаю, даже при минимальной загрузке, имеется вероятность задержки произвольной при передаче пакета.

Прошу прощения что ввёл Вас в заблуждение. Ошибка была при объявлении сегмента (в pragma директиве). xcl файл написан правильно. Пока не глянул адреса переменных - не понял. В результате компилятор размещал данные в ОЗУ а не в сегменте INFOA. ОЗУ в LPM3.5 разрушается. Всем спасибо.

Кстати как раз в кубе инициализация тактовой неполная. И требует правки руками как правило. По крайней мере для 32F4.. Ну а если захочешь какие-нибудь мелочи, или кварц поставил не "тот", то поехал с кубом бороться. Хотя саму библиотеку посмотреть можно. У меня сделано так: пытаюсь проинитить кварц -> если не нахожу оного, то запускаюсь от внутреннего и выставляю признак ошибки. Потом тоже и с часовым.

Доброго времени суток. Собственно проблема в заголовке. Для одной темы требуется низкое потребление. Опираясь на предыдущий опыт, реализовал. К сожалению не хватает BackUp памяти. Стал использовать FRAM из INFOA сегмента. Не вижу противоречий с даташитом. По потреблению она не больше. Потребление в режиме записи не нашёл. Но судя по косвенным признакам оно не возрастает. Количество циклов - достаточное. Возникает проблема при переходе в LPM3.5. Весь сегмент INFOA портится. Не могу понять причину. Раньше я там записывал калибровку и всё работало. Как стал активнее писать - разрушается. То что дело в LPM3.5 проверил. Заменяешь переход на LPM3 и всё работает. Если стоит 3.5 то по выходу из сна вижу искажённые данные. Из мыслей, может надо выждать какое нибудь завершение записи? Нигде не нашёл какого либо упоминания об этом. Перед переходом в LPM3.5 проверял SYSCFG0. Бит DFWP установлен. То есть модификация запрещена. Может кто подсказать что?

В доке на МК имеется достаточно детальное описание как программируется дисплей. Вы сможете слегка уменьшить отображаемое поле. Но в целом, TFT дисплей это всё же не телевизор и поля с краёв будут небольшими. То есть я думаю вас это не спасёт. Хотя я не пробовал, честно скажу.

Более 20 лет назад предприятие, на котором я работал выпускало линии разварки выводов м/х. Гранитные плиты дошлифовывались вафельным полотенцем. Несколько рубиновых лазеров. Некоторые линии поставлялись на экспорт. В том числе в швецию. И это только одно из изделий. Сейчас там рынок. Шмотками торгуют. Станки и оборудование в 90-ые продали в Польшу и Индию. Сложно сделать рывок в одной, отдельно взятой области. Что-то можно производить на тайване, но производить ты будешь лишь устаревший кремний. Это же очевидно! Надо либо взращивать монстра типа Intel, либо государство должно помогать в фундаментальных вложениях. На разработку новых линий уйдут десятки лет. Но нет другого пути. А государство только бабки драть научилось...

Ну да неплохо. У них сейчас 2 маркировки. По одной из них, там где "IN" лидирующая - шаг дюймовый. Мне вообще кажется, что надо в некоторых вопросах перестать ходить "своим путём". А именно в тех вопросах, где плетёмся далеко в хвосте. Основоположник задаёт стандарты. Поэтому если хочешь их задавать, то надо вырваться в лидеры.

Так подождите, а вам не встречалась описанная мной ситуация. То есть вы закладываете отечественную микруху, а приходит аналог зарубежный? У нас сейчас Интеграл даже не парится ... Сразу и маркировку наносит импортную типа IN74HC... ))

Ещё вопрос будет ли наше лучше серийного ширпотреба того же st. Одно дело если требуется радиационная стойкость, а в изделия запихивается ширпотреб, другое если вопрос в надёжности изделия и применяется тот же st с avtomativ и ещё более жёсткими стандартами. Закупается по разным каналам и электроника военной приёмки. А с другой стороны, бывали случаи когда на предприятии том же ангстрем закупается МК а отгружается импортный аналог.

Вы бы почитали мой пост предварительно. Тогда бы поняли что DMA2D целесообразен только в режиме 16 или 24-битного цвета. ... Давайте поясню на пальцах. В МК есть 2 совершенно независимых узла: LTDC (контроллер дисплея) и DMA2D (ускоритель, но фактически контроллер прямого доступа к памяти позволяющий работать с прямоугольными областями памяти). LTDC фактически отображает область памяти (видеобуфер) на экран. А с помощью DMA2D вы можете модифицировать ваш видеобуфер. То есть сам DMA2D к дисплею никакого отношения не имеет. Поскольку в экране у вас ничего не хранится, то видеобуфер должен быть обязательно. Там находится то, что отображается на дисплее. Самый экономный режим для вашего МК - 8 бит (L8 - 256 цветов из палитры 16 бит или аналогичный AL44 - палитра 16 цветов с 16 градациями яркости). Для реализации потребуется 800*480 = 384 кб. У Вашего контроллера лишь 256. Выхода 3. 1) Добавить память внешнюю. Но на проводах не запаяешь. Работать не будет. Придётся переразводить плату. 2) Применить дисплей с меньшим разрешением. Например 4.3" 480*272 = 130кб. Качество картинки будет описанное выше. DMA2D будет использоваться ограниченно (только копирование и заливка). 3) Применить дисплей с собственным контроллером типа 1963 или другим. Там память находится на самом дисплее. DMA2D в этом случае теряет смысл.

Скорее всего расчёт берётся по "типовому подключению". То есть считается что выход нагружен на емкостную нагрузку. Ёмкостью является, в том числе, ёмкость монтажа, затвор полевого транзистора и т.п. Грубо говоря, SPI вход микросхемы, тоже является емкостным (КМОП). Далее чем выше частота переключения на емкостную нагрузку и чем круче фронты, тем больше потребление. Ёмкость обладает малым омическим сопротивлением и увеличение выходного тока увеличит потребление. То есть, как я понимаю: a) Влияние будет зависеть от схемы и разводки. б) Влияние будет больше сказываться на высоких скоростях.

Ну я вот думаю.. Каким образом они видят, что что-то не то? Я вижу только один вариант. Планировщик при переключении контекста анализирует указатель стека на предмет нахождения его в границах памяти выделенной для данной задачи. Ну и если он вылез, то хук. Надо посмотреть настройки этого хука.

Посмотрите как данная фича во FreeRTOS реализована. Просто и красиво. Есть несколько вариантов. 1. Куча забивается 55 при инициализации и ты смотришь глазами на сколько она занята. 2. При переключении задач планировщик смотрит значение указателя стека, на предмет "вылезания" ( думаю у вас этот случай). Теоретически может не проявляться. Так как надо чтобы совпали 2 события. ... Вы можете всунуть аналогичную хрень в планировщик RTX и посмотреть. Возможно у вас в задаче используется SP нестандартно местами, и самого "нарушения" нет?

Насколько я понимаю, достаточно просто считать. Помнится чтобы пропускную ОЗУ увеличить вообще регенерацию отключали, при непрерывном чтении.

Да посмотрел, там 0 ws до 24МГц и 1ws выше. Ширина шины флэш 32 бита всего, правда есть prefetch bufer небольшой... В целом достаточно убого, по ускорению выборки.

В статье указано, что 16 машинных циклов пройдёт от прерывания, до выполнения 1 команды прерывания. То есть до входа в прерывание. Сама п/п прерывания, должна сначала сохранить текущий контекст в стеке (текущие регистры) ну и возможно что-то проинициализировать (смотря как вы программу написали), после чего она приступит к выполнению программы пользователя. Учитывая, что 16 тактов это уже 333 нс, то 800 в целом неплохо. Не совсем понятно откуда у вас существенный выигрыш при размещении прерывания в ОЗУ. По моему у вас должно бы 0 циклов ожидания, при такой тактовой. Ну и 1.5 мкс на выполнение тоже неплохо... )) всё относительно. Еще недавно это было совершенно недостижимо. ))) А в целом если у вас критическое исполнение, причём масштабы на микросекунды, то необходимо использовать аппаратные ресурсы. Джитер образуется, за счёт того, что некоторые комманды выполняются > одного такта, а также за счёт работы конвеера, на сколько я понимаю.

Немного не в тему, конечно, но синхронизировать часы по RS485, это не самый точный способ. А использовать ds1306 вообще странновато, на мой взгляд. Я конечно не знаю полного техзадания ... На своих образцах калибровал часы. Можно добиться точности пару секунд в месяц. Собственно реальная точность указана в руководстве по эксплуатации. Если требуется совместная работа (то есть взаимная синхронизация) то лучше синхронизировать по какому-нибудь высокоскоростному интерфейсу. Обычно используется GPS, либо ethernet.