Napi Qt okosság, avagy a -fast opció csodákra képes 

Van pár feladat aminek a végrehajtását szeretem elkerülni a számítógépemen. Ilyen például a Qt fordítás. Baromi sokáig tart, és végig üvegeli a a gépet. A gentoos "compile 5 hours to run 5 ns faster" filozófia pedig eddig még nem érintette meg a lelkemet.

Beágyazott szuttyok esetén nem mindig adatik meg az a lehetőség, hogy bináris csomagot használjon az ember. Így volt ez most is, amikor egy Friendlyarmos panelre kellett Qt-t varázsolnom. Az openembedded sajnos csak úgy képes Qt-t fordítani, ha az először lefordítja az x86-osat, majd az embeddedet. Ezt el kívántam kerülni, ezért 2 napig reszeltem a bitbake és az mkspec fájlokat, de végül feladtam.
Képtelen volt desktopon futó qmaket összehozni, így végül ezt a leírást használtam:

http://billforums.station51.net/viewtop ... p;p=44#p44

Illetve megspékeltem az opciókat ezekkel:


./configure -embedded arm -xplatform qws/linux-arm-g++ -prefix /usr/local/Qt -little-endian -no-qt3support -opensource -no-accessibility -no-webkit -no-script -no-javascript-jit -no-scripttools -nomake examples -nomake demos -nomake docs -nomake translations -qt-mouse-tslib -DQT_KEYPAD_NAVIGATION -reduce-relocations -fast


A fordítás egy Intel T7400 C2D-n kevesebb mint 20 perc alatt lezajott.

Öröm van a köbön.
[ hozzászólás ] ( 1 megtekintés ) [ 0 trackbackek ] permalink ( 2.9 / 155 )
Napi Qt okosság: avagy mit csináljunk, ha a rajzolt QGraphicsItemet nem lehet mozgatni 

A szituáció:

Adott a QGraphicsView aminek a mousePress, mouseRelease, és mouseMove memberjeit overrideolom.
A pressEventben létrehozok egy RockItemet, ami mozgatható, és egy QPolygont rajzol. A moveEventben, amennyiben rajzolás van ehhez az adott RockItem polygonjához fűzöm az event->pos() pontot. A releaseben pedig befejezem az adott elemet (innentől polygont nem polylinet paintel.

A probléma:
Az így letett elemek nem mozgathatóak. Amennyiben a konstruktorban hozunk létre ilyeneke pld. egy QSettingsből, akkor lehet őket mozgatni. Amennyiben mozgatjuk a legutoljára rajzolt RockItemen kívül valamelyik elemet, úgy hogy a sceneRect megváltozzon a friss elem is mozgathatóvá válik. Ha a releaseEventben a setSceneRect()-et hívok nem történik módosulás. A scene frissítésével ugyanez a helyzet.

A megoldás:
RTFM, avagy barátkozás a Qt doksival:
http://doc.trolltech.com/4.6/qgraphicss ... ethod-prop
Akinek ez nem megy annak marad a megoldás mint nekem a googlecodesearch :)
[ hozzászólás ] ( 1 megtekintés ) [ 0 trackbackek ] permalink ( 3 / 180 )
IBM STB02501 pinout 

I have managed to generate a pad layout picture for the IBM STB02051Set top Box Soc from this BSDL file.



I will desolder this CPU from my Amino Aminet 110 to trace the JTAG pins.
[ hozzászólás ] ( 12 megtekintés ) [ 0 trackbackek ] permalink ( 2.9 / 152 )
Broadcom BCM6348 pinout 

I have generated the pinout image for the Broadcom BCM6348 BGA package:



The input source was:
http://www.f-x.fr/wikini/wakka.php?wiki=Bcm6348PinOut

The generation was done with a small Qt program:
http://balubati.atw.hu/blog/images/pinoutviewer.tar.gz

A pinout image for a smaller package can be found here:


http://pudeev.livejournal.com/37410.html


[ hozzászólás ] ( 3 megtekintés ) [ 0 trackbackek ] permalink ( 3 / 140 )
Netgear DG834GT USB host - Successful end of the story 

I have put a dot to the end of a long story.
About three years ago I have get an Sky networks rebagged Netgear DG834GT from my friend Azbeszt.

First of all I have disassembled it, and realized that it has an unsoldered USB port. I have placed the soldered the missing components, (connector, voltage regulator, and the D+ D- protector resistors), but it did not detected any USB devices. I have talked with other people who owns a BCM63XX based routers, and one of them have done this trick on a Comtrend router:

http://img530.imageshack.us/img530/2545 ... 6v2xp2.gif

He notified us, about he had to pull up a pin to enable the port.
I have populated all of the unpopulated pullup resistors place, but I have not succeded.

As the time went on I have purcashed two other unit.
So I have decided to desolder a CPU one of them.
The desoldering was done in my friend's lab.

According to this pinout:
http://www.f-x.fr/wikini/wakka.php?wiki=Bcm6348PinOut/

Only the D+ D- and the USB_FLT was routed out from the BGA.
I have traced the USB_FLT trace, but I have not found the other end of the stripe. It does not seems to be connected to anywhere with desoldered CPU. With populetated CPU it has ~90KOhm resistance to the ground. Fortunatelly the trace is connected to an stripe in the inner layer with a trough hole via. So very carefully it is possible to solder a wire to the via.

The via is located in the half way between C702 and C423.
To locate it flip your board to face to the soldering side of the PCB. Rotate it to have the LAN connectors closer to you.


This area will be in the upper side of it:


There is a drawing which via is it:


(please note that this is not scale drawing)


Solder a thin Cuz wire to it and connect it to the 3V3. The easiest place to find the 3V3 is the serial connector (J503) third pin.
Connect to it with an 2K resistor.

Power up your device, and do
cat /proc/bus/usb/devices

And you should see your device details there.
Or you can use the lsusb (from usbutils package).

The additional information about the hack's details could be found here:
http://wiki.openwrt.org/oldwiki/openwrt ... ar/dg834gt

Currently it works for me with an r18196 of the trunk. I will try the bleeding edge version asap.
[ 1 hozzászólás ] ( 23 megtekintés ) [ 0 trackbackek ] permalink ( 2.9 / 198 )

<< <Előző | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | Következő> >>

 
számláló