Pridnya

Между двумя модулями нет расхождения 100 нс. Там меньше 10 нс. Вот картинка с двух GL8088S. Здравствуйте, Владимир. Есть вопрос "как отключить сообщения GPGST"? Про сообщения GST в описании сообщений и команд v1.1 не упоминается, а модуль выдает это сообщение. Вот у меня сообщения в эксперименте с выдергиванием антенны (временно). Широту и долготу я заменил знаками вопроса. Включил выдачу RMC и ZDA, а GST (Статистика ошибки определения местоположения) мне пока нужна, нужно только дата и время: И еще было бы интересно, как для сообщения ZDA установить часовой пояс (в сообщении это поле равно нулю)? Про часовой пояс тоже не упоминается.

У меня Windows x32, я скачал с сайта дистрибутив Setup_EmbeddedStudio_v310i_win_x86.exe. Дистрибутив сохранился в каталоге, путь к которому содержит кириллицу, пара каталогов: Из каталога с таким путем установка не пошла, отобразилось сообщение с каракулями вместо кириллицы, скриншот Instalation Error. Я скопировал дистрибуив на диск С и установил оттуда, установилось. Я уже нажимал, но оригинальный пример HelloWorld не собирается, появляется ошибка "Error Starting Process...". Может, в этой IDE еще что-то нужно настроить. Я только установил, запустил IDE, затем нажал кнопку Build и всё. Все, вопрос решился. По умолчанию SES располагает каталог с примером в каталоге C:\Documents and Settings\Demetrius\Мои документы\SEGGER Embedded Studio Projects\Hello\ Путь содержит кириллицу. Если создать новый проект в каталоге, путь к которому не содержит кириллицу, например, C:\Documents and Settings\Demetrius\SES\ то все работает:

Здравствуйте! Есть IDE от Segger - Segger Embedded Studio, можно использовать для Cortex M0-M7. На сайте написано, что можно в некоммерческих целях можно использовать, например, дома в образовательных целях, для этого достаточно лицензии Non Commercial License. Сама IDE устанавливается и открывается, но при попытке собрать пример появляется сообщение "не найдена коммерческая лицензия", а она мне не нужна, я хочу не коммерческую. Где брать?

Спасибо! Как раз метров 10-20, не больше. :rolleyes: А я ищу, одно старье какое-то попадается вроде SN75ALS123 (Permits Digital Data Transmission Over Coaxial Cable, Strip Line, or Twisted Pair), как раз на 50-ти омный кабель работает. DataSheet SEPTEMBER 1987 − REVISED FEBRUARY 1993 и уже тогда NOT RECOMMENDED FOR NEW DESIGN. Ни разу не приходилось передавать PPS по коаксиальному кабелю.

Добрый день, Владимир! Модуль ML8088 работает, сигнал 1PPS есть. А как усилить сигнал PPS с выхода GL8088S/ML8088S чтобы его можно было раздать по коаксиальному кабелю? Т.е. примерная структура: ML8088 выход PPS->Усилитель->Согласующее устройство 50 Ом ->ВЧ-разъем BNC. Т.е. какой усилитель можно применить для этих целей? Может быть вы с каким-то усилителем уже тестировали?

Для этого нужно настроить какой-нибудь UART на вывод, переопределить макрос, который выводит отладочные строки в конкретный UART, и в настройках стека разрешить вывод отладочной информации вообще и в конкретных ситуациях.

Укажите хотя бы версию LwIP, а то люди отвечают даже не зная какая у вас версия (1.3.2...2.0.0). :rolleyes: И версию компилятора тоже можно указать.

Спасибо! В случае SPI для нескольких микросхем потребуется дешифратор 3-8 для CS и три лини SI, SO, SCK. Получается, что можно и I2C использовать с прерываниями, но лучше еще и с RTOS, если я правильно понял. Про принцип, естественно, слышал, сам использую USART передатчик по прерываниям или через DMA. Спасибо!

