Nem lehetne valahogy növelni a kommunikáció sebességét? Pl. másik kvarccal? Hogy ne 9600-al menjen

ugye te használod a szoftveres komunikációt? szerintem nem érdemes szoftveresen szenvedni, használd az usartot, kössd át a dolgokat, írd át a progit úgy, hogy tudjad használni, akár 625000bit/sec is lehet majd az átviteli sebességed.
mitől 3* annyi min a memória tartalma??

Nem lehet , mert szoftveresen generált az RS232. Egyszerűen elhasználtam a PIC USART-os lábát. 2 port kellett a címzéshez. 1 port az adatok kiolvasásához.

Nem lehet mert mindent egy PIC végez. Pont ez volt a célom. Csak azt nem értem hogy most a VisualBasic comport komponense ilyen x@r vagy én vagyok béna.
Hát a "soremelés" és "kocsi vissza" karakterek miatt 3x annyi. Annyira evidens hogy majd kiszúrta a szemem , mégis rácsodálkoztam. Persze ezeket ki kellett szednem a hasznos adatok közül. Utána egy tömbe íratni. Majd a képernyőn láthatóvá tenni.

Szóval a 3perc 20s még belefér. Bárcsak rájönnék hogy tudom elérni.

Hát így néz ki a kódrészlet:
Private Sub MSComm1_OnComm()
Select Case MSComm1.CommEvent
Case comEvReceive
s = MSComm1.Input
ik = ik + 1
scdata(ik) = Asc(s)
If ik = 10000 Then
For ik = 0 To 10000
If scdata(ik) = 10 And scdata(ik + 1) = 13 Then
scdata(ik) = 0
scdata(ik + 1) = 0
End If
Next
For ik = 0 To 10000
If scdata(ik) > 0 Then
Text1.Text = Text1.Text & scdata(ik)
End If
Next
End If
End Select

End Sub

de minek kellenek azok cr meg lf byteok, minden hasznos adatbájt után küldessz 2 ilyet?? minek?? kapcsoldd ki, hogy ne külddjön a pic ilyet, nem lehet?

Mit tom én? A basic fejlesztőkörnyezet generálja a kódot. Az Assemblybe meg nem volt kedvem belenyúkálni mert elég csúnya ez a része. De lehet hogy átírom, amúgy is nem lenne rossz ha gyorsabb lenne az átviteli sebesség.
De egyenlőre már azzal is beérném ha rájönnék a PC-s programom átvitel hibájára, azaz inkább lassúságára.

hja, 3* gyorsabb...., a pic müxik 19200bit/s el is szoftveresen picbasicben...

Na abban még nem néztem. Csak a Mikrobasicben. Köszi.

Na alakul. Lefaragtam 3 perc 20s -ról 52s-re. A késleltetési időt az átvitelek között megfeleztem és ezzel nyertem 100s-et és elhagytam az utasítás CrLf részét ezzel meg mégtöbb időt nyertem. Szóval már csak 52s. De a PC programom hibáját még mindig nem tudom.

Szóval köszi a tippet. Mára abbahagyom a számítógépezést. Fáj a szemem.

Sziasztok!

Hi!

Én úgy küldöm az adatot, hogy egy timerrel időzítem az AVR-ben. Minden timer interruptnál elküldök egy bájtot. Ezt a másik oldalon berakom egy tömbbe, növelem a tömbindexet, és ennyi, ezt ismétlem végig. Ez nem sok művelet a PC oldalon se, elég gyorsan lehet csinálni.
Tehát nincsen ilyen buffer meg semmi, hanem egyszerűen átküldök egy darab bájtot. Így kb másfél perc alatt küldök át 32KB-ot 115200bps sebességgel. Igazából a küldés sebessége nem is olyan lényeges, mert a bájtok közti várakozás sokkal több szerintem. Persze a timerrel lehet ezt még szabályozni, lehet hogy megnövelem meg a baud rate-t is lejjeb veszem hogy pontosabb legyen a 16 megás kaviccsal és akkor nem veszik el adat.

mi lenne ha paritásbitet használnátok?? hasznos dolog...

Hasznos, csak megbonyolítja a szoftvert. Ugyanis ha a paritásbit rossz, akkor újra kell küldeni. Ehhez viszont szólni kell a PC felől a szkópnak hogy küldje újra. Ehhez valami kézfogáso technika kell, ami legalább kétszerannyi adatforgalom. És a PC vezérli az átvitelt, nem a kontroller...stb stb

sztem nem ennyire bonyolult, ha rossz a paritásbit akkor a pc szól tx vonalon a kontroller usartjának ami csinál egy interruptot, megnézi mi jött be (az jött be, hoyg: küldd újra a x bájtotot!) és akkor újra küldi.... mér lenne 2szer annyi adatforgalom? csak akkor szól pc a szkópnak mikor baj van.
Lenne egy kérdésem: ezeket a ferrite bead-eket usbéhez honnan szerzitek be?? kell az egyáltalán?

én csak azért erőltetem a paritásbitet, mert ami el tud romlani az el is fog, és ugye a bitek is ilyenek, egyébként még én sem használttam ezt a paritásbites dolgot sehol, csak kipróbáltam..., szkóp lesz az első ha lesz..

