Планирую сделать FDD эмулятор на Atmega8

[EvgenRU]

А в ардуино IDE разве нельзя делать ассемблерные вставки?

Можно, но толку от них, если неизвестно, что в каком регистре и их нужно сохранять перед использованием

Что именно пытались генерить и насколько сильно не успевает AVR?
Пушей "видимо много", или на самом деле много (легко понять по листингу)?
GCC с ассемблерными вставками как вариант не рассматриваете?
Библиотека работы с SDHC и FAT32 на ассемблере или Algoritm Builder-е уже существует или планируете писать и отлаживать сами?

Вот такая LPM конструкция работает нормально

ISR(USART_UDRE_vect)
{
tmp2 = MFM_tab[1];
UDR0=(byte)(tmp2 >> 8);
UDR0=(byte)tmp2;
}

а вот такая уже нет

ISR(USART_UDRE_vect)
{
tmp2 = MFM_tab[track0[i++]];
UDR0=(byte)(tmp2 >> 8);
UDR0=(byte)tmp2;
}

GCC со вставками опять же упрется в сохранение регистров.
Для AB думаю не составит большой сложности FatFs переделать, там кода не много.

В принципе, если на компе TRD перегнать в MFM, и потом эти данные выдавать, то ардуины должно хватить (теоретически)

[Advertiser]

[s_kosorev]

а вот такая уже нет
ISR(USART_UDRE_vect)
{
tmp2 = MFM_tab[track0[i++]];
UDR0=(byte)(tmp2 >> 8);
UDR0=(byte)tmp2;
}

это на ассемблере делать нужно
причем что бы шустрее работало, MFM_tab выравнять в памяти по 256байт граице, в ISR можно сказать каждый такт на счету
причем что бы быстрее было, 2 таблицы, сначала 256 старших байт, потом младших

[Trol73]

GCC со вставками опять же упрется в сохранение регистров.
Для AB думаю не составит большой сложности FatFs переделать, там кода не много.

Идея писать все на ассемблере - это преждевременная оптимизация, классическая ошибка проектирования. GCC умеет оптимизировать код, тем более, такой тривиальный. Перенос на ассемблер может дать не более ~10% ускорения, что в данном случае не имеет никакого значения.

Для начала надо оптимизировать код на Си. А для этого надо смотреть его ассемблерный листинг.

Сейчас бросаются в глада две вещи:
1. MFM_tab[track0[i++]] - зачем тут два массива? нельзя сразу поместить подготовленные данные в массив track_data[] ?
2. ну и да, алгоритм надо преобразовать так, чтобы индексы были однобайтными - это сокращает код в разы.

В принципе, если на компе TRD перегнать в MFM, и потом эти данные выдавать, то ардуины должно хватить (теоретически)

Перегонять TRD во что угодно можно и на самом девайсе - есть SD-карта, и ничто не мешает на нее сохранять временные данные в любом удобном формате

[s_kosorev]

track_data[]

тогда на буфер сектора надо будет 512 байт а не 256

- - - Добавлено - - -

как вариант можно нечто такое расмотреть

alignas(256) static const uint8_t mfmtab_h[256] = { .... };
alignas(256) static const uint8_t mfmtab_l[256] = { ... };
	
alignas(256) static uint8_t  sect_data[2][256];
register uint8_t rdbuff asm("r3"); // тут держим старшую половину адреса текущего буфера
register uint8_t rdpos  asm("r4"); // тут позиция в буфере

ISR(USART_UDRE_vect, ISR_NAKED)
{
	asm ("push r31");
	asm ("push r30");
	asm ("push r29");
	// формируем указатель в буфере сектора
	asm ("mov  r31, r3");
	asm ("mov  r30, r4");
	// читаем данные из буфера сектора
	asm ("ld   r29, Z");
	asm ("inc  r3");
	// формируем указатель на mfmtab_h
	asm ("ldi  r31, hi8(mfmtab_h)");
	asm ("mov  r30, r29");
	// чтение mfm_h
	asm ("lpm   r29, Z");
	asm ("sts  0xc9, r29");
	// формируем указатель на mfmtab_l
	asm ("inc  r31");
	// чтение mfm_l
	asm ("lpm   r29, Z");
	asm ("sts  0xc9, r29");
	
	asm ("pop  r29");
	asm ("pop  r30");
	asm ("pop  r31");
	asm ("reti");
	
	/* аналог на Си
	uint8_t* pos = (uint8_t*)((rdbuff << 8) | rdpos);
	UDR0 = mfmtab_h[*pos];
	UDR0 = mfmtab_l[*pos];
	rdpos++;
	*/
}

