jcxz

Неск. лет назад реализовывал на LPC1768 SMTP-клиент (поверх своего TCP-стека). Самостоятельно конечно, без чьих-то исходников. Смотрел тогда тоже в сторону добавления возможности работы через шифрованное соединение. Но тоже понял, что там всё непросто. И очень мало толковой документации по этому делу - это самое главное! В то время как нешифрованный SMTP разжёван вдоль и поперёк в разных источниках. Именно это меня тогда и остановило. В результате нашёл достаточно много нешифрованных SMTP-серверов и решил пока отложить эту тему до тех пор когда реально припрёт. Если нароете хорошее описание SMTP-протокола через защищённое соединение - выкладывайте. Думаю тоже когда-то придётся вернуться к этой теме. Как я подозреваю: там главное установить и поддерживать шифрованное соединение, а уж протокол SMTP через него - точно такой-же как и через открытое.

Достаточно. О чём я выше и написал. Но ТС хочет красиво. А красиво это - или перегрузить в этом union-e/struct-е операторы присваивания/приведения типа или воспользоваться соответствующим префиксом компилятора если таковой есть (как в IAR).

Если компилятор поддерживает соответствующий префикс, создать пакованные типы: typedef __packed u16 u16p8; typedef __packed s16 s16p8; typedef __packed u32 u32p8; typedef __packed s32 s32p8; typedef __packed u64 u64p8; typedef __packed s64 s64p8; либо, если в компиляторе нет соответствующего префикса, создать соотв. классы и перегрузить в них операторы присваивания и приведения типа: struct u32p8 { u8 bytes[4]; operator u32() const { return u32load(&bytes); } u32p8 & operator =(u32 val) { u32save(&bytes, val); return *this; } }; где: u32load() и u32save() - макросы, которые на процессоре поддерживающем невыровненный доступ определены просто как чтение или запись значения по этому адресу, а на процессоре не поддерживающем невыровненный доступ - они осуществляют побайтное чтение/запись слова.

А в чём именно трудность? Завести на все модули параллельно один сигнал и по этому сигналу стартовать измерения.

Нет. Вы очевидно полагаете, что ОС это нечто такое, божественное, состоящее не из команд, действующее непостижимым образом. Нет, всё проще - ОС состоит из тех же самых команд, что и остальной код и переключение контекста (которое есть и в ОС), никто не мешает сделать вручную. И принудительности никакой не надо - переключение надо делать там-же, где у ТС-а находится switch/case (ну или вызов очередной функции из таблицы), только вместо этого будет сохранение контекста точки вызова (регистры, указатель стека, PC) и восстановление контекста тела автомата. И в результате получаем тело автомата в виде линейного кода, а не разорванного на много частей switch/case-ами и не распиленное на отдельные функции. И таких автоматов может быть сколько угодно - для каждого свой стек. Единственное что правда, так это то, что тело такого автомата будет похоже на задачу ОС с корпоративной многозадачностью.

Причём тут RTOS?? Где Вы её узрели в моём сообщении?

А с помехоустойчивостью? Как Ваш девайс отнесётся к воздушному разряду 15кВ в щуп? :smile3009:

Так может тогда уже FlexRay? :)

А теперь подайте на Ваш блютуз несколько сотен вольт как хочет ТС. И конечно - держать его при этом надо руками в гараже на сыром цементом полу. :smile3009:

Есть гораздо более наглядные способы организации автоматов состояний чем switch/case или туева хуча функций. Например - переключение стека, когда значениями автомата состояний становятся значения PC (или как там в AVR называется счётчик команд?) И код автомата выглядит совершенно линейным и простым. Нет. PC - вот лучшее место для хранения состояния автомата состояния! :yeah:

Похоже Вы правы - никаких аргументов не приемлет. Непонятно - зачем тогда вообще спрашивал?

Было как-то у меня подобное на XP. Решилось обновлением FTDI-шных дров на последние дрова скачанные с сайта ftdi. По идее любая терминальная программа работает на пользовательском уровне привилегий и не может привести к синему экрану чтобы она не делала. В крайнем случае - она просто будет закрыта по "Приложение выполнило недопустимую операцию и будет закрыто". К синему экрану может приводить некорректная работа каких-то дров. Да и не было в сообщении ТС-а ничего о используемом приложении на компе. С чего Вы решили, что это терминалка?

