Yogen

Если стек в конце, а данные в начале, то при выходе из границ стек будет безболезненно юзать пространство свободного ОЗУ. А если стек вначале, то при том же форсмажоре он сразу перейдёт через нижнюю границу RAM. Во первых не в интернете а в EWВ\arm\config\devices\... А во-вторых не надеюсь, а подвергаю сомнению и советуюсь с теми кто эту тему проходил. B)

Я так и думал. Смутило, что в примерах для SТM32 и ADuCM360/361 он не привязан ни к началу ни к концу, а плавает вместе с данными. Там всё просто в файле icf place in RAM_region { readwrite, block CSTACK, block HEAP };

Так и есть. Но я почему начал копать?! У меня при разных размерах стека загрузчика и приложения, а именно когда в загрузчике он больше, не стартует приложение. Как будь-то бы мусором из стека загрузчика инициализируются переменные в основном приложении. При размещении стека в конце ОЗУ он слишком далеко от данных приложения и этого эффекта уже нет. Конечно это не выход из положения и нужно разбираться что там происходит. Но такая удалённость данных от стека может предохранить их в случае пробоя последнего, может поэтому его народ старается размещать его в конце.

Здравствуйте. Написал приложение с собственным загрузчиком на ADuCM360. Работает, но до последнего момента был неясен вопрос инициализации вершины стека при переходе с загрузчика на основное приложение. Понятно, что при старте загрузчика по ресету стек инициализируется автоматически по указателю на нулевом адресе. Но при переходе на основное приложение этого не происходит и его нужно инициализировать вручную, например так: __set_MSP(*(__IO uint32_t*) FLASH_APPLICATION_ADDR); // Новая вершина стека. Насколько успел разобраться, указатель стека по адресу начала основного приложения инициализируется компилятором в соответствии с директивами файла конфигурации *icf линкера. В файлах *icf из примеров написано: place in RAM_region { readwrite, block CSTACK, block HEAP }; но при таком размещении стек гуляет по памяти в зависимости от размера пользовательских данных в RAM и размера самого стека. Однако здесь же на форуме читал что народ ставит вершину стека в конец RAM, поэтому переписал так: place at address mem: (__ICFEDIT_region_RAM_end__ - __ICFEDIT_size_cstack__) { block CSTACK}; place in RAM_region { readwrite, block HEAP }; Всё ли правильно сделал и какие могут быть подводные камни? Где посмотреть пример файла конфигурации с привязкой вершины стека к концу RAM скажем для STM32?

Тоже интересует этот вопрос. Все пакеты дублируются с маленькой паузой, благо отбраковываются принимающей стороной. Удалось разобраться зачем так сделано или исправить?

Спасибо. Вот конфиг передающего девайса, он же пишется в приёмник // Sync word qualifier mode = 16/16 sync word bits detected // CRC autoflush = true // Channel spacing = 199.951172 // Data format = Normal mode // Data rate = 38.3835 // RX filter BW = 101.562500 // PA ramping = false // Preamble count = 4 // Whitening = true // Address config = No address check // Carrier frequency = 430.007690 // Device address = 0 // TX power = 0 // Manchester enable = false // CRC enable = true // Deviation = 20.629883 // Packet length mode = Variable packet length mode. Packet length configured by the first byte after sync word // Packet length = 60 // Modulation format = 2-FSK // Base frequency = 430.007690 // Modulated = true // Channel number = 20 Смущает содержание принятого CC1101_PKTSTATUS= 18 = 10010. Признака хорошей преамбулы нет, CRC тоже нет. Читаю вроде правильно, с установленным CC1101_READ_BURST.

