Polaris

А если так: AT+HTTPPARA="URL","http://xxxxxxxxx.ru:80/?id=123" Номер порта должен все-таки за именем следовать, а не за запросом.

Согласен, не вижу смысла гадить в каталог с исходниками, даже если это делает CMake

Не уверен по этому поводу, потому что если он где-то и находится, то make его сразу же после ошиьки стирает. Но предполагаю, что находится он действительно в bin. На другом форуме обратили внимание на то, что arm-none-eabi-size обращается к ${EXECUTABLE}, который предполагается найти в корне, поэтому нужно обращаться к ./bin/${EXECUTABLE}. Но я выяснил еще одну вещь - даже если такой подход сработает, то все равно основная работа будет вестись в корне, чего мне не хотелось бы, проблема тут больше с запуском cmake. Я это делал вот так: cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE=arm-none-eabi-gcc.cmake mingw32-make Теперь же делаю вот так: cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE=arm-none-eabi-gcc.cmake . -Bbin cmake --build ./bin Теперь вся служебная информация оказывается в bin, включая и генерируемые map, hex, bin

Вот полный текст CMakeLists.txt: cmake_minimum_required(VERSION 3.5) project(xxx) enable_language(C ASM) set(CMAKE_C_STANDARD 99) set(CMAKE_C_STANDARD_REQUIRED ON) set(CMAKE_C_EXTENSIONS OFF) set(EXECUTABLE ${PROJECT_NAME}.out) include_directories(src) set(sources src/main.c ) add_executable (${EXECUTABLE} ${sources}) target_compile_definitions(${EXECUTABLE} PRIVATE -D__ATSAMC21E18A__ -D__TARGET_CPU_CORTEX_M0 ) target_compile_options(${EXECUTABLE} PRIVATE -mcpu=cortex-m0plus -march=armv6-m -mthumb -mfloat-abi=soft -fdata-sections -ffunction-sections -fno-strict-aliasing -Wall -O2 ) target_link_options(${EXECUTABLE} PRIVATE -Tsys/samc21g18a_release.ld -mcpu=cortex-m0plus -march=armv6-m -mthumb -mfloat-abi=soft -Wl,-Map=${PROJECT_NAME}.map,--cref -specs=nano.specs -Wl,--gc-sections -lm -lc -lnosys ) target_link_libraries(${EXECUTABLE} PRIVATE m ) add_custom_command(TARGET ${EXECUTABLE} POST_BUILD COMMAND arm-none-eabi-size ${EXECUTABLE}) add_custom_command(TARGET ${EXECUTABLE} POST_BUILD COMMAND arm-none-eabi-objcopy -O ihex ${EXECUTABLE} ${PROJECT_NAME}.hex COMMAND arm-none-eabi-objcopy -O binary ${EXECUTABLE} ${PROJECT_NAME}.bin)

Та же ситуация, каталог создан, но пуст, ошибка та же.

Пытаюсь заставить собираться проект под Cortex-M0+ при помощи GCC и CMake, в принципе, все получается, но один момент никак не хочет работать так, как нужно мне. Мне хотелось бы, чтобы результат работы линкера сбрасывался не в корень проекта, где лежит CMakeLists.txt, а в подкаталог проекта, например, в bin. Пишу что-то такое: #set(CMAKE_RUNTIME_OUTPUT_DIRECTORY bin) Каталог bin в результате прогона make создается, но он пуст, а прогон make дает следующую ошибку: [100%] Linking C executable bin\xxx.out arm-none-eabi-size: 'xxx.out': No such file mingw32-make[2]: *** [CMakeFiles\xxx.out.dir\build.make:913: bin/xxx.out] Error 1 mingw32-make[2]: *** Deleting file 'bin/xxx.out' mingw32-make[1]: *** [CMakeFiles\Makefile2:82: CMakeFiles/xxx.out.dir/all] Error 2 mingw32-make: *** [Makefile:90: all] Error 2 Если убрать определение CMAKE_RUNTIME_OUTPUT_DIRECTORY, то все работает, но файлы бросаются в корневой каталог, что неудобно. В чем может быть проблема? В данный момент я работаю с Windows и mingw.

