Spider

оно и сейчас так, только __interrupt 1 __using 2, а толку... если не SDCC, то что?

Всем привет! Не понятен момент описания прерываний. Точнее описывать их получается, но вот поведение линковщика неоднозначно. К примеру имеем main.c в котором скопом весь код программы в том числе и прерывания: void main(void) { бла бла бла } UART0_ISR() { обработчик } Теперь собираем его, и получаем примерно следующее: 563;-------------------------------------------------------- 564; interrupt vector 565;-------------------------------------------------------- 566 .area HOME (CODE) 000000 567 __interrupt_vect: 000000 02 00 29 [24] 568 ljmp __sdcc_gsinit_startup 000003 32 [24] 569 reti 000004 570 .ds 7 00000B 32 [24] 571 reti 00000C 572 .ds 7 000013 32 [24] 573 reti 000014 574 .ds 7 00001B 32 [24] 575 reti 00001C 576 .ds 7 000023 02 01 C9 [24] 577 ljmp _isr_uart 578;-------------------------------------------------------- 579; global & static initialisations 580;-------------------------------------------------------- Теперь "причёсываем" код. Создаём uart.c и переносим в него прерывание. собираем. Линкуем. 526;-------------------------------------------------------- 527; interrupt vector 528;-------------------------------------------------------- 529 .area HOME (CODE) 000000 530 __interrupt_vect: 000000 02 00 06 [24] 531 ljmp __sdcc_gsinit_startup 532;-------------------------------------------------------- 533; global & static initialisations 534;-------------------------------------------------------- А где?! Нет, сама функция собирается, но как обычная: 560;-------------------------------------------------------- 561; code 562;-------------------------------------------------------- 563 .area CSEG (CODE) 564;------------------------------------------------------------ 565;Allocation info for local variables in function '_isr_uart' 566;------------------------------------------------------------ 567; uart.c:41: _ISR_UART() 568; ----------------------------------------- 569; function _isr_uart 570; ----------------------------------------- 0000D8 571 _isr_uart: 00000F 572 ar7 = 0x0F 00000E 573 ar6 = 0x0E 00000D 574 ar5 = 0x0D 00000C 575 ar4 = 0x0C 00000B 576 ar3 = 0x0B 00000A 577 ar2 = 0x0A 000009 578 ar1 = 0x09 000008 579 ar0 = 0x08 Что я могу сделать не так? Это что получается прерывания должны быть только в основном коде?

Всем привет! Помогите понять как работает __sbit в SDCC. К примеру код из Keil: sfr FSR = 0xF8; /* FSR */ sbit MCDIS = FSR^7; sbit STP = FSR^6; sbit WEN = FSR^5; sbit RDYN = FSR^4; sbit INFEN = FSR^3; sbit RDIS = FSR^2; sbit RDEND = FSR^1; sbit WPEN = FSR^0; Как я понимаю в SDCC я должен описать что-то типа: __sfr _-at 0xF8 FSR; __sbit __at 0xF8 WPEN; __sbit __at 0xF9 RDEND; __sbit __at 0xFA RDIS; и так далее. правильно? А тогда как быть, к примеру, с регистром sfr FPCR = 0xF9; ? Ведь к примеру sbit NUPP = FPCR^0; будет всё тем же __sbit __at 0xF9 NUPP;, что не отличается от __sbit __at 0xF9 RDEND;? Не понимаю ничего :crying:

Прошу прощения что встреваю :) А тоже самое возможно с sdcc? Ключи подобные у компилятора есть. makefile я доработал примерно следующей строкой discovery: @echo Discovery $(extension) sdcc -I"C:\Program Files\SDCC\include" -E -dD "$(specs_file)" @echo ' ' но даже если у меня получается заставить Eclipse выполнить male .... discovery, то в консоль он ругается что нет такой цели для сборки discovery. Настройках проекта отключена генерация makefile и судя по всему он пользуется моим при сборке all или clear. Но вот discovery не хочет делать. Руками вызвать make получается. Как это? Я не совсем допонимаю механизм работы этого всего. Что должно быть в результате? Как с этим связан spec.C файл?

