AtMega vs. PIC24?

[tef4o]

От: AtMega vs. PIC24?

Малко те позабравих... и аз за Микрочипското Си говорех. Интересно ми е какъв код ще изкара за сметките, все пак приложението е тайм критикъл.
А на какво си пишеш софта за компа? Че ако е на Бейсик (споменаваше се някъде, но може и да съм се заблудил) на 3 мегабита с визуализация май ше се оака

П.П. За разлика от теб, преди малко успях да взривя един транзистор Вярно, от 3 платки, скалъпени набързо и без предварителни проверки, двете тръгнаха от раз, та време беше да подпаля нещо

[sparkybg]

От: AtMega vs. PIC24?

... на 3 мегабита с визуализация май ше се оака ...

Контролите за визуализация са си мое дело. Засега ползват WINAPI, но ако се наложи ще ги стъкмя за DirectX. VisualBasic не е толкова бавен, колкото му се носи славата че е. Като се изключат някои проверки и се използват целочислени променливи, си тръгва съвсем прилично. Още повече на 2 гигахерцов лаптоп.

А сметките се състоят в няколко умножения и събирания. PID контрол. Побира се в около 200 инструкции. Подпрограмката, дето ще ги прави, ще върви от RAM-а, вместо от Flash-а, понеже RAM-а е с 0 цикъла на изчакване, а Flash-а - с 3.

[tef4o]

От: AtMega vs. PIC24?

Имам идея как еаботи VB, и аз го ползувам (пусти мързееееел...). Но не съм го изпъвал на чак такива скорости през контролата за ком-порта. Проблема не е в сметките (за визуализацията говоря), по-скоро ме притеснява, че цялата забавачка с четенето на данните от порта ще го мотка. кажи как се държи, като го пуснеш, да знам колко са му възможностите в такъв режим.

За няколко умножения и събирания на 16 битово ядро 200 операции ми се виждат множко, но не знам на кое викаш "няколко" и каква точност гониш.

[sparkybg]

От: AtMega vs. PIC24?

FTDI си имат DLL-и за директна работа с FT232R. Ако контрола се мотка, или ще си направя мой, или ще ползвам директно DLL-а на FTDI.

А ядрото е 32 битово. Умножава за 2 цикъла. Само деленето е малце по-бавно. Входа и изхода са 10 битови, с тенденция да станат 12 битови, евентуално. При 32 битово умножение, точността ще е предостатъчна. След като стане ясно как работи на пълната си скорост, ще се намалява докато смогва. Според това колко смогва, ще се опита с dsPIC30 или dsPIC33, понеже имат по-добри ADC-та, някои образци с по 2 на брой напълно самостоятелни, други с по 1 ADC, но с по няколко отделни Sample-and-hold буфери.

Говори се че microchip в момента готвят нова серия PIC32-ки, на повече мегахерци, с повече памет, с по-малкко крака, и с по-разнообразна периферия. Наскоро са купили и ново ядро от MIPS. Явно имат намерение за сериозно развитие на PIC32 серията. Ще видим.

А току виж съм пробвал и ония на Renesas някой хубав ден. То е въпрос на цена най-вече.

[tef4o]

От: AtMega vs. PIC24?

Опс, вярно, че беше на повечко битове Подведох се по споменаването на Пик30...

[sparkybg]

От: AtMega vs. PIC24?

Приключението по сглобяването приключи. Сега предимно ще се правя на програмист.

[tef4o]

От: AtMega vs. PIC24?

Въпрос: масовата употреба на SMD на (все пак) експериментална платка, няма ли да те озори в последствие? Малко късничко е за такова питане, просто като видях платката готова и ...

[sparkybg]

От: AtMega vs. PIC24?

Въпрос: масовата употреба на SMD на (все пак) експериментална платка, няма ли да те озори в последствие? Малко късничко е за такова питане, просто като видях платката готова и ...

Дори са ми по-лесни. Еле пък с оня поялник. Взел съм си "ножовидни" човки, с които се разпоява лесно. А и ако не беше SMD, платката щеше да стане 2 декара.

После:
Аналоговите усилватели на грешка на изхода вече са проиграни и със сигурност работят. Надявам се да отпаднат и директно от DAC-а да управлявам инвертора.
От входа до ADC-то има само един филтър (от 8-и ред) под въпрос, и то не какъв, а дали да го има въобще. Предвидил съм джъмпери. От DAC-а до изхода също един филтър е под въпрос - отново съм предвидил джъмпери.

Голямата играчка ще е с PID контрола, докато му наглася коефициентите и усредняването по време. Това обаче с предварителни сметки не става. Трябва на място, при работеща машина.

