amost

Тиристор ТС122-25-5, 1989 и 1992 годов выпуска. Новые, в наличии около 400шт. Цена: 1,5usd/шт. -- от 50 шт. 1,3usd/шт. -- от 100шт. 1 usd/шт. -- все разом (около 400шт.) Отправлю по Украине Новой Почтой. РФ -- ваши предложения по отправке вопросы в ЛС или на amost точка ua собака gmail точка com

на буржуйских форумах в таких случаях обычно создают темы с громкими названиями типа "STP16CP05 (в моем случае) is driving me crazy" и это именно то, что происходит сейчас со мной. отсутствие специальных знаний и опыта сказывается наверное. имею драйвер светодиодов STP16CP05 подключенный AVR микроконтроллеру. схема включения стандартная SDI, CLK и LE заведены на пины порта А микроконтроллера, сконфигурированные как выхода, OE подключен к 0. Побитово выдвигаю два байта на линию SDI, генерирую CLK, по завершению вывода двух байт генерирую LE. все правильно, ведь так? инфа поступает в драйверы и светодиоды горят. и все классно до попытки измерить напряжение на шине питания -- при касании щупом (пинцетом, кусачками, отверткой) происходит чудо и вся загруженная мной комбинация сдвигается на 1...n разрядов. что делать -- не знаю. гуглил, пробовал все известные мне способы -- ничего не помогает. что делал: 1. поставил электролит 47мФ на плате с контроллером (микроконтроллер и драйверы светодиодов размещаются на разных платах соединенных штыревыми разъемами и шлейфом) -- начало загружать правильную комбинацию при подаче питания 2. поставил кондеры по 0,1мФ возле корпусов STP16CP05 -- не помогает 3. поставил кондеры по 0,1мФ в точке подачи питания на плату с драйверами -- не помогло 4. поставил электролит в точке подачи питания на плату с драйверами -- не помогло 5. завел отдельно питание на плату с драйверами (раньше было: БП--плата_МК--плата_с_драйверами) -- изменений нет 6. поменял драйвер -- результат тот же 7. пробовал подтягивать линии LE и CLK к нулевому потенциалу резисторами 10к (?) -- без изменений Более того, появляется такое ощущение, что при наличии кер. конденсатора 0.1мФ возле драйвера делает схему еще более чувствительной. Может след. поможет больше прояснить ситуацию: МК установлен на самодельной макетке, вырезанной резаком, с широкими шинами питания (около 8мм), тактовая 8МГц, питание 5В, МК ATmega162. С помощью этой же платы я около года назад успешно прошел через весь цикл разработки прошивки для бегущей строки (использовались похожие сдвиговые регистры HC595). Для драйверов и светодиодов сделаны отдельные платы, поключаемые к микроконтроллерной плате шлейфом с BLS разъемом и штырями. Длинна шлейфа около 20см. Выход SDO STP16 висит в воздухе. Принимаются любые советы, особенно ценные с теоретическим бэкграундом или ссылкой. Вечерком, после работы все протестим :)

видимо глюк был, теперь пропускает.

впервые попробовал возможности C по объявлению указателя на функцию и тут -- на тебе. определяю функцию void fu(void) { } указатель на функцию void (*pfu) (void) = fu; при попытке сохранить PN gets crashed. Что интересно, если функция с параметрами, то все нормально. сталкивался кто-либо с подобным? может я что-то не правильно описываю?

avr-gcc раньше объявлял одну/несколько байтовых переменных, дефайнами называл их биты. обращаясь к биту, использовал имя переменной, и соответствующее имя бита. очевидно, вариант неудобен при наличии большого кол-ва битовых переменных, нужно же помнить какой бит в каком байте. может наверняка есть какой-то более удобный метод. макрос, определяющий имя байта с флагами по имени бита, что-ли.

спасибо. сделал так : #define INPUT1 PORTD,2,0 #define INPUT2 PORTD,3,1 #define INPUT3 PORTD,4,2 #define INPUT4 PORTD,5,3 #define _M_SCAN_INPUT(port, pin, pos, loc) \ loc |= ( ((port >> pin) & 0x01) << pos) #define M_SCAN_INPUT(INPUT, loc) _M_SCAN_INPUT(INPUT, loc) вызываю M_SCAN_INPUT(INPUT1, pin_state_cur); M_SCAN_INPUT(INPUT2, pin_state_cur); M_SCAN_INPUT(INPUT3, pin_state_cur); M_SCAN_INPUT(INPUT4, pin_state_cur);

что-то запутался я со вложенными макросами. например есть макрос #define M_SCAN_INPUT(port, pin, pos, loc) \ loc |= ( ((port >> pin) & 0x01) << pos) теперь хочу значения port, pin, pos спрятать еще в один дефайн : #define INPUT1 PORTD,2,0 что-бы в конечном итоге вызвать макрос таким образом : M_SCAN_INPUT(INPUT1, pin_state_cur); как по мне то должно работать. выдает эррор несоответствия количества аргументов при вызове макроса.