кстати да, к примеру ёмкость CR2032 240 mAh, это я даже представить боюсь сколько она протянет при потреблении 0,1 uA. лет 30...

И так можно продолжать бесконечно. Если говорить о ионисторе, то в масштабах телефоностроения поставить микроимпульсник для его "порционной" зарядки не стОит ничего, то что я видел так и было решено. Схем телефонов валом.

Не поверите, но ДА! В большинстве своём да. В последнее время стали ставить МАААААханький ионистр.

Дык он это.. на то и OpenSource. Я ставлю его на все свои поделки, и начал это делать ещё с Роутеров. Собираешь только то что нужно и ВОЛЯ! А вы попробуйте винду ЦЕ собрать под что-нить. Свихнётесь! Да если взять тупо ядро и собрать, то это может ещё и не заработать, но ведь думать тоже надо. Да много чего написано кривыми авторами и как вообще попало в релиз, но оно есть, и если надо заставить что-то работать здесь и сейчас, то это в самый раз. Потом уже будем посмотреть что не так. Альтернатива что?

Плохо значит разбираетесь. Все верёвочки управления USB протянуты в JAVA среду. Всё описано и работает узумительно, даже не надо модулей ядра, чтобы заставить работать железку. У меня уже несколько проектов работает так. Вас куда-то не в ту степь понесло...

буду занудой, но kolobok0 прав. Вы задали очень мутный "вопрос".

даже бизибокс не нужен, и так все работает.

esp8266 (+NodeMCU) + STM32

Интересный у тебя вопрос. А что ты хочешь? Припаяй к ней BlueTooth и общайся с ним, хотя что-то я слышал, что в iOS нет SPP, тогда Wifi :) Ну или самое простое USB HID, опять же ограничение наличием HOST у Android и пролёт iOS устрйоств.

Я уж думал в наши дни никого кодировками не удивить. А тут вон оно что...

Именно так и сдала - работает. Очередной костыль.