Скоро надявам се да смогрна поне до някъде да напиша софтуера. Периферията, дето ми трябва, съм я подкарал - разбирай серийния порт, ADC-то и DAC-а. Уж всичко работи според замисъла. Ще видим. Довечера ще си играя с обратната връзка за скоростта на телоподаване, например. После започвам същественото програмиране, заедно с PC интерфейса.

Получи се доста голямо приключение, но отдавна не ме е тресъл така ентусиазма.

[tef4o]

От: AtMega vs. PIC24?

Спарки ... май ще имам амлко нужда от помощ. Общи напътствия по-скоро.
както споменах по-горе, като опре до писане на програми за ПеЦе, ползувам VB, предимно от мързел. Проблема е, че до скоро си карах на VB6 и не съм имал ядове. Сега реших да съм в крак с времето и се метнах на VB.net ... и псувам. Няма да изпадам в подробности, щото не са по темата, но определено имам нужда от 2-3 съвета по отношение на комуникацията с ком-порта. през същото ФТ232.
На VB6 си бачка като пич, на .нет обаче чете 2 байта правилно, 2 без последния бит (на същя хардуер и на същия лаптоп) и се видях в чудо. Нямам никакво време да започвам да преписвам всичко на VB6 или на друг език.

Ако е удобно, метни ми един телефон на лични, едва ли ще ти отнема повече от 5 минути.

[sparkybg]

От: AtMega vs. PIC24?

zero eight osem 907 dwe 7 пет седем

Конкретно, вземи си програмка за прихващане на комуникациите през COM порта, и виж какво реално става. Тоест, на колко BPS отваря порта, и т.н. Симптомите приличат на разлика в скоростта на FT232-то, и скоростта на UARTA на микроконтролера, който използваш. Допустимата разлика е до +/- 3%, до колкото помня.

Скоростта на FT232-то драйвера си я изчислява така:
3000000/(n+x), където n може да е между 1 и 16384, а x може да е само нула, ако n=1 или 0.125, 0.25, 0.375, 0.5, 0.625, 0.75 и 0.875, когато n>=2.

Разбирай, избери такава скорост на COM порта, която би дала минимална разлика със скоростите, които може да поддържа UART-а на микроконтролера. Обикновено за почти всички , дори стандартните, скорости има някаква разлика. Точно съответствие има при силно ограничен брой скорости, освен ако не си подбрал кварца на микроконтролера така, че UARTA му да може да тръгне на точната скорост.

Например аз за да го подкарам на 3 мегабита, трябваше да избера скорост на PIC32-ката, делима точно на 3Mhz. В моя случай 75Mhz, вместо максималните 80.

Друго, не знам какво ползваш в VB.NET за достъп до серийния порт, но някои такива стандартни компоненти понякога налагат изкуствени и безсмислени ограничения на скоростите, които се ползват.

Ако искаш дори можеш да закачиш един осцилоскоп на подходящото място, и да гледаш на какви скорости реално работи приемането и предаването.

ПП: И аз пиша на VB6. .NET ползвам рядко, макар да се замислям да пиша конкретното на .NET, заради графичния интерфейс на .NET.

ППП: Аз ползвам Serial Port Monitor 4.0.2.274. за гледане какво става по com портовете. 5MB е.

[tef4o]

От: AtMega vs. PIC24?

Мммм... ясно. Комуникацията като такава си бачка, проверено. Проблема е някъде в самата контрола на дотнет-а (в смисъл - аз не мога да се оправя с нея). ОК, ще мисля нататък ...
Благодаря за съдействието!

Edit: подкарах го мръсника. Просто въпросната контрола се опитва да прекара всичко през енкодинг (мамка му, ако някой успее да ми обясни ЗАЩО) и всичко с вдигнат старши бит минава за 63 по дефолт - ASCII, 7 битово. И това не разбрах защо, след като дори VB4 бачкаше на 8 бита.
За бела, тестовата последователност беше 252 252 66 66, а 252 без 2те младши нули си е ... 63, та ми трябваше известно време да се усетя

Проблема е във "вредни" привички от старата версия, където начина на четене на данните се задаваше по друг начин. Четенето в двоичен вид не се задава, както беше преди (ModeText/ModeBinary), а се разчита, че компилера сам ще се сети какво искаш от него по това в какъв вид променлива вкарваш съдържанието на буфера. Това е.
Плюс всичките постотии, докато му обясниш че при раздвижване на ком-а, трябва да генерира събитие, но това вече е отделна тема.

[sparkybg]

От: AtMega vs. PIC24?