Я вообще шину I2С использовал только на MCU PIC16 от Microchip, да и то программный вариант: выделяешь два вывода и работаешь. Медленная она, но полезная, когда нечасто нужно опрашивать несколько микросхем на шине I2C или в пределах печатной платы связать все узлы, поддерживающие I2C. А вообще использую интерфейсы UART и SPI, они быстрые (несколько мегабит или несколько десятков мегабит в секунду), по ним можно передавать большие блоки данных, и здесь удобно пользоваться прерываниями на низких скоростях и DMA на больших. Но вот совсем не пойму, а какой смысл использовать на медленной шине I2C прием и передачу по прерываниям, и еще DMA для I2C использовать? Поясните в двух словах, если не сложно! :rolleyes:

Да ладно! Вот это "simple" каждый понимает по-своему, в меру разумения. Код клиента на Си не привязан к ядру (к системе команд), даже к периферии не привязан, зато привязан к конкретному TCP/IP-стеку, который портируется для конкретной архитектуры (и не всегда есть порт для конкретной архитектуры). Для того же LwIP есть несколько вариантов клиента (с использованием RTOS и без неё) и т.д. А у Microchip клиент за 10 лет практически не изменился, в последней версии microchip\mla\v2016_08_08\framework\tcpip\src\sntp.c практически тот же что и в 2007-м году файл, только нет строк об авторах и дате. Стыдно, наверное. :rolleyes:

Виноват, товарищи! Это я использовал один из режимов работы PTP-clock, а там есть еще один, как раз с учетом отношения частот 168/50=3,36 и тогда часы идут очень хорошо. Вот код инициализации: void InitPtpClockStm32F407(void) { ETH->PTPTSAR = 0x4C30C30C; // 2^32/(168/50) = 2^32/3.36 = 1278264076.19 округляем 0x4C30C30C ETH->PTPSSIR = 20; // 20 наносекунд. /* In Fine update mode, the value in this register is added to the system time whenever the accumulator gets an overflow. Fine update mode: значение ETH->PTPSSIR добавляется к системному времени каждый раз когда аккумулятор переполняется. */ ETH->PTPTSCR |= ETH_PTPTSCR_TSE; // Time stamp enable. ETH->PTPTSCR |= ETH_PTPTSCR_TSSTI; // Time stamp initialize. ETH->PTPTSCR |= ETH_PTPTSCR_TSFCU; // Fine update method. ETH->PTPTSCR |= ETH_PTPTSCR_TSARU; // Addend register update. Если закомментировать, то часы не идут. ETH->PTPTSCR |= ETH_PTPTSCR_TSSSR; // digital rollover control, 0 - 999 999 999. ETH->PTPTSCR |= ETH_PTPTSCR_TSPTPPSV2E; // Time stamp PTP packet snooping for version2 format enable. ETH->PTPTSCR |= ETH_PTPTSCR_TSSIPV4FE; // Time stamp snapshot for IPv4 frames enable. } Эти регистры хранят секунды и наносекунды. sprintf(LCD.line_1,"%d%c%d",ETH->PTPTSHR, '_',ETH->PTPTSLR);

Не понял вашего вопроса. IEEE1588 PTP v2 - новая для меня тема, да и не только для меня. Мало с кем поговорить на эту тему можно, поэтому приходится искать ответы в описаниях микроконтроллеров разных производителей, описании оборудования (PTP-серверы для локальных сетей). Сама тема очень интересная и нужная: промышленные сети как раз используют этот протокол (и импортные серверы точного времени в основном, ценой 5-10 k$), а у нас в России еще SNTP не все используют - синхронизируются по RS485. Есть люди, которые думают, что до 1 секунды (показометр) достаточно, а там рассинхронизация в несколько секунд. И вряд ли кого-то пустят со своим оборудованием на объект, где используется IEEE1588, если оборудование не поддерживает этот стандарт.

Вы снова пошутили? Или я опять что-то не понял? В 2012-м году я использовал Microchip Solutions v2010-10-19\Microchip\TCPIP Stack\, эта библиотека у меня и сейчас установлена. Она содержит исходник SNTP-клиента на Си - файл sntp.c, в котором есть запись Она означает, что SNTP-клиент в исходниках у Microchip есть с 2007-го года, т.е. почти 10 лет. Я вообще знаком с продукцией Microchip, с неё и начинал, а с STM32 последние несколько лет работаю. А сложности там есть и SNTP-клиенты бывают простые и посложнее, как и программисты. А вопрос попал в тему "ARM" из-за того, что SNTP-клиент для LwIP-стека может отличаться от SNTP-клиента для Microchip TCP/IP-стека и т.д. И чем выше производительность микроконтроллера, тем выше достоверность и точность установки времени (мне нужно не хуже 0,01 сек). Для меня есть разница. И мне такие ответы не интересны. В первом посте я немного ошибся: SNTP-клиент вставляет свою метку времни в запрос в поле u32_t transmit_timestamp[2], а получает её обратно в поле u32_t originate_timestamp[2] (NTP-клиент Windows переставляет метку).

А я сегодня случайно обнаружил что описание PTP IEEE1588 в LPC43xx (NXP) повторяет абзац из STM32F74x (ST), рисунок один и тот же и абзац практически точь-вточь. Может, не такие они и разные.

Попробовал поработать с PTP-таймером STM32F407. Он состоит из двух счетчиков: 1) счетчик секунд uint32_t 2) счетчик субсекунд uint32_t c верхним значением 0x7FFFFFFF или 999999999 (зависит от настроек), при этом теоретическое разрешение по времени равно: 1) 1/(0x7FFFFFFF+1) = 0.465 наносекунды. 2) 1/(999999999+1) = 1 наносекунда. А правктически этот счетчик инкрементируется на определенное значение каждый период HCLK, которая у меня равна 168 МГц - максимальное по DataSheet. PTP-clock инициализируем (хоть с нуля) и включаем, они идут даже без подключения к сети Ethernet. Особенность у часов такая: каждый клок HCLK значение счетчика субсекунд увеличивается на заранее заданное значение в регистре ETH_PTPSSIR (Ethernet PTP subsecond increment register). Для случая, когда максимальное значение счетчка субсекнд равно 0x7FFFFFFF и тактовая частота равна HCLK равна 168 МГц значение ETH_PTPSSIR должно быть равно: 0x7FFFFFFF / 168000000 = 12,78 округляем до 13-ти. Из-за этого округления прецизионные часы будут идти неточно без внешней синхронизации. Получается, чтобы они шли точно тактовая частота HCLK должна быть такой, чтобы значение 0x7FFFFFFF / HCLK было целым. Не понимаю, почему так сделано. Ведь с микросхемы PHY LAN8720A на STM32F407 подается опорная частота 50МГц, почему бы не сделать тактирование PTP clock от этой частоты. Переключаем счетчик на верхнее значение 999999999 и выбираем частоту 50 МГц и часы бы шли более менее точно. PS: Получается, что никакого смысла использовать PTP-clock совместно с SNTP-клиентом нет, тем более, что формат меток времени NTP-timestamp не совместим с PTP-timestamp (для NTP субсекунды 0...0xFFFFFFFF, для PTP субсекунды 0...7FFFFFFF или 0...999999999). Я-то думал, что форматы меток совпадают и можно копировать метку из NTP в PTP, а здесь еще дополнительные преобразования нужны. Буду использовать системный таймер, в нем тактировать UnixTime и счетчик миллисекунд.

