vptr

Кстати, здесь http://sapr-journal.ru/uroki-altium/sozdanie-topologicheskogo-posadochnogo-mesta-komponenta-v-altium-designer/ рассмотрен вопрос создания библиотечного компонента в альтиум применительно к пикадовскому опыту. Указаны отличия:

Как отключить сообщение об ошибке при старте Altium 19.1.9, - an error occurred while establishing a connection to the database. После установки алтиума сообщения не было и похоже появилось после выполнения пункта обучалки от алтиума при установке гостовских рамок: 4. В открывшемся диалоговом окне Load Preferences перейдите к папке C:\Users\Public\Documents\Altium\AD_GOST_QS\Templates\Preferences и откройте файл Default_GOST.DXPPrf.

максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx Раньше, по интернету народ искал самописные драйвера для COM порта, которые на некоторых материнках даже работали и позволяли взять скорость выше чем 115200. Сам когда-то такой драйвер использовал, но работает он не на всех материнках.

А когда в компьютере стандартный COM порт стал штатно поддерживать скорость 921600? И как же разбирать синхронизировать и гарантировать целостность данных без привета из 90-х

1-й вариант лучше. 2-й вариант не гарантирует стабильности или придется делать задержку большой, с запасом. У нас была похожая проблема. Гоняли по RS232 на 115200 каждые 5 мс 54 байта. Пакет был с контрольной суммой и заголовком. Так вот чтение этого пакета на компьютере, без потерь, могло зависеть от всего - число запущенных программ в виндос, скорости компьютера, приоритета потока в котором читается ком порт. На новых компьютерах потерь не было, на старых как повезет. Еще зависит как организовано чтение на компьютере, при использовании C#, на старых машинах возникает больше проблем.

не факт, что показания АЦП будет правильным в момент превышения напряжения по входу. При этом могут врать и другие входы АЦП, на которых нет превышения напряжения.

...

вот ветка http://electronix.ru/forum/index.php?showt...p;#entry1121225, пишут что 19 транзакций за 1 кадр. Вопрос в том, чтобы все это на компьютере собрать и не потерять.

Скорость со стороны ПК чем контролируется? Это самописное ПО или чего-то стандартное?

Транзакций несколько, но вот остается вопрос, стек от STM выполняет ли это? И сколько максимальное число транакций, после одного SOF?

А разве не эта запись #define CDC_DATA_MAX_PACKET_SIZE 64 /* 64 Endpoint IN & OUT Packet size */ ограничивает число байт, отправляемых за 1 мс по приходу SOF. Тогда получается максимальная скорость 1000*64 = 64 000 Байт = 64000*8=512 000 бит/сек

Давно это было... Режим настраивается AN_InitStructure.CAN_ABOM = DISABLE; Для STM32F407 при DISABLE передача останавливалась.

По-моему в STM32 "бесконечность" настраивается. Этот режим можно включить или выключить. Там по превышению ошибок, передача останавливается.

По 2 вопросу. Надо открыть пример из этой библиотеки в среде (я в Keil открывал), для своего процессора и для своего класса USB. Компильнуть, увидеть что все компелится и потом посмотреть в кейле, какие файлы с и h подлключены именно к данному примеру. Потом только эти файлы надо поключать к своему проекту. По 3 вопросу. Есть какое-то описание от STM, называется UM1021 http://www.st.com/st-web-ui/static/active/...rchtype=keyword Примеры от STM по части USB VCP c небольшой недоработкой, там надо добавлять кусок кода, чтобы не зависнуть в этом USB коде при определенных условиях. Для HID тоже слышал о проблемах. Как-то оно работает, но до оптимальной работы надо допиливать. Да и это не совсем библиотека, это пример с добавкой всякого ненужного кода для моргания свтодиодом и т.д. Весь этот мусор потом надо вычищать.

Тут не все понятно в исходных данных. Вы хотите одновременно передавать информацию от этих датчиков или есть какой-то протокол, делающий разделение по времени? Сообщение через кан с одинаковыми идентификаторами одновременно передавать нельзя, если сможете сдвинуть их по времени, то проблем не будет. Остается вопрос при приеме этих данных. Легче всего, если внутри пакета будет уникальный признак датчика, а если этого нет то опять же можно попробовать по времени вылавливать пакеты от датчиков относительно какой-то временной точки отсчета, которую вам надо организовать. (маркер пакет или чего-нибудь подобное)

правильно понимаете, можно прошить прямо с компьютера. Прога DfuSe Demonstrator. Там прошивка выполняется в два этапа . На первом этапе из hex файла формируется новый файл, который потом на втором этапе заливается в процессор. Процессор надо ставить в режим загрузки, управляя входами boot. Заливка по USB описана здесь http://www.st.com/st-web-ui/static/active/...rchtype=keyword

а если попробовать передавать стандартный ID (11-бит) а не расширенный, как сейчас у вас. Извиняюсь, мой код работает для стандартного ID

В STM32F4xx для приема сообщения, я записывал фильтр по другому CAN_FilterInitStructure.CAN_FilterMode = CAN_FilterMode_IdMask;// CAN_FilterInitStructure.CAN_FilterScale = CAN_FilterScale_32bit; CAN_FilterInitStructure.CAN_FilterIdHigh =0x07F1<<5;// идентификатор 0x07F1 пишется в старшие разряды CAN_FilterInitStructure.CAN_FilterIdLow = 0x0000; CAN_FilterInitStructure.CAN_FilterMaskIdHigh = 0x07ff<<5;// 0 - любой бит проходит, 1 - только заданный в фильтре CAN_FilterInitStructure.CAN_FilterMaskIdLow = 0x0000; // CAN_FilterInitStructure.CAN_FilterFIFOAssignment = 0; CAN_FilterInitStructure.CAN_FilterActivation = ENABLE; CAN_FilterInit(&CAN_FilterInitStructure); попробуйте CAN_FilterInitStructure.CAN_FilterIdHigh =0x000C<<5;// CAN_FilterInitStructure.CAN_FilterIdLow = 0x0000; библиотека от STM не настолько высокоуровневая, как хотелось бы. Чтобы биты идентификатора попали на свое место в служебных регистрах, данные необходимо сдвигать на пять разрядов.

