Jump to content

    

Д_М

Участник
  • Content Count

    133
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Д_М

  • Rank
    Частый гость

Информация

  • Город
    Краснодар

Recent Profile Visitors

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

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

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

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

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

    Мораль: Надо учить железо и FreeRTOS! Правильно?
  7. LPC1768 для освоения ARM

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

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

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

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

    Приветствую! Перепала в руки серьёзная отладочная плата с LPC1768. На плате много чего ценного - CAN, Ethernet, Дисплей... Стоит ли учиться ARM на этом процессоре, или купить отладочную плату на чём-то более популярном, например STM32F103?
  12. Приветствую! Просматривая темы форума, у меня сложилось мнение, что многие используют сгенерированные демо-проекты. Когда задействуется только один ресурс, всё работает хорошо. Но когда задействованных ресурсов более, чем один, начинаются зависания. Всё, как на СodeVision AVR в давние времена. Это и подвигло меня, в своё время, написать собственный диспетчер многозадачности, который я использовал много лет. Много чего полезного было написано. Но было бы глупо эти наработки переносить на ARM. В моих проектах одновременно работают оба UART, CAN, I2C и никаких зависаний. От ARM требуется ещё Ethernet. Нужно ли ARM изучать с самого низа, или можно писать на верхнем уровне с расчётом на OS? Очень много времени потратил на то, чтобы пройти AVR от низа до верха. Столько времени у меня уже не осталось. Для того и придумали OS, чтобы не изобретать то, что было уже изобретено и не один раз. Ведь пишут же люди программы для Windows на C Builder, не имея ни малейшего представления о том, как работает компьютер! Более того, старые программы, которые напрямую обращались к регистрам устройств, на современных Виндах не работают. В современных условиях всё только через системные функции. Дошёл ли ARM до этого? Или до этого ещё далеко и старый Modbus/master надо писать ручками?
  13. Спасибо большое!
  14. Только заметил, что если требуется 8 бит размер данных UART, то должны быть установлены соответствующие биты в регистрах UART. Если значения будут нулевыми, то размерность получится не 8, а 5 бит. Никогда не заморачивался по этому вопросу и всегда получалось 8 бит. Ни уж то StartUp устанавливает нужные биты, чтобы получился размер 8 бит данных?
  15. Приветствую! Конечная цель - разместить код в загрузчике. Имеется загрузчик 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 Кто-то знает, как настроить стек данных? Заранее благодарен!