Автор SNTP-клиента он же является автором многочисленных правок LwIP-стека, его имя присутствует в файлах. И я ожидал, что это толковый товарищ, а оказывается за ним все нужно проверять. А вообще, я пишу свою реализацию, хочется учесть недостатки существующих SNTP-клиентов. Я вроде не просил. И с SNTP-клиентом знаком. В последней версии MLA Microchip дает исходники простенького такого клиента. Вот мое мнение по этому поводу. Меня интересует, а как в MPLAB Harmony c SNTP-клиентом дела? SNTP-клиент - вещь абстрактная, он не знает о существовании микроконтроллеров, не знает на какой архитектуре запущен. Но SNTP-клиент для PIC-ов есть и выложен он в mla\v2016_08_08\framework\tcpip\src\sntp.c. Но он совсем простой, т.к. авторы предполагали, что он будет работать даже на PIC18. Но после PIC18 есть же еще PIC24, PIC32MX и PIC32MZ, и не совсем правильно для PIC32 использовать клиент со времен PIC18 (те же исходникик). Если архитектура микроконтроллера позволяет, то можно и улучшить SNTP-клиент, повысить точность. PS: Полно простых реализаций SNT-клиентов, которые не проверяют, когда последний раз синхронизировался сам сервер, не вставляют в запрос свою метку времени, не учитывают субсекунды (до секунд и хватит), не учитывают время задержки, а ведь SNTP позволяет получить точность 1-50 мс от сервера в Интернете и до 0,2 мс от сервера в локальной сети. И тоже называются SNTP-клиентами.