да нет, я не надеюсь на авось. Вы красиво критикуете надежность моей системы -- хорошо. я не мудренный опытом разработчик, я просто любитель, который делает для себя полные глюков "поделки". с этой позиции я и читал ДШ, где в упор не увидел и слова о необходимости синхронизации каждого байта по линии SS и сброса счетчика бит SPI. поймите, вопрос о выборе типа последовательной связи не стоит, это можно обойти. входной индекс обнуляется. об очереди я знаю. я привел часть кода, которую оставил после появления глюков. буфер не обнуляю только потому, что во время отладки передаю заранее известное кол-во символов, меньше длины приемного буфера слейва. этот вариант я тоже рассматривал. в ДШ написано, что SPIF сбрасывается автоматически при первом чтении SPSR, т.е. он сбрасывается еще при выполнении поллинга. хотя, наверное, стоит попробовать сбрасывать самому. спасибо всем за ответы. тема и правда бестолковая. можна закрывать.

код стандартный, вытянутый из ДШ void USART_transmit_char(char c) { while ( !( UCSRA & (1 << UDRE)) ) ; UDR = c; } ... int main(void) { counter = 0; for(;;) { while (counter < gBuf_ind_in) USART_transmit_char(usi_in_buf[counter++]); if (counter == IN_BUF_LGTH) counter = 0; } } поставил. картина та же. нет, SS-ом не дергаю. если честно, смысла в этом я не видел. насколько я понял из ДШ, передача каждого байта пакета не сопровождается дерганьем линии SS. SS сбрасывается вначале пакета данных и устанавливается снова по окончании передачи того-же пакета.

а откуда ему взяться, этому лишнему клоку? там же просто все должно быть -- байт отправил, дождался окончания передачи, отправил следующий.

здравствуйте. пришлось связать два камня по SPI. передача данных в одну сторону Mega8 (master) --> tiny2313. инициализацию мастера и слейва сделал по ДШ. mega8: void SPIinit(void) { DDRB |= (1<<PIN_SPI_MOSI) | (1<<PIN_SPI_SCK) | (1<<PIN_SPI_SS); SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR0); } t2313: void USIinit(void) { DDRB = (1<<USI_PIN_DO); PORTB |= (1<<USI_PIN_DI) | (1<<USI_PIN_SCK); USICR = (1<<USIOIE) | (1<<USIWM0) | (1<<USICS1); } отправляю байт void SPI_send_byte(char data) { SPDR = data; while( !(SPSR & (1<<SPIF)) ) ; } принимаю на тиньке ISR (USI_OVERFLOW_vect) { USISR |= (1<<USIOIF); usi_in_buf[gBuf_ind_in] = USIDR; gBuf_ind_in++; } после получения каждого нового символа передаю его слэйвом по UART. так вот, один байт таким способом я принять могу, но если посылается несколько байт -- получается каша. правильно принимается только последний символ из всего потока. ставлю после передачи каждого символа задержку -- SPI_send_byte('b'); _delay_loop_1(48); SPI_send_byte('a'); _delay_loop_1(48); SPI_send_byte('d'); _delay_loop_1(48); SPI_send_byte(' '); -- слэйв принимает нормально. да, если нужно то mega запущена на 16МГц, tiny2313 -- 8МГц. клок на SPI на мастере делится на 16. если делить на 128 то нормально принимает при значении задержки между символами приблизительно 3мкс (начинает принимать нормально при _delay_loop_1(15)). изначально, было две версии: 1. передача очередного байта начинается до завершения передачи предыдущего. думаю этот вариант исключается поллингом флага SPIF, и флага WCOL. (?) 2. тинька не успевает обрабатывать поток данных. этот вариант тоже вроде как исключил -- понизил частоту клока, сократил до минимума обработчик прерывания. пробовал даже после 4-5 принятых в ОЗУ символов запрещать прерывания на слэйве и спокойненько выдавать буфер в UART. теоретически, могу оставить задержки между символами. но хочется же знать в чем соль. хотя бы на чьей стороне? мастер/слэйв? да, мой первый проэкт именно на C. могу чего-то не знать.

спасибо. скорее всего буду пробовать рисовать. хотя немного дороговато, но других выходов нет. в Украине я найти подобного не смог. в Чип-Дип"е действительно есть то, что нужно, примерно за 3-4 дол. но к нам, как я понял, не отправляют, жаль.

Здравствуйте. собственно, не совсем вопрос, скорее просьба. ищу я макетку, под SMDшный LQFP корпус. пока безуспешно. с недавних пор уже начал подумывать не нарисовать ли что-либо подобное, и заказать изготовление на какой-л. фирме. так, наверное, было бы быстрее, проще и надежнее. могу разводить платы в P-CADе, но только как говориться "для себя", для последующего изготовления при помощи ЛУТ. т.е. не знаю какими свойствами должен обладать файл, с которого будет выполняться изготовление ПП (какие слои использовать, отверстия, как обозначить область вскрытия лаком, нужно ли подстраиваться под конкретное оборудование на котором будет изготавливаться ПП и т.д). Поэтому, вижу для себя два варианта решения проблемы: 1. искать уже нарисованную макетку, уже подогнанную для изготовления (может кто-то сталкивался и имеет подобные наработки). 2. ткнуть меня носом в какой-то ликбез, где подробно описан процесс подготовки к изготовлению ПП. да, вот примерный рисунок того что мне нужно:

да в том то и дело, что решен он не особо изворотливым путем. просто перекинул линии прерывания, сейчас ПОП вызывается по старт-биту. правда приходится весь байт одним махом принимать, но в моем случае это приемлимо

похожая, спасибо вопрос решен