Из личного опыта: В случае, когда работодатель организует корпоративный автобус, он (доморощенный работодатель конечно) любит делать так, чтобы этот самый автобус приезжал на работу скажем за полчаса (а то и больше) до начала рабочего времени. И аналогично - вечером. А получающаяся каждый день переработка чтобы не учитывалась как гибкий график.

Осцилл по любому со спичечный коробок не получится - одних входных аналоговых цепей сколько будет. Но если использовать встроенное АЦП - и даже по размеру платы всё равно меньше будет чем на PIC с неск. внешними.

а) Читайте внимательнее - фраза была про Ваш приёмник, где 4 чипа (2памяти+декодер+МК) можно заменить одним МК. б) Встречали. Вас уже известили об LPC4370 - значит он Вам известен B)

Т.е. - Вы уже выбрали это странное решение и никаких других не рассматриваете? Почему? Обычно нормальное решение задачи начинается формированием нескольких путей решения и затем - анализом плюсов и минусов каждого пути и выбором оптимального. Ваш выбор ничем не обоснован (как и выбор базы для приёмника, где всю Вашу схему можно заменить одним МК Cortex-M вместо кучи чипов).

И что вы этим хотели сказать? Я думаю - тут каждый сможет написать GetSntpTime() что из того? Вы лучше вернитесь к теме топика, как советовал модератор, и изложите результаты решения задачи осциллографа: какую выбрали элементную базу? какие решения по функциональной схеме? какие характеристики осциллографа решили реализовывать? Схема подключения АЦП (если внешнее), расчёт по загрузке процессора, как будете реализовывать синхронизацию (самый требовательный к быстродействию процессора участок)? ТЗ хоть составили? :laughing:

Да, Вы правы - очередное хамло.... В игнор.

А как тогда данные пересылаются в LCD? Просто пиксель за пикселем строка за строкой вся картинка сразу? И какие сигналы управления? Я думаю - можно. Изучить сигналы управления в EMC, сравнить их с сигналами LCD и подумать можно ли состыковать. А потом - просто скопировать весь объём данных как будто просто в память.

А некоторые кроме пустого трёпа и теоретизирования ничего реально сделать не умеют. И уже и MP3-плееры и приёмники (почему-то синхронизирующиеся по SNTP от радиостанции ) и осциллографы, из главных требований к которым - быстрое включение. Вобщем куча пустых слов, абсолютная некомпетентность в обсуждаемых вопросах - вот и всё. Я ещё в самом начале сказал, что ТС что-то реальное сделать не сможет и не будет. Просто заняться ему нечем...

Опять про нс.... Похоже Вы не поняли - я уже выше написал в чём у Вас проблема. Никто не меряет сигналы в десятки нс, измерителем с разрешением в десяток МГц. На какой частоте Вы думаете у Вас GPIO работает? B) Измерять время выполнения команд надо таймером, а не GPIO. Ну а если так хочется GPIO, то измерять только группу команд от 1000 и больше чтобы получить полезный результат.

На этом МК я получал частоты прерывания от таймера (с полезной работой внутри в десяток команд) до 500-600 КГц. И получал работающий ISR на частоте 200КГц с выполнением нескольких десятков команд внутри ISR с записью всех регистров в память и копированием до 2-х десятков слов ОЗУ-ОЗУ. Странно, что с вашим опытом в десятки проектов B) у Вас не получается гораздо более простая задача...

Да это Вы похоже издеваетесь, мозг тут всем выносите, "десятки проектов" и т.п. И при этом меряете команды дёргая ножкой и ещё про какие-то нс пишете!

Прям беда эти 250нс! :smile3009: И что за задача такая, интересно, требующая прерывания в 1МГц?? Ага "реализованы десятки проектов" и после этого не знаете, что получить такие частоты прерывания крайне проблематично - не знаете?? Имхо - это вроде как почти самоочевидно. Сомнения берут в десятках проектов... И каким образом кстати произведены все эти замеры с точностью до десятков нс? Вы умудрились воткнуть щуп осциллографа прямо в AHB? :blink: Поделитесь вашим бесценным опытом! B)

Где написано? И что? 12 - только вход + прерывание выполняющейся в фоне команды + время на загрузку кода (prefetch) ISR + выполнение ISR + выход ISR + prefetch фонового кода. И prefetch - вещь длительная из из flash. У Вас откуда прога выполняется? Наверняка из флешь. И какая частота флешь?