Д_М

Прошу прощения, но я себя недооценил. Нашёл сам. Это делается в Options >> Output converter. Может быть кому-то ещё это поможет. Программа загрузилась и работает. Лампочка мигает. 4000 рублей уже были потрачены не зря. Раз уж я открыл эту тему, с вашего позволения буду здесь задавать свои дилетантсткие вопросы. Вопрос номер 1. Где взять готовый, отлаженный проект с FreeRTOS для STM32F103 и IAR? Спасибо!

Приветствую! Прошу прощения, но вой вопрос настолько дилетантский, что не нашёл я ответа на этом форуме. Имеется компилятор IAR 7, отладочная плата STM32-P103 (https://www.chipdip.ru/product/stm32-p103), программатор ST-LINK/V2 (mini) (https://www.chipdip.ru/product/st-link-v2-mini?from=visited_product), загрузчик ST visual programmer. Последний признал и программатор и отладочную плату. Память программируемого контроллера считывается. Тем меня и заинтересовала эта отладочная плата, что к ней идёт тестовая программу. Компилятор эту программу признал, откомпилировал. Но самое интересное - а где исполняемый файл, который нужно загружать? Во-первых было создано две папки Flash Debug и RAM Debug. Ни там, ни там нет файлов в hex формата. Создаётся впечатление, что по умолчанию создаётся Debug формат, а не исполняемый. На IAR для AVR это переключается в Linker >> Output. Но здесь такого нет. ST visual programmer не признаёт файлы созданные компилятором. Ему надо только hex формат. Ни разу я не видел, чтобы компиляторы выдавали исполняемые файлы в другом формате. Заранее благодарен за помощь!

Просто фантастика! Получилось! Кто бы мог подумать, что из-за бессмысленной команды так всё может измениться. А ведь на Меге работало именно так. Спасибо Вам большое!

Пробовал, успокоения совести ради, включить фуз бит WDTON. Не получается даже залить программу через загрузчик. Когда вернул обратно, загрузка работает, программа работает. WDT завязан на UART. Сброс WDT производится после получение ответа по UART. Пока не подключено устройство по UART, программа работает. После первого ответа UART производится инициализация и сброс WDT. Таймаут 2 секунды для UART более, чем достаточно. Проверено многократно на Меге. Здесь же перегружается без видимой задержки.

Ошибочно указал 2,5 секунды. WDP0..2 = 1 то есть 2048K. На Меге примерно 2 секунды и получается. На AT90CAN128 сразу же перегружается, без видимой задержки.

Приветствую! Код, который давно использую на ATmega128 некорректно работает на AT90CAN128. Расчётный таймаут 2,5 сек, фактически многократно меньше. Измерить нет возможности. void WDT_res(void) { GI_disable; WDTCR |= (1<<WDCE) | (1<<WDE); WDTCR = 0x00; WDTCR |= (1<<WDCE) | (1<<WDE); WDTCR |= (1<<WDE) | (1<<WDP0) | (1<<WDP1)| (1<<WDP2); GI_enable; } Как ни вчитывался в мануалы, но не нашёл отличия между микроконтроллерами в механизме WatchDog. Где искать различия? Если вдруг есть отработанный код, заранее благодарен!

Приветствую! Нужна утилита, способная выступать в качестве TCP клиента и сервера. Что-то вроде вот этого https://www.hw-group.com/software/hercules-setup-utility Всем хороша эта утилита, но она не отображает принятые посылки в hex виде, а только в текстовом. А мне нужно протестировать устройство по MODBUS/TCP. А этот протокол двоичный. Вот и получается, что я могу отправлять запросы прибору в hex формате, а то, что прибор присылает, прочесть не могу. Есть кто-то знает программу, способную отображать принятые TCP пакеты в hex формате, подскажите, пожалуйста! Заранее благодарен!

Кто, что думает про вот это? https://www.segger.com/products/rtos/embos/ Это, скорее FreeRTOS, или скорее Linux?

Спасибо за спецификацию! Прямо, как мультфильме "Малыш и Карлсон" - "Она, такая толстая, хочет залезть в такую маленькую коробочку!" Как, столько всего, можно запихнуть в 8 байт посылки CAN? У интерфейса CAN не так много степеней свободы - 29 бит для идентификатора, и ещё биты управления. А в спецификации ни слова не сказано, как CIP увязать с CAN. Для того и придумали CAN, чтобы не обременять людей писаниной. Готовый транспорт для 8-ми байт информации. CIP - универсальный протокол, для которого не имеет значения, какой буде транспорт. Всё сказанное в спецификации CIP хорошо вяжется с Ethernet, но не с CAN.

Самое информативное, что нашёл мне Гугл, вот это http://can.marathon.ru/page/can-protocols/devicenet/spec Там сказано, что спецификацию можно приобрести. Действительно ли за описание протокола надо ещё платить?

Приветствую! Не удалось найти в сети спецификацию этого протокола. Сказано, что DeviceNet базируется на протоколе CIP (common industrial protocol). Его описание я тоже не нашёл. Проще ли в реализации DiveceNet, чем CANopen? Стоит ли связываться с DeviceNet, или лучше браться за CANopen?

Мораль: Надо учить железо и FreeRTOS! Правильно?

Правильно ли я понял мысль, что Embedded Linux настолько же RTOS, насколько и Windows CE?

Спасибо за поддержку! В подавляющем большинстве случаев, контроллер крана работает на 90%, как многоканальный преобразователь протоколов. А это самое слабое место банальных, общепромышленных PLC. PLC - это для элеваторов и котельных. Вычленить из CAN посылки полезные данные, масштабировать их, воткнуть их в MODBUS на Си дело плёвое. Но бывают задачи на кранах, где требуется много математики, в том числе и тригонометрии. Синусы, косинусы, квадратные корни нужно считать в реальном времени. Писать свои собственные шедулеры - дело неблагодарное. Я через это прошёл. Считал его идеальным, пока не столкнулся с проблемами надёжности. Рвал на себе волосы от непонимания, что я ещё недопонимаю. К счастью, мне пришло прозрение и я нашёл один крошечный изъян. А много и не надо, чтобы система была ненадёжной. Без шедулера мои проекты работать не будут - требуется по 20 таймеров. Процессора с таким количеством аппаратных таймеров не бывает. Значит, нужны программные таймеры. Web инструментарии не рассматриваю. Вот и получается, что у меня выбор не велик - либо FreeRTOS, либо Linux. Стоит ли сразу замахиваться на Linux? Или не выпендриваться, а браться за FreeRTOS? Если последний вариант, то какой камень для этого лучше подойдёт - STM, или LPC?

В данный момент я связан с подъёмными кранами. У меня есть аппаратное решение на AVR, которое содержит на борту CAN и много RS485. Работает все хорошо, не тормозит, но дни AVR сочтены. И ещё нужно Ethernet, Wi-Fi, USB. Интересует завершённое, промышленное устройство в корпусе на DIN рейку. Питание 24V DC. Обязательно трёхходовая гальваническая изоляция. То есть всё изолировано от всего - клеммы питания, процессор, интерфейсы. Блок питания процессора должен быть 4-х полюсный. На каждый интерфейс должен быть свой 4-х полюсный DC/DC. CAN желательно два. Но одного хватит. А RS485 надо много, как минимум, 6. Маловероятно, что найдётся такое готовое устройство. Рассматриваю устройство с двумя RS485. Если, вдруг, у кого-то есть устройство, удовлетворяющее таким требования, предлагайте. В разработку деньги вкладывать не буду. Скорее договорюсь с поставщиком вышеупомянутого устройства на AVR, о замене процессора на современный. Не делать буду это только после того, как освою ARM. Потому и спрашиваю мнение о кандидатуре на замену AVR.

Спасибо за поддержку! Сам учусь, как раз, на ARM7 - LPC2364. Попалось в руки неплохое устройство. Первые шаги сделал - загружать программу научился. В Keil делал простенькие программы мигания светодиодами, раскрутил менеджер многозадачности от Keil. Задействовал UART. Но последний так и не заставил работать должным образом. Не получилось у меня приручить буфер приёма-передачи. На AVR тоже есть буфер передачи, но только на один байт. Хватало! А у LPC2364 буфер шикарный, но не получилось извлечь из этого пользу. Поймал себя на мысли, что опять начинаю такой же путь, от само низа до самого верха, какой я проделал на AVR. Не хочется писать то, что было написано давным давно и много раз. Хочется взять операционку и не лезть в глубину. Если такое, конечно, возможно но uC! Желание слезть с ARM7 возникло по причине того, что уже очень мало информации по это контроллеру. А STM32F103 - самый обсуждаемый контроллер на этом форуме. Хочется подружить контроллер, IAR, FreeRTOS. Хочется быть независимым от производителя контроллеров. Напрашивается вывод, что изучать uC на самом нижнем уровне - дело неблагодарное. Для того люди и придумали драйверы, чтобы не подгонять каждый раз софт под железо. Нужен контроллер, для которого производитель написал API, которые хорошо дружатся и с независимыми компиляторами (Keil, IAR) и независимой операционной системой (FreeRTOS). Не хочется связываться с компиляторами и OS от производителя uC. Что посоветуете?

Приветствую! Перепала в руки серьёзная отладочная плата с LPC1768. На плате много чего ценного - CAN, Ethernet, Дисплей... Стоит ли учиться ARM на этом процессоре, или купить отладочную плату на чём-то более популярном, например STM32F103?

Приветствую! Просматривая темы форума, у меня сложилось мнение, что многие используют сгенерированные демо-проекты. Когда задействуется только один ресурс, всё работает хорошо. Но когда задействованных ресурсов более, чем один, начинаются зависания. Всё, как на СodeVision AVR в давние времена. Это и подвигло меня, в своё время, написать собственный диспетчер многозадачности, который я использовал много лет. Много чего полезного было написано. Но было бы глупо эти наработки переносить на ARM. В моих проектах одновременно работают оба UART, CAN, I2C и никаких зависаний. От ARM требуется ещё Ethernet. Нужно ли ARM изучать с самого низа, или можно писать на верхнем уровне с расчётом на OS? Очень много времени потратил на то, чтобы пройти AVR от низа до верха. Столько времени у меня уже не осталось. Для того и придумали OS, чтобы не изобретать то, что было уже изобретено и не один раз. Ведь пишут же люди программы для Windows на C Builder, не имея ни малейшего представления о том, как работает компьютер! Более того, старые программы, которые напрямую обращались к регистрам устройств, на современных Виндах не работают. В современных условиях всё только через системные функции. Дошёл ли ARM до этого? Или до этого ещё далеко и старый Modbus/master надо писать ручками?

Спасибо большое!

Только заметил, что если требуется 8 бит размер данных UART, то должны быть установлены соответствующие биты в регистрах UART. Если значения будут нулевыми, то размерность получится не 8, а 5 бит. Никогда не заморачивался по этому вопросу и всегда получалось 8 бит. Ни уж то StartUp устанавливает нужные биты, чтобы получился размер 8 бит данных?

Приветствую! Конечная цель - разместить код в загрузчике. Имеется загрузчик AVR230 http://microsin.net/programming/AVR/avr230...bootloader.html Проект имеет уйму настроек. Если что-то неудачно зацепить, концов не найти. Проект был изначально для IAR 2.28. Вроде бы получилось его адаптировать на IAR 6.40. Загрузчик работает, программы тоже. Проблема началась, когда к проекту загрузчика прицепил ранее отлаженный код. Линкер выдаёт следующее: Error[e16]: Segment CSTACK (size: 0xfc0 align: 0) is too long for segment definition. At least 0x2 more bytes needed. The problem occurred while processing the segment placement command "-Z(DATA)CSTACK+(RAM_SIZE-40)=RAM_BASE-(RAM_BASE+RAM_SIZE-1)", where at the moment of placement the available memory ranges were "DATA:142-10ff" Reserved ranges relevant to this placement: DATA:100-101 NEAR_Z DATA:102-141 RSTACK DATA:142-10ff CSTACK Error while running Linker В проекте есть файл .xcl, содержащий следующую строку: -Z(DATA)CSTACK+(RAM_SIZE-40-APP_SRAM_USAGE)=RAM_BASE-(RAM_BASE+RAM_SIZE-1) Несколько мудрёное уравнение. И самое главное, в нём есть неизвестное APP_SRAM_USAGE. Было замечено, что ошибка линкера появляется, когда в обработчике прерывания встречается обращение к структуре через указатель. Когда в теле обычной функции, то всё нормально. И чего линкер прицепился к обработчику прерывания?! #pragma vector=TIMER0_OVF_vect __interrupt void T0_mng (void) { char from_T0; from_T0 = TCNT0; while(from_T0 == TCNT0); TCNT0 += (255-T0_preload); //Syst->swe_Time = Syst->qty_SWI_executors++; /* Вызывает ошибку Линкера */ } В свойствах проекта нет возможности изменить размеры стеков. Получается, что всё определяется файлом .xcl Кто-то знает, как настроить стек данных? Заранее благодарен! bootldr.rar

Большое спасибо за помощь!

Когда делаю вот так Syst->SIO1.CRC = CRC(*Syst->SIO1.ptr, Syst->SIO1.CRC, SIO1_poly); Компилятор выдаёт следующее предупреждение: Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement D:\Work\MC\Gateway\Actual\Modbus_master1.c 170 И ещё выдаёт такое же предупреждение, когда делаю так if(Syst->SIO1.size < Syst->SIO1.amount) { } Не любит компилятор, когда в одной команде дважды фигурирует обращение к структуре, через указатель. Кажется распутал. Причина оказалась в том, что указатель размещается в строго определённом физическом адресе. __no_init volatile syspar *Syst @0x0100; Так нужно для совместного обращения из applycation и boot секторов. Если сделать просто syspar *Syst; То никакой ругани нет.

extern unsigned int CRC(char data, unsigned int crc, unsigned int poly); void MB1_Send(void) { union { char *ch; int *ui; }target; unsigned char amount = Syst->SIO1.amount, data = *Syst->SIO1.ptr; if(Syst->SIO1.size < amount) { Syst->SIO1.CRC = CRC(*Syst->SIO1.ptr, Syst->SIO1.CRC, SIO1_poly); // Ругается компилятор Syst->SIO1.CRC = CRC(data, Syst->SIO1.CRC, SIO1_poly); // Не ругается компилятор Тоже самое, но через промежуточную локальную переменную.

Объявления unsigned int *crc; syspar Sys; // Декларация структуры типа syspar __no_init volatile syspar *Syst @0x0100; Syst = &Sys; crc = &Syst->SIO1.CRC; // Ругается компилятор crc = &Sys.SIO1.CRC; Error[Pe513]: a value of type "unsigned int volatile *" cannot be assigned to an entity of type "unsigned int *"