Colobox

Спасибо всем за ответы!!! :rolleyes:

А насколько сильно имеет значение соответствие версий пакетов версиям ОС? В смысле, проблемно подбирать все это по сайтам и т.д., или таки лучше сразу Debian- сразу все в одном, во избежание шаманства?

Никогда не занимался Линуксом, но хотелось бы начать. Подскажите, пожалста, наиболее удобный и стабильно работающий Линукс (разновидность, версию) и прочие пакеты для разработки embedded C++ и не только ( включая GUI ). Возможно, вопрос ламерский довольно, но пока не знаю, как подступиться к этому Пингвину :-)

Хм... Посмотрел внимательно прогу: в одном классе описал массивы, а память под них не выделил, ни статически, ни динамически, а потом заносил в эти масссивы данные, портя память. Скорее всего в этом и была проблема. Спасибо за ответы :)

Нет, классы ни причем: //----------------------------------------------------------- void Select ( byte Address ) { if( Address ) CS0_ON; else CS1_ON; } //------------------------------------------------------------ int main() { ..................... ..................... Select ( 0 ); ..................... ..................... } Такой безотносительный код тоже виснет. Программа вылетает в _exit: И потом на j-link овский резет не реагирует, так в exit-е и находится.

Доброго всем времени суток! LPC2138, IAR 4.5 Имеется вот такой код обмена по SPI: #define CS0_ON IO0CLR_bit.P0_7= 1// #define CS0_OFF IO0SET_bit.P0_7= 1// #define CS1_ON IO0SET_bit.P0_10= 1// #define CS1_OFF IO0CLR_bit.P0_10= 1// #define CS_OFF CS0_OFF; CS1_OFF //----------------------------------------------------- bool TSpiTransfer::Pop( void ) { if ( !Ready() ) return false; //==== Start(); //==================================== TTransaction* t= &Transaction[current]; //================= byte a= t->Address(); Select(a); //================= Buffer[0]= t->Cmd();// t->Load( Buffer ); //==== byte l= t->Length(); for ( byte i = 0; i < l; ++i ) { Spi0ReadWrite( Buffer[i] ); }; //==== l= t->ResponseLength(); for ( int i = 0; i < l; ++i ) { Buffer[i]= Spi0ReadWrite(); }; //================= CS_OFF;// //================= t->Apply();// run= false; //======================================= Discount(); //==================================== return true; } //------------------------------------------------------ void TSpiTransfer::Select ( byte Address ) { //===================== switch ( Address ) { case 0 : CS0_ON; break; case 1 : CS1_ON; break; //==== default : CS0_ON; };//end of switch ( Address ) //====================== } //------------------------------------------------------ После запуска мк виснет насмерть. Пошагово смотрел- выполняются несколько команд в начале main(), затем прерывание по системному таймеру- обработка прерывания и... переход на начало программы, затем прерывание и т.д. по кругу. Если Select() убрать, то все нормально. Если вместо Select() просто поставить CS0_ON (без выбора), например, то все нормально также. Чем ИАРу switch с ногодерганьем не нравица???!!! :-( Причем, замена switch на if (...) else if (...) приводит к такому же зависону.

Спасибо за указание! Надо будет еще это повнимательнее рассмотреть. ...Забавно- сходные темы и так синхронно появились :)

Начиная с некоторой версии моего проекта появилась странная вещь: Прога не функционирует как надо- переполняется RSTACK, причем факт переполнения не зависит от размера стека( 128 уровней ставил ). Аппаратно, проект- это две АТмеги128 (мастер и слейв) на плате, общающиеся по SPI, в обеих ось (v.3.00) Проблема с мастером. Отладчик- JTAG ICE Мастер получает байты от слейва с некоторым периодом, ну и обрабатывает их в процессах. Обнаружил, что переполнение возникает в обработчике прерывания именно в момент записи: msg_SpStart=s; /SPI interrupt service routine #pragma vector = SPI_STC_vect OS_INTERRUPT void ISR_SPI(void) { OS::scmRTOS_ISRW_TYPE ISR; //Считываю принятый байт byte s=SPDR;//получение команды msg_SpStart=s; msg_SpStart.sendISR(); } Правда, SP указывает на начало стека- если точки останова ставить в обработчике прерывания, если убрать, и стопорить прогу вручную, SP убегает до 0x05C4, при установленном диапазоне 0х140-0х160. Настройки оси: #define scmRTOS_ISRW_TYPE TISRW_SS #define scmRTOS_SYSTEM_TICKS_ENABLE 1 #define scmRTOS_SYSTIMER_HOOK_ENABLE 1 #define scmRTOS_IDLE_HOOK_ENABLE 1 #define scmRTOS_IDLE_PROCESS_DATA_STACK_SIZE 70 #define scmRTOS_IDLE_PROCESS_RETURN_STACK_SIZE 10 #define scmRTOS_CONTEXT_SWITCH_SCHEME 1 Откатился назад, до безглючной версии, и упростил ее до предельного вида- пустые процессы и один обработчик SPI. // Process types // typedef OS::process<OS::pr0, 300, 200> TPInSpi; typedef OS::process<OS::pr1, 300, 200> TPOutSpi; typedef OS::process<OS::pr2, 300, 200> TPPack; typedef OS::process<OS::pr4, 300, 200> TPTestIn; typedef OS::process<OS::pr3, 300, 200> TPRele; //------------------------------------------ int main() { InitHard(); CONFIG_CSW(); START_SYSTEM_TIMER();//6ms OS::Run(); } //--------------------------------------------------------------------------- OS_PROCESS void TPInSpi::Exec() { for(;;) { msg_SpStart.wait();// byte spcmd=msg_SpStart; msg_SpStart.reset(); }//end_of_for(;;) } //--------------------------------------------------------------------------- OS_PROCESS void TPOutSpi::Exec() { for(;;) { }//end_of_for(;;) } //--------------------------------------------------------------------------- OS_PROCESS void TPPack::Exec() { for(;;) { }//end_of_for(;;) } //--------------------------------------------------------------------------- OS_PROCESS void TPTestIn::Exec() { //byte n_rele=1; for(;;) { Sleep (); }//end_of_for(;;) } //--------------------------------------------------------------------------- OS_PROCESS void TPRele::Exec() { Sleep(); }//end_of_for(;;) } //--------------------------------------------------------------------------- inline void InitHard(void) { ........... ........... ........... //----------------- // USART initialization // Communication Parameters: 8 Data, 1 Stop, No Parity // USART Receiver: On // USART Transmitter: Off // USART Mode: Asynchronous UCSR0A=0x00; UCSR0B=0x90;//разрешение приема и прерывания по-приему //--Дальнейшие настройки-- UCSR0C=0x86; UBRR0H=0x00; UBRR0L=0x11;//12мгц- 38400 //----SPI---- SPCR|= (1 << MSTR);//мастер SPCR|= (1 << SPIE);//разрешение прерываний SPCR|= (1 << SPE);//включение модуля } //----------------------------------------------------------- //SPI interrupt service routine #pragma vector = SPI_STC_vect OS_INTERRUPT void ISR_SPI(void) { OS::scmRTOS_ISRW_TYPE ISR; //Считываю принятый байт byte s=SPDR;//получение команды msg_SpStart=s; msg_SpStart.sendISR(); } Переполнение стека появилось!!! И именно в тот же момент. Если установить #define scmRTOS_ISRW_TYPE TISRW эффект не проявляется, но чем #define scmRTOS_ISRW_TYPE TISRW_SS хуже?! Да и как вообще все это можно объяснить?

:bb-offtopic: Все понятно, но "домофоННых систем" -то чем провинились? (большими буквами- ошибки, как я понял) Другое дело, запятой нету... :rolleyes:

Спасибо за обстоятельные ответы. Заработало :-) Может, включить эти измененные new и delete в дистрибутив оси?

Нет-нет, я про тот объект, который создается собственно оператором new. Ведь new и malloc- это не совсем идентичные функции,- new выделяет память под объект заданного типа и запускает конструктор этого объекта- и вот, память выделили, а конструктор?! Чего то недопонимаю? А сборка мусора -это , по-сути, дефрагментация кучи, что б дырок не было?

А где же в этих "новых" new и delete вызовы конструктора и деструктора объекта?!

Опс, а как там выделить эти malloc и free? Если не сложно, можно небольшой примерчик?

Делаю проект с использованием оси и с динамическим созданием объектов. Причем, создание и удаление объектов производяться в различных по приоритету (разумеется) процессах. Программа работает несколько минут, потом виснет (включая айдл процесс, тикает только системник). Наибольший адрес объекта, созданного когда-либо в рантайме, вылетает далеко за пределы кучи. Все сводится к тому, что проблема в создании обекта в одном из процессов. Так вот вопрос, можно ли безопасно создавать объекты в разных процессах, не опасаясь, что процедура "new" будет прервана высшестоящим процессом, в котором тоже запустится new, c вытекающим сбоем в работе динамической памяти??

Совершенно верно: в настройках проекта эта самая near_heap находится в группе "DLIB heap sizes". Только сейчас осознал, вот, блин... :-)