Jump to content

    

vet

Свой
  • Content Count

    537
  • Joined

  • Last visited

Community Reputation

0 Обычный

About vet

  • Rank
    Знающий
  • Birthday 07/22/1977

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array
  1. Типовой финт ушами для строкового представления числового макроса: #define STR_HELPER(x) #x #define STR(x) STR_HELPER(x) #define VERSION 1 char g_VersionSignature[] = "VERSION=" STR(VERSION); GCC: в строке лежит VERSION=1. IAR: в строке лежит VERSION=VERSION. Можно ли с этим бороться/обойти? UPD: Вопрос снят, причиной была ошибка в имени макроса, которую препроцессор не обнаруживает.
  2. Пытался работать с I2C-периферией и на STM32F, и на STM32L, на F она откровенно не работала, на L получше, но всё равно застревала в ошибочных состояниях, помогало только отключение периферии, остановка тактирования и её перезапуск со сбросом.
  3. Похоже, что виновата стандартная реализация __dwrite; захардкожены стандартные stream'ы - stdout и stderr, на остальные она реагирует сабжевым бряком. __dwrite: 0x8008086: 0xb580 PUSH {R7, LR} 0x8008088: 0x2900 CMP R1, #0 0x800808a: 0xd101 BNE.N 0x8008090 0x800808c: 0x2000 MOVS R0, #0 0x800808e: 0xbd02 POP {R1, PC} 0x8008090: 0x2801 CMP R0, #1 0x8008092: 0xd001 BEQ.N 0x8008098 0x8008094: 0x2802 CMP R0, #2 0x8008096: 0xd102 BNE.N 0x800809e 0x8008098: 0xf001 0xfa70 BL __iar_sh_stdout_swo 0x800809c: 0xbd02 POP {R1, PC} 0x800809e: 0xf001 0xfa93 BL __iar_sh_write 0x80080a2: 0xbd02 POP {R1, PC} Жаль, в мануалах она не упомянута, это сэкономило бы время.
  4. IAR EWARM 6.40.5, STM32L151. Отлаживаю через SWD, использую вывод в SWO (Library configuration - stdout/stderr via SWO). Если включить Buffered terminal output в опциях проекта (Library options), отладчик начинает останавливать программу на инструкции BKPT 0xab: __iar_sh_write: 0x80095a0: 0xb510 PUSH {R4, LR} 0x80095a2: 0xb084 SUB SP, SP, #0x10 0x80095a4: 0x0013 MOVS R3, R2 0x80095a6: 0x9000 STR R0, [sP] 0x80095a8: 0x9101 STR R1, [sP, #0x4] 0x80095aa: 0x9302 STR R3, [sP, #0x8] 0x80095ac: 0x2201 MOVS R2, #1 0x80095ae: 0x0004 MOVS R4, R0 0x80095b0: 0x4669 MOV R1, SP 0x80095b2: 0x2005 MOVS R0, #5 > 0x80095b4: 0xbeab BKPT #0xab 0x80095b6: 0x1a18 SUBS R0, R3, R0 0x80095b8: 0x0021 MOVS R1, R4 0x80095ba: 0x46c0 MOV R8, R8 0x80095bc: 0x46c0 MOV R8, R8 0x80095be: 0xb004 ADD SP, SP, #0x10 0x80095c0: 0xbd10 POP {R4, PC} _LocaleC_isalpha: 0x80095c2: 0xf1a0 0x0161 SUB.W R1, R0, #97 ; 0x61 0x80095c6: 0x291a CMP R1, #26 ; 0x1a 0x80095c8: 0xd201 BCS.N 0x80095ce 0x80095ca: 0x2001 MOVS R0, #1 0x80095cc: 0x4770 BX LR 0x80095ce: 0x3841 SUBS R0, R0, #65 ; 0x41 0x80095d0: 0x281a CMP R0, #26 ; 0x1a 0x80095d2: 0x4180 SBCS R0, R0, R0 0x80095d4: 0x0fc0 LSRS R0, R0, #31 Что это и как с ним бороться? UPD 29/01 15:14 Дополнительная информация. В Debug log при остановке программы появляется строчка Invalid file handle 6. Это валидный хэндл, программа пишет через него поток во внешнее устройство на шине I2C. Функции __read, __write, __open, __close, __lseek переопределены соответствующим образом. Стек вызовов: fflush - fflushOne - __write_buffered - __dwrite - __iar_sh_write.
  5. EWARM 6.21.3.2937. В устройстве имеется самопальная файловая система на флэшке. Решил воспользоваться возможностями стандартной библиотеки С в плане файловых потоков, чтобы получить буферизацию ввода/вывода и легкочитаемый код, а заодно свести обмен с разномастной периферией к операциям с файлами. Установил в настройках Full library, написал свои __read(), __write(), __open(), __close(), __lseek(), remove(), rename(), выделил 8 КБ под кучу. Собрал. В принципе работает, но частенько при открытии файла ломается выделение памяти, либо программа вовсе виснет. Трассировка под отладчиком на предмет поиска зависания уводит куда-то в недра менеджера динамической памяти. Предположений пока два: или неправильно сконфигурировал стандартную библиотеку, или баг в IAR'овском менеджере памяти. Для проверки второго предположения написал свой менеджер (malloc/realloc/free/new/delete) — с ним проблем нет. Вопрос, собственно, в том, сталкивался ли кто-нибудь с таким поведением стандартной библиотеки IAR, и что можно сделать, чтобы всё же воспользоваться библиотечным кодом и не городить велосипедов?
  6. Аргументы для прикручивания FAR: /co /e$CUR_LINE$ $FILE_PATH$
  7. В IDE IAR EWARM 5.20 проявляется один надоедливый глюк: при попытке открытия некоторых файлов проекта (щелчком по строчке в окне Workspace или переходом к ошибке компиляции по F4) вылетает окно с ошибкой; файл, соответственно, не открывается. После чего при закрытии IDE появляется следующий бессмысленный диалог: Исключение файла из проекта и его повторное включение ситуации не меняет. Settings/ и *.dep удалял - безрезультатно. Существует ли рецепт борьбы с этим злом?
  8. Выводы по теме: пин SSEL предназначен для использования только в slave режиме SPI. Любые манипуляции с ним в master режиме - программные ли, аппаратные ли - приведут к переходу SPI в slave режим. Если нужен мастер - разводим вход выбора ведомого уст-ва на другой вывод LPC. Поправьте, если я неверно понял.
  9. Не поможет ли кто прояснить причину таких вот граблей. Используются ноги: P1.20(SCK0), P1.21(SSEL0, управляется программно), P1.23(MISO0), P1.24(MOSI0). Посылаю в SPI0 байты данных: #define BIT(n) (1UL<<(n)) void SpiInitHW() { //PIO PINSEL3_bit.P1_20 = 3; //SCK0 FIO1CLR = BIT(20); //low FIO1DIR_bit.P1_20 = 1; //output PINMODE3_bit.P1_20 = 2; //no pull-up PINSEL3_bit.P1_21 = 0; //PIO FIO1SET = BIT(21); //high FIO1DIR_bit.P1_21 = 1; //output PINMODE3_bit.P1_21 = 2; //no pull-up PINSEL3_bit.P1_23 = 3; //MISO0 FIO1DIR_bit.P1_23 = 0; //input PINMODE3_bit.P1_23 = 0; //pull-up (вход выведен на разъём) PINSEL3_bit.P1_24 = 3; //MOSI0 FIO1CLR = BIT(24); //low FIO1DIR_bit.P1_24 = 1; //output PINMODE3_bit.P1_24 = 2; //no pull-up //SPI PCLKSEL0_bit.PCLK_SPI = 1; S0SPCCR = 0x80; S0SPCR = BIT(5)/*MSTR*/; } void SpiSelect() {FIO1CLR = BIT(21);} void SpiDeselect() {FIO1SET = BIT(21);} INT8U SpiTransfer(INT8U data) { S0SPDR = data; while (!S0SPSR_bit.SPIF); return S0SPDR; } //................. for (;;) { WAIT(signalSend); //ждем сигнала на передачу байта SpiSelect(); SpiTransfer(mSend); SpiDeselect(); } SSEL держит низкий уровень в течение байтового интервала, как задумано; на SCK и MOSI - молчание. Что здесь не так?
  10. События на этих портах не будут вызывать обработчик EINT3, если это не разрешено явно для каких-либо выводов данных портов. Посмотрите, не пишет ли код инициализации в регистры IOnIntEnF/IOnIntEnR.
  11. LPC2378, та же проблема - не удаётся оживить SPI. //SCK PINSEL3_bit.P1_20 = 3; //SCK0 FIO1CLR_bit.P1_20 = 1; //low FIO1DIR_bit.P1_20 = 1; //output PINMODE3_bit.P1_20 = 2; //no pull-up //SSEL PINSEL3_bit.P1_21 = 3; //SSEL0 FIO1SET_bit.P1_21 = 1; //high FIO1DIR_bit.P1_21 = 1; //output PINMODE3_bit.P1_21 = 0; //pull-up //MISO PINSEL3_bit.P1_23 = 3; //MISO0 FIO1DIR_bit.P1_23 = 0; //input PINMODE3_bit.P1_23 = 0; //pull-up (вход выведен на разъём) //MOSI PINSEL3_bit.P1_24 = 3; //MOSI0 FIO1CLR_bit.P1_24 = 1; //low FIO1DIR_bit.P1_24 = 1; //output PINMODE3_bit.P1_24 = 2; //no pull-up //SPI PCLKSEL0_bit.PCLK_SPI = 3; //PCLK_SPI = CCLK/8 S0SPCCR = 0x80; //prescaler S0SPCR = 1<<5 /*MSTR*/; После записи в S0SPDR через некоторое время выставляется флаг SPIF в S0SPSR; тем не менее, активности на ногах MOSI, SCK не наблюдается. Выходом SSEL управляю через FIOSET/FIOCLR; пробовал выставлять его в режим GPIO. Внешний подтягивающий к 3,3В 10кОм резистор на SSEL ставил. Программный SPI работает без проблем.
  12. Пользуюсь AVRDUDE+usbasp, жалоб нет.
  13. после выполнения вышеприведенного кода пресловутая команда загрузки будет лежать в ОЗУ по адресу вектора IRQ.
  14. vashurin 1 char __flash *p = (char __flash *)0x1000; char b = *p; 2 while (!(UCSRA&(1<<TXC))); 3 if (UCSRA&(1<<TXC)) {...}