За програмиране на ARM ползвам Wiggler подобен програматор/дебъгер, но ме отчайва скоростта, с която се качват hex-овете. Чакам по 10 сек. за някъв файл от няколко К, не ми се мисли кво ще е, когато нарастне повече. Не знам, всъщност, това от дебъгера ли зависи или от самия чип. Ако е от дебъгера, може ли по някъв начин да се настрои LPT за по-висока скорост и ще се промени ли нещо?

Ако си с WINDOWS не знам как ще докараш времена под 1 ms все пак не е real-time ОС .

Ползвам JTAG за ARM основно за четене и писане на фърмуер не за дебъг. Но не можах да се переборя с бавните скорости на LPT JTAG-овете, решението беше: http://www.segger.com/jlink.html . Пише и чете по-бързо от програматора. Проблем се оказа че искаха доплашане от около $400 да да се активира функцията Flash Write, но този проблем беше заобиколен доста бързо (без допълнително доплащане).

Та според мен решението е USB.

За колко време ъплодваш 256К hex?

LPTто има към 500к скорост в секунда, със сигурност не е от него. общо взето повечето програматори са бавни заради некадърното изпълнение, абсолютно смешна ситуация - тъпчат по няколко стотин байта в секунда. не знам каква е тая тотална несериозност по отношение на скоростите, и то при положение че не продаваш на усери, дето не са наясно какви са възможностите на елементната база.

пробвай NtSetTimerResolution

ето ти примерен код:




пример за викане:
ULONG ActualTime = 0;
return NT_NtSetTimerResolution(100*10L, true, &ActualTime); // установява желана "резолюция" 100ns

ефекта от промяната на резолюцията на системния таймер има ефект върху всички приложение - след приключване на приложението се връща старата стойност ... всъщност ако има няколко приложения променящи таймера - се използва най-малката

ефекта е примерно при Sleep(1) и при превключването на нишки ...

мин. стойност за таймера зависи според (на моя с Виста32 е 0.5мс)... по дефолт май за XP e 5ms така че ако го смениш на 1ms - и твоя програматор ползва Sleep(1) за времезадръжка - може да се ощастливиш с x5 производителност

(твоето приложениие дето сменя резолюцията - трябва да е актиено през цялото време !)

1Mb за около 5 сек.
Точно не съм го засичал но в понеделник може да го погледна по-точно.

Ей хора прочетете малко що е то JTAG за ARM и ще ви стане ясно защо тоя или оня програматор е по-бърз или по бавен.

JTAG комуникацията си е цял протокол с команди и данни. Значи Willem-а цялата "логика" на протокола е изнесена на PC то. Затова е и толкоз бавен.

На по-марковите програматори, част от командите са имплементирани директно във програматора на ниско ниво, а комуникацията с PC е само на високо ниво.

На съвсем марковите почти всичко е завряно в прогрматора, PC то просто му мята фаил.

Та народа си го е казал - за толкоз пари - толкоз. За willem иде реч.

Първото нещо което спъва е протоколът по JTAG - има доста overhead ако го ползваш само за да прехвърляш данни. Второто е самия начин за наливане на данни в ARM - симулират се инструкции за зареждане на данните в регистър и после записването им на някой адрес, като накрая има възстановяване на PC. Третото е че самият паралелен порт си е бавничък и с тия дълги жици и лоши фронтове не може и да се вдига особена скорост. Четвъртата е самият OS и бавния начин по който се осигурява user-ски достъп до паралелния порт.

Ако имаш възможност, наливай само малка boot програма с JTAG, после останалата част от кода/данните - с твоя си програма по UART (ако има) или нещо друго.
Или просто стани много търпелив.

Да, това и аз съм си го мислел с bootloader-а, още повече, че има готови Въпроса е как ще накарам глупавото ИДЕ като натисна бутона Дебъг да не програмира, а направо да тръгва. Трябва да го разуча тоя въпрос.

Някога съм си писал малки bootloader-и, дори малък JTAG дебъгер. Никога обаче не ползвам IDE, така че не знам какво да ти кажа.

Може би ако в адресното пространство на контролера има код който отговаря на това което е генерирала средата няма да има проблеми. Натискаш "Stop" примерно, то по PC се ориентира къде е, вади debug info и ти отива на правилното място в source-a, после си dump-ва която памет реши. Поне така си мисля.

Прати ЛС или майл ако имаш нужда от помощ...

Според това -> http://en.wikipedia.org/wiki/IEEE_1284 <-
паралелния порт достига 33,3МВ/s в ЕРР режим...

Едната тройка да не е в повече? Малко по-горе в същата статия:

Enhanced Parallel Port (EPP) is a half-duplex bi-directional interface designed to allow devices like printers, scanners, or storage devices to transmit large amounts of data. EPP can provide up to 2 Mbit/s bandwidth, approximately 15 times the speed achieved with normal parallel-port communication with far less CPU overhead.

И то ако има системен софтуер който да държи постоянно буферите пълни. 2Mbit прави 250kHz ... не чак толкова много.

Най-важното - при Wiggler единият от битовете данни играе ролята на TCLK, което значи че теоретично не можеш да имаш честота над 125 kHz. Оттук нататък ясно ли е?

Още малко по темата: и тези 125 kHz не са особено достижими ако на PC-то има могъща OS - или всеки опит за директен достъп от userspace до паралелния порт ще минава през купчина изключения и емулации, или за всяко обръщане на TCLK битчето ще се минава през дълга верига system calls.

Най-добре е ако има драйвер който има директен достъп до паралелния порт и цъка TCLK, или ако например Linux програма се стартира с root privilege която може да заяви директен достъп до паралелния порт ако е свободен.

За една бърза работа по JTAG са необходими примерно 6-20 МHz честота на TCLK, ето защо както отбеляза преди един колега, ако искате скорост - купете си правилния хардуер, който приема заявките от PC на високо ниво и сам организира JTAG протокола. Или пък си направете.

Може наистина да са объркали броя на тройките.
Ако си сигурен че си прав - редактирай статията в wiki-то...