Перейти к содержанию
    

ARV

Свой
  • Постов

    1 257
  • Зарегистрирован

Весь контент ARV


  1. не знаю, что такое discovery, но проблема с подсветкой синтаксиса, обозначенная мной, решается тупым typedef __flash const char fchar; - после этого Eclipse прекрасно понимает, что fchar это тип и все подсвечивает правильно.
  2. у меня с английским не очень хорошо, а автопереводчикам не очень доверяю... Eclipse Luna мало того, что второй вариант объявления не понимает, но если такое объявление находится в числе параметров функции - вся функция не подсвечивется, и ниже по коду могут быть сбои парсера синтаксиса...
  3. все, тему можно закрывать 4.8.1 хотя еще рано закрывать тему: просветите еще, пожалуйста, как правильно определять массив в flash: 1. __flash const bla_bla_bla array[]; 2. const bla_bla_bla __flash array[]; Eclipsе не распарсивает второй вариант, хотя вроде как он правильный...
  4. блин, Сергей, ну спасибо Вам! как я лоханулся-то! действительно, переделал константы на 0xFF, 0xFE и т.д. - появились проверки!!! спасибо огромное! этого самого integer promotions в данном месте и не увидел вообще, незаметно подкрался...
  5. скачал с сайта Атмела текущую версию тулчейна для AVR8... ща попробую рекомендованную Вами скачать. еще раз и помедленнее, пожалуйста. в моем понимании беззнаковый байт -1 это всего-навсего 0xFF, и потому должен сравниваться...
  6. #define NO_CHAR -1 #define ANY_VAR -2 #define ANY_DIG -3 #define ANY_CHAR -4 в массиве - набор правил, т.е. условий проверки пары символов в строке. должны совпасть оба символа в строке с тем, что задано в одной из структур массива. если задано prev_ch = NO_CHAR - предыдущий символ не проверяется, потому что это ситуация начала строки и предыдущего символа просто нет. если curr_ch = NO_CHAR - в строке должен быть на текущей позиции пробел. ANY_VAR - символ в строке должен лежать в некоем диапазоне значений. ANY_DIG - символ должен быть цифрой. все остальное - прямое равенство. номер структуры, для которой первой все условия совпадут и есть номер правила.
  7. pgm_read_xxx - это кошмар :( проще будет перенести массив в ОЗУ. перенес массив в ОЗУ... складывается впечатление, что что-то у меня не то записано в условиях внутри цикла, потому что компилятор упорно выбрасывает все if-ы - видно, считает, что условия никогда не выполняются. но я не вижу этой однозначности... может, со стороны виднее: ткните носом!
  8. уважаемый klen, нельзя ли попросить Вас опубликовать ссылочку на то место, куда Вы складываете свои релизы? дело в том, что отдельно публикуемые Вами ссылки на архивы рассыпаны по сообщениям в этой теме и выискивать нужное нелегко... а вот чтобы самому покопаться в накопленном добре - это было бы удобно... в частности, меня интересует AVR, а Вас, как я понимаю, уже нет - вот я бы и поглядел на "старенькое"...
  9. я перешел с WinAVR на AVR Toolchain практически только из-за этой самой поддержки __flash, ибо реализация вышеупомянутой функции при помощи pgm_read_xxxx - это не геморрой даже, это ужас нерожденного... так что по существу моего вопроса скажете, уважаемые коллеги? неужели никто с массивами структур во flash не работает?!
  10. Не едут лыжи, помогите понять, почему происходит следующее. есть такая структура typedef struct{ uint8_t prev_ch; // предыдущий символ uint8_t curr_ch; // текущий символ uint8_t auto_eq; // автовставка TOC_EQUAL uint8_t can_ok; // разрешено нажатие ОК (конец редактирования) uint8_t approved_begin; // индекс первого разрешенного следующего символа uint8_t approved_end; // индекс последнего разрешенного следующего символа } smart_rule; делаю массив таких структур в адресном пространстве __flash, которое как бы поддерживается AVR Toolchain (и для обычных строк действительно поддерживается!) const smart_rule __flash rules[RULES_CNT] = { тут инициализирую все структуры } затем есть код, с которым дикие проблемы: uint8_t find_rule(uint8_t pos, char *s){ uint8_t i; for(i=0; i < RULES_CNT; i++){ if((rules[i].prev_ch == NO_CHAR) && (pos == 0)){ if((rules[i].curr_ch == NO_CHAR) && (s[pos] == ' ')) break; if((rules[i].curr_ch == ANY_VAR) && (s[pos] >= TOC_WDAY) && (s[pos] <= TOC_QUART)) break; if(rules[i].curr_ch == s[pos]) break; } if(rules[i].prev_ch == ANY_CHAR){ if((rules[i].curr_ch == NO_CHAR) && (s[pos] == ' ')) break; if((rules[i].curr_ch == ANY_VAR) && (s[pos] >= TOC_WDAY) && (s[pos] <= TOC_QUART)) break; if(rules[i].curr_ch == s[pos]) break; } if((rules[i].prev_ch == ANY_DIG) && (s[pos-1] >= '0') && (s[pos-1] <= '9')){ if((rules[i].curr_ch == NO_CHAR) && (s[pos] == ' ')) break; if((rules[i].curr_ch == ANY_DIG) && (s[pos-1] >= '0') && (s[pos-1] <= '9')) break; if((rules[i].curr_ch == ANY_VAR) && (s[pos] >= TOC_WDAY) && (s[pos] <= TOC_QUART)) break; if(rules[i].curr_ch == s[pos]) break; } } return i; } проблемы следующие: 1. в том виде, как описано, Eclipse категорически отказывается понимать обращение к массиву типа такого rules.prev_ch - пишет, что Field 'prev_ch' could not be resolved, аналогично и на все другие поля. при этом компиляция идет без ошибок. 2. Eclipse перестает ругаться, если меняю определение массива на такое: __flash const smart_rule rules[RULES_CNT] 3. ладно, пусть я не понимаю, как правильно определить массив во flash, НО!!!! в итоговом коде нет тела вышеприведенной функции find_rule - если отключаю оптимизацию, остается ПУСТОЙ ЦИКЛ, а при включенной оптимизации даже нет обращения к функции! ПОЧЕМУ? почему компилятор считает, что ни один if не сработает? что я делаю не так? почему если я задаю опции -fdata-sections и -Wl,-gc-sections, то мой массив rules исчезает из кода?! я же делаю к нему обращения!
  11. не существует понятия "действующая мощность", кроме как в воспаленном воображении креативных деятелей от науки! Мощность бывает активная, реактивная, полная и кажущаяся. рекомендации по тому, откуда взять расшифровку терминов, я давал. что там вики пишет по этому поводу не читал и не намерен - в лучшем случае там будет без ошибок переписанные определения из настоящих книг, в худшем - переписанное с ошибками и "креативными" додумываниями.
  12. несомненно, вычислить можно. только RMS реально имеет смысл для сигналов, среднеее значение которых равно нулю, например, синусоидльный переменный ток. для пульсирующих однополярных вполне можно обходиться средним. RMS - это замена среднего значения в этих случаях :)
  13. если какой-то файл редактировался, скажем, тремя авторами в разное время разными участками, имеется ли возможность "откатить" изменения, сделанные только одним из редакторов, оставив изменения остальных в силе? что будет, если при этом один участок кода многократно правился всеми тремя, причем один изменял изменения другого?
  14. RMS или действующее значение (это синонимы по сути) имеет смысл только для не постоянного напряжения и тока! определяется эта величина, как значение постоянного тока или напряжения, выделяющего на той же нагрузке ТУ ЖЕ САМУЮ АКТИВНУЮ МОЩНОСТЬ. вдумайтесь, как вы определите RMS-мощность?! попытки определения Prms=Irms*Urms являются, как мне кажется, следствием того, что во всех областях техники сейчас засилье малограмотных манагеров, выдающих себя за крутых специалистов, которые с легкостью вводят понятные им новые понятия и характеристики. На самом деле эта величина имеет иное название. Откройте любую книгу по электротехнике, особенно хороши книги 30-40х годов, т.к. написаны действительно умными людьми, а не 30-летними докторами наук, и прочтите определения основных электрических параметров переменного тока. На эти параметры частота (СВЧ или УВЧ или иная) никак не оказывает влияния.
  15. несомненно шкаф поедет целиком :))) мой вопрос ведь и был о том, зачем каждые 5 лет придумывать новый интерефейс для передачи потока данных, который, если разобраться, не особо-то и необходим? иначе говоря, кому интересно для перевозки шкафа выделять целую фуру, если можно обойтись и газелькой? HDMI именно из-за того, что передаются сырые данные имеет небольшую длину и стоит бешеных денег! при этом передаваемые данные искажаются и теряются, если кабель не самый качественный. это все издержки. через пару лет появится что-то типа superHDMI (а может и уже появилось) для передачи видеоданных стандарта 4К или там 16К, при этом доставка этих данных до устройства воспроизведения так и будет по дешевой витой паре...
  16. спасибо за ответы. разумеется, я не владею стандартами, но пытаюсь осмыслить все, что попадает в круг моих, пусть даже частных, интересов. я не предлагал передавть сырые данные. растр в компе практически всегда хранится в так или иначе сжатом виде - и всех это устраивает. только суперпрофессиональные художники/дизайнеры работают с "сырыми" данными, но по-моему, и это скорее показатель крутости, чем необходимости. итак, работа со сжатыми растрами ВСЕХ устраивает, и только на промежутке видеокарта-монитор зачем-то необходимо передавать сырые данные... зачем и почему? или после того, как сжатый растр (текстуру) видеокарта натянет на поверхность, в итоге получается суперкачественное изображение, которое иначе, как передачей нативных пикселов нельзя отобразить?! оно же по определению будет хуже исходного плоского растра! :) кстати, если отображаемый растр не совпадает с физическим разрешением монитора, то монитор самостоятельно "коверкает" его - и это опять же никого не смущает! так кому в итоге НЕОБХОДИМЫ гигабиты данных, посылаемых в монитор?!
  17. Кто-нибудь может разъяснить, почему в компьютерные мониторы и видеокарты в процессе своего развития (переходе с VGA на цифру) встраивают какие-то постоянно изобретаемые интерфейсы типа DVI, HDMI и наверняка что-то на очереди созревает, в то время как любой видеопоток легко передается через обычную сетевушку? не разумнее ли было бы просто встраивать сетевую карту в монитор и использовать его именно как сетевое устроство? это ведь решило бы все проблемы "мультимониторного" подключения, заодно было бы полностью стандартизировано и однозначно драйверонезависимо... мне кажется, кроме плюсов, ничего негативного в этом нет... или я что-то важное упускаю?
  18. хоть убейте, не понимаю, чем лучше префиксная запись. если в байт-код писать признак скобок для будущей "печати", то совершенно без разницы, что пре-, что пост- вот на счет бита скобок - это хорошая идея, сразу бы ее подкинули - может, я б давно все сделал :)
  19. я делаю интерпретатор собственного байт-кода. ОПЗ позволяет получить строго линейный байт-код, т.е. извлекаю байт за байтом и исполняю, не нужно передвигать указатели, помнить предыдущие состояния и т.п., как для дерева. получение ОПЗ из нативной формулы достаточно простое, я его уже реализовал. чем лучше дерево для интерпретации - не понимаю. возможно, был бы смысл в нем для интерпретации не формул, а именно языка более высокого уровня, с ветвлениями, подпрограммами, циклами и т.п., но даже и в этом не уверен. остается небольшое дело: показать байт-код в виде понятного человеку выражения. на сегодня эта проблема уже решена мною примерно на 90%, на Си, без динамического распределения памяти (на статическом массиве байтов). пока что немного вызывает проблему унарные и тренарные операторы - в упомянутый ранее алгоритм эти операторы вписываются плоховато... спасибо за внимание.
  20. я очень благодарен за советы сломать до основания все и построить новое лучшее... но я был бы еще более благодарен за ответы по существу моего вопроса, без критики моего подхода (оставьте мне мое желание стучаться в открытые двери).
  21. вот, кстати, на хабре нашел алгоритм: http://habrahabr.ru/post/147104/ только вот для МК с небольшим объемом ОЗУ алгоритм с динамическим выделением памяти - это не фонтан... и работа со строками тоже не очень хороша...
  22. должно получиться, я надеюсь... хранить в том виде, как вводится формула, можно, но вот интерпретация будет тормозной.
  23. храню и исполняю я в польской, но ведь пользователю надо иной раз показать, что именно там харнится и исполняется? и показать надо в том виде, как он вводил.
×
×
  • Создать...