Микроконтроллеры AVR

[veso74]

... Это 32-битное умножение и 64-битное деление вместе с другим полезным кодом в t13 не влезало, это я подкоркой запомнил.

Нет. С Ардуиновское MicroCore к ATtiny13 код влезает в память: и с 64-битное деление, и с float (как и в PIC с float, там нет 64 бит), но хочу меньше ресурсов за другие функции: енкодер, дисплей и т.д. .
---
Мой вопрос скорее информативный. На самом деле код умножения не большой. lst файл. Так и будет, только калибровка точности VFO (correction) заключалась бы в том, чтобы хочу вводить его в 125000000 Hz, а не в float коэффициент. В float усложняет расчет.

....................   float fr = f * 34.360030370;  //  2^32 / F_MCLK = 4294967296 / 125000000 = 34.359738368
....................   f = (uint32_t)fr;
00B3:  MOVF   28,W
00B4:  MOVWF  2E
00B5:  MOVF   27,W
00B6:  MOVWF  2D
00B7:  MOVF   26,W
00B8:  MOVWF  2C
00B9:  MOVF   25,W
00BA:  MOVWF  2B
*
00D9:  MOVF   7A,W
00DA:  MOVWF  24
00DB:  MOVF   79,W
00DC:  MOVWF  23
00DD:  MOVF   78,W
00DE:  MOVWF  22
00DF:  MOVF   77,W
00E0:  MOVWF  21
....................

[ozforester]

Так и ответ был информативный. Если не знать наверняка, что там лишнего в операциях, то как это лишнее убирать. PIC то скольки-битный? А то у Attiny13 всего восемь бит, операции восьмибитные. Проверьте как будет выглядеть это же умножение для неё.

[veso74]

Два МК - PIC и ARV - 8 битныe. Не понимаю ассемблер. LST файлы после компиляции. Оба файла за соответствующие контроллера успешно загружает частоту в AD. Думаю, что больше нечего делать с оптимизацией. Код для вычисления оказался не большой, оставлю на этом.

[ozforester]

О да, пытаться оптимизировать код после gcc было бы легкомысленно. (: Но когда человек хорошо знает задачу, он может сократить код только для данного случая. Я это имел в виду. Пик, к сожалению, не знаю совсем, а то как умножает компилятор avr тихонько посмотрю и подумаю. Это полезно.

[ozforester]

Вот, выжал из avr-gcc (:
Это, конечно, уже с "костылём", без него меньше 40 байт никак не получалось.
Блинькает портом PB1
attiny13 с фьюзами (E:FF, H:FF, L:71)

$ avr-size blink.hex
   text       data        bss        dec        hex    filename
      0         26          0         26         1a    blink.hex

[veso74]

blink.hex -> ошибка моделирования в Proteus - невозможно запустить.

PC=0x0014. [AVR WATCHDOG] Incorrect watchdog timer setup sequence. [U1]
PC=0x0000. [AVR CPU] RET address = 0x0000 [U1]
Invalid opcode 0xFFFF at PC=0x008A

А код с 64 байт "мигает" и в Proteus. (Atiny13 в MicroCore)

#include <avr/io.h>
#include <util/delay.h>

int main(void) {
  DDRB = 0b00000001;

  while (1) {
    PORTB ^= _BV(PB0);
    _delay_ms(100);
  }
}

"Очень мало" (код) иногда не хорошо .

На самом деле схема с DS18B20 и OLED из другой темы выдает аналогичную ошибку и отказывается запускаться в Proteus.
Не знаю, какой компилятор используете, но вероятно что-то не так (или симуляция не так :П).

[ozforester]

avr-gcc --version
avr-gcc (Gentoo Hardened 11.2.1_p20211127 p0) 11.2.1 20211127


00000000 <.sec1>:
   0:    52 e0           ldi    r21, 0x02    ; 2
   2:    57 bb           out    0x17, r21    ; 23
   4:    06 c0           rjmp    .+12         ;  0x12
   6:    06 b3           in    r16, 0x16    ; 22
   8:    12 e0           ldi    r17, 0x02    ; 2
   a:    01 27           eor    r16, r17
   c:    08 bb           out    0x18, r16    ; 24
   e:    18 95           reti
  10:    fa cf           rjmp    .-12         ;  0x6
  12:    44 ec           ldi    r20, 0xC4    ; 196
  14:    41 bd           out    0x21, r20    ; 33
  16:    78 94           sei
  18:    ff cf           rjmp    .-2          ;  0x18


$ md5sum blink.hex
b7d99a5dc6f323a7d0477bb1971ab598  blink.hex

Это просто компромисс между ограничениями и целью.
P.S. Протеусу привет!

[ozforester]

схема с DS18B20 и OLED из другой темы выдает аналогичную ошибку

Это, вероятно там, где размер файла 1024 байта, и где тоже пришлось немного позаимствовать место у таблицы векторов, что может и не нравится симулятору. Но, специально для него есть другая прошивка к другому датчику, в которой все лишние манипуляции со стеком и прерываниями оставлены в каноническом виде. Если будет время, попробуйте предложить её протеусу. Там, кстати, прменяется растяжение фонта на основе алгортима "в лоб" (так называю прямую проверку бит в исходном байте и одновременное формирование бит выходного слова) И, да, снова ассемблер, хотя мысленно перехожу на си, понимая, что с кортексами на ассемблере не взлетишь.

[veso74]

Нет. С Вашим кодом симуляция в Протеусе не запускается. Сообщение такое же, как и в предыдущем коде.
А с моей (похожий тип термометра, написанной на C, MicroCore и Arduino) запускается и работает.

[ozforester]

Понятно, Протеус опять капризничает. PC указывает на запись в контрольный регистр таймера. По даташиту бит WDCE должен устанавливаться и в течение следующих четырех тактов меняться прескалер, но если читать совсем внимательно, то в начале абзаца говорится о "если запрограмирован фьюз вотчдога". А затем "To ... change the prescaler bits, WDCE must be set" без лишних комментариев кочует в описание контрольного регистра таймера. Учитывая общее количство страшилок в разделе, программисты решили не заморачиваться и добавить установку прескалера в два приема при любой конфигурации. Мне "градусник" к Альфе Центавра не запускать, а конфигурация простая и предсказуемая - нчего байты транжирить на двойной подход к регистру. Протеусу глубоко сочувствую, но потакать не стану, так и передайте, пусть не обижается. (: