-
Постов
520 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о Spider
-
Звание
В поисках истины
- День рождения 03.10.1984
Старые поля
-
skype
Array
-
Vkontakte
Array
-
G+
Array
Контакты
-
Сайт
Array
-
ICQ
Array
-
Yahoo
Array
-
Skype
Array
Информация
-
Город
Array
Retained
-
Звание
Array
-
Spider подписался на STM32WLE5CC LoRa SF12 125kHz не работает , ST-Link V2 Aliexpress , Checksum GD32f107 Ethernet LWIP и 4 других
-
ST-Link V2 Aliexpress
Spider ответил Igor_S тема в ARM, 32bit
Разбери и глянь на чём он. Если там всё ще STM32 хоть и клон то можно попробовать зашить его и обновить до актуальной версии даже почти не опасаясь его закирпичить. Если же там китай мама проц, то можно тоже сделать всё что выше но с шансом окирпичиться 99%. -
Checksum GD32f107 Ethernet LWIP
Spider ответил BALDA тема в ARM, 32bit
Боже ш ты мой.. А в чём проблема взять и посмотреть? Open Source же... В "штатном" понимании считается, что железка сама посчитает CRC эзернет фрейма. Но никто не запрещает этого делать софтово в рамках метода netif->linkoutput() Я надеюсь не просто заменил проц, но и пересобрал код и перенастроил периферию? -
Checksum GD32f107 Ethernet LWIP
Spider ответил BALDA тема в ARM, 32bit
Ещё есть CRC у Ethernet фрейма -
Checksum GD32f107 Ethernet LWIP
Spider ответил BALDA тема в ARM, 32bit
да точно так же как и у всех. Может стоит подтянуть матчасть, так сказать... Что такое Ethernet фрейм и что такой пакет и какие там CRC, а их там много, даже в одном фрейме -
Checksum GD32f107 Ethernet LWIP
Spider ответил BALDA тема в ARM, 32bit
Да если речь о IP семействе, но! Не понятно как это будет работать в случае CRC Ethernet фрейма. Согласно документации Ethr CRC добавляется к пакету, т.е. если там будет уже CRC он и её посчитает. -
Checksum GD32f107 Ethernet LWIP
Spider ответил BALDA тема в ARM, 32bit
А в самом стеке то контролька считается? ethernetif_input() вызывается? -
// Глобальные переменные volatile uint8_t speedMode = 50; // Текущий режим скорости .... if (speedMode > 2000) { speedMode = 50; } uint8_t будет доооооооолго достигать чего то выше 255 😜
-
Ну что... Китайцы вышли с Новогодних праздников и ответили мне на вопрос. Их ответ меня не удивил, но расстроил Если коротко: Ну так получилось, уж извините! Если долго: Попробовали мы разные примеры, в паре с другими модулями. Попробовали разные комбинации приёмников и передатчиков, и они признали что Е77 не удачно разведён и не способен передавать на данной скорости. Извините, до свидания.
-
Всем привет! Столкнулся со странной и казалось бы простой но всё же проблемой, не могу запустить RTC. Прошивка пока пустая, настроено тактование от внутреннего RC8Mhz, USART5 для вывода околоотладочной информации, FWDG (на максимальное время, что-то около 29 сек) и собственно RTC. Так вот RTC не запускаются. void RtcInit( void ) { if( RtcInitialized == false ) { rcu_periph_clock_enable(RCU_BKPI); rcu_periph_clock_enable(RCU_PMU); pmu_backup_write_enable(); bkp_deinit(); rcu_osci_on(RCU_IRC40K); // Это было и так рынее включено, if (rcu_osci_stab_wait(RCU_IRC40K)) { // но пусть будет для наглядности rcu_rtc_clock_config(RCU_RTCSRC_IRC40K); // rcu_periph_clock_enable(RCU_RTC); rtc_register_sync_wait(); // Вот от сюда далее никуда не идём. rtc_lwoff_wait(); rtc_prescaler_set(40 - 1); rtc_lwoff_wait(); rtc_interrupt_disable(RTC_INT_ALARM); rtc_lwoff_wait(); rtc_interrupt_enable(RTC_INT_OVERFLOW); rtc_lwoff_wait(); NVIC_SetPriority( RTC_IRQn, 1); NVIC_EnableIRQ(RTC_IRQn); } RtcInitialized = true; } } Вроде как всё правильно... Согласно даташиту надо синхронизироваться с RTC, что и пытаемся сделать. /*! \brief wait RTC registers synchronized flag set \param[in] none \param[out] none \retval none */ void rtc_register_sync_wait(void) { /* clear RSYNF flag */ RTC_CTL &= ~RTC_CTL_RSYNF; /* loop until RSYNF flag is set */ while(RESET == (RTC_CTL & RTC_CTL_RSYNF)){ } } Ну и собственно RTC_CNT всегда НОЛЬ. Я что-то не так понимаю?
-
Ну это само собой. В итоге проблема оказалась в другом немного.
-
Ну да, они и не отрицают, что там SX126x и мол как работать с ней читай у них в даташите. Гляну что там по ерратам... Да особо ничего. Видно что есть синхра и около 14 чирпов информации, что по мне немного маловато.... А сделана обычной SDRкой...
-
Всем привет! Имею на руках несколько макеток на основе STM32WLE5CCUx пытаюсь на них изучать LoRa на практике. Наткнулся на такую странность, как то, что в режиме LoRa SF12 125kHz не стабильно принимаются данные (ничего не могу сказать на счёт стабильности отправки). Но суть в том, что пример PING_PONG отлично работает в любых других комбинация, а вот в вышеописанной пропускает пакет, принимает но с неверным CRC и так далее. Если отключить проверку CRC и всё же взглянуть на пакет дынных, то там от части мусор, с некоторыми просветами реальных данных - скажем так рандомно пробивается реальная информация. Если в этом же примере понизить (или повысить, смотря с какой стороны смотреть) SF до 11, то всё начинает работать. Так вот вопрос: Нужны какие-то дополнительные танцы с настройкой для запуска оговоренной скорости? Или всё как и с другими, только у меня что-то не работает? Вот наглядно две отправки PING. Но приняты они были "криво"
-
В продолжение экспериментов. Если понизить SF до 10 включительно и ниже, то пакеты принимаются во всех режимах (Explicit и Implict) корректно. И да, с на мой взгляд с таймаута всё верно, а точнее при SF10 и выше я пробовал от 3000 до 10000 ms, это при условии что JOIN пакет длиною 23 байта, а 23 байта на 125kHz и SF12 это где то 1.4Сек. Я что-то упускаю в настройках?
-
Просто нет слов.... Нахрена мне это всё? Опять же по делу есть что? Почему HDK KO когда на мой взгляд всё настроено корректно? Пока вы умничали ещё раз пролистал мануал и стандарт и пришёл к выводу, что данная ситуация возникает при не верном трактовании заголовка PHDR в Explicit mode. Попробовал принять пакет в режиме Implict mode и он таки принялся, но от части там какой-то шум, даже с учётом того, что теперь я должен получить PHDR+PHDRCDC в payload часть.
-
А можно что-то более по делу? Без индикации какой у вас интеллект?