adnega

Не понятен спектр потребления, не понятны вопросы сертификации и т.п. Описанное вами решение не соответствует требованиям CAN, из-за выпрямителей оно не эффективно при 20А и вы теряете общий провод. 24В и 20А! - какая траншея? Если бы ТС подробнее описал сложности с новой проводкой, то было бы с чем сравнивать.

У профессионалов, как правило, нет проблем с дополнительной парой проводов при решении задачи оптимальным способом. Если уже есть проводная линия, не понятно, что мешает дополнить ее еще парой проводов? Сколько будет стоить добавить эти провода? На мой взгляд, на порядок дешевле, чем придумывать способ обхода. При этом по надежности с выделенной линией вряд ли что сравнится.

И где же в стандарте говориться про физический уровень? Я прочитал, что т.е. в стандарте физический уровень не описывается. Для работы CAN нужно в среде создать два состояния: доминантное и рецессивное, каждое со своими свойствами. Как это сделать - зависит от задачи. Конкретно для этой задачи вряд ли есть стандартное решение или простое решение. Проще передавать по какой-нить powerline-технологии и сделать CAN-шлюзы под данную технологию - тут я с novikovfb согласен. Делать свое powerline-решение под требования CAN я бы не советовал (уж слишком нагрузка у вас непростая).

ТС тоже не робкого десятка, раз хочет менять лампочки под фазным напряжением.

Дык, ремонт в квартире периодически делать нужно. Тут далеко не капиталка, а перед поклейкой обоев пробросить чутка проводов в стенах, не так дорого и не так сложно. Зато в будущем - никаких проблем. Менять силовую проводку (читай knx в щиток) я большой противник. Нужно чтобы в одно посадочное место устанавливались хоть умный, хоть обычный выключатель. Если хочется дешево, то есть много лампочек с esp8266 внутри, и всякие там Xiaomi. Перепроверьте, есть мнение (nooLite-F) что это уже не так.

Лучше всего отдельный кабель до выключателя: по нему подавать питание 24В и интерфейс, лучше CAN :)) Один раз напрячься, зато потом никаких проблем.

Вы точно уверены что это данные из сектора? Пробоволи считать их повторно или на ПК? После команды чтения следует ответ на команду, а затем нужно ждать признака данных (очень долго). После признака данных идут данные и CRC. Ни разу, ни при каких обстоятельствах не видел, чтобы изначально рабочая карта начала выдавать 0xFF вместо данных. Я много лет собираю таких "уродцев" в свою коллекцию, но ничего подобного не встречал. Есть две "левые" карточки, купленные в отделе носовых платков, дык, одна вообще не читается, а на второй работают только первые 128МБ из 2ГБ, но такие карты не для серьезного рассмотрения. Мне кажется я уже тут выкладывал результаты исследований карт при чтении потока в реальном времени, но не могу найти где именно. Чтение велось блоками по 256Б и по 8КБ (по 10 000 блоков в каждом эксперименте). Все данные считываются верно, но с различной задержкой. Иногда задержка настолько велика, что поток реального времени невозможен (в звуке появляются щелчки). Такие события имеют желтый фон. SDIO_stat_2.pdf