Здравствуйте. Прошу помочь с приёмом на CC1101. Ситуация такая: есть готовый девайс на CC1101 и исходники к нему. Использую его при отладке как передатчик. В соответствии с исходниками, запрограммирован макет на основе такого же девайса с подключенным на проводах МК, работает приёмником (то есть железо аналогичное). После долгих танцев с бубном получил на GDO2 приёмника красивые импульсы (настроено 0x46 – вниз по синхрослову, вверх после приёма пакета). По концу импульса по прерыванию, перехожу в SIDLE, считываю STATUS_RX, PKTSTATUS и FIF0_RX. После этого чищу буфер RfStrobe(CC1101_SFRX); и возвращаюсь в режим приёма RfStrobe(CC1101_SRX); В результате вижу какую-то ересь (данные в десятичном формате): ****** RX_STSTUS: 11 PACKET_STSTUS: 18 FIF0_RX: 8,70,46,46,79,219,36,10,108,69,0,20,8,0,16,137,236,202,131,130,34,248,53,7,15,24 ,21,108,67,64,145,135,107,243,86,16,239,11,61,31,65,0,89,127,62,129,53,11,0,0,20 ,0,0,199,1,0,0,16,252,0,10,0,0,96, ****** Но даже это не всегда, чаще число приятных байт в RX_STSTUS равно нулю, а в FIFO тот же мусор. Особенности эксперимента: 1. Притащил железо домой без антенн, вместо них две иголки, начальство уверяло, что и без них нормально работает на близких расстояниях. 2. Расстояние между приёмником и передатчиком около метра. Вопросы: 1. О нормальной работе каких частей/настроек говорит наличие импульсов? (Импульсы меняют длину, как будь-то иногда принимается синхрослово, иногда весь или часть пакета) 2. Что должно быть в FIF0_RX в норме? Нули? Пока ни разу не удалось их увидеть как будь-то что-то с чтением. Burst-чтение вроде работает нормально, все 47 регистров настройки считывает нормально.

К вопросу «использовать режим WOR или запускать режим прослушки эфира микроконтроллером?». STM32 можно затактировать от 1МГц XTAL и работать с него на время окна RX (всего лишь +1 mA потребления МК к стандартным 15 mA потребления RF-чипа в режиме RX) … а дальше, если что-то приняли разогнаться через PLL до 72МГЦ для дальнейшей обработки. Чем не вариант экономии?!

Несколько лет кантора на GPS и GSM от Quecte. Хорошее соотношение цена/качество. http://www.quectel.com/UploadFile/Product/...cation_V2.0.pdf

10 секунд на поиск доступных датчиков? Ну.. может быть. В принципе процедура разовая и запускается вручную. Сделаю наверное 5, но откажусь от WOR пусть рулит МК, в 10мс всё равно уложиться должен. Только нюанс: получается один запрос на все слэйвы, придётся фильтрацию по адресам отключать.

Даже при таком тайминге 10/1000 ms и потреблении RF 15mA, от аккумулятора 1000 mah всего 9,5 месяцев. Маловато будет.

Мегабитов тут не будет. Чип максимум на 500кб/c. А для предполагаемого трафика хватит и 100кб/с за глаза. МК планирую STM32. Но вариант автономного датчика предполагает однократный съём данных раз в месяц или реже, либо однократный суточный запуск для записи данных на SD. Всё остальное время МК спит. Просыпаться каждый раз вместе с CC1100 вроде как не нужно, он сам пишет принятые данные в FIFO и если там корректный пакет пробуждает МК через GPIO.

Рисунок из описания режима Wake-on-Radio CC1101. Чип за за 14.4 мс успевает проснуться, послушать эфир и снова уснуть на 11мс. Почему глупо? Ведь чем меньше тем лучше? Если я правильно понял за время нахождения слейвов в RX мастер должен успеть передать как минимум один запрос, поэтому их нужно посылать как можно чаще, у мастера питание неограничено. А вот слэйв может слушать уже раз в секунду, всё равно поймает, ведь время прослушки будет больше периода запросов. P.S. RTC в устройстве не будет.

Режим Wake-on-Radio в CC1101 совсем не то, что я думал. Обычный переход в режим приёма по программируемому таймеру на программируемое время, при отсутствии несущей назад в сон. Получается, если я буду просыпаться каждую секунду на время большее, чем периодичность запросов мастера, их я могу сделать хоть каждые 10 ms, то я гарантированно приму запрос. И среднее потребление будет равно длительности нахождения в RX/1 сек. Время настройки на мастера будет от 0 до 1с?

А как можно привязать сканирование эфира к тайм-слотам? Шкала реального времени у мастера и слэйвов?