Не ожидал такой лажи от создателей примеров lwIP contrib-1.4.1, sntp.c. Клиент получает структуру (ответ на запрос с метками времени): #define SNTP_OFFSET_ORIGINATE_TIME 24 #define SNTP_OFFSET_RECEIVE_TIME 32 #define SNTP_OFFSET_TRANSMIT_TIME 40 ... struct sntp_msg { PACK_STRUCT_FIELD(u8_t li_vn_mode); PACK_STRUCT_FIELD(u8_t stratum); PACK_STRUCT_FIELD(u8_t poll); PACK_STRUCT_FIELD(u8_t precision); PACK_STRUCT_FIELD(u32_t root_delay); PACK_STRUCT_FIELD(u32_t root_dispersion); PACK_STRUCT_FIELD(u32_t reference_identifier); PACK_STRUCT_FIELD(u32_t reference_timestamp[2]); // Время синхронизации сервера. PACK_STRUCT_FIELD(u32_t originate_timestamp[2]); // Метка времени клиента (для проверки ответа на свой запрос) PACK_STRUCT_FIELD(u32_t receive_timestamp[2]); // Время получения запроса сервером PACK_STRUCT_FIELD(u32_t transmit_timestamp[2]); // Время на момент отправки ответа сервером. }; ... static void sntp_recv(void *arg, struct udp_pcb* pcb, struct pbuf *p, ip_addr_t *addr, u16_t port) { ... // Создается новый массив для полученной эталонной метки времени. u32_t receive_timestamp[sNTP_RECEIVE_TIME_SIZE]; ... /*И в новый массив копируется метка "Время получения запроса сервером", при этом сколько времени сервер потратил на обработку запроса никого не интересует. А другие SNTP-клиенты копируют "Время на момент отправки ответа сервером", в этом случае задержка сервера не имеет значения.*/ pbuf_copy_partial(p, &receive_timestamp, SNTP_RECEIVE_TIME_SIZE * 4, SNTP_OFFSET_RECEIVE_TIME); // Далее следует установка времени. sntp_process(receive_timestamp); И еще одинаковые длинные имена используют внутри структуры и во временном массиве receive_timestamp[]. Берут не ту метку и заведомо ухудшают точность. И на этом нам предлагается учиться.

Еще один "велосипед". Не очень понятно, почему вы вместо функции strftime() стандартной библиотеки time.h пишете свою, делающую то же самое. Или не знали о её существовании? Какой смысл? И за 4 года никто не спросил и не поправил. В предыдущем посте кто-то даже просветлился. А что еще написать на такую портянку, когда сразу не въехал. time_t rawtime = 1480685759; // Fri, 02 Dec 2016 13:35:59 GMT struct tm * timeinfo; timeinfo = (struct tm*)localtime(&rawtime); char buffer [80]; strftime (buffer,80,"%d.%m.%Y %X",timeinfo); puts (buffer); // 02.12.2016 13:35:59 Ладно бы вы использовали какой-нибудь R32C Renesas и их компилятор NC100 в котором стандартная библиотека time.h вообще не реализована, но вы же отвечаете в теме по ARM, а в ARMCC хорошая библиотека. PS: И UnixTime в структуру руками не нужно переписывать (у вас 70 строк кода???): void sntp_seconds2tm(uint32_t sec32, struct tm* res)... Из NTP timestamp вычитаем разницу в секундах между 1970-1900 годами и используем стандартную функцию. PPS: Дальше черпать неохота, т.к. почерпнуть нечего.