Вы в своей прошивке должны дисплей проинициализировать, а затем выводить в него данные/картинку. Что-то типа этого con_str("disp_code = "); con_word(LCD_ReadReg(0x0000)); con_str("\n\r"); con_start(); if(LCD_ReadReg(0x0000) == 0x8989) { LCD_WriteReg(0x0000,0x0001); delay_ms(50); /* Enable LCD Oscillator */ LCD_WriteReg(0x0003,0xA8A4); delay_ms(50); LCD_WriteReg(0x000C,0x0000); delay_ms(50); LCD_WriteReg(0x000D,0x080C); delay_ms(50); LCD_WriteReg(0x000E,0x2B00); delay_ms(50); LCD_WriteReg(0x001E,0x00B0); delay_ms(50); LCD_WriteReg(0x0001,0x2B3F); delay_ms(50); /* 320*240 0x2B3F */ LCD_WriteReg(0x0002,0x0600); delay_ms(50); LCD_WriteReg(0x0010,0x0000); delay_ms(50); LCD_WriteReg(0x0011,0x6078); delay_ms(50); //0x6070 LCD_WriteReg(0x0005,0x0000); delay_ms(50); LCD_WriteReg(0x0006,0x0000); delay_ms(50); LCD_WriteReg(0x0016,0xEF1C); delay_ms(50); LCD_WriteReg(0x0017,0x0003); delay_ms(50); LCD_WriteReg(0x0007,0x0133); delay_ms(50); LCD_WriteReg(0x000B,0x0000); delay_ms(50); LCD_WriteReg(0x000F,0x0000); delay_ms(50); LCD_WriteReg(0x0041,0x0000); delay_ms(50); LCD_WriteReg(0x0042,0x0000); delay_ms(50); LCD_WriteReg(0x0048,0x0000); delay_ms(50); LCD_WriteReg(0x0049,0x013F); delay_ms(50); LCD_WriteReg(0x004A,0x0000); delay_ms(50); LCD_WriteReg(0x004B,0x0000); delay_ms(50); LCD_WriteReg(0x0044,0xEF00); delay_ms(50); LCD_WriteReg(0x0045,0x0000); delay_ms(50); LCD_WriteReg(0x0046,0x013F); delay_ms(50); LCD_WriteReg(0x0030,0x0707); delay_ms(50); LCD_WriteReg(0x0031,0x0204); delay_ms(50); LCD_WriteReg(0x0032,0x0204); delay_ms(50); LCD_WriteReg(0x0033,0x0502); delay_ms(50); LCD_WriteReg(0x0034,0x0507); delay_ms(50); LCD_WriteReg(0x0035,0x0204); delay_ms(50); LCD_WriteReg(0x0036,0x0204); delay_ms(50); LCD_WriteReg(0x0037,0x0502); delay_ms(50); LCD_WriteReg(0x003A,0x0302); delay_ms(50); LCD_WriteReg(0x003B,0x0302); delay_ms(50); LCD_WriteReg(0x0023,0x0000); delay_ms(50); LCD_WriteReg(0x0024,0x0000); delay_ms(50); LCD_WriteReg(0x0025,0x8000); delay_ms(50); LCD_WriteReg(0x004f,0); LCD_WriteReg(0x004e,0); } LCD_WriteReg(0x004e, 0); LCD_WriteReg(0x004f, 0); LCD_WriteIndex(0x0022); for( index = 0; index < 320 * 240; index++ ) { LCD_WriteData(index); } Прицепил. 3.2inch_320x240_Touch_LCD_A.7z

Что вы понимаете под "пропадают данные"? Иногда карта может задумываться надолго, но рано или поздно ответит. Если ответ не нужен, то посылайте CMD12 - это прервет операцию чтения. Переходить из "tran" в "stby" и обратно я бы не советовал. У меня карточки годами находятся в "tran" и ничего. Чтение, правда, эпизодическое; записи вовсе нет. Заметил, что со временем карты могут начинать "задумываться" даже при эксплуатации только в режиме чтения. Задержки могут быть и по 600мс.

Точных данных нет. У меня сделано костыльно: в функции записи смотрю - если перед этим было чтение, то тупо делаю 500 раз SDIO_Delay(). Но уму в такой ситуации нужно запускать задержку в фоне, возвращать управление из функции, при сработке задержки делать запись и в конце рапортовать через callback-функцию. Но потом забросил отладку записи и не стал ничего переделывать. void SDIO_Delay(void) { volatile int i; for(i = 0; i < 0x20; i++); }

Ага. Каждая процедура чтения и записи сектора начинается с CMD13_SEND_STATUS.

Карта, с которой работаешь должна быть в режиме "tran". Из этого режима ее можно читать и писать. Про произвольный переход по таймауту в режим "stby" ничего не знаю - Card State Transition Table говорит, что из "tran" в "stby" можно попасть только через CMD7.

На старой работе, где руководство запрещало "собственные велосипеды", в одном из проектов я принципиально решил использовать StdLib и другие готовые решения (FreeRTOS, uIP). Докладываю: это был первый и последний раз. По времени разработки, изучения, решения проблем - сделать свой велосипед было бы гораздо легче и лучше. Мне повезло, что у меня уже есть богатая библиотека решений, но для новичков со стандартными средствами запуск будет быстрее, чем писать все самому. При этом помним большими буквами, что применение библиотек не освобождает от необходимости чтения DS, RM, AN и т.п. Иногда приходится изучать StdLib|HAL, чтобы понять как производитель рекомендует работать.

В копилку статистики: я не использую.

Как победить - не знаю. Я сделал костыль: в функции "записать сектор" смотрю, если перед этим была операция чтения, то выжидаю некую паузу. Выше слегка наврал: проблема происходит после запись-чтение-запись. Если сделать запись-чтение-пауза-запись, то все ок. int SDIO_Read(DWORD sector, BYTE *buf, const int buf_size, const void *p, tSDIO_CALLBACK *cb) { ... sdio_last_rd = 1; ... } int SDIO_Write(DWORD sector, BYTE *buf, const int buf_size, const void *p, tSDIO_CALLBACK *cb) { ... if(sdio_last_rd) { sdio_last_rd = 0; for(i = 0; i < 500; i++) SDIO_Delay(); } ... }

Нет - запись можно вести потоком без каких-либо пауз с максимально возможным темпом. Как только в статусе появляется ready - сразу же начинаю новую запись, и нет проблем. Но при использовании FAT нужно получать очередной свободный кластер, для этого придется считать с карты. Так вот такое считывание после предварительной записи отправляет карты в вечный busy. Скорее всего, это момент считывания таблицы FAT для поиска свободного кластера.

Не знаю. У меня такая же проблема, но на SDIO. Отправить карту в нокаут просто: записываем сектор, затем читаем какой-то сектор. Если перед чтением поставить задержку, то все ок. Если снизить частоту интерфейса, то все ок. Что только не делал со статусом карты и битами SDIO - результат нулевой. Писать на карту можно сколь-угодно долго - никаких проблем. Но последователь чтение-запись-чтение без пауз - получаем из любой карты busy-труп. В Спецификации SD и в Интернете - пустота по этому вопросу.

Вам же для отладки нужно. Киньте проводком. Когда все отладите - отключите debug-вывод портянок и уберете провод.

Почитать Инструкцию

Ровно так же никто из профи не сможет ничего придумать, чтобы по вашему желанию "2х2=5". Грамотное решение - попросить вторую сторону не присылать данные, к обработке которых вы не готовы. TCP позволяет это делать, причем очень гибко и грамотно. Если вы не хотите разобраться как это сделать, то да - увеличивайте буфер, но не надо в код вставлять задержки, даже если сейчас это работает. И точно не нужно хамить людям, которые считают такой подход дурным тоном программирования.

Перечитал пост #29. Кроме все остальное по делу и справедливо. Хотя, и процитированное предположение имеет право на жизнь.

Что ж остается лишь пожелать вам удачи.

Дык, вы же их обрабатываете без проблем. Просто вы хотите параллельно зачем-то сгенерить гораздо большую по объему отладочную информацию и успеть ее выплюнуть. Старайтесь в отладку выкидывать только ошибки и результат обработчика HardFault. Что вам мешает подключиться к uart от модема и записывать весь обмен, а затем его обрабатывать (в том числе и с помощью спецутилит)? Дык, попытайтесь писать суть, а не "много букв". Не всегда, чем длиннее текст, тем там больше информации. Как называется ваша тема? И при чем тут printf, когда причина у вас в совершенно другом месте? Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать. У меня позиция, что отвечая на форуме - помогаешь не ТС, а всем, т.к. кто-то может столкнуться с аналогичной проблемой в будущем.

Еще в посте #9 уважаемый jcxz посоветовал проверить консерваторию. Я полностью поддерживаю его совет, а от себя посоветовал бы не переходить на необоснованное хамство в отношении людей. Подход, который вы используете не годится для решения коммерческих задач, а поскольку у вас есть руководство, то осмелюсь предположить, что ваша задачка не поделка выходного для. Если вы для себя или для начальства хотите получить подтверждение "эта задача не может быть решена", то вы ошибаетесь - задача элементарная, но вы решаете ее не с того края, отсюда и сложности. Попробуйте успокоиться и понять, что вам советуют. Я сам в том месяце работал с ESP8266 и МК уровня STM32F0. От сервера приходят UDP-пакеты и я на каждый должен ответить. Но пока я отвечаю на предыдущий, ко мне может прилетесь еще несколько новых. Памяти на всех нет в принципе. Поэтому, получив и обработав пакет, я помечаю, что нужно отправить ответ (один флаг). Получив другие пакеты - обрабатываю их и устанавливаю соответствующие флаги. Когда есть возможность отправить ответ, смотрю первый попавшийся флаг и отправляю соответствующий ответ сбросив флаг. Расход памяти минимальный, все пакеты обрабатываются, никто не теряется, никаких задержек нет. Предыдущий код требовал, чтобы сервер не отправлял UDP-пакет, не получив ответ на предыдущий, т.к. буфера перетерались. Все решает грамотная архитектура, а необходимость задержек, зависимость от размера буферов и т.п. являются свидетельством неграмотной архитектуры или ее отсутствия. Кто-то называет это консерваторией. Подход "через сутки разберусь, а дальше меня не волнует" тоже не признак профессионализма. Завтра начальство захочет новую фичу, и вы с большой вероятностью не сможете ее добавить, т.к. ваш подход обладает плохой масштабируемостью. Пару раз по банальным фичам ответите начальству отказом - на вашем месте будет работать другой программист. Оно вам надо?

Вы можете стандартными средствами TCP притормозить выдачу данных удаленной стороной, чтобы она вам буфер не перезаписывала.