Для STM32F4xx включается режим Mask mode и настраивается mask register, в котором необходимо указать биты идентификатора сообщения, участвующие в сравнении при получении сообщения по CAN. Т.о. например, настраиваем в mask register младших пять бит как “don’t care” и в результате все сообщения у которых совпадут старшие биты, (младшие пять бит могут быть любыми) - будут приняты. Получаем 32 сообщения принимаемых через один фильтр.

на сайте stm, есть STM32F4xx_DSP_StdPeriph_Lib_V1.0.0 ( http://www.st.com/internet/com/SOFTWARE_RE...dperiph_lib.zip ), там примеры и библиотека под всю периферию. Есть там файл библиотеки stm32f4xx_spi.c, в котором сказано To configure I2S full duplex you have to: * * 1. Configure SPIx in I2S mode (I2S_Init() function) as described above. * * 2. Call the I2S_FullDuplexConfig() function using the same strucutre passed to * I2S_Init() function. * * 3. Call I2S_Cmd() for SPIx then for its extended block. * * 4. To configure interrupts or DMA requests and to get/clear flag status, * use I2Sxext instance for the extension block. а в примере (I2S/I2S_TwoBoards/DataExchangePolling/main.c) сделанном под эту библиотеку - есть код для Master full Duplex configuration

спасибо, судя по всему в этом и есть причина вот этот код рабочий void TIM4_IRQHandler(void) { if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET) { TIM_ClearITPendingBit(TIM4, TIM_IT_Update);// если вызывать позже, то возможен хаос //здесь обработчик прерыания CountTest2++; ... } } Если TIM_ClearITPendingBit(TIM4, TIM_IT_Update) вызывать позже в обработчике прерывания (причем не сразу, а так через несколько команд), то наступает описанный выше хаос. В общем сам виноват, в примерах от STM так и сделано, сперва if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET), потом TIM_ClearITPendingBit(TIM4, TIM_IT_Update) и только после этого код обработки прерывания причем даже код ниже становится рабочим, но понятно что так делать нельзя, т.к. любые действия до TIM_ClearITPendingBit(TIM4, TIM_IT_Update); не есть хорошо void TIM4_IRQHandler(void) { GPIOC->ODR ^= GPIO_Pin_13; //индицируем прерывание для отладки if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET) { TIM_ClearITPendingBit(TIM4, TIM_IT_Update);// если вызывать позже, то возможен хаос //здесь обработчик прерывания CountTest2++; } }

да и обработка прерывания завершается TIM_ClearITPendingBit(TIM4, TIM_IT_Update) все как в примерах void TIM4_IRQHandler(void) { GPIOC->ODR ^= GPIO_Pin_13; //индицируем прерывание для отладки if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET) { //здесь обработчик прерыания CountTest2++; TIM_ClearITPendingBit(TIM4, TIM_IT_Update); } }

не любит STM чтобы использовали код не так, как в их примерах)). Заметил тоже самое с другими прерываниями. Например с таймером, вот такой код работает нормально: void TIM4_IRQHandler(void) { if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET) { //здесь обработчик прерывания } } а теперь для теста добавим пару переменных void TIM4_IRQHandler(void) { CountTest1++; if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET) { //здесь обработчик прерывания CountTest2++; } } В этом случае все рассыпается, переменная CountTest1 будет постоянно быстрее накапливаться, чем переменная CountTest2. Это говорит о том, что void TIM4_IRQHandler(void) вызывается намного чаще, чем планировалось. Но вот такой код: void TIM4_IRQHandler(void) { if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET) { //здесь обработчик прерывания CountTest2++; } CountTest1++; } работает нормально и CountTest1 всегда равна CountTest2. Получается, что вставка кода до строки if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET) все ломает. Это одинаково проявляется на STM32F207 и STM32F407. Для эксперимента пробовал добавить GPIOC->ODR ^= GPIO_Pin_13; и посмотреть осциллографом длительность на GPIO_Pin_13. Получается полный хаос. 150 мс прерывания работают как положено раз в 1 мс (таймер настроен на 1 мс), потом на 150 мс висит 0 на GPIO_Pin_13. Может зависнуть на 150 мс и с 1 на выходе GPIO_Pin_13. void TIM4_IRQHandler(void) { GPIOC->ODR ^= GPIO_Pin_13; //индицируем прерывание для отладки if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET) { //здесь обработчик прерывания CountTest2++; } } опять же, если GPIOC->ODR ^= GPIO_Pin_13, добавить после строки if (TIM_GetITStatus(TIM4, TIM_IT_Update) != RESET), то все оживает и работает как положено.

у меня на WinXp был один виртуальный привод от daemon tool. STM32 ST-LINK Utility видит ST-Link с STLinkUSBDriver.dll версии 4.2.1.0, Если установлен STLinkUSBDriver.dll версии 4.2.2.0 то ST-Link становится невидимым и спасает отключение виртуального привода от daemon.

спасибо, помогло. А старая dll работает и с виртуальным приводом, получается. по этой ссылке более старая версия v2.1 https://code.google.com/p/fishingtime-robon...mp;can=2&q= при ее установке ставится более старая версия STLinkUSBDriver.dll. сама dll занимает 65536 Bytes, если надо могу выслать