Hi,
I was greatly interested in the talk you gave at FOSDEM this weekend. Many thanks for that!
I forgot to add that the features we talked about are only available in our develop branch and several feature branches. There is a lot of microcontroller code lying around, which we still have not yet had time to refactor in the format that we need it. While the interfaces are pretty much done, we still need to code the platform-specific implementation for those and this takes time. We currently focus on all STM32F0 through STM32F4 devices, as these are the ones we use most frequently.
We have a project in the works based around an LPC1768 part. Looking at the wiki / git repo I see some support for the LPC1343, although not the LPC1768, and both parts seem to be based on an ARM Cortex-M3
In the old master branch, a lot more architectures were “sort of” supported. We had some ARM7, AVR32 and also LPC code in there.
I was wondering if there is any out-of-the-box support for the LPX17xx series, or if you could comment on what would be involved for me to add this?
No out-of-the-box support, sorry. There is old code for the GPIO of the LPC17xx [1], but there are no device files and it is in the wrong place and format. For most peripheral drivers we reverted back to the CMSIS implementations. However, the hard stuff like startup scripts and build system integration are done, we just have not used an LPC in our robots since we started the restructuring.
(Presumably as a start there would need to be a new XML configuration file, as you mentioned in the talk?
In short: at minimum there needs to be a new device file and a good implementation of GPIO. You would also need a startup and linker script, but we already have some. I will write a more detailed wiki entry and link it here for the benefit of all. Give me till end of this week. Until then you can have a look at the current format of uncommitted device files [2] to get an idea of what is required. They must be copied into /xpcc/src/xpcc/architecture/platform/xml/ . Be aware that only the committed device files have been tested, the others have only been generated with best intentions.
Also I'm very interested in I2C driver support)
I recommend to use the SoftwareI2cMaster with the GPIO classes on the LPC, because writing driver code for a hardware I2cMaster is a lot of work and should only be debugged with a logic analyser. The interface and documentation for I2cMaster and others can be found here [3]: The implementations are then in [4] . The external hardware drivers can be found in: /xpcc/src/xpcc/drivers/ . For I2c, we provide a delegate-like implementation, where the driver is asked by the I2cMaster what to do next in a asynchronous way. Have a look at the implementation of the TMP102 [5] for a usage with the I2cAdapter (the comfortable delegate version) and an I2c Eeprom implementation with manual callback implementation [6] (more options were needed to do a "write(eeprom address) - write(eeprom data) - read” operation). Cheers, Niklas [1]: https://github.com/roboterclubaachen/xpcc/tree/develop/src/xpcc/architecture... [2]: https://www.dropbox.com/s/mocxy5jbrth68ad/xml.zip [3]: https://github.com/roboterclubaachen/xpcc/tree/develop/src/xpcc/architecture... [4]: https://github.com/roboterclubaachen/xpcc/tree/develop/src/xpcc/architecture... [5]: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/driver/tempe... [6]: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/driver/stora...