[neiver 0]

Я заменил их макроопределениями типа USE_PORTA, которые объявляю в файле подобном avr/io.h для нужных мне контроллеров.

 

Да, ручками-то конечно можно определения писать, но не хочется.

[neiver 0]

Sergey_B, я пожалуй воспользуюсь вашей идеей с USE_PORTA. Для avr-gcc их можно определить автоматом, а для IAR - вручную

[neiver 0]

Добавил поддержку компилятора от IAR в свои списки линий. В общем работает.

Обновления в Git репозитории:

http://github.com/KonstantinChizhov/AvrPro.../master/avrcpp/

 

ЗЫ.

Что-то меня не впечатлил этот хвалёный компилятор от IAR Systems для AVR.

Я нашел тоько два вида оптимизации которые он делает лучше чем GCC:

- Common subexpression elimination,

- умеет работать с однобайтовыми указателями.

А в остальном как-то не впечатляет.

[MrYuran 18]

ЗЫ.

Что-то меня не впечатлил этот хвалёный компилятор от IAR Systems для AVR.

Я нашел тоько два вида оптимизации которые он делает лучше чем GCC:

- Common subexpression elimination,

- умеет работать с однобайтовыми указателями.

А в остальном как-то не впечатляет.

Не совсем в тему, но всё-таки местами он (ИАР) гораздо лучше работает.

В mspgcc при всех моих потугах мне так и не удалось достичь иаровского размера бинарника.

Разница как минимум 20%.

Существенно, когда балансируешь на грани невпихуемости.

Хотя, глючки иногда подкидывает специфические и трудноуловимые. Например, коллега целый день бился, пока не поменял bool на char. И это при нулевой оптимизации.

Преимущество ИАРа в том, что его лучше затачивают под конкретную платформу (под каждую из).

Недостаток - при этом он код теряет переносимость, вследствие специфических приёмов.

[Quasy 0]

Вопрос автору этого инструмента: как будет выглядеть после трансляции асм-код для ATmega128 при записи в группу из 4-х бит число 0x0A. Группа такая (начиная с младшего в группе): PA.0, PB.0, PD.3, PD.4? Хотелось бы посмотреть именно "боевой", (не учебный) код, который будет сгенерирован в этом случае. Спасибо.

 

[neiver 0]

to Quasy.

Исходный код:

#include <avr/io.h>
#include "iopins.h"
#include "pinlist.h"
#include "util.h"

using namespace IO;

typedef PinList<Pa0, Pb0, Pd3, Pd4>  Pins;

int main()
{
    Pins::Write(0x0A);
}

 

Асм листинг для атмега128:

 

000000be <main>:
    
  be:    d8 98           cbi    0x1b, 0; 27

  c0:    c0 98           cbi    0x18, 0; 24

  c2:    82 b3           in    r24, 0x12; 18
  c4:    87 7e           andi    r24, 0xE7; 231
  c6:    80 61           ori    r24, 0x10; 16
  c8:    82 bb           out    0x12, r24; 18


  ca:    80 e0           ldi    r24, 0x00; 0
  cc:    90 e0           ldi    r25, 0x00; 0
  ce:    08 95           ret

 

Как-то так. Писать в виртуальные порты константы не интересно - запись любого набора бит в один порт будет соптимизирована не более чем до:

in    r24, PORTx
andi    r24, Mask; 
ori    r24, Value
out    PORTx, r24

Интереснее запись занчеия неизвестного во время компиляции - там будет перетасовка бит из входного значения в резистры.

 

ЗЫ.

Интересно, что вам мешает взять исходный код и поэкспериментировать самостоятельно.

[Quasy 0]

Как, это уже и есть боевой код? Но согласитесь, в таком виде его применять просто нельзя. Где в вашем варианте элементарные мероприятия по защите от неатомарности портовой операции "чтение-модификация-запись"?

[neiver 0]

Атомарность доступа далеко не всегда нужна. Обеспечивать ее всегда слишком расточительно. Если она всё-таки необходима используйте ATOMIC_BLOCK и иже сним, например:

 

ATOMIC_RESTORESTATE

{

Pins::Write(0x0A);

}

 

В чём проблема-то?

[Quasy 0]

