This patch adds support for the toolchains, provided by
KEIL:
* http://www.keil.com/c51/
* http://www2.keil.com/mdk5/
Now QtC's compiler page have additional 'KEIL' selector
which allows to user to choose a desired C/C++ compiler
from set of the KEIL toolchains.
In this case the QtC will tries to detect the compiler ABI,
in which was added the additional OMF binary format type
which is produced by C51 compiler:
* http://www.keil.com/support/docs/93.htm
Currently are supported the following architectures:
* ARM
* 8051 (aka MCS51)
In addition, were added changes to the QBS Project Manager
plugin to make it work with QBS 1.13 (where previously were
added support for KEIL toolchain).
So, now do not need to do an additional 'hacks' into the
'qbs.toolchain' property of QtC KEIL kit.
Following features are not implemented yet:
* Debugger integration.
* Compile output parsers.
* Toolchains auto-detection.
* Support for C251, C166 architectures.
Change-Id: If0cc18d22b7dc0e5ce9096bdb3dc699ee3edde66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This patch adds support for the toolchains, provided by
IAR Embedded Workbench:
* https://www.iar.com/iar-embedded-workbench/
Now QtC's compiler page have additional 'IAREW' selector
which allows to user to choose a desired C/C++ compiler
from set of the IAR EW toolchains.
In this case the QtC will tries to detect the compiler ABI,
in which was added the additional MCS51 architecture (which
includes all family for Intel x8051 MCU's):
* https://en.wikipedia.org/wiki/Intel_MCS-51
Also, now the ABI has an additional proprietary UBROF binary
format type which is produced by some of IAR EW compilers:
* https://netstorage.iar.com/SuppDB/Public/UPDINFO/011281/ew/doc/EW_MigrationFromUBROF.pdf
* https://netstorage.iar.com/SuppDB/Public/UPDINFO/013556/ew/doc/UBROFRecordTags.pdf
Currently are supported the following architectures:
* ARM
* 8051 (aka MCS51)
* AVR
In addition, were added changes to the QBS Project Manager
plugin to make it work with QBS 1.13 (where previously were
added support for IAR toolchain).
So, now do not need to do an additional 'hacks' into the
'qbs.toolchain' property of QtC IAR kit.
Following features are not implemented yet:
* C-SPY debugger integration.
* Compile output parsers.
* Toolchains auto-detection.
Change-Id: I4a7794efe8dc15652f5a7f1f3dd966c367943484
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Get closer to a uniform pattern of code layout (public/private,
pimpl naming...)
Change-Id: If2bc6dcee3df9127274f479b4ebc270d283dcb65
Reviewed-by: Xing Xiong
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Except for the DesktopDevice, which is kind of special. Also try
a bit to make (and partially fail at doing so) naming and code
structure (#include, use of namespaces) more similar to each other.
Change-Id: I9fe266e706b72c14f59ff03ca1ae02dba3adcc71
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Since the need for code reuse is gone due to the recent changes
in the RunConfiguration base infrastructure, it's easier and less
code to completely separate the cases.
Change-Id: I3fc558ea60e02f34b50869d4b55a43a6360e9208
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Purely mechanical, no visible/functional changes intended or expected.
- have one file pair for each set of config/factory/widget
- de-pimpl BareMetalRunConfigWidget, it's very local now
- use new wrapWidget convenience function for run config widget setup
Change-Id: Icd0df2bc7e206d6bf15d722f7eaa3b9fbee0b0fa
Reviewed-by: Alexander Drozdov <adrozdoff@gmail.com>
Reviewed-by: hjk <hjk@qt.io>
... into two, each handling one type of RunConfiguration only.
This is temporary to allow easier removal of boiler plate.
Change-Id: I0c8427eaeef07dff06dce7824a87b222f8f05019
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The user has only one possibility to setup of the remote GDB server
when a new device is created (or to modify it for existing device).
It is possible only in the host/port fields for connection to the
GDB server. It is a little inconvenient for the user. If the user
wants to use other configuration of the GDB server, then need every
time to edit the current configuration.
Improving this it is introduction a new concept with a new entity
named as "GDB server provider". Now to the device debugging purpose
the user can choose any of the GDB provider from the list (by analogy
with toolchain and so on). Each configuration of GDB provider is
created by the user manually on the new "GDB Server Provider" options
page. This can be made before or after creation of device.
A GDB server provider can work in three startup modes (depends on
implementation of concrete provider):
1) NoStartup mode.
This means that we do not want to startup a provider, we just trying
to connect to the already started GDB provider server. This mode uses
the TCP/IP connection with manually specifying of remote host and port.
2) StartupOnNetwork mode.
This means that we want to launch of the GDB provider automatically
before connect to it in process of remote debugging. This mode also
uses the TCP/IP protocol. In addition to it, a GDB provider can has
additional options which are contains a paths to provider executable
file, to configuration files and so on (it is depends on concrete
provider implementation). This mode (with NoStartup) covers about 90%
of usecase, and is supported by most set of the GDB server providers.
3) StartupOnPipe mode.
This is similar to StartupOnNetwork mode and we also automatically
starts the GDB server provider before debugging. But in this case is
used the Pipe mode instead of TCP/IP. Not each of the GDB provider
can support debugging via pipes.
This patch has concrete implementations for a following set of the
GDB server providers:
* "Default" provider which supports only the NoStartup mode.
* "Open On-Chip Debugger" (http://openocd.sourceforge.net/)
provider which supports all modes.
* "STLinkUtil" (https://github.com/texane/stlink)
provider which supports NoStartup and StartupOnNetwork modes.
Tested on Windows and Linux with:
* target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2
* provider: OpenOCD v0.8.0 (tested on Windows and Linux)
* provider: STLink-Util (tested on Linux only)
* toolchain: ARM GCC v4.9.2
* debugger: GDB v7.8.1 (with Python support)
* QtCreator with QBS project
Task-number: QTCREATORBUG-13686
Change-Id: I59c775d91b0a4227d931188879850c536290e1ba
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com>
Reviewed-by: hjk <hjk@theqtcompany.com>
Remove usage of the Q_EXPORT_PLUGIN macros, which do not exist in Qt 5.
Change-Id: I678c3cf10b9c5d5c1b9f252b0ecd1c97dc810a47
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
The cleanup goes by the comments found in
https://codereview.qt-project.org/#change,65366,patchset=6
It removes code and comments identified as unneeded.
It also further minimizes the impact on code outside the
plugin dir.
Change-Id: I22bfe9654d0fb6e0bb8f0018ecbe326cda804223
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
This patch adds the baremetal plugin. The baremetal plugin is for
debugging small targets with hardware debugger where the remote linux
plugin does not fit. It adds a new kit and device class of type
baremetal. The device allows entering custom gdb commands. Currently only
qmake builds are possible. To use this with smaller devices without qt
a fake-qt installation is needed. CMake and qbs is currently not
supported.
Change-Id: I86816f897a2e9ed8b95e3184387969cedf8a14d7
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