Всем привет! Работаю с железкой по i2c, в основном "обращения" все по 1 байту - пишу адресс, читаю 1 байт. всё это работает. Но вот если хотя бы 2 байта, а то и более зависает приём на последнем байте. void MPU6050_I2C_BufferRead(u8 slaveAddr, u8* pBuffer, u8 readAddr, u16 NumByteToRead) { // ENTR_CRT_SECTION(); /* While the bus is busy */ //while (I2C_GetFlagStatus(I2C_FLAG_BUSBUSY)); /* Send START condition */ I2C_GenerateSTART(ENABLE); /* Test on EV5 and clear it */ while (!I2C_CheckEvent(I2C_EVENT_MASTER_MODE_SELECT)); /* Send MPU6050 address for write */ I2C_Send7bitAddress(slaveAddr, I2C_DIRECTION_TX); /* Test on EV6 and clear it */ while (!I2C_CheckEvent(I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)); /* Clear EV6 by setting again the PE bit */ I2C_Cmd(ENABLE); /* Send the MPU6050's internal address to write to */ I2C_SendData(readAddr); /* Test on EV8 and clear it */ while (!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED)); /* Send STRAT condition a second time */ I2C_GenerateSTART(ENABLE); /* Test on EV5 and clear it */ while (!I2C_CheckEvent(I2C_EVENT_MASTER_MODE_SELECT)); /* Send MPU6050 address for read */ I2C_Send7bitAddress(slaveAddr, I2C_DIRECTION_RX); /* Test on EV6 and clear it */ while (!I2C_CheckEvent(I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED)); volatile u8 t; /* While there is data to be read */ while (NumByteToRead) { if (NumByteToRead == 1) { /* Disable Acknowledgement */ I2C_AcknowledgeConfig(I2C_ACK_NONE); /* Send STOP Condition */ I2C_GenerateSTOP(ENABLE); t=0; } /* Test on EV7 and clear it */ if (I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_RECEIVED)) { /* Read a byte from the MPU6050 */ *pBuffer = I2C_ReceiveData(); /* Point to the next location where the byte read will be saved */ pBuffer++; /* Decrement the read bytes counter */ NumByteToRead--; } } /* Enable Acknowledgement to be ready for another reception */ I2C_AcknowledgeConfig(I2C_ACK_CURR); // EXT_CRT_SECTION(); } t=0; чтобы отладчиком туда попасть после STOP :) Анализатором на щине i2c всё правильно - все байты приняты, последний NACK и STOP. По коду же после STOP событие I2C_EVENT_MASTER_BYTE_RECEIVED не выставляется, но при 1 байте всё работает. Что я делаю не так? Да и код-то из примера STMовского...

Да как бы загрузчик уже закончен и работает. И всё после себя подтирает и выходит красиво. Просто там я знаю что трогал и что убрать. Всё красиво работает.

Думал об этом. Но в программу у меня хорошо получается переходить переносом прерывайний и всего такого. Просто интересно было, если не учитывать действия "софта" содержимое RAM после софтового сброса сохраняется...

а RAM проца после SoftReset в каком состоянии?

А как поймать? Яж написал, что не хочу ресет, ибо придётся деражать кнопочку. Хочется перейти в бутлоадер, да так, чтобы дать ему понять, что это произошло не по ресету, а именно его вызвали "на сцену".

Всем првиеТ! Экспериментирую с bootloader и пока сделал так: в самое начало Flash располагаю Bootloader, а с 0x0800400 первый попавшийся пример с USART из набора ChibiOS (ессестно с измененным .ld скриптом, чтобы начиналось всё с 0x0800400). Бутлоадер проверяет не нажата ли кнопочка при подаче питания на протяжении там 500ms и если нет, то перекидывает таблицу указателей и стек "на основное приложение", ежеле нажата кнопочка, то загружается сам и делает своё грязное дело. Ну всё примитивно просто и как обычно. Теперь захотелось странного - загрузить бутлоадер из приложения. Самое простое сделать SoftReset, но надо держать кнопочку. тогда я сделал ячейку в памяти куда пишу флаг и снова переношу таблицу векторов и вызываю ResetHandler бутлоадера. Но вот беда, всё падает и зависает. Нет, переходить то оно переходит, но вызываются какие-то прерывания, видать которые были настроены в примере. Я пошёл в ЛОБ - перечислил перед переносом таблицы прерывания все регистры переферии, где можно было бы разрешить прерывание и запретил их наверняка. Отключил SysTick. Но ВСЁ РАВНО что-то происходит и bootloader зависает в Assert вызванный из заглушки на прерывание. Есть способ выяснить что его вызывает? Дебагер не видит какое прерывание прыгнуло в этот указатель - back trace тупо начинается сразу с Assert(). Сижу вот и описываю все вектора в пустышки, дабы понять какая именно пустышка вызывается.

Ага! Именно так. Ноги растут из ST-Util, перешёл на OpenOCD (оно конечно странно как-то ходит по коду, такое ощущение что по ASM ходит вместо C)

Оно запускается, инициализируется. При этом я могу пройти по всем строкам F10 и ноги будут "дрыгаться" даже выплёвывает 1 байт в USART но до второго дело не доходит, потому что прерывание не вызывается чтобы выплюнуть следующий. Та же ситуация с таймером - я взвожу его и.... бесконечно кручусь в цикле ожидая его 0. т.е. по коду ходится, исполняется, bp срабатываю если до них доходит дело.

в том-то и дело что уже всё перепробовал. В этом прерывании уменьшаются софтовые таймеры, так вот и было замечено, что они перестали работать. "висят" с начальным значением.

Всем привет! Как-то так получилось, что отладкой почти не пользовался. Тут понадобилось и обратил внимание что к примеру SysTick не вызывает прерывание. т.е. если просто подать питание на проц - то всё работает, а если подключиться отладчиком и начать "отлаживать" то таймер замер и ничего не происходит. Я что-то не так делаю?