MBedder, терминатор (06.12.2010 17:02 - 17:11, просмотров: 229) ответил fk0 на Немного отвлечённо, но общие соображения: 1) нельзя из C переключить OSCCON (ибо код получается разный с/без оптимизации и нет гарантии работы). 2) надо *всегда* программировать все FSR, особенно касающиеся конфигурации ног, с нуля как положено-
- Не всё так просто. Про эти builtin_write... нигде вообще не говориться. Хотя конечно *.h из комплекта компилятора разглядывать, безусловно, полезно. Кроме того, упоминание о pps.h есть в family peripheral library что подразумевает её наличие и fk0(296 знак., 06.12.2010 17:28)
- То есть, PPSUnlock() вместо твоей квазиассемблерной портянки, и PPSOutput(U2TX,RP5) вместо твоего "RPOR2bits.RP5R = 5" - это гавнокод, а в hlpMPLABC30.chm.Built-In Function List тебя забанили? Спасибо, посмеялсо от души :)) - MBedder(06.12.2010 17:44)
- Ещё раз, для тормозов. Использование PPS-xxx -- подразумевает использование platform peripheral library, которая МОЖЕТ НЕ ИСПОЛЬЗОВАТЬСЯ. Да -- индусский говнокод. Лишняя сущность. Замечание же на счёт использования __builtin_write_OSCCONL и т.п. fk0(50 знак., 06.12.2010 17:46)
- НИКАКИХ "platform peripheral library" на дух не требуется, PPS.h содержит все, что нужно. Я сначала написал свой PPS.inc для ASM30 и запостил на микрочиповский англофорум, а разработчики С30 потом сделали из моего PPS.inc свой PPS.h - MBedder(06.12.2010 17:52)
- Прочитал внимательно. Я таки действительно не прав и PPS.h полезная штука. Но его нет ни в документации вообще, ни в примерах, только какие-то обрывки в документации peripheral library. Но с другой стороны: для переназначения входов толку от fk0(253 знак., 06.12.2010 17:57)
- Не надо ля-ля - ошибке там взяться неоткуда, т.к. параметры передаются в виде ИМЕН периферийного сигнала и RP/RPI-ноги, на которую этот сигнал требуется вывести - PPSOutput(U2TX,RP5), PPSInput(U1RX,RPI34), или даже в обратном порядке, если так MBedder(62 знак., 06.12.2010 18:05)
- U2TX в голове удержать легко. А RPI34 (33, 35...)-- нет. И писать xxx = 35 или xxx = MY_LONG_AND_INTELLIGIBLE_NAME_35 -- разницы нет. - fk0(06.12.2010 18:13)
- И опять не надо ля-ля - RPI35, как и все остальные RPx, написан на картинке цоколевки чипа в ДШ, поэтому ничего лишнего держать в голове не придется - MBedder(06.12.2010 18:16)
- Может я сошёл с ума, но у меня в голове прекрасно размещаются словари в тысячи слов из разных областей, но совершенно не удерживаются 2-3-значные числа и другие шифровки и телефонные номера (только после длительного повторения). Донести fk0(117 знак., 06.12.2010 18:25)
- Ты уже вконец
заебалзаговорился. Код-шифровка - это как раз твои RPOR12bits.RP25R = 7, а символьное имя - это PPSOutput(SDO1,RP25) - MBedder(06.12.2010 18:31) - пурга - Vit(06.12.2010 18:27)
- Ты уже вконец
- и на символе камня в схеме - Vit(06.12.2010 18:19)
- Ну это уже перебор - настоящие (= нефинские) программеры в схемы не лазят :)) - MBedder(06.12.2010 18:33)
- Может я сошёл с ума, но у меня в голове прекрасно размещаются словари в тысячи слов из разных областей, но совершенно не удерживаются 2-3-значные числа и другие шифровки и телефонные номера (только после длительного повторения). Донести fk0(117 знак., 06.12.2010 18:25)
- И опять не надо ля-ля - RPI35, как и все остальные RPx, написан на картинке цоколевки чипа в ДШ, поэтому ничего лишнего держать в голове не придется - MBedder(06.12.2010 18:16)
- U2TX в голове удержать легко. А RPI34 (33, 35...)-- нет. И писать xxx = 35 или xxx = MY_LONG_AND_INTELLIGIBLE_NAME_35 -- разницы нет. - fk0(06.12.2010 18:13)
- Но если ещё поразмышлять: magic numbers в коде в самом нижнем слое обслуживающем железо -- это, наверное, не страшно. Там их и без того хватает. PPS.h в общем по-моему полезен, но не более того. __builtin_write_xxx более существенны: при fk0(145 знак., 06.12.2010 18:01)
- "Маладэц, дэушк - звук сумэл падабрать. А вот запах - нет"(с) :)) - MBedder(06.12.2010 18:07)
- Не надо ля-ля - ошибке там взяться неоткуда, т.к. параметры передаются в виде ИМЕН периферийного сигнала и RP/RPI-ноги, на которую этот сигнал требуется вывести - PPSOutput(U2TX,RP5), PPSInput(U1RX,RPI34), или даже в обратном порядке, если так MBedder(62 знак., 06.12.2010 18:05)
- Прочитал внимательно. Я таки действительно не прав и PPS.h полезная штука. Но его нет ни в документации вообще, ни в примерах, только какие-то обрывки в документации peripheral library. Но с другой стороны: для переназначения входов толку от fk0(253 знак., 06.12.2010 17:57)
- НИКАКИХ "platform peripheral library" на дух не требуется, PPS.h содержит все, что нужно. Я сначала написал свой PPS.inc для ASM30 и запостил на микрочиповский англофорум, а разработчики С30 потом сделали из моего PPS.inc свой PPS.h - MBedder(06.12.2010 17:52)
- Ещё раз, для тормозов. Использование PPS-xxx -- подразумевает использование platform peripheral library, которая МОЖЕТ НЕ ИСПОЛЬЗОВАТЬСЯ. Да -- индусский говнокод. Лишняя сущность. Замечание же на счёт использования __builtin_write_OSCCONL и т.п. fk0(50 знак., 06.12.2010 17:46)
- Таки говнокод -- все builtins описаны в доке на C30. А вот PPS.h тут очень даже непричём. Надо исправлять... - fk0(06.12.2010 17:37)
- Подключаешь PPS.h и пишешь PPSInput(fn,pin), PPSOutput(fn,pin) и PPSUnLock/PPSLock вместо гавнокодища. RTFM! - MBedder(06.12.2010 17:47)
- То есть, PPSUnlock() вместо твоей квазиассемблерной портянки, и PPSOutput(U2TX,RP5) вместо твоего "RPOR2bits.RP5R = 5" - это гавнокод, а в hlpMPLABC30.chm.Built-In Function List тебя забанили? Спасибо, посмеялсо от души :)) - MBedder(06.12.2010 17:44)
- Не всё так просто. Про эти builtin_write... нигде вообще не говориться. Хотя конечно *.h из комплекта компилятора разглядывать, безусловно, полезно. Кроме того, упоминание о pps.h есть в family peripheral library что подразумевает её наличие и fk0(296 знак., 06.12.2010 17:28)