В даташийта на PIC16F1827 на страница 366 и 367 са отбелязани изискванията за времената. Странното е, че въпреки че клока е външен изискването е Clock High и Clock Low периода да са 1 Tcy + 20ns. Това обаче си противоречи малко с изречението


Разбира се аз приемам че Tcy е времето за една инструкция или Tosc * 4, защото навсякъде е иползвано в този смисъл.

Ясно е, че има изисквания за SS сигнала спрямо системния клок, но защо и клок-а? Ето още един цитат:


... който ме навежда на мисълта, че в sleep или не все си работи асинхронно и не зависи от системния клок.

Обаче зависи. Пробвах го. Ако пусна SPI с честота 1MHz, и PIC16F1827 работи на 4 МХз всичко е наред (въпреки че не съм точно сигурен за + 20-те наносекунди. на 2 МХз не работи. Изобщо. Връща пълни бози - рандом генератор.

Аз ли не съм допрочел добре или те не са донаписали както трябва?

Трябваше да продължиш в другата тема "MSSP на PIC16F1827 и SS пина", за да може написаното евентуално да е полезно и на друг, без да се налага да рови, но както и да е...
Чети ...

Не исках проблемите от другата тема да пречат. Всъщност проблема беше програмен.
Ще опиша по-подробно картинката: Използвам Data изходите за на PORTD на PIC18F45K22 и за SPI2 за да комуникира с PIC16F1827 трябва да съм сигурен че съм вдигнал SS за да не пречи изхода на SPI-то на PIC16 кодато PIC18 праща данни на дисплея. В една от другите теми мислех, че SDO на PIC16F1827 не минава във висок импеданс защото като го свържа на дисплея се появяваха безсмислици. Всъщност проблема беше програмен и го отстраних - не щраках правилно SS.
Колкото до темата с къдравия сигнал на clock-a ... проблема беше в сондата и след подходящо свързване сигнала се вижда че е идеален...
Това:

...предполага, че в даташийта е написано правилно и аз съм прочел грешно, така че ще му ударя още един прочит.

Освен това свалих честотата на SPI на 1 MHz докато съм сигурен че всички останали проблеми са изчистени и след това ще се боря с проблеми с висока честота.

Препоръчах ти да четеш по-внимателно документацията, ератата, че и Чичко Гугъл да попиташ, ако трябва.
Щото може да има грешка в документацията, бъг или път грешката да е твоя. В случая, просто е написано малко йезуитски.

Обвързването на външния клок с Tcy го разбирам като обвързване с минималното Tcy. Виж картинката с входния капацитет за който са зададени тези времена.

Що се касае за SPI OPERATION IN SLEEP MODE:

In SPI Master mode, when the Sleep mode is selected, all module clocks are halted and the transmission/reception will remain in that state until the device wakes. After the device returns to Run mode, the module will resume transmitting and receiving data.

Демек, изчакай да свърши transmission/reception и тогаво ходи да спиш, щото по време на сън клока спира.

In SPI Slave mode, the SPI Transmit/Receive Shift register operates asynchronously to the device. This allows the device to be placed in Sleep mode and data to be shifted into the SPI Transmit/Receive Shift register. When all 8 bits have been received, the MSSPx interrupt flag bit will be set and if enabled, will wake the device.

Значи, спи си, като дойде байт - ще те събудя.

ама говорим за Slave mode. PIC16F1827 със SSP2 в SPI slave режим. Пише че може да работи в sleep. Но на мен не ми трябва в sleep. Искам да разбера има или няма зависимост в слейв режим от клока и ако го накарам да заспи (защото може понеже в слейв режим клока се подава отвън) как така ще зависи от Tcy след като системния клок е спрял... Малко е тъпо.

Сега - относно спането, аз не ща да го приспивам изобщо, но ако това ще помогне да получа байт по-бързо бих го приспал. Тъпо е да го щракам на 32 МХз и да харча ток само заради SPI-to след като ми върши работа 1 МХз. Проблема е обаче, че в даташийта не пише да има разлика между speep и run mode за SPI slave, но пише, че зависи от системния клок и оперира в sleep, когато няма системен клок - като да сипваш уиски с кана, но да можеш да сипваш със скоростта на дозатор само, въпреки че няма такъв...

За този контролер няма много инфо в гугъл. Може да опитам с други от серията - може някой да си е блъскал главата вече.

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

Набляга се на това, че и в слийп режим байтовете си вървят, въпреки, че вътрешния клок е спрян.

Приеми, че хардуерно имаш шифт регистър с външен клок и външни серийни вход и изход. Вътрешни ти са паралелните шини за запис и четене и входовете за тяхното управление и изходите за състоянието (флаговете).

И аз това казвам. Отде тогава изискването SPI slave clock High time и Low time >= Tcy + 20 ns? - виж страница 366 и 367

Е това е очевидно и без да съм ти чел чипа, външния клок го синхронизират по вътрешния,
то без някаква синхринизация няма и как да работи. Стандартна практика, преди да ползват
нещо вътре първо го синхронизират.

tgi обикновено се вслушвам обаче тук не съм съгласен. Да, синхронизация трябва да има, но не на клока, а на SS сигнала. Както е описано в документацията MSSP е отделна периферия. Шифт регистъра му работи по външния клок. Единствената нужда от синхронизация е когато SR се напълни и рече да копира във SPBUF. това вече трябва да е в синк с вътрешния клок. И пак казвам - в sleep нямаш вътрешен клок. а MSSP в слейв режим работи в sleep. Виж цитата от документацията:



Т.е. от 'къв зор им е да го синхронизират след като пишат че е асинхронно?

На границата на двата клок домейна се прави синхронизация. Не е задължително да е на самия външен клок. След като може да работи и приспан, по-вероятно границата е между шифт регистъра и буфера. На това място нищо не трябва да се променя по-бързо от един такт на системния клок.
Предполагам, ако пращаш байтовете с достатъчна пауза между тях, ще работи и с по-бърз външен клок. Ако са непосредствено един след друг, или ще се прехвърлят грешно в буфера, или няма да се установяват правилно флаговете за получени данни или за изтърван байт от непрочетен буфер.
Ама това са хипотези само, при това без значение. След като имаш ограничение в спецификацията, значи го спазваш.

Даже и да не синхронизират серийния клок (възможно макар и не особено вероятно), нали за да
прочетат/напишат шифт регистъра трябва да го цъкнат синхронно спрямо вътрешните клоци.
Инак просто няма да работи, понякога ще го четат баш в момент на преход и т.н. бози.

Та точно кой клок къде синхронизират не знам но и не е интересно в твоя контекст, именно
синхронизацията е причина за тия времена дето им се чудиш .

Edit: Писали сме едновременно със 741, горе-долу едно и също но по различен начин та
оставям и моето.

Това беше и моята логика. За целта на пробата пращах байт на всеки 0.2s. Не става.

Ок. Да кажем, че са имали причина да ограничат външния клок до честотата на вътрешния. Това, което ме интересува е мога ли да пращам байт в sleep mode с голяма скорост... тъй като вътрешен клок няма. Според спецификацията SPI clock high и low трябва да е >= Tcy+20ns -> в sleep режим това е безкрайност + 20ns. т.е. честотата на външния клок трябва да е 0 -> следва че не може да работи в sleep mode. И пак по спецификация казват, че може да работи в sleep. Няма отделни времена за slave в sleep и в run mode.

При такива противоречия си мисля че има грешка в спецификацията. Поправете ме ако бъркам, но според мен е очевидно че спецификацията е непълна или си противоречи.

Не е кой знае каква философия да се направи така, че и двете неща от спецификацията да са верни.
Провери го, за пет минути работа е.

ще го пробвам. само че ще ми е много трудно да го накарам да заспи точно когато този отсреща праща байт, особено като имам таймер който ще го събуди. Май ще трябва да го пусна на 32 МХз ... добре че харчи само около 5 мА. От друга страна мога да го включа на 32МХз и да го приспивам (и без това при 32 МХз ще си свърши работата 64 пъти по-бързо от 500 кХз... дали е буден или не като идва нещо по СПИ няма да има значение стига честотата да е <= 8 МХз. Може да ръчна OSCTUNE и да вдигна честотата малко над 32 МХз така че да изпълня условието + 20ns.

Ами приеми, че SPI интерфейса като хардуер има такива ограничения за клока, т.е. такава му е максималната тактова честота. Виж колко е максималната честота на клока в мастър режим - май пак толкова. Би могло да се очаква и повече, но ти гарантират до Fosc/4 = 8 MHz max. А тия 20ns са вероятно очакваните rise/fall времена. Пусни по-бърз външен клок и виж какво става. Предполагам, че до определена честота ще работи...



На slave в sleep не му трябва вътрешен клок - нали за това е външния.
Разреши прекъсването, заспивай и пусни другия проц да предава, а при прекъсване зареждай байта който ще предаваш и ще видиш какво се получава.