Да, и чтобы два раза тему не открывать, у меня тут тоже проблемка нарисовалась с ADC. Раньше я всегда использовал только ADC0, теперь стало необходимо опрашивать несколько каналов с ADC0, а ADC1 запускать на конвертацию сразу целого блока по DMA. Все вроде бы хорошо, но выяснилось, что теперь при обращении к ADC0, когда я меняю канал измерения, код виснет на ранее совершенно безопасной строчке. /**< Disable ADC */ channel->CTRLA.bit.ENABLE = 0; while (channel->SYNCBUSY.reg & ADC_SYNCBUSY_ENABLE); /**< Set channel */ channel->INPUTCTRL.bit.MUXPOS = input; /**< Enable ADC */ channel->CTRLA.bit.ENABLE = 1; while (channel->SYNCBUSY.reg & ADC_SYNCBUSY_ENABLE); /**< Reset ready flag */ channel->INTFLAG.reg |= ADC_INTFLAG_RESRDY; /**< Start conversion */ channel->SWTRIG.bit.START = 1; Строчка эта: Отладчик показывает, что в SYNCBUSY бит ENABLE больше не сбрасывается. Если отключить ADC1, то все работает нормально. Очень странно, что одна инстанция так влияет на другую. Вроде бы в эррате ничего про подобные коллизии нет. Если вдруг кто имеет объяснение этому поведению - буду рад послушать.

Если есть инкремент в назначении или источнике, то нужно модифицировать адрес, dmadescr.BTCNT.reg = DMAC_BTCNT_BTCNT(4); будет недостаточно, нужно еще сделать: dmadescr.DSTADDR.reg = (uint32_t) &adcresult; descriptor.DSTADDR.reg += 4 * sizeof(uint16_t); В даташите стоит: DSTADDR[31:0] Transfer Destination Address This bit group holds the destination address corresponding to the last beat transfer address in the block transfer. Уж не знаю, зачем они это сделали, но у меня работает.

Ставил, эффект нулевой, что работает с третьим, не работает с первым.

Аналогичная ситуация, STM32F446, ADC_ExternalTrigConv_T1_CCх не захотел работать ни под каким соусом.

Да, интересный факт, я там даже не искал, смотрел исключительно главу про CAN. Но на самом деле у меня ревизия E, так что, думаю, поправили не слишком хорошо. Но с их качеством документации оно и неудивительно.

Да, с землей есть такое, но суть оказалась не в этом. Проблема была в слишком большом разбросе частот у висящих на шине устройств, для такой скорости в ATSAMC21 нельзя использовать PLL, у него точность оказалась даже ниже, чем у внутреннего генератора, когда запитал ядро от внутреннего, а CAN от внешнего кварца без всякого умножителя, проблема исчезла начисто. Но все равно спасибо за идею!

Занимаюсь реализацией самописного протокола для CAN на ATSAMC21, в целом все понятно и четко, скорость работы - 500 кбит/с. Для отладки и управления со стороны компьютера использую CAN-USB адаптер от Kvaser. Вроде бы все работало, начал смотреть, что там происходит на шине и обнаружил достаточно большое количество Error frames. Причем обнаруживаются они только в том случае, когда на шине более одного участника. Если к адптеру подключена одна плата - все хорошо, подключаешь вторую - до одного процента пакетов испорчены. Выглядит это вот так: Зеленый канал - это состояние питания микроконтроллера, желтый - сама шина. Второй участник при этом совершенно точно ничего не передает, я специально становился в отладке на функцию передачи - она ни разу не вызывалась. Кабель достаточно короткий, с обеих сторон терминирован 120 Ом. Как видно из скриншотов, выброс связан с искажение бита ACK, но кто это может делать - я совершенно не понимаю. Фильтры на участниках настраивал и таким образом, чтобы отбрасывать чужие пакеты, ничего не дало, в принципе, и не должно было дать, это же ACK. Что бы это могло быть?

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

Описание голого радио у Nordic все-таки есть