Понадобилось прогонять через систему 100Мб, видимо UDP пакетами.
От контроллера нужно лишь наличие мощи, чтоб переваривать 100Мб и отправлять в некий другой интерфейс.
Чем иp ARM минимально можно обойтись?
Работал тока с младшими stm32 и аналогичными LPC, они явно не тянут.
Полная версия этой страницы: 100Mb Ethernet
Что это по вашему не тянут? и 100Мб это скорость или объём? Скорость не та? Потеря пакетов? Младший это 107 как я понимаю. И какой Phy используете?
Цитата(Aner @ Apr 21 2012, 12:50) 
Что это по вашему не тянут? и 100Мб это скорость или объём? Скорость не та? Потеря пакетов? Младший это 107 как я понимаю. И какой Phy используете?
100Мб - это поток(вероятно UDP пакеты), реально будет меньше ~30-50Мбод, но запас это хорошо. Суть девайса парсить этот поток и выплевывать информацию в 16 последовательных интерфейсов ~3-5Мбод.
По ощущениям stm32 f107 не успеет. Может стоит смотреть в сторону Cortex M4?
Интересует ваш опыт работы с загруженным Ethernet 100.
Непонятно зачем конкретизировать физ. уровень, я пока выбираю контроллер.
Цитата(pil @ Apr 21 2012, 16:57)
16 последовательных интерфейсов ~3-5Мбод.
Это где вы их наберете? Столько-то. Как то вам надо бы поближе к реальности.
Цитата(pil @ Apr 21 2012, 15:57)
По ощущениям stm32 f107 не успеет. Может стоит смотреть в сторону Cortex M4?
Интересует ваш опыт работы с загруженным Ethernet 100.
Интересует ваш опыт работы с загруженным Ethernet 100.
Подобный поток (80+Мбит/с) вполне нормально перелопачивался даже на SAM7X. А вот 16 последовательных интерфейсов придется окучивать внешней логикой.
... отправлять в некий другой интерфейс. Это как? Как только какая мало-мальская обработка (5-8 команд) потока, то приплыли.
Не тот проц для этого выбрали. Cortex_ы любые, не причем. Сразу FPGA выбирайте.
Не тот проц для этого выбрали. Cortex_ы любые, не причем. Сразу FPGA выбирайте.
Спасибо всем за ответы.
Варианты значит такие:
1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов
2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD
А какого уровня FPGA смотреть/пробовать? (уже не та ветка форума похоже)
Варианты значит такие:
1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов
2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD
А какого уровня FPGA смотреть/пробовать? (уже не та ветка форума похоже)
Цитата(pil @ Apr 21 2012, 23:30)
Варианты значит такие:
На самом деле надо много считать.
1. Ethernet - как будет выполнен? Соединение точка-точка? Тогда реально можно получить суммарно 80-90Мбит.
Какого размера будут передаваемые блоки данных? Ethernet-фрейм в стандарте по минимуму содержит 26-28 байт
служебных. Если у вас блоки данных будут по 2 байта, то требуемые 50Мбит вы не получите. Вы упомянули UTP.
Там служебной информации еще больше. Если же не точка-точка, а в локалке еще есть кто-то живой, то скорость
передачи становится вообще не подлежащей расчету.
2. Следующее узкое место - передача данных из буферов Ethernet на последовательный интерфейс. Ладно бы один.
Тогда DMA и все в порядке. У вас 16. Значит что-то внешнее. Но во что-то внешнее, в ту же FPGA, тоже надо передать,
да еще и засинхронизировать. Как это сделать хз. Может быть использовать интерфейс внешней памяти? Тогда да,
контроллер с Ethernet и FPGA.
... 1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов
3-й цыклон, 2 помедленнее, но может вас и устроит.
2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD
... выбор зависит от протоколов ваших интерфейсов.
3-й цыклон, 2 помедленнее, но может вас и устроит.
2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD
... выбор зависит от протоколов ваших интерфейсов.
Цитата(alag57 @ Apr 21 2012, 18:12)
Это где вы их наберете? Столько-то. Как то вам надо бы поближе к реальности.
Не-не, Сашка! Тут можно хитро-вывернуться, если собрать четыре одинаковых независимых девайса и соединить их параллельно в Ethernet.
Каждый из девайсов имеет один ethernet-вход и четыре USART-выхода. Девайсы имеют один и тот же IP адрес и принимают UDP-поток на одинаковый номер порта (например 12345). Приняв UDP-пакет каждый девайс выделяет из него свою порцию данных для _своих_ четырех последовательных портов. Собственно, здесь эти четыре девайса и будут различаться.
Цитата(zhevak @ Apr 22 2012, 23:45)
Тут можно хитро-вывернуться, если собрать четыре одинаковых независимых девайса и соединить их параллельно в Ethernet...
И кто им раздаст один и тот же поток? Разве что налепить за одним PHY четыре процессора, но этот вариант явно хуже, чем одна FPGA или один процессор + CPLD/FPGA.
Цитата(zhevak @ Apr 23 2012, 00:45)
Не-не, Сашка! Тут можно хитро-вывернуться
Да, можно и так. Особенно если FPGA для тебя (точнее для меня
) темный лес. Но блин затратно наверное. Но исходить все равно надо из начальных условий, о которых я и
написал. Если в сети будет еще кто-то живой - забудь о 100 Мбитах, и даже о 50. Если у
тебя пакеты в которых данных по 2 байта - забудь тоже. Да и ТС не говорит, что за
последовательные каналы ему нужны. Может SPI. Столько тоже нет. Хотя может у каких-нибудь
чипов и есть 4 SPI, не в курсе, не пользовал.
Цитата(aaarrr @ Apr 23 2012, 01:52)
И кто им раздаст один и тот же поток? Разве что налепить за одним PHY четыре процессора, но этот вариант явно хуже, чем одна FPGA или один процессор + CPLD/FPGA.
Возможно мы говорим о разном. Я имею ввиду -- UDP-поток, ну или свой какой-нибудь "доморощенный" (не стандартный). Источнику достаточно "вещать" в сеть, а заботиться о том, принимается ли поток -- не обязательно. Так сказать симплекс-передача без обратной связи. Его задача -- выплюнуть в сеть информацию, а уж поймали ли ее, и сколько девайсов поймало -- не его дело.
"С моей стороны проблем нет. Пули из ствола ушли. Проблемы на вашей стороне." (с)исадмин на службе.
На месте приема цепляем параллельно четыре приемника, которые должны иметь одинаковые параметры. Приемники принимают _ВСЕ_ пакеты, которые приходят к ним на вход. Сортировкой пакетов типа наш-не наш и последующим их дропанием занимается проц.
Да, и самое главное, наверно тут не следует поднимать стандартные библиотеки для работы с сетевыми протоколами. Я бы написал свою реализацию. Собственно, я как-то давно так и делал, еще на ENC28J60 + MEGA8/16. Особо сложного тут ничего нет. Сложности только в маршрутизации этого нестандартного потока. Если потребуется маршрутизация, то можно же на одном из четырех девайсов поднять частично ICMP, ARP-протоколы. Пусть один за четырех отдувается. Не проблема.
Я не знаю. Я бы делал так, как описываю. Я не знаком с технологией FPGA, поэтому мне проще поставить четыре копеечных STM32 и не затягивать разработку. Мое рабочее время стоит на много дороже. Устройство вряд-ли будет производится серийно. Поэтому разница в 1000 рублей (четыре МК, вместо одного, округленно) -- никак не скажется на конечной стоимости изделия, цена которого вряд-ли будет ниже 10-20 труб.
Вообще, задача не тривиальная. Думать надо. Может быть будет проще сразу на передающей стороне разделить каналы.
Извините за оффтоп.
Цитата(alag57 @ Apr 23 2012, 10:58)
Если в сети будет еще кто-то живой - забудь о 100 Мбитах, и даже о 50. Если у
тебя пакеты в которых данных по 2 байта - забудь тоже.
тебя пакеты в которых данных по 2 байта - забудь тоже.
Ага. Все так.
Да уж... поколение молодых разработчиков. Привыкли, понимаешь, мыслить на уровне кубиков библиотечных функций и программировать мышкой. Надеются на то, что мощный проц всё вытащит. Глубоко не копают. Зачем? Лего-разработчики, мать их! (Это я не о ТС. Это я по старчески, по доброму. В воздух.)
Цитата(pil @ Apr 22 2012, 01:30)
Варианты значит такие:
1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов
2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD
1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов
2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD
а какой именно последовательный интерфейс, если только в одну сторону надо, то можно попробовать из 16-ти разрядного параллельного порта (как у блэкфинов, например) сделать 16 последовательных интерфейсов типа SPI.
ну или из внешней шины памяти,
а если без запаса, ~40мБит езернета устроит, то можно вообще сделать на ADSP-BF592 + KSZ8851SNL.
Цитата(zhevak @ Apr 23 2012, 09:19)
Возможно мы говорим о разном. Я имею ввиду -- UDP-поток, ну или свой какой-нибудь "доморощенный" (не стандартный). Источнику достаточно "вещать" в сеть, а заботиться о том, принимается ли поток -- не обязательно. Так сказать симплекс-передача без обратной связи. Его задача -- выплюнуть в сеть информацию, а уж поймали ли ее, и сколько девайсов поймало -- не его дело.
Только источнику придется вещать в broadcast или multicast режиме, иначе до всех не дойдет.
QUOTE
а какой именно последовательный интерфейс, если только в одну сторону надо, то можно попробовать из 16-ти разрядного параллельного порта (как у блэкфинов, например) сделать 16 последовательных интерфейсов типа SPI.
Да и аля-UART можно. На любом ARM'е с DMA, только поставить защелку придется. Какой-нибудь LPC17xx вполне подойдет. Да и STM32, видимо, тоже.
Принимаете из сети пакет, проворачиваете биты (можно и на большом брате проворачивать) и укладываете в буфер, а DMA по таймеру сам отправит в параллельный порт. Выход этого же таймера надо использовать как CLK, если это SPI, либо как тактовый сигнал защелок, если это UART - чтобы не было джиттера.
Однако, так хорошо получится только в том случае, если надо организовать исключительно вывод. При необходимости ввода данных можно только SPI организовать без геморроя.
Цитата(aaarrr @ Apr 23 2012, 14:25)
Только источнику придется вещать в broadcast или multicast режиме, иначе до всех не дойдет.
Я бы сделал все-таки нестандартный протокол. Оставил бы от Ethernet только физику. Сделал бы соединение
точка-точка, без локалки. Тогда можно гарантировать требуемые 50Мбит. Может быть действительно что-нибудь
из DSP? Или старшие ARM? Как у них ногами шевелить можно не в курсе.
Цитата
из 16-ти разрядного параллельного
Не забываем только про синхронизацию. Успеем?
Цитата(alag57 @ Apr 23 2012, 17:21)
Не забываем только про синхронизацию. Успеем?
ну если внешняя шина или параллельный порт (как у блэкфинов) с DMA, то вроде нет проблем с синхнонизацией.
Цитата(Rst7)
На любом ARM'е с DMA, только поставить защелку придется. Какой-нибудь LPC17xx вполне подойдет. Да и STM32, видимо, тоже.
не особо пристально разглядывал детали периферии у всевозможных армов, но наличие вменяемого параллельного порта с ДМА, у stm да и у lpc вроде не заметил, ткните носом если не сложно.
видел только 10 битный для камер вход.
добавлено:memory dma на регистр GPIO нормально работает? как быть если на вход надо от внешних клоков (это без относительно данной темы, просто вопрос возник)
можно конечно просто сдвиговый регистр из последовательного в параллельный на spi повесить, но с быстрым spi чтобы быстрее 30МГц, что-то у армов беда какая-то. да и переворачивать биты на такой скорости поди не потянут.
QUOTE
но наличие вменяемого параллельного порта с ДМА, у stm да и у lpc вроде не заметил, ткните носом если не сложно.
Ну вот на примере LPC17xx - настраиваете DMA на передачу память-периферия, с инкрементом источника (это указатель на буфер) и с адресом приемника - адресом обычного GPIO. А в качестве источника запроса используете MATx.x
Вот пример (тут, правда, по таймеру в SPI выдается, но никто не мешает заменить регистр на GPIO)
CODE
unsigned short *TX_DMA_P=TX_outbuf0;
//TXSIZE
//Souce burst size=1
//Destination burst size=1
//Source transfer width=16-bit
//Destination transfer width=16-bit
//Source increment=1
//Destination increment=0
//Terminal count interrupt enable bit=1
#define TX_DMA_START_VALUE_CTRL (((TX_SIZE*3)<<0)+(0UL<<12)+(0UL<<15)+(1UL<<18)+(1UL<<21)+(1UL<<26)+(0UL<<27)+(1UL<<31))
//Enable, Source ignored, Destination - MAT1.0, memory to peripheral, ITC=1
#define TX_DMA_START_VALUE_CONF ((1UL<<0)+(10UL<<1)+(10UL<<6)+(1UL<<11)+(1UL<<15))
//Обработчик DMA, вызывается по концу передачи буфера в ЦАП
//Запускает следующий сегмент данных и стартует задачу передатчика
void GPDMA_IRQHandler(void)
{
UREG intf=DMACINTSTATUS;
if (intf&1)
{
//Прерывание от канала 0, передатчик
DMACINTTCCLEAR=1; //Сбрасываем флаг прерываний
DMACC0SRCADDR=(unsigned long)TX_DMA_P; //Откуда
DMACC0CONTROL=TX_DMA_START_VALUE_CTRL; //Размер и прочее
DMACC0CONFIGURATION=TX_DMA_START_VALUE_CONF; //Старт тут
NVIC_SetPend(NVIC_TIMER2); //Стартуем TMR2_IRQHandler - основной код передатчика
}
}
void InitTX(void)
{
DEBUG_PUTS("TX: Init timer for samples (~130.2kHz).\r\n");
T1MCR=2/*+1*/; //MR0I(выключен)+MR0R(включен)
T1MR0=768/3-1; //100MHz/(3*256)=130.2kHz
T1TCR=1; //Counter Enable
DEBUG_PUTS("TX: Configure DMA.\r\n");
DMACCONFIGURATION=1; //Enable DMA
DMAREQSEL_bit.DMASEL10=1; //Select MAT1.0 for DMA request
DMACC0SRCADDR=(unsigned long)TX_DMA_P;
DMACC0DESTADDR=(unsigned long)(&SSP0DR); //Менять тут
DMACC0CONTROL=TX_DMA_START_VALUE_CTRL; //
DMACC0CONFIGURATION=TX_DMA_START_VALUE_CONF;
}
А на предмет развернуть биты - тут есть хитрость. Если их разворачивать путем перестановки каждого бита по одному - да, будет долго. Но есть хороший способ, примерно такой:
CODE
#define C2P_STAGE(RA,RB,SHIFT,MASK) do{UREG32 t=((RB>>(SHIFT))^RA)&(MASK);RA^=t;RB^=t<<(SHIFT);}while(0)
void C2P(UINT32 *s,UREG l)
{
UREG32 r0,r1,r2,r3,r4,r5,r6,r7;
do
{
r0=s[0];
r1=s[1];
r2=s[2];
r3=s[3];
r4=s[4];
r5=s[5];
r6=s[6];
r7=s[7];
C2P_STAGE(r0,r4,4,0x0F0F0F0F);
C2P_STAGE(r1,r5,4,0x0F0F0F0F);
C2P_STAGE(r2,r6,4,0x0F0F0F0F);
C2P_STAGE(r3,r7,4,0x0F0F0F0F);
C2P_STAGE(r0,r2,2,0x33333333);
C2P_STAGE(r1,r3,2,0x33333333);
C2P_STAGE(r4,r6,2,0x33333333);
C2P_STAGE(r5,r7,2,0x33333333);
C2P_STAGE(r0,r1,1,0x55555555);
C2P_STAGE(r2,r3,1,0x55555555);
C2P_STAGE(r4,r5,1,0x55555555);
C2P_STAGE(r6,r7,1,0x55555555);
*s++=r0;
*s++=r1;
*s++=r2;
*s++=r3;
*s++=r4;
*s++=r5;
*s++=r6;
*s++=r7;
}
while(--l);
}
Собственно, что там происходит:
CODE
Проворот:
Исходная матрица
a0b0c0d0e0f0g0h0
a1b1c1d1e1f1g1h1
a2b2c2d2e2f2g2h2
a3b3c3d3e3f3g3h3
a4b4c4d4e4f4g4h4
a5b5c5d5e5f5g5h5
a6b6c6d6e6f6g6h6
a7b7c7d7e7f7g7h7
Меняем по 4 бита:
T=((R4>>4)^R0)&0x0F0F0F0F;
R0^=T;
R4^=T<<4;
...
e0f0g0h0e4f4g4h4
e1f1g1h1e5f5g5h5
e2f2g2h2e6f6g6h6
e3f3g3h3e7f7g7h7
a0b0c0d0a4b4c4d4
a1b1c1d1a5b5c5d5
a2b2c2d2a6b6c6d6
a3b3c3d3a7b7c7d7
Меняем по два бита
T=((R2>>2)^R0)&0x33333333;
R0^=T;
R2^=T<<2;
g0h0g2h2 g4h4g6h6
g1h1g3h3 g5h5g7h7
e0f0e2f2 e4f4e6f6
e1f1e3f3 e5f5e7f7
c0d0c2d2 c4d4c6d6
c1d1c3d3 c5d5c7d7
a0b0a2b2 a4b4a6b6
a1b1a3b3 a5b5a7b7
Меняем по 1 биту
T=((R1>>1)^R0)&0x55555555;
R0^=T;
R1^=T<<1;
h0h1 h2h3 h4h5 h6h7
g0g1 g2g3 g4g5 g6g7
f0f1 f2f3 f4f5 f6f7
e0e1 e2e3 e4e5 e6e7
d0d1 d2d3 d4d5 d6d7
c0c1 c2c3 c4c5 c6c7
b0b1 b2b3 b4b5 b6b7
a0a1 a2a3 a4a5 a6a7
Описана только работа с одним байтом, а проворачивается сразу 4 в каждом регистре, т.е. за раз - 32 байта.
Ух ты, сколько ответили. Спасибо!
1. Нестандартный Ethernet не пойдет, т.к. этим выходом наша подсистема заканчивается. Странно в документации будет это описывать. Все делается как ОКР, не хватит 100Мбит - вижу тока вариант 1Гб сеть ну или что то последовательное типа LVDS. На данный момент 100Мбит Ethernet, до второй ревизии как минимум.
2. Дальше внутряння сеть RS485 со скоростями 5-10Мбод. Причем не стандартная шина, а звезда (в устройстве так надежнее/удобнее). Оконечниками будут STM32F205 (мне оно ближе).
3. На роль центрального узла Ethernet -> 16*RS485 думаю попробовать тот же stm32 + CPLD MAX V, на макетке попробуем успеет ли stm выплевывать. (может посоветуете через что их лучше соединить?). Не хватит stm, буду думать. Мощные FPGA для меня туманная тема.
4. Передача двунаправленная, но посылки RS485 -> Ethernet редкие. Думаю нужно ли закладывать фул дуплекс или хватит 1/2 дуплекс RS485.
1. Нестандартный Ethernet не пойдет, т.к. этим выходом наша подсистема заканчивается. Странно в документации будет это описывать. Все делается как ОКР, не хватит 100Мбит - вижу тока вариант 1Гб сеть ну или что то последовательное типа LVDS. На данный момент 100Мбит Ethernet, до второй ревизии как минимум.
2. Дальше внутряння сеть RS485 со скоростями 5-10Мбод. Причем не стандартная шина, а звезда (в устройстве так надежнее/удобнее). Оконечниками будут STM32F205 (мне оно ближе).
3. На роль центрального узла Ethernet -> 16*RS485 думаю попробовать тот же stm32 + CPLD MAX V, на макетке попробуем успеет ли stm выплевывать. (может посоветуете через что их лучше соединить?). Не хватит stm, буду думать. Мощные FPGA для меня туманная тема.
4. Передача двунаправленная, но посылки RS485 -> Ethernet редкие. Думаю нужно ли закладывать фул дуплекс или хватит 1/2 дуплекс RS485.
Цитата(pil @ Apr 24 2012, 06:39)
3. На роль центрального узла Ethernet -> 16*RS485 думаю попробовать тот же stm32 + CPLD MAX V, на макетке попробуем успеет ли stm выплевывать. (может посоветуете через что их лучше соединить?). Не хватит stm, буду думать. Мощные FPGA для меня туманная тема.
боюсь даже в самый жирный макс5 16 уартов не влезет, да и памяти нет, а fifo там не помешает. при этом он не в самом прияном корпусе и раза в два дороже младших циклонов
проще тогда каких-нибудь MAX3107 4 штуки на spi/usartы понавесить. правда там ограничение на spi 26MHz на все 4 канала, может быть маловато.
ну или сгородить таких же SPI -> 3-4 UARTa переходники из младших stm32f100, раз stm32 так нравятся, дешевле может выйти.
Цитата(Rst7)
Описана только работа с одним байтом, а проворачивается сразу 4 в каждом регистре, т.е. за раз - 32 байта.
да, красиво.
QUOTE
Передача двунаправленная, но посылки RS485 -> Ethernet редкие. Думаю нужно ли закладывать фул дуплекс или хватит 1/2 дуплекс RS485.
Сделайте полный дуплекс и скорость обратного канала снизьте до получения вменяемого результата с 16тью программными UARTами на прием. Способ быстрой передачи "туда" я уже написал.
И в общем никаких FPGA/CPLD Вам рядом не понадобится, только пара регистров.
QUOTE
да, красиво.
Идея в общем не моя, я ее только для ARM подточил. Просто неспешно тут делаю аудио-интерфейс на 16 входов плюс 16 выходов, вот и приходится эмулировать по 8 последовательных синхронных портов (интерфейсы к кодекам I2S) в каждую сторону. Как раз 3МБод там летит.
Цитата(pil @ Apr 24 2012, 04:39)
Странно в документации будет это описывать.
Давайте о терминах. Странно будет описывать rs-485 работающий на скорости 5-10Мбит и имеющий топологию звезды.
Это далеко от стандарта. Это уже не rs-485. Это что-то другое - назовите Pil-485 и ни каких проблем.
Тоже самое о Ethetnet, если принимать что пользуешься только стандартом на физический уровень. Назовем Pilnet и
никто вам слова не скажет. Единственно, что не понятно - что за устройство является источников такой уймы данных.
Если это какое-то стандартное с интерфейсом Ethernet, то никуда не денешься, надо придерживаться стандарта. Если
устройство разрабатывается вами, то какие проблемы?
Цитата(alag57 @ Apr 24 2012, 14:38)
Давайте о терминах. Странно будет описывать rs-485 работающий на скорости 5-10Мбит и имеющий топологию звезды.
Это далеко от стандарта. Это уже не rs-485. Это что-то другое - назовите Pil-485 и ни каких проблем.
Тоже самое о Ethetnet, если принимать что пользуешься только стандартом на физический уровень. Назовем Pilnet и
никто вам слова не скажет. Единственно, что не понятно - что за устройство является источников такой уймы данных.
Если это какое-то стандартное с интерфейсом Ethernet, то никуда не денешься, надо придерживаться стандарта. Если
устройство разрабатывается вами, то какие проблемы?
Это далеко от стандарта. Это уже не rs-485. Это что-то другое - назовите Pil-485 и ни каких проблем.
Тоже самое о Ethetnet, если принимать что пользуешься только стандартом на физический уровень. Назовем Pilnet и
никто вам слова не скажет. Единственно, что не понятно - что за устройство является источников такой уймы данных.
Если это какое-то стандартное с интерфейсом Ethernet, то никуда не денешься, надо придерживаться стандарта. Если
устройство разрабатывается вами, то какие проблемы?
Источник это пока теория, но точно не моя разработка, соответственно Ethernet стандартен.
Rs485 5-10Мбод звездой - это просто 16 стандартных RS485 (точка-точка)
Цитата(Rst7 @ Apr 23 2012, 14:05)
Да и аля-UART можно. На любом ARM'е с DMA, только поставить защелку придется. Какой-нибудь LPC17xx вполне подойдет. Да и STM32, видимо, тоже.
Принимаете из сети пакет, проворачиваете биты (можно и на большом брате проворачивать) и укладываете в буфер, а DMA по таймеру сам отправит в параллельный порт. Выход этого же таймера надо использовать как CLK, если это SPI, либо как тактовый сигнал защелок, если это UART - чтобы не было джиттера.
Однако, так хорошо получится только в том случае, если надо организовать исключительно вывод. При необходимости ввода данных можно только SPI организовать без геморроя.
Принимаете из сети пакет, проворачиваете биты (можно и на большом брате проворачивать) и укладываете в буфер, а DMA по таймеру сам отправит в параллельный порт. Выход этого же таймера надо использовать как CLK, если это SPI, либо как тактовый сигнал защелок, если это UART - чтобы не было джиттера.
Однако, так хорошо получится только в том случае, если надо организовать исключительно вывод. При необходимости ввода данных можно только SPI организовать без геморроя.
Непонятно, что такое джиттер?
А получится эмитировать 16 UART'ов? (SPI не так хорош, но можно и 16 SPI).
QUOTE
Непонятно, что такое джиттер?
Дрожание фронтов. Конкретно из-за того, что DMA будет переносить данные из ОЗУ в порт, а может запаздывать на несколько тактов из-за арбитража. Для SPI это не страшно, все равно данные в приемниках защелкиваются по тактовому сигналу, а вот для UART надо дополнительно поставить защелки, простробировав их тактовым сигналом - от того же таймера, который используется для генерации запросов на DMA-пересылку.
QUOTE
А получится эмитировать 16 UART'ов?
Эмулировать, Вы имели в виду? На вывод - запросто (уже вроде все разжевал), на ввод с заявленными скоростями не успеет.
Цитата(Rst7 @ Apr 25 2012, 00:27)
Дрожание фронтов.
для UART надо дополнительно поставить защелки
на ввод с заявленными скоростями не успеет.
для UART надо дополнительно поставить защелки
на ввод с заявленными скоростями не успеет.
Все-таки мне кажется вариант от Саши Жевака предпочтителен.
Одна и та же (почти) программа для всех четырех девайсов (или контроллеров).
Полноценное использование DMA и вообще аппаратуры (что здесь и нужно).
Никаких (почти) проблем с обратной связью. По крайней мере пока не вижу противопоказаний.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.