Qt Creator 4.3.1 is included in the Qt 5.9.1 offline installer packages and available via the online installer.

Qt Creator 4.3.1 is included in the Qt 5.9.1 offline installer packages and available via the online installer.

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.

| 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 |
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
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:
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:
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: