AtMega vs. PIC24?

[sparkybg]

От: AtMega vs. PIC24?

И... отивам на варианта в единия край PICльо директно на USB-то и захранен от него (има драйвери за Windows, Linux, Android), от там пращам през UARTа му по оптика до друг PICльо, закачен и захранен от CAN шината. Терминацията ще е в кабела според нуждите (междинна или средна точка по веригата). Така и да се издъня откъм "USB" частта, ще я сменя само нея директно с FT232R. Ама все си мисля че няма да се стигне до там.

Остава само въпроса кой точно вариант на драйвер да използвам. Клоня към libusb (понеже го има и за трите платформи), но ме гложди едно съмненийце за бъдещето му, понеже е Оpen Source проект. Друг вариант е да ползвам MCHPUSB библиотелите на Microchip с "generic driver", каквото и да значи това.

Някой, нещо?

[sparkybg]

От: AtMega vs. PIC24?

Мдаа... седях, мислих, и пак седях, и пак мислих, и най-накрая се хванах че чета даташита на TOSLINK ресивера, и вътре си пише че иска модулиран сигнал. Демек RS232 върху TOSLINK колкото и да ми се ще няма да го бъде. Не и по простия начин.

ittso, ти какво и как си пускал по тия "светлинни жици", че нещо се омотах съвсем?

...а докато продължавам да ровичкам по въпроса, ще нахвърлям проектче с digital isolator, че е време работата да мръдне на някъде.

[majmuncho]

От: AtMega vs. PIC24?

Мега-та определено е по-добрият вариант - не гледай честоти и други такива неща - погледни архитектурата на процесорте - пиковете като цяло имат много малко регистри и пишеш като луд елементарен код - Атмел-ската архитектура разполага с доста регистри и това което правиш на ПИК с 3 инструкции става с една
пример - при ПИК зареди - събери - съхрани - при атмел става с 1 инструкция ...такива неща гледай ... те са основното което ще те мъчи ... дане говорим страницирането на паметта при ПИК ... и хилядите особености за всяко едно елементарно нещо ... аз съм работил и с ПИК и с Атмел - верно преди 4-5 години ... но едва ли са се променили нещата ... честотите не са проблем ... обикновено с микроконролери се следят естествени процеси, които протичат бавни и по-виската честота освен до по-голяма смущаемст и изисквания към захранването ... нищо не ти помага ... темата е много дълга

[ittso]

От: AtMega vs. PIC24?

Мдаа... седях, мислих, и пак седях, и пак мислих, и най-накрая се хванах че чета даташита на TOSLINK ресивера, и вътре си пише че иска модулиран сигнал. Демек RS232 върху TOSLINK колкото и да ми се ще няма да го бъде. Не и по простия начин.

ittso, ти какво и как си пускал по тия "светлинни жици", че нещо се омотах съвсем...

Някак ми е убегнал въпроса и чак сега го виждам.
Понеже не цитираш какво си чел, не знам какво да ти отговоря, но малко напосоки...
Предполагам, че в документацията са имали предвид, че трябва да се подава модулиран сигнал за да работи като Toshlink (оптичната версия на S/PDIF, цифрово аудио).
Иначе, в зависимост от подаденият логически сигнал, трансмитерът излъчва или не излъчва светлина. Излъчването е статично, без модулация. В смисъл, трансмитерът не модулира сигнала. Ресивърът съответно формира същият логически сигнал на изхода си в зависимост дали е или не е осветен.

[sparkybg]

От: AtMega vs. PIC24?

Мега-та определено е по-добрият вариант - не гледай честоти и други такива неща - погледни архитектурата на процесорте - пиковете като цяло имат много малко регистри и пишеш като луд елементарен код - Атмел-ската архитектура разполага с доста регистри и това което правиш на ПИК с 3 инструкции става с една
пример - при ПИК зареди - събери - съхрани - при атмел става с 1 инструкция ...такива неща гледай ... те са основното което ще те мъчи ... дане говорим страницирането на паметта при ПИК ... и хилядите особености за всяко едно елементарно нещо ... аз съм работил и с ПИК и с Атмел - верно преди 4-5 години ... но едва ли са се променили нещата ... честотите не са проблем ... обикновено с микроконролери се следят естествени процеси, които протичат бавни и по-виската честота освен до по-голяма смущаемст и изисквания към захранването ... нищо не ти помага ... темата е много дълга

Хвърли един поглед на PIC32 конкретно. Ядрото е MIPS, не микрочипско.

[sparkybg]

От: AtMega vs. PIC24?

Някак ми е убегнал въпроса и чак сега го виждам.
Понеже не цитираш какво си чел, не знам какво да ти отговоря, но малко напосоки...
Предполагам, че в документацията са имали предвид, че трябва да се подава модулиран сигнал за да работи като Toshlink (оптичната версия на S/PDIF, цифрово аудио).
Иначе, в зависимост от подаденият логически сигнал, трансмитерът излъчва или не излъчва светлина. Излъчването е статично, без модулация. В смисъл, трансмитерът не модулира сигнала. Ресивърът съответно формира същият логически сигнал на изхода си в зависимост дали е или не е осветен.

Трансмитера е ясен. Проблема е в ресивъра. Ето какво пише в даташита на TOSHIBA:

Note 2: 7.5Mb/s (max.) Biphase Signal.When modulated optical high level signal is received, output signal is high.
When modulated optical low level signal is received, output signal is low.
When non- modulated signal (optical all high or all low level signal) is inputted, output signal is not stable.

А това е от даташита на SHARP:

(2) The output (H/L Level) of this product are not fixed constantly when it receivers the modulating light
(including DC light, no input light) less than 0.1 Mb/s.

[sparkybg]

От: AtMega vs. PIC24?

Още пAри :


Като имаш и 3d модел на кутията, в която ще го слагаш, работата е песен. На по-късен етап ще сложа добавя схемата, а на още по-късен - и софтуера и фирмуера, когато ги напиша.

ПП: Прикачил съм и схемата.

[ittso]

От: AtMega vs. PIC24?

Трансмитера е ясен. Проблема е в ресивъра. Ето какво пише в даташита на TOSHIBA:


А това е от даташита на SHARP:

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

[sparkybg]

От: AtMega vs. PIC24?

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

Вероятно е нещо, свързано с Auto Gain на усилвателя на ресивъра. Иначе наистина няма логика. Както и да е де. То може да се направи UART-а в "паузите" да предава постоянно битове "01010101", и тогава проблема отпада. Като вземем в предвид че UART-а може да работи с DMA, даже и процесора няма да се товари въобще.

[ittso]

От: AtMega vs. PIC24?

То няма какво друго да е. Или коригират усилването или офсета.
Щом са го описали има нещо де, но аз не съм се сблъсквал с въпросния проблем...

[sparkybg]

От: AtMega vs. PIC24?

Едно рендерче от SolidWorks.

[sparkybg]

От: AtMega vs. PIC24?

Да се изфукам с кво се сдобих:


+ 2 100 кракови RX62N с максималното памет.

[ittso]

От: AtMega vs. PIC24?

Мдаааа. И с доволна усмивка и няколко попържни наум, пикът небрежно беше захвърлен в чекмеджето с ненужни вещи...

[sparkybg]

От: AtMega vs. PIC24?

Мдаааа. И с доволна усмивка и няколко попържни наум, пикът небрежно беше захвърлен в чекмеджето с ненужни вещи...

Попържните бяха преди да го поръчам. Поради грешка във фирмуера PICKit3-ката ми изгори един PIC32. Или по-точно изгори му интерфейса за програмиране. Поредния пример как с малко желание можеш да осереш всичко. Обаче продължавам да твърдя че PIC32-ката е не лош микроконтролер, и надали скоро ще ми излезе от полезрението.

[Rabin]

От: AtMega vs. PIC24?

С интерес наглеждам темата, въпреки, че нямам какво да съветвам точно Спарки. И аз си разцъквам подобни неща, ама от нямане какво да правя, не гоня конкретна задача.
Таковата... каква е крайната цел на задачата? То PID сервомотори бяха, то CAN, то оптики... И графични LCD дисплеи!!!