тело ISR где то 19 тактов, GCC раз 5 больше выхлоп дает

[tnt23]

Идея писать все на ассемблере - это преждевременная оптимизация, классическая ошибка проектирования. GCC умеет оптимизировать код, тем более, такой тривиальный. Перенос на ассемблер может дать не более ~10% ускорения, что в данном случае не имеет никакого значения.

Ерунда. В данном случае писать на ассемблере можно и нужно, особенно если прикинуть длительность bit cell (500нс) и время выполнения однотактовой AVR инструкции на 16МГц (62.5нс).

Топикстартеру - я это все уже проходил на ATmega256@16MHz. Помогал только выпрямленный tight loop c очень плотным кодированием по тактам, а также высушенные и обрезанные по самое немогу обработчики прерываний. Да, и еще у меня была привешана внешняя DRAM c программной же регенерацией.

Мой вам совет (с) маркер из "Шерлока Холмса" - выкинуть AVR и взять любой STM32.

- - - Добавлено - - -

Например, самый простой из семейства STM32F0 на Терраэлектронике - 84р (восемьдесят четыре рубля, Карл!). Тактовая 48МГц, фигова куча периферии - а кстати, для формирования MFM потока можно использовать SPI, - и вообще.

[dosikus]

Тактовая 48МГц,

Причем гонятся до 64МГц, но это уже из области извращений...
А STM32F0x2 умеют набортный DFU бут ...

[s_kosorev]

В данном случае писать на ассемблере можно и нужно, особенно если прикинуть длительность bit cell (500нс) и время выполнения однотактовой AVR инструкции на 16МГц (62.5нс).

итого при 120 инструкций на байт MFM, ISR в 20-30 тактов, оставляет уйму времени для подкачки данных с SDCARD, 20-25% времени ядра на ISR это ниочем, зачем тут ARM с кучей не нужной для задачи перефирии?

Кстати в ARM почти весь профит от частоты съест вход в ISR, возможно даже будет не хватать

[Trol73]

тогда на буфер сектора надо будет 512 байт а не 256

А разве 256 байт - это критично для m328? Массивы mfmtab так вообще 512 байт занимают..

Ерунда. В данном случае писать на ассемблере можно и нужно, особенно если прикинуть длительность bit cell (500нс) и время выполнения однотактовой AVR инструкции на 16МГц (62.5нс).

На ассемблере есть смысл писать критичные к скорости выполнения куски кода в конечном приложении. Это позволить немного ускорить код. Сейчас же речь о прототипе, который только формирует сигнал и ничего при этом не делает, с картой не работает. Эти 10% выигрыша быстродействия тут не должны играть решающую роль. Когда добавится работа с картой требования к процессорному времени, затрачиваемому на формирования сигнала могут возрасти.

Проходил нечто подобное когда делал поддержку воспроизведения WAV 44100 Гц в своём магнитофоне. Сначала все тормозило и скорости не хватало. Переписывания кода обработчика прерывания на Си, разбиение массивов длиной 512 байт на два массива по 256 байт дало ощутимый прирост в скорости выполнения. Небольшие оптимизации библиотеки поддержки SD-карты и FAT-а (разворачивания циклов, inline-зация нескольких функций и отключение лишних проверок) ещё немного ускорило прошивку.
Потом переписал обработчик прерывания на ассемблер. Да, он стал работать чуть быстрее, но основной вклад внесла именно оптимизация Си-кода и отказ от 16-битных индексов массивов.

PS. использование 48МГц МК для эмуляции флопа для компьютеров, частота которых измеряется единицами МГц - как-то неприлично, имхо

[s_kosorev]

так вообще 512 байт занимают..

ну так таблицы в флеше, а 2 буфера в оперативке по 512 это уже 50% памяти в расход ушло

[Trol73]

ну так таблицы в флеше, а 2 буфера в оперативке по 512 это уже 50% памяти в расход ушло

Ну не совсем 50% в расход, а + 256 байт, т.е., +25% за сильное упрощение процедуры обработчика. Тут вопрос, на что еще нужна память во время выдачи трека. И, если её хватает, то это вообще не проблема.