Citat:
Ursprungligen postat av
ekonomisnigeln
Använder mig av försöker få kontakt med bluetooth genom "target remote" men den verkar inte ta emot mac-addresser. Hur ska jag gå tillväga? För det ska gå.
Jag vet inte riktigt vad du vill åstadkomma ?
Men antar att du menar ungefär det här:
Bluetooth tycks bara ha vissa användningsområden, tex file transfer och print-funktion och liknande.
Bluetooth har liksom inga generella funktioner, men det går kanske att tilldela den en nätverksadress ?
Så att den fungerar med TCP. Bluetooth kan dock fås att fungera som en generell seriell COM-port, men alla inställningar finns nog inte för en standard seriell port. Utan default är troligen RTS/CTS, och att det inte går att använda de andra.
Nåväl, ser man på Enhetshanteraren i Windows så får Bluetooth rätt ofta COM 11 som seriellt portnummer.
Du behöver alltså starta gdbserver på din remote maskin, länka den till COM 11
Och starta ditt remote-program.
På den lokala så startar du alltså gdb och ber den ansluta till din COM-port som du tilldelat din Bluetooth.
Alla källkodsfiler måste ligga i samma träd som ditt kompilerade program ligger i,
annars kan debuggern inte matcha kodraderna mot stegen i exen/binären.
Möjligt att du måste ha kopia på samma källkodsträd på din lokala maskin.
Lite underligt men jag har för mig att det var viktigt att filerna hade samma tidsstämpel på både den lokala och den remote maskinen. Man zippade alltså hela trädet, och packade upp det på sin lokala maskin.
Jag är inte säker på att den seriella portens hastighet räcker för det du vill debugga.
Tex om du har _Trace-utskrifter och skickar dem till debugfilen så hinner du kanske inte se alla raderna heller.
Här finns en del förklarat:
https://sourceware.org/gdb/current/o...onnecting.html
På en del Linux-distar kan man inte veta hur bra/dåligt Bluetooth fungerar. Du bör se till att Btooth är alltid påslagen om det finns någon energi inställning på denna. Brukar alltid vara ihopkopplat med det trådlösa WiFi-kortet (det är delvis samma kretskort).
Kom ihåg: Om du har ett jättestort men ändå "glest" källkodsträd så kan nog även gdb nästan frysa ifall källkodsträdet ligger på en långsam enhet.
Med "glest" källkodsträd menar jag filer som är ovidkommande, tex *.jpg som inte hör ihop med programmet.
Eller tex för stort sökdjup...
Detta fenomen har dykt upp på MSofts Visual Studio med tex långsamma NAS-enheter vid remote debugging.
Visual Studio har även den en möjlighet att debugga remote.
Om du har Linux på både local och remote så se till att Linuxen är uppdaterad och att du har gcc uppdaterad gällande alla headerfiler.
Var säker på att datorerna inte går i vänteläge eller sleep. Då får du ett helvete att få igång kommunikationen mellan gdb och gdbserver igen. Likadant om du tappar Btooth-förbindelsen för då får den börja om igen med handskakningsprocessen mm..
Kanske svårt att beskriva hur du ska göra här i enbart text. Kanske att något youtubeklipp finns ?
Finns nämligen en del roliga exempel på "skit bakom spakarna" som har debuggat debuggern istället för binären, och inte haft en aning om vilka kommandon de skrivit.
Kolla också datumet när tipset är upplagt, det gäller för övrigt allt som har med Linux att göra att det finns mycket som är föråldrat, obsoleta tips ute på nätet.
COM 11 är bara ett hypotetiskt COM nummer, annars är COM1 - COM4 de normala som varit med sen PC-DOS 3.*
Du kan antagligen bara använda ett COM nummer upp till COM255, Btooth täcker normalt inte fler enheter.
Du bör också se till Btooth inte accessar fler enheter än minimalt.
Lycka till !!
