Qt Creator 4.3.1 is included in the Qt 5.9.1 offline installer packages and available via the online installer.
Archivi categoria: Qt
Qt 5.9.0 for Application Development
Qt Developer Days 2013
L’evento si è tenuto a Berlino il 7-9 ottobre e si terrà a San Francisco il 6-8 novembre 2013.
Dal prossimo anno garantiremo la nostra presenza a questi ed altri fondamentali eventi per lo sviluppo software. Infatti praticamente l’intera nostra attività si basa sulla sistemistica Linux e lo sviluppo Qt.
Lightning Talks
Title | Presenter |
---|---|
Red Herring – QML nd HMTL5 | Till Adam |
QML gotchas | Aurindam Jana |
The Raspberry Pi Camera Module | Jeff Tranter |
Using QVariant printing capabilities along with some syntactic sugar for simple string formatting | John Melas |
Quick and physical (adding simple mechanical interactions to your QML) | Vladimir Moolle |
Title | Presenter |
---|---|
The QML runtime | Alan Alpert |
CalendarApp (QtOnAndroid) and DesktopApp (Qt) using GnuPG and sync via Drupal Services | Christoph Hagemeyer |
Banana accounting spreadsheet software | José Del Romano |
How do we write SQL queries in 2013? | Andras Mantia |
How to use Facebook, Ads, In-App Purchases and Analytics in mobile Apps with Qt | Christian Feldbacher |
Title | Presenter |
---|---|
fullmo Kickdrive – Qt Quick in Industry Automation | Oliver Heggelbacher & Frankie Simon |
Remote Debugging With GammaRay | Volker Krause |
Data Visualization in 3D | Sami Makkonen |
Easy Qt Development on embedded devices with Hemera | Dario Freddi |
Qt Quick Enterprise Controls | Hanne Linaae |
Title | Presenter |
---|---|
Cheap radio control for electronic timing systems using Qt, BlackBerry 10, and Raspberry Pi | Kalle Dalheimer & Benoit Dumas |
What’s new in QDateTime and QLocale | John Layt |
Fancy video effects with QtGStreamer and Qt Quick 2.0 | Mathias Hasselmann |
Implementing moc using clang’s libraries | Olivier Goffart |
QtCreator for BareMetal development | Tim Sander |
How to create a CoverFlow in QML | Igor Grivko |
Title | Presenter |
---|---|
Accessing Android System Services with Qt for an Aircraft | Walter Roth |
Command-line parsing in Qt | David Faure |
QML’s many faces | Kevin Krammer |
News from Inqlude, the Qt library archive | Cornelius Schumacher |
Extending Your Qt Widget Desktop Application as a Back-end Service for Web and Mobile Devices | Cameron Kiddle |
LABijk: bus di comunicazione.
Il progetto LABijk, per la complessità strutturale che lo caratterizza, richiede un’attenta riflessione sulle sue scelte di fondo: il microserver, l’architettura di questo, i microcontroller, lo standard verso attuatori e sensori, i bus di comunicazione, i protocolli di sicurezza, e molto altro.
In uno sviluppo aperto andremo a classificare in modo ordinato ogni punto citato ed altri ritenuti indispensabili.
Continuiamo il nostro dibattito soffermandoci a riflettere sul/i bus di comunicazione da adottare tra il microserver e i dispositivi i al primo livello .
E’ ovvio pensare ad ethernet, ma pesano le seguenti argomentazioni
- impegnativo in termini infrastrutturali, switch POE, cablaggi strutturati, …
- in termini di microcontroller comporta costi ed elettronica non trascurabili
- Arduino in relazione alle porte ethernet e POE non è così interessante, anche per costi
- il codice TCPIP per Arduino è piuttosto debole
- i dispositivi del primo livello dovrebbero quindi essere schede ARM quali RaspberryPI
- RPI scalda, richiedono risorse memoria enormemente superiori di Arduino, quindi usa tecnologie fragili come SD
Quindi ethernet è solo per usi specifici e vedrebbe Arduino fuori gioco, precludendo tutta la gestione dell’elettronica in stile Arduino.
I vecchi bus seriali tipo RS232 sono lenti soprattutto se il dispositivo centrale, in questo caso il micorserver, fa pooling tra i periferici. Ricordiamo che una gestione ad eventi che parta dalle periferiche è esclusa perchè si perde il controllo delle periferiche stesse.
Consideriamo il bus USB:
- è stabilissimo, robustezza derivata dall’enorme impiego
- tutti lo usano a tutti i livelli
- è uno standard: chiunque sa quale sia un cavo USB
- Arduino con il suo primo microcontroller a bordo implementa la comunicazione USB in modo eccellente
- i costi sono praticamente abbattuti
- test di pooling per mesi da microserver verso Arduino via USB alla velocità massima hanno visto una precisione assoluta
- il microserver, centro stella, può non avere seriali, ma le macchine attuali abbondano di porte USB
- il cavo USB porta anche l’alimentazione, sufficiente per un Arduino Uno SMD con un po’ di elettronica, quindi abbiamo gratuitamente l’equivalente della POE
- la massima lunghezza del cavo USB è di circa 5 metri, ma si possono usare estensori USB via cavo tipo rete per lunghezze pari a 50 metri. Il costo di un’estensione è di circa una decina di euro e di cavo standard rete con RJ45, che è molto meno di uno splitter POE
Linux permette il controllo preciso delle porte USB, test verso Arduino, attraverso USB, mediante programma compilato C++ in pooling mostrano il funzionamento ininterrotto in mesi.
Un aspetto delicato da capire per bene è l’adozione, da parte del gruppo di progettazione Arduino, del reset in caso di perdita di connessione del BUS USB. Aspetto che si rivela invece estremamente utile per il recupero eventuale di una periferica fuori controllo: basta chiudere e riaprire la porta USB.
I microcontroller i di primo livello, connessi al microserver centrale tipicamente mediante USB, devono comunicare con gli altri ij del secondo livello.
Le seguenti osservazioni portano alla migliore scelta per queste tratte:
- serve un bus estremamente robusto
- che utilizzi cavi comuni, per dire quelli utilizzati dell’impiatistica per i sistemi di allarme, trasportando anche l’alimentazione
- che permetta tratte fino a 1200 metri
- che sia preciso, simmetrico
- che permetta di collegare allo stesso bus di pochi fili molte periferiche
- che apaprtenga ad uno standard ampiamente utilizzato.
Quindi la scelta è il bus RS485.
Le ultime considerazioni sono relativa all’ultima tratta ovvero dai dispositivi ij a quelli ijk, che sono sensori, attuatori ed elettronica varia:
- le schede prototipali sono da escludere, possono essere tollerate in particolari utilizzi
- rafforzando il punto precedente: le attività di saldatura di componenti, soprattutto se superficiali, sono, tranne in specifici casi, da escludere
- serve uno standard che porti i pin delle schede Arduino, tipicamente Uno SMD, ad insiemi di connettori, tra le molte proposte nel mercato, la forse più ricca è lo standard Grove
- Grove implementa bus a 4 fili: due alimentazioni e due pin di segnali
- il bus Grove è facilmente utilizzabile o mediante cavi patch già pronti oppure estendendo la connessione con cavo tipo quelli adottati nel sistema di sicurezza, ovvero lo stesso che abbiamo indicato per la connessione dei dispositivi i di primo livello i con i dispositivi ij di secondo livello.