Szerintem csak nagyobb sebeségnél van értelme a paritásnak. PIC oldalról is és PC oldalról is tökéletes az átvitelem. Minden adat megérkezik helyes értékkel a PC-re. Nekem azzal van a gondom hogy az én általam VisualBasic-ben írt programomnál lassú az adatok vétele. Más sorosporti terminál programoknál tökéletes az átvitel. Tegnap már nem volt erőm hozzá. Most körbejárom a VisualBasic Comport komponensének tulajdonságait. Tuti van valahol valami késleltetés amit nem állítottam be.

Nálam is egyébként nem az adatok értéke a rossz. Ami megérkezik az a bájt jó. Csakhogy van ami nem érkezik meg. Az ellen meg a paritásbit se tud mit tenni. Van egy kis hiba abban amit leírtál, ugyanis elég gyorsan küldözgeti a szkóp az adatot. Így mire észrvesszük PC-n a paritáshibát, és átküldjük az üzenetet, már lehet hogy 3 bájtot elküldött a szkóp. Erre vannak a számítógéphálózatokban mindenféle protokollok (Go Back N meg hasonlók) de az rengetek overhead és 3-szor lassab lesz tőle a dolog.

Bbatka: Én még mindig azt javaslom hogy térj át Delphire ha nagyon nem megy. Vagy keress valami mintapéldát neten forrással. Amúgy nem értem hogy mi lehet a baj. Ha egyesével átlövöldözöd a bájtokat, és hagy köztük elég időt, akkor nem kéne hogy elvesszenek.

Valami apró hiányosság lehet. Már pár mintapéldát átnéztem. Eltérést nem tapasztaltam.
Már én is fontolgatom a Delphit.

A tegnapi programozásom eredménye:
http://forum-masterfoxx.fw.hu/forum/menu.zip
A videó eleján azért ugrik át néhány menüpontot, mert ráfeküdtem a gombra
Ha lejön a fájl, akkor írjátok át a kiterjesztést *.wmv-re, máshogy nem tudtam felrakni

Klassz.

Fasza
Szerintem ne egy kerettel jelőld ki az aktuális ikont hanem tedd inverzé. Úgy látványosabb és még profibb lenne!

vagy nagyítsd ki egy kicsit, a többit meg "húzd" összébb, persze szépen, animálva

:worship::worship::worship::worship::worship::worship:Minden elismerésem! Ez nagyon überf@sza lett! És még mondják, hogy a sufnicuccok nem jók... A LEGJOBBAK!

Úgy néz ki sikerült áttörést elérnem. A következő lényeges beállításokat kísérleteztem ki.

Handshaking comXOnXOff
InBufferSize 32766
InputLen 1

Egyébként valaki, valamelyik fórumba azt írta hogy csak string formában képes a VisualBasic az adatokat fogadni. Nos ez nem igaz mert az InputMode beállítható bináris formára is.
Ami lényegesre rájöttem, hogy nem érdemes az InputLen-el variálni hanem 1-re kell beállítani.

Hi!
Nekiálltam áttervezni a nyákot. Egy oldalas lesz, de nem kell összevissza kötögetni, hanem egy 20-as meg egy 10-es szalagkábellel meg tüskesorral korrektül össze lehet kötni a modulokat. 3 Darabból fog állni. Egyenként kb 13*8 centis nyákok lesznek. Ezeket egymás fölé fogom elhelyezni. Az elsőn a memória és a címzés lesz. A másodikon az ADC és a ATmega. A 3.on pedig az analóg rész és az USB.
valahogy úgy fog kinézni ahogy a csatolmányban. Még így is sok átkötés kell, de legalább egyoldalas, midnen DIP foglalatos, úgyhogy kezdők is simán utánépíthetik majd. Lesz még hely egy logikai analizátor résznek is benne.

Jó
Csak az a bajom vele, hogy vannak olyan fóliaszigetek, amik csak a levegőben lógnak. Szerintem ez nem túl szerencsés, mert rengeteg zajt összeszedhet . Célszerű GND-re kötni
Én most az analóg részt tervezem, meg kéne építeni, hogy tovább tudjak haladni a digitális panellal


Mindenkinek a szkópjában lesz egy sajátosság

Azokat majd kijavítom, most csak az autokitöltést bekapcsoltam gyorsan.

ezt miben tervezted?? olyan mint amiket én csináltam régen psp-ben ,
tipp:
Ilyen nyákrajzokat meg néhány színből álló képeket amik eredetileg vektorosak (vagy azok lehetnének) célszerűbb gif-be vagy png-be konvertálni, mert veszteség mentes (ilyen esetekben) és kisebb is méretben, mint a jpg.:yes:

Sprint layout-ban terveztem, de még nincsen kész. Csak gyorsan kimentettem.

Tetszik a nyákterved.

Tegnap addig jutottam el hogy most már biztonságos az adatok lekérdezése a PIC-ről. File-be írattam az adatokat és ebből fog dolgozni. Akármikor újra meg lehet majd nyitni a mérési adatokat.
Eljutottam a legnehezebb részhez a Design-hoz.