Май питах и в друга тема, ама я споделете какъв флюс ползвате. Иде реч за течен.

Аз ползвам no-clean IF7002 (май беше) на InterFlux, и от качествата му съм доволен, обаче много трудно се чисти, особено изпод чиповете. Снощи съм си играл 40 минути, и похарчил литър изопропанол, и пак има остатъци тук-там, под чиповете.

Замислям се да си направя колофон+изопропанол, ако на пазара няма нещо по-добро. Ама ми се струва че няма начин да няма начин.

[sparkybg]

От: AtMega vs. PIC24?

Мммм... ясно. Комуникацията като такава си бачка, проверено. Проблема е някъде в самата контрола на дотнет-а (в смисъл - аз не мога да се оправя с нея). ОК, ще мисля нататък ...
Благодаря за съдействието!

Edit: подкарах го мръсника. Просто въпросната контрола се опитва да прекара всичко през енкодинг (мамка му, ако някой успее да ми обясни ЗАЩО) и всичко с вдигнат старши бит минава за 63 по дефолт - ASCII, 7 битово. И това не разбрах защо, след като дори VB4 бачкаше на 8 бита.
За бела, тестовата последователност беше 252 252 66 66, а 252 без 2те младши нули си е ... 63, та ми трябваше известно време да се усетя

Проблема е във "вредни" привички от старата версия, където начина на четене на данните се задаваше по друг начин. Четенето в двоичен вид не се задава, както беше преди (ModeText/ModeBinary), а се разчита, че компилера сам ще се сети какво искаш от него по това в какъв вид променлива вкарваш съдържанието на буфера. Това е.
Плюс всичките постотии, докато му обясниш че при раздвижване на ком-а, трябва да генерира събитие, но това вече е отделна тема.

Я дай подробности кое точно ползваш за серийния порт? Според това, дето чета из интернет, system.io.ports.serialport. Ама то не е контрол, в понятието, което се влага в това във VB6, ами просто обект с ивенти, и то ивентите са само ако искаш. При това не всички версии на .NET Framework работят добре с ком порта. И по-точно 1.1 няма поддръжка, и трябва да ползващ старата контрола от VB6. Останалите поддържат, но има проблем s 2.0SP1 и 3.5, който съдържа в себе си и 2.0SP1 Trqbwa da se raboti s 3.5SP1, което има в себе си 2.0SP2, или последната версия - 4.0, с което аз се боричкам в момента.

Аз за себе си реших генерално да минавам на .NET. В работата минаваме на клиент-сървър, и всичко ще се пренаписва, и така или иначе ще трябва да си човъркам дъртия порграмистки мозък с нещо ново, което отдавна не се е случвало.

[tef4o]

От: AtMega vs. PIC24?

Ай стига бе, дърт... като те гледам, я си набор, я не

Майтапа настрана, ползувам .нет 4.0. (VS2010). И да, същата контрола.
Проблема ми е предимно в привикването, в смисъл, че нещата са принципно различни, а старите навици умират трудно Все пак съм зарязал другите езици още как излезе VB5 и то най-вече заради супермързеливото писане.

Само не съм решил дали да се връщам към доброто старо Си (не АНСИ, естествено, чак толкова нерви нямам) или да доразуча java-та. Така и не съм обръщал сериозно внимание на тоя език. Блазни ме най-вече, че (поне по идея) е платформено независим, а това си е едно добро основание да зарежа и Уин-а. Особено пък за дребни клиентски машини, на които работи само една, строго специализирана програма, какъвто е най-често случая при мен. Както и да е, това е разговор за друга тема.

Между другото, бера сериозни ядове с ивентите на серийния. За момента съм ги заобиколил ... някак. Работи стабилно, а предвид острата липса на време, повече не ми и трябва, но е грозно леко ме дразни. Не искам да ползувам ocx-са от 6тицата, че там пък започват други главоболия, а нямам време да се обяснявам и с инсталатори.
Ако имаш някой линк под ръка, където малко по-човешки е обяснена ей тая част с "има ивенти, но само ако искаш" (искам), метни насам, че попадам само на някакви идиотски примери, опиращи до предаване/приемане на файл, които не ме топлят.

Пренаписването от 6 на нет си е ... пренаписване. Има някакви "преводачи", но според това, което прочетох, няма нищо, на което може да се разчита сериозно. Поне не се очертава да ти е скучно скоро

[sparkybg]

От: AtMega vs. PIC24?

Това е най-доброто, което намерих. Покрай COM порта има и доста други писания, но общо взето полезни, според мен.

http://www.innovatic.dk/knowledg/Ser.../SerialCOM.htm