Здравствуйте, товарищи! Использую стек lwIP 1.3.2, протокол SNTP (за основу взят sntp из архива contrib-1.4.1). Заполняю структуру sntp_msg, struct sntp_msg { PACK_STRUCT_FIELD(u8_t li_vn_mode); PACK_STRUCT_FIELD(u8_t stratum); PACK_STRUCT_FIELD(u8_t poll); PACK_STRUCT_FIELD(u8_t precision); PACK_STRUCT_FIELD(u32_t root_delay); PACK_STRUCT_FIELD(u32_t root_dispersion); PACK_STRUCT_FIELD(u32_t reference_identifier); PACK_STRUCT_FIELD(u32_t reference_timestamp[2]); PACK_STRUCT_FIELD(u32_t originate_timestamp[2]); PACK_STRUCT_FIELD(u32_t receive_timestamp[2]); PACK_STRUCT_FIELD(u32_t transmit_timestamp[2]); }; вставляю в неё свою метку времени originate_timestamp[] и отправляю её NTP-серверу (служба времени Windows), в ответ получаю такую же структуру с четырьмя метками времени. В файле sntp.c (из архива contrib-1.4.1) есть функция /* SNTP processing of received timestamp */ static void sntp_process(u32_t *receive_timestamp) { /* convert SNTP time (1900-based) to unix GMT time (1970-based) * @todo: if MSB is 1, SNTP time is 2036-based! */ time_t t = (ntohl(receive_timestamp[0]) - DIFF_SEC_1900_1970); #if SNTP_CALC_TIME_US u32_t us = ntohl(receive_timestamp[1]) / 4295; SNTP_SET_SYSTEM_TIME_US(t, us); /* display local time from GMT time */ LWIP_DEBUGF(SNTP_DEBUG_TRACE, ("sntp_process: %s, %"U32_F" us", ctime(&t), us)); #else /* SNTP_CALC_TIME_US */ /* change system time and/or the update the RTC clock */ SNTP_SET_SYSTEM_TIME(t); /* display local time from GMT time */ LWIP_DEBUGF(SNTP_DEBUG_TRACE, ("sntp_process: %s", ctime(&t))); #endif /* SNTP_CALC_TIME_US */ } Из этого кода следует, что метка времени receive_timestamp[] (момент времени, когда NTP-сервер получил запрос клиента) переводится из NTP timestamp в UnixTime и далее используется клиентом как "время сервера" (эталонное), при этом никак не учитываются два параметра из протокола SNTP (RFC1769 SNTP v3) - циклическая задержка и смещение времени (см.скриншот). Это авторы кода так упростили себе задачу и почему они так сделали? И как учесть циклическую задержку и смещение?

Чтобы управлять высоким уровнем нужно что-то подать на вход, должен быть источник напряжения. Чтобы управлять нулем достаточно чему-нибудь оборваться в схеме или замкнуть и вот он ноль, т.е. источника нет, а управляющий сигнал как бы есть.

Да, в этом файле если накосячить, то в HardFaultHandler улетает. :rolleyes: ; <o> Stack Size (in Bytes) <0x0-0xFFFFFFFF:8> ; </h> Stack_Size EQU 0x000003FF; 0x00000400 да хоть вот так AREA STACK, NOINIT, READWRITE, ALIGN=3 Stack_Mem SPACE Stack_Size __initial_sp Понятно, откуда у товарища ошибка появилась. Вообще и startup и scatter файл создаются IDE при создании проекта и ошибок с выравниванием нет.

Так в развитии темы "минимальный ток самоочистки" (удаленного концевика ) появится тема "напряжение пробоя оксидной пленки" или "процентное соотношение компонентов в сплаве из которого сделаны контакты реле". У меня PB2/BOOT1 подсоединен к GND через резистор 1кОм.

Сначала вы мне напомнили, что можно разрабатывать программы без IDE, затем посоветовали читать доку на предыдущую версию моего компилятора, а затем посоветовали поправить scatter-файл, ну я и подумал, что вы знаете, что там поправить в 14-ти строках включая комментарии. :rolleyes: Я вам scatter-файл, а вы "я не страна советов".

Пока ждал вашего ответа. Уже успел по вашей ссылке сходить, понравились регистраторы. Cortex A8 MCU, на Linux что ли (судя по объему ОЗУ на Linux)? Только что-то описания не нашел и в таблице про синхронизацию времени ни слова. :rolleyes: Вот мой scatter-файл (создается IDE при создании проекта) для проекта с симулятором, я в этом проекте всякие мелочи: Что в нем поправить?

Хорошо! Как мне (и другим желающим) смоделировать такую же ошибку при работе с ARMCC! Подскажите.