А проблема в том, что, в предлагаемом виде генерируемый код фигурально выражаясь, подпадает под статью "Вредительство". По крайней мере в стране эмбедеров :)) Применять его пока нельзя. И мне очень бы хотелось посмотреть генерируемый вашим инструментом вариант боевого код с учетом неатомарности. Или вы предлагаете программисту, применяющему ваш код, надеяться что не будет прерываний? Или вы предлагаете самому программисту позаботиться об атомарности? Очень хочется посмотреть вариант Безопасного кода записи в группу. Спасибо.

 

Дилемма. Без организации критической секции код применять нельзя. С организацией критической секции ваш код займет 11 тактов, что недопустимо. А все потому, что ваш код не научился делать четыре операции SBI/CBI.

[Сергей Борщ 128]

Или вы предлагаете программисту,

Ключевое слово "программисту". Которому голова дана не только чтобы в нее есть.

Или вы предлагаете программисту, применяющему ваш код, надеяться что не будет прерываний?

У меня нет махания ногами в прерываниях. Нафига мне лишний оверхед с вашей атомарностью?

А все потому, что ваш код не научился делать четыре операции SBI/CBI.

Зал притих - покажите, на примере порта E.

[neiver 0]

Заботиться об атомарности всё равно прийдётся программисту. Даже операция вида int c = a + b; И всегда есть шанс, что прерывание случится в момент когда первый байт в переменную "с" уже записан, а второй нет. И если в этом перерывании используется эта переменная "с"...

Вы предлагаете использовать везде операции SBI/CBI и выводить значение побитно? А что, если мы будем записывать значение неизвестное во время компиляции побитно? Попробуйте сами написать, хоть на Си, хоть на ассемблере. Покажите как должно быть правильно.

[Quasy 0]

Ключевое слово "программисту". Которому голова дана не только чтобы в нее есть.

У меня нет махания ногами в прерываниях. Нафига мне лишний оверхед с вашей атомарностью?

Зал притих - покажите, на примере порта E.

Залу не надо притихать! Он и так 8 страниц переливал из пустого в порожнее и не обсуждал самое главное - безопасность применения. Про PORTE? Ну, вам-то я скажу по секрету: у Atmega 128 (про который речь) его адрес 03 :) SBI & CBI. У меги128 90% портов в битовом пространстве.

 

 

 

Вы предлагаете использовать везде операции SBI/CBI и выводить значение побитно? А что, если мы будем записывать значение неизвестное во время компиляции побитно? Попробуйте сами написать, хоть на Си, хоть на ассемблере. Покажите как должно быть правильно.

Мы пока говорим про константы. Если настало время - я скажу и про переменные. Там для предложенной группы нет альтернативы варианту с побитовым анализом переменной и операциям SBI/CBI.

[DimaG 0]

Как, это уже и есть боевой код? Но согласитесь, в таком виде его применять просто нельзя. Где в вашем варианте элементарные мероприятия по защите от неатомарности портовой операции "чтение-модификация-запись"?

А вы все операции с портами ввода-вывода оборачиваете в критические секции? Даже те, которые абсолютно не зависят от прерываний? Надеюсь, что нет.

Тогда какой смысл оборачивать в критические секции операции в "библиотечном" классе? Разумно это отдавать на откуп пользователю

 

у меня это например реализовано так:

template <class ELEMENT, class SYNC_OBJ>
class TClQueue;

[Quasy 0]

А вы все операции с портами ввода-вывода оборачиваете в критические секции? Даже те, которые абсолютно не зависят от прерываний? Надеюсь, что нет.

Тогда какой смысл оборачивать в критические секции операции в "библиотечном" классе? Разумно это отдавать на откуп пользователю

 

у меня это например реализовано так:

template <class ELEMENT, class SYNC_OBJ>
class TClQueue;

Кто сказал про "класс"? Я просил результирующий асм-код и критикую его. Где будет решаться проблема неатомарности - это я и хотел понять. Причем критика не понедельничного злого бодуна, а вполне конструктивная: я предлагаю путь.

[MrYuran 18]

Тут пришёл поручик Ржевский и всё опошлил.

 

Скажите, Quasy, а нафига козе боян зачем вообще нужна ваша атомарность?

Я пока не вижу особых критических моментов.

Выставили байт - подали отдельно строб.

Тем более что при вашем битовом анализе всё равно вручную всё обеспечивать.