По скоро губи време в сетването на дата пин-а (Set serial bit - this macro sets/resets LATx bit). Компилатора трябва да е мноо тъп за да не направи 4 последователни шифта през carry - не е там забавянето, а и ако беше от шифтването щеше да се бави и при втория шифт. Ако битовете са до 48 може да се мине и с 3 шифта както каза Ники. Разгледай си асемблера след компилация и ще видиш къде ти се бави.

Да, би било интересно да се види disassembly листинг-а.
В макроса за сетване на data пин-а, има също операция с 64 битова променлива - лог AND, което плюс времето за шифтване след това на 64 битовата променлива frame идва в повече от само шифтване на response докато трае CLK HIGH. Да, това вероятно e причината за разликата между времената CLK_HIGH - CLK_LOW, но не е основната причина за това "че бави". Основната причина за това "че бави" според мен е в използването на 64 битови променливи и как се справя с това съответната имплементация на компилатор за dsPIC33F (т.е. колко точно е тъп компилатора).
А операциите с 64 битови променливи при 16 битово MCU едва ли стават само и единствено в регистрите на ядрото. Докато стигнеш до тези 3-4 последователни шифтвания, нали променливата се прочита от паметта, между всяко шифтване нали се проверява за пренос, после се пише обратно в паметта и т.н.

Закъснение в долното ниво на клока се допълва заради преход към началото на цикъла и проверката на условието му.
В по горно мнение това се избягва с цъкъл do..while, стига компилатора да ползва една инстрикция за проверка.
На асемблер дсПИК има инструкция за цикъл и забавяне от преходи и проверка на условие няма да има.
След като се уточни от къде и как идва MASK, прочитането на пин е 2-3 инструкции, сетването на пин е 4 инструкции и два шифта по 3 инструкции всеки.
Всичко става само с регистри, прехвърляне с памет е преди и след цикъла.

Но ако не се е отказал питащия да даде листинг.

Така както е с главни букви, ако се следва популярната нотация, MASK би трябвало да е константа. Но със сигурност за това парче код MASK е променлива, която е в корелация с n и двете зависят от броя битове за текущия фрейм. Ако on build time, MASK се закове на (1<<63) (т.е. дефинираме я като константа) това, на един не толкова тъп компилатор, би помогнало в оптимизациите. Но в случая съм сигурен че MASK е променлива/аргумент щом като:

Най-вероятно MASK е дефинирано така:


Ако MASK се дефинира като (1ULL<<63) и frame се шифтне преди влизане в цикъла:


С тази промяна ще си проличи дали това което предположих по-горе е вярно, в поизравняване на HIGH - LOW времената на клока.

И на мен ми изглежда да е променлива.
И маскирането с 64 бита е основнята тежест в забавянето.
По горе колегите предложиха хардуерен СПИ, ама с това маскиране и писане на пин не ми се вижда постижимо. Ако е само четене-може би.
За да се оптимизира маскирането при тоя проц, ще трябва преди цикъла след проверка на МАСК в кой регион от 64 бита попада, а в цикъла да се маскира само единия регистър, не 64/48 бита.

Zdraw даде разумен съвет с разцепването на цикъла,
SPI-то може да е /може да не е решение - може да е бавно превключването между
GPIO и SPI режим на пиновете, платката може да е готова вече и да не позволява SPI.

На мене ми е чудно- защо е избран такъв "плаващ" брой битове , сещам се за някакви светодиодни ленти...

С максимум оптимизиран цикъл ще се постигне скорост около 1-1.1МХз.
А с развитие на идеята на Zdrav, изпълнение не с цикъл а с последователен бит-банг, може и да стигне скорост 2.6МХз.

ПП: Отдавна не бях мислил във формат ембедед. Всъщност се коригирам, този процесор може да превключва периферии на всеки пин, stefan63 е прави и може да се адаптира комбинация от СПИ и бит-банг за повече скорост. С по стари пикове съм имал проблеми от спайкове на клока в подобна комбинация, но за този не съм в час.

Незнам дали по-нагоре някой не е писал, но повечето пикове имат малък сегмент програмируема логика(не точно като на фпга или цплд, но имаш примитиви, които може да навържеш).
не е трудно да си напишеш какъвто искаш шифт регистър, и да го аксесваш като memory mapped peripheral илиу закакчиш през ДМА.

признавам, че за пик съм писла има няма преди 12 години, и то насила, но повечето микриконтролери го имат - NXP със сигурност.

Погледнах, dspic33 има нещо подобно, ама е повече ориентирано към входове.
Чак 48 битов регистър ....май не.

Хайде сега , не може ли да си опишеш 48 итов регистър?

Една идея, дано не ви се стори много смешна.
Два синхронизирани SPI бъса, единият бълва битовата поредица по MOSI,
вторият бълва поредица от 0 и 1 пак по MOSI, които имитират тактовия сигнал,
с дължина, каквато е необходима.
Съответно, вторият SPI трябва да е с два пъти по-голяма честота.
Не знам доколко е осъществима в този процесор.

смях

Е, от време на време трябва и малко смях.
Може би трябваше да го постна в "Хумор".
Още един въпрос от серията тъпи - на този dsPIC33F SPI не поддържа ли
I2S variable word length data?

@al_at и SPI "трикове"
https://github.com/fizban99/microbit_hcsr04