| |
|
  |
 В какой моде запускать main?, Вот в чем вопрос. |
|
|
|
|
 Apr 17 2009, 00:51
|
Гуру
Группа: Участник
Сообщений: 2 254
Регистрация: 4-05-07
Из: Moscow
Пользователь №: 27 515
|
Почему-то я не смог обеспечить вложенные прерывания, если запускаю процессор
в SVC mode. __nested подвешивает тогда прерывания намертво. И никаких тебе приоритетных прерываний.
Таким образом только USER or System.
А без вложенных прерываний - жизнь не мила. Символы RS232 приемника теряются.
Но где-то мелькало сообщение, что WinCE запускает программы юзера в SVC mode. (Товарищ, который об этом писал из пользовательской программы менял таблицу распределения виртуальной памяти и вообще, делал все, что хотел.)
Возможно, если вход-выход из IRQ писать отдельно и читать руками вектор прерывания, то может и можно что-то сделать? И стоит ли?
А то уж очень не хочется ломать прямую загрузку вектора из АИК. Типа, одна команда, практически.
И чем так плоха System mode?
--------------------
On the road again (Canned Heat)
|
|
|
|
|
|
|
|
Apr 17 2009, 01:09
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(DpInRock @ Apr 17 2009, 04:51)  А без вложенных прерываний - жизнь не мила. Символы RS232 приемника теряются. Для UART'ов есть PDC. Дергать процессор прерыванием на каждый байт, я бы сказал, неразумно. Цитата(DpInRock @ Apr 17 2009, 04:51) Возможно, если вход-выход из IRQ писать отдельно и читать руками вектор прерывания, то может и можно что-то сделать? И стоит ли?
А то уж очень не хочется ломать прямую загрузку вектора из АИК. Типа, одна команда, практически. Для начала нужно разобраться, а стоит ли огород городить (см. выше). Естественно, вложенные прерывания обеспечить можно. Не знаю насчет __nested (IAR, как я понимаю?), но уж руками точно. И прямую загрузку вектора ломать для этого не понадобится. Цитата(DpInRock @ Apr 17 2009, 04:51) И чем так плоха System mode? Ничем - нормальный привилегированный режим.
|
|
|
|
|
|
|
|
Apr 17 2009, 15:25
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(DpInRock @ Apr 17 2009, 15:44) Было бы нагло начинать писать программу с PDC для DBGU. Тем более, из средств отладки - только 4 светодиода на плате.
(Но попробую. По крайней мере приемник. У звука сделал большой буфер, чтобы пореже дергал (раз в 16 мс). А он больше 100 микросекунд иногда забирает. ) А DBGU именно для отладки используется ? Конечно нужно использовать PDC, правда у DBGU нет очень удобного для этого флага TIMEOUT. Но в принципе, если речь об отладке, то прерывания DBGU вобще не нужны, достаточно задать буфер приличной длины и опрашивать чего там напередавалось в каком-нить переодическом прерывании(если есть) в системе. ИМХО, это совсем не случай для вложенности прерываний...
|
|
|
|
|
|
|
|
Apr 17 2009, 20:00
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 17 2009, 19:35) Да, Атмелы пожмотились почему-то на такую ерунду  ага, у мня в проекте где много интерфейсов(то есть почти все какие есть в SAM7А3) из-за этого отдельные линии квитирования Если автор топика не против,то задам свой вопрос почти по теме.. помница Вы упоминали о ~2 случаях использования вложенных прерываний на АРМ очень просто интересно, я несколько раз порывался написать свои хитрые обработчики с возможностью вложенных прерываний и так их и не написал тк каждый раз был придуман алгоритм который будет лучше без всяких вложенных прерываний, ну и на обработчиках IRQ я тоже не хило при этом экономлю... Вот чисто для себя решил что IRQ только "последовательно"(но короткие обработчики), а если нужно чего-нить супербыстрое то FIQ и 1 источник... Вот и хотелось бы услышать о Ваших случаях когда вложенные прерывания понадобились...
|
|
|
|
|
|
|
|
Apr 17 2009, 20:38
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(singlskv @ Apr 18 2009, 00:00) Вот и хотелось бы услышать о Ваших случаях когда вложенные прерывания понадобились... Например, в LED экране на SAM7X: - 3 прерывания (2 таймера и SPI) обеспечивают развертку, очень короткие, имеют высший приоритет (т.к. тайминги жесткие, развертку ломать нельзя). - прерывание от EMAC'а имеет приоритет на единицу ниже: поток здоровый (~80Мбит/с в обе стороны), реагировать нужно быстро. - перывание от UART'а. - прерывание от PIT. Еще в проекте измерительного стенда примерно со столь же тяжелым раскладом. Короче, вложенные прерывания оказываются востребованы тогда, когда нужно разрулить большое число источников с низкой латентностью. В большинстве же случаев действительно достаточно обычных IRQ или IRQ+FIQ. P.S. Пользуясь случаем, хочу послать луч ненависти инженерам фирмы Атмел за фиксированный размер приемного буфера EMAC в 128 байт.
|
|
|
|
|
|
|
|
Apr 17 2009, 21:00
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 00:38) Например, в LED экране на SAM7X:
- 3 прерывания (2 таймера и SPI) обеспечивают развертку, очень короткие, имеют высший приоритет (т.к. тайминги жесткие, развертку ломать нельзя).
- прерывание от EMAC'а имеет приоритет на единицу ниже: поток здоровый (~80Мбит/с в обе стороны), реагировать нужно быстро.
- перывание от UART'а.
- прерывание от PIT. рулить разверткой - понятно, там это главная реалтайм задачка... Цитата Еще в проекте измерительного стенда примерно со столь же тяжелым раскладом. Измерительтный стенд говорите.... Влияние "цифрового" джиттера на измерение частоты ? Цитата Короче, вложенные прерывания оказываются востребованы тогда, когда нужно разрулить большое число источников с низкой латентностью. В большинстве же случаев действительно достаточно обычных IRQ или IRQ+FIQ. Мы это стараемся разруливать с помощью дополнительных процов...переферийных...
|
|
|
|
|
|
|
|
Apr 17 2009, 21:12
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(singlskv @ Apr 18 2009, 01:00) рулить разверткой - понятно, там это главная реалтайм задачка... На самом деле, одна из самых мелких по сложности и занимаемым ресурсам. Но да, реалтайм и все тут. Цитата(singlskv @ Apr 18 2009, 01:00) Измерительтный стенд говорите....
Влияние "цифрового" джиттера на измерение частоты ? Нет, просто монстрическая система из-за большого числа источников данных. Цитата(singlskv @ Apr 18 2009, 01:00) Мы это стараемся разруливать с помощью дополнительных процов...переферийных... Дополнительный проц - дополнительные деньги. И дополнительный разноплановый геморрой - программ писать в два раза больше, кроме того, нужно еще придумывать интерфейсы взаимодействия.
|
|
|
|
|
|
|
|
Apr 17 2009, 21:34
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 01:12) Дополнительный проц - дополнительные деньги. И дополнительный разноплановый геморрой - программ писать в два раза больше, кроме того, нужно еще придумывать интерфейсы взаимодействия. А вот здесь совсем не соглашусь... Доп проц конечно деньги, но очень небольшие по сравнению с основным(1-1,5$ +) если нужен реальный реалтайм то других вариантов практически нет к примеру, опрос N входов с определением частоты на них там цифровой джиттер самое важное, сделать его разумным при наличии других интерфейсов невозможно... Ну вот пример, можно ли на АРМ7 который подключен к ПЦ через USB(961Кбод) и 3 x RS232(115Кбод) опрашивать 4-8 сигналов частотой 10Кгц ? А при наличии переферийной меги8 уже можно...
|
|
|
|
|
|
|
|
Apr 17 2009, 21:41
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(singlskv @ Apr 18 2009, 01:34) цифровой джиттер самое важное, сделать его разумным при наличии других интерфейсов невозможно... Так его на ARM'е в принципе сделать разумным затруднительно, безотносительно наличия интерфейсов. Цитата(singlskv @ Apr 18 2009, 01:34) Ну вот пример, можно ли на АРМ7 который подключен к ПЦ через USB(961Кбод) и 3 x RS232(115Кбод)
опрашивать 4-8 сигналов частотой 10Кгц ?
А при наличии переферийной меги8 уже можно... Уточните, что значит "опрашивать сигнал частотой 10Кгц". А, например, если прошивку обновить в периферийном контроллере надо - уже проблема. Сделать мостик в основном, да наворотить софт для PC, который соберет/разберет несколько прошивок в один файл (ибо делать больше одного - не уважать клиента) и т.п.
|
|
|
|
|
|
|
|
Apr 17 2009, 21:58
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 01:41) Так его на ARM'е в принципе сделать разумным затруднительно, безотносительно наличия интерфейсов. Ну тоже можно(и я над этим думаю для младших чипов как перферийных) при ограничении использования инструкций с набором регистров. Цитата Уточните, что значит "опрашивать сигнал частотой 10Кгц". Опрашивать с частотой 20Кгц+, ну и соответственно уметь "поймать" меандр с частотой 10Кгц(за 1 сек например). Цитата А, например, если прошивку обновить в периферийном контроллере надо - уже проблема. Сделать мостик в основном, да наворотить софт для PC, который соберет/разберет несколько прошивок в один файл (ибо делать больше одного - не уважать клиента) и т.п. Вот здесь Вы очень правы, то есть как бы и все инструменты есть(для ПЦ), но как только задумываешься их прикрутить для реалтаймовских вещей то сразу желание пропадает... Ну наверное для этих частей просто должны быть прошивки которые "никогда" не меняются...
|
|
|
|
|
|
|
|
Apr 17 2009, 22:08
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(singlskv @ Apr 18 2009, 01:58) Ну тоже можно(и я над этим думаю для младших чипов как перферийных) при ограничении использования
инструкций с набором регистров. Объяснить это желание компилятору только затруднительно  Да и все пересылки данных автоматически пострадают. Лучше тогда не использовать прерывания... да и ARM тоже. Цитата(singlskv @ Apr 18 2009, 01:58) Ну наверное для этих частей просто должны быть прошивки которые "никогда" не меняются... Никогда не говори "никогда" Если в системе что-то может меняться, то оно обязательно потребует изменений.
|
|
|
|
|
|
|
|
Apr 17 2009, 22:28
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 02:08) Объяснить это желание компилятору только затруднительно Да и все пересылки данных автоматически пострадают. Лучше тогда не использовать прерывания... да и ARM тоже. В подобных системах(синхронный опрос входов) прерывание принципиально одно, а как его синхронизировать... ну есть варианты с парой таймеров например... но пока еще думаю... Цитата Никогда не говори "никогда" Если в системе что-то может меняться, то оно обязательно потребует изменений. конечно может поменяться..., но этот момент по возможности будет оттягиваться до бесконечности, в конце концов софт на нижнем уровне(переферийном) написан просто "идеально" ...
|
|
|
|
|
|
|
|
Apr 17 2009, 22:40
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(DpInRock @ Apr 18 2009, 02:12) Вложенные прерывания на самом деле завсегда пригодятся и надо заранее к этому готовиться. Вот в том то и дело что они(Вложенные прерывания) пригодятся Вам 1 раз из 100 но при этом, написав обработчик умеющий работать с вложенными прерываниями, он у Вас будет везде...
|
|
|
|
|
|
|
|
Apr 17 2009, 22:53
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 02:40) ИМХО, если сразу не получается добиться удовлетворительных результатов, то это прямая дорога к использованию CPLD/FPGA.
С софтом можно возиться бесконечно, но только при наличии экономической целесообразности. Ну я пока толком и не поробовал(на АРМ) но думаю что 8 сигналов частотой до 50(может 100)Кгц это вполне доступно... Цитата(aaarrr @ Apr 18 2009, 02:46) Нет, только на прерываниях с приоритетом меньше максимального. Да и не мешает ни разу - в любой системе можно разумно расставить приоритеты. О "бездумном", как бы сказал коллега zltigo, расточении памяти не упоминаю, ибо на самом деле оно несущественно в 99.9% случаев. Не очень понял как должен выглядеть обработчик IRQ что бы он зависил от приоритетов.
|
|
|
|
|
|
|
|
Apr 17 2009, 23:13
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 03:07) Затем, чтобы получить возможность уйти на обработку самого приоритетного. Тогда это уже ловля "блох" и где-то в общем алгоритме допущена ошибка... ИМХО, при одновременном возникновении прерываний из разных источников тратить время на определение "кто приоритетьнее" это просто глупость...
|
|
|
|
|
|
|
|
Apr 17 2009, 23:38
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 03:28) "Просто FIQ" дает только один источник с более высоким приоритетом. Попробую просто пояснить свою мысль... Почти все кто переходит на АРМ с некоторым упорством достойным лучшего применеия пишут свой обработчик IRQ(который замечу вызывается всегда) и в этом обработчике всегда предусмотреннны все возможные фичи типа вызова вложенных прерываний итд... только вот все эти фичи нужны в 1% проектов а пользуют их всегда... Странная история...
|
|
|
|
|
|
|
|
Apr 17 2009, 23:44
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(singlskv @ Apr 18 2009, 03:38) Почти все кто переходит на АРМ с некоторым упорством достойным лучшего применеия пишут
свой обработчик IRQ(который замечу вызывается всегда) Еще раз: не всегда. Цитата(singlskv @ Apr 18 2009, 03:38) и в этом обработчике всегда предусмотреннны все возможные фичи типа вызова вложенных прерываний итд... Это единственная фича, для которой нужен свой обработчик. Цитата(singlskv @ Apr 18 2009, 03:38) только вот все эти фичи нужны в 1% проектов а пользуют их всегда... Ну и что? Можно подумать, что это неподъемный труд - написать/скопипастить.
|
|
|
|
|
|
|
|
Apr 17 2009, 23:59
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 03:44) Еще раз: не всегда.
Это единственная фича, для которой нужен свой обработчик.
Ну и что? Можно подумать, что это неподъемный труд - написать/скопипастить. Труд вполне подъемный, но зачем ? Зачем нужен весь этот лишний код в 99% проектов ? Вот у меня под рукой есть маштабная(не маленькая) разработка на АРМ, и вот эта фраза в коментах меня просто развеселила: Код #define DISABLE_NESTED_FIQ // Запрет вложенности FIQ
#define DISABLE_NESTED_IRQ // Запрет вложенности IRQ
// Вложенность IRQ НЕОБХОДИМО запретить
// для нормальной одновременной работы
// моста на подчиненные сети USART
// и алгоблочных запросов в подчиненную
// сеть то есть сначала долго и упорно писали весь код чтоб все работало с вложенными прерываниями а потом оказалось что из-за не реентерабельности вложенные прерывания нужно запретить... и при этом мой код на этой же задачке намного быстрее(а я и не пытался сделать вложенные прерывания)...
|
|
|
|
|
|
|
|
Apr 18 2009, 00:06
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(singlskv @ Apr 18 2009, 03:59) Труд вполне подъемный, но зачем ?
Зачем нужен весь этот лишний код в 99% проектов ? А зачем делать круглые глаза при виде такого решения? Я не пропагандирую повсеместное использования вложенных прерываний, но иногда они действительно нужны. Лишний код имеет объем порядка 80 байт на источник, что, согласитесь, не повод рвать на себе волосы. Цитата(singlskv @ Apr 18 2009, 03:59) сначала долго и упорно писали весь код чтоб все работало с вложенными прерываниями
а потом оказалось что из-за не реентерабельности вложенные прерывания нужно запретить... Из-за чего? При чем тут реентерабельность вообще?
|
|
|
|
|
|
|
|
Apr 18 2009, 00:21
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 04:06) Лишний код имеет объем порядка 80 байт на источник, что, согласитесь, не повод рвать на себе волосы. Рвать волосы конечно не стоит, но допустим это обмен по i2c на скорости 400кбод и проц работает на частоте 48Мгц. 400Кбод/9 = ~44Кбайт/сек (пиковая) 44Кбайт * "80 байт на источник"(только для выяснения причины)/4 = ~0.88Мбайт/сек (это только то что мы теряем на входе в прерывание) дальше считать ? я ни разу не понимаю почему нужно(обязательно) терять по 0,5мкс на кждый вход в прерывание...
|
|
|
|
|
|
|
|
Apr 18 2009, 00:35
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(singlskv @ Apr 18 2009, 04:21) дальше считать ? За идиотский TWI опять-таки скажите спасибо атмеловцам. Прерываться ради него с частотой 44кГц неразумно, как и вообще прерываться с такой частотой. Цитата(singlskv @ Apr 18 2009, 04:21) я ни разу не понимаю почему нужно(обязательно) терять по 0,5мкс на кждый вход в прерывание... Да не обязательно. Ну, дайте Вы своему TWI высший приоритет - получите нулевой оверхед. А 0.5мкс потратите там, где и так уходит 50, и добавка не покажется заметной. Все в конечном итоге зависит от конкретной системы, нельзя утверждать, что вложенные прерывания - это абсолютное зло, так же как и нельзя утверждать и обратное. Цитата(defunct @ Apr 18 2009, 04:33) 128 абсолютно разумное число. О как! И в чем же состоит абсолют, хотелось бы мне услышать? Мне вот почему-то кажется, что изменяемый размер буфера - гораздо более гибкое решение, Вы не находите?
|
|
|
|
|
|
|
|
Apr 18 2009, 00:40
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(aaarrr @ Apr 18 2009, 03:35) О как! И в чем же состоит абсолют, хотелось бы мне услышать? В золотой середине между 1536 и 1. Видители когда надо принимать много и быстро, от фиксированного буфера не уйти. Вопрос сколько его сделать? Чем меньше тем сложнее и соответвенно медленнее с этим работать, чем больше - тем выше расход памяти.
|
|
|
|
|
|
|
|
Apr 18 2009, 00:45
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(defunct @ Apr 18 2009, 04:40) Видители когда надо принимать много и быстро, от фиксированного буфера не уйти. Видите ли, мне приходилось иметь дело с разными MAC'ами, и почему-то нефиксированный размер входного буфера их разработчиков не смутил. Цитата(defunct @ Apr 18 2009, 04:43) так уж и 100%? G.711-30? 100%. Не угадали.
|
|
|
|
|
|
|
|
Apr 18 2009, 00:45
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 04:35) За идиотский TWI опять-таки скажите спасибо атмеловцам. Прерываться ради него с частотой 44кГц неразумно, как и вообще прерываться с такой частотой. Уже много раз их поминал..., однако это не мешает мне работать через него с мегой на ~ 150Кбод и 400 тоже возможно(если не делать искуственный оверхед ) Цитата Да не обязательно. Ну, дайте Вы своему TWI высший приоритет - получите нулевой оверхед.
Все в конечном итоге зависит от конкретной системы, нельзя утверждать, что вложенные прерывания - это абсолютное зло, так же как и нельзя утверждать и обратное. Я и не утверждаю что это абсолютное зло, просто для меня странными выглядят попытки заставить это работать, пользоваться этим всегда, а реально воспользоваться премуществами 1 раз в жизни...
|
|
|
|
|
|
|
|
Apr 18 2009, 00:51
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(singlskv @ Apr 18 2009, 04:45) Уже много раз их поминал..., однако это не мешает мне работать через него с мегой на ~ 150Кбод и 400 тоже возможно(если не делать искуственный оверхед ) А мне вот наоборот приходилось снижать скорость до 20кГц, чтобы не слишком отвлекаться на прерывания от TWI. Я уж не говорю о какой-то нездоровой прихоти инженеров Атмела, благодаря которой модуль влетает в underrun, являясь мастером на синхронной в общем-то шине Цитата(singlskv @ Apr 18 2009, 04:45) Я и не утверждаю что это абсолютное зло, просто для меня странными выглядят попытки заставить это работать,
пользоваться этим всегда, а реально воспользоваться премуществами 1 раз в жизни... Попытки полезны для мозга, для осознания назначения и особенностей работы различных режимов процессора, например.
|
|
|
|
|
|
|
|
Apr 18 2009, 01:06
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(aaarrr @ Apr 18 2009, 04:51) Попытки полезны для мозга, для осознания назначения и особенностей работы различных режимов процессора, например. Я же не против попыток, я не поддерживаю повсеместное использование спецобработчиков IRQ там где это нафиг не нужно... З.Ы. TWI ИМХО, можно разуливать почти всегда, по крайней мере после приведения логики обращений(чтение/запись) c мегой к варианту общения с EEPROM траблов больше нет. Ну а частота прерываний... это все-таки уже вопрос об общеем построении системы...
|
|
|
|
|
|
|
|
Apr 18 2009, 01:09
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(defunct @ Apr 18 2009, 05:01) Ну дык почему же вы остановились на Atmel'е? Выбирайте такой MAC который наиболее подходит к вашей задаче. По причине наличия у Атмела приличного SPI с DMA, и отсутствия LPC на момент начала проекта. Цитата(defunct @ Apr 18 2009, 05:01) Причем тут разработчики Atmel? Грех в них тапком не кинуть Уж больно много приходится заниматься их продукцией, и качество оной не окрыляет.
|
|
|
|
|
|
|
|
Apr 18 2009, 01:13
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(singlskv @ Apr 18 2009, 04:06) я не поддерживаю повсеместное использование спецобработчиков IRQ там где это нафиг не нужно... +1 Цитата Попытки полезны для мозга Для мозга более полезно находить способы как обойтись без попыток.
|
|
|
|
|
|
|
|
Apr 18 2009, 01:16
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(singlskv @ Apr 18 2009, 05:06) Я же не против попыток, я не поддерживаю повсеместное использование спецобработчиков IRQ там где это нафиг не нужно... Дык и я не поддерживаю, хотя и не вижу в этом особого зла. Цитата(singlskv @ Apr 18 2009, 05:06) З.Ы. TWI ИМХО, можно разуливать почти всегда, по крайней мере после приведения логики обращений(чтение/запись) c
мегой к варианту общения с EEPROM траблов больше нет. Ну а частота прерываний... это все-таки уже вопрос об общеем
построении системы... Да, EEPROM - это, кажется, один из очень немногих относительно надежно работающих с TWI продуктов Цитата(defunct @ Apr 18 2009, 05:13) Для мозга более полезно находить способы как обойтись без попыток. Да, например, задать глупый вопрос на форуме.
|
|
|
|
|
|
|
|
Apr 18 2009, 02:47
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(aaarrr @ Apr 18 2009, 04:57) А TE сбрасывать приходится? Ну, может просто повезло. Однако ситуация была отловлена вполне конкретно: TGO стоит, а передачи на самом деле нет. Приходится, но это редкое явление, хотя устройств много... уже б наверное проявилось где-то/как-то. Вот сейчас проделал небольшой эксперимент "в лоб", после установки EMAC_TSTART вставил сл. код: Код ....
// Start frame transmission.
pEMAC->EMAC_NCR |= AT91C_EMAC_TSTART;
delay_cycles( rnd() & 0xFFF );
if (pEMAC->EMAC_TSR & AT91C_EMAC_TGO)
{
pEMAC->EMAC_NCR &= ~AT91C_EMAC_TE;
r++;
if (pEMAC->EMAC_TSR & AT91C_EMAC_TGO)
f++; // TGO still set (reset failed)
else
s++; // TGO=0 (reset succeed)
}
....
} Пока r == s (уже > 100K) PS: проц из относительно старой партии - 0616.
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
