Hi, I was greatly interested in the talk you gave at FOSDEM this weekend. Many thanks for that! 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 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? (Presumably as a start there would need to be a new XML configuration file, as you mentioned in the talk? Also I'm very interested in I2C driver support) Thanks! Alex Lennon http://www.dynamicdevices.co.uk
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...
On 03/02/2014 15:14, Niklas Hauser wrote:
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.
Understood
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.
OK, many thanks Niklas. I am away from the end of the week for 10 days or so but will pick this up when I'm back in the office
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.
Will do
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] .
Hopefully life should be slightly easier for me as currently the requirement on us is for I2C slave only. I've spotted some LPC17xx example code for I2C slave so will have a play with this in the meantime
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).
Great thanks!
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... _______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi Alex, On 02/03/2014 03:25 PM, Alex J Lennon wrote:
On 03/02/2014 15:14, Niklas Hauser wrote:
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.
Understood
Actually (and what Niklas probably isn't aware of) one of my projects for our robotics club is using the lpc11c24 microcontroller. Thus I'll need to get at least the Gpio, the Uart and the CAN driver running on this platform within the next couple of months.
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.
As Niklas said the startup script and all cortex specific stuff is shared and can be found here: https://github.com/roboterclubaachen/xpcc/tree/develop/src/xpcc/architecture... In order to use the interrupts on your controller you will need to add a vendor- (or rather part-) specific interrupt table.
(Presumably as a start there would need to be a new XML configuration file, as you mentioned in the talk?
For the xml configuration file you can have a look at the one for the lpc11c24: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture... I created that one by hand in order to test the drivers. That is the reason why I only added the pins that I needed to the gpio driver. When you start with a new architecture it is always a good idea to build up the first device file step by step. When your code works you can always check and see if there is a source that you can use in order to generate device files from.
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.
For a rudimentary linker script you can just copy the one for the lpc11c24 and change the memory sizes. A quick look at the memory layout of your chip might be helpful in case NXP decided to go with different starting addresses. The linker scripts go into the linker directory and need to be referred to in the xml device file. https://github.com/roboterclubaachen/xpcc/tree/develop/src/xpcc/architecture... Startup stuff is covered by the cortex core driver that I mentioned earlier. Depending on your chip you might have to handle some specific cases, like setting the Interrupt Vector Controllers vector table address correctly. I had a quick look at the LPC176x/5x User manual and it seems like NXP did not screw up the GPIO quite as badly as they did with the lpc11c24 where they had to dedicate one page in the manual for every pin, because they all work differently. So a GPIO driver could probably be implemented in about two or three days (by someone who is new to xpcc). Also you will need a clock driver if you do not want to be stuck with the startup frequency. For this you can have a look at the implementation for the lpc11c24: https://github.com/roboterclubaachen/xpcc/tree/develop/src/xpcc/architecture... This can be a little bit hard to grasp because it uses Jinja2 Templates as well as C++ quite extensively. However, feel free to ask questions on the mailinglist if you are stuck. One advice I can give you is to first create some code that sets up the clock frequency and outputs that on one of the pins. As soon as his works you can try to move this to an xpcc driver, or maybe integrate with the existing driver for the lpc11c24. Short note on the subject of driver names: If there is only one driver (e.g. for the lpcs we only have drivers for lpc11c24 at the moment) we normally name it as short as possible. That's why all the drivers for the lpc11c24 are named `lpc`. If you discover, that you cannot make the existing lpc drivers work for the lpc1768, you should at a new driver called `lpc17`, because it can be assumed (or at least hoped for) that it will work for all NXP microcontrollers of the lpc17 series.
I will write a more detailed wiki entry and link it here for the benefit of all. Give me till end of this week.
That is a great idea. Alex: if you want you can have a look at the things I mentioned earlier in this mail and ask on the mailing list if or rather when there are additional questions. That might help in collecting topics that the wiki article should address. Kevin
On 03/02/2014 19:00, Kevin Laeufer wrote:
Hi Alex,
Hi Kevin, many thanks for the detailed information
On 02/03/2014 03:25 PM, Alex J Lennon wrote:
On 03/02/2014 15:14, Niklas Hauser wrote:
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.
Understood
Actually (and what Niklas probably isn't aware of) one of my projects for our robotics club is using the lpc11c24 microcontroller. Thus I'll need to get at least the Gpio, the Uart and the CAN driver running on this platform within the next couple of months.
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.
As Niklas said the startup script and all cortex specific stuff is shared and can be found here: https://github.com/roboterclubaachen/xpcc/tree/develop/src/xpcc/architecture...
In order to use the interrupts on your controller you will need to add a vendor- (or rather part-) specific interrupt table.
(Presumably as a start there would need to be a new XML configuration file, as you mentioned in the talk?
For the xml configuration file you can have a look at the one for the lpc11c24: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture...
I created that one by hand in order to test the drivers. That is the reason why I only added the pins that I needed to the gpio driver. When you start with a new architecture it is always a good idea to build up the first device file step by step. When your code works you can always check and see if there is a source that you can use in order to generate device files from.
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.
For a rudimentary linker script you can just copy the one for the lpc11c24 and change the memory sizes. A quick look at the memory layout of your chip might be helpful in case NXP decided to go with different starting addresses. The linker scripts go into the linker directory and need to be referred to in the xml device file. https://github.com/roboterclubaachen/xpcc/tree/develop/src/xpcc/architecture...
Startup stuff is covered by the cortex core driver that I mentioned earlier. Depending on your chip you might have to handle some specific cases, like setting the Interrupt Vector Controllers vector table address correctly.
I had a quick look at the LPC176x/5x User manual and it seems like NXP did not screw up the GPIO quite as badly as they did with the lpc11c24 where they had to dedicate one page in the manual for every pin, because they all work differently. So a GPIO driver could probably be implemented in about two or three days (by someone who is new to xpcc).
Also you will need a clock driver if you do not want to be stuck with the startup frequency. For this you can have a look at the implementation for the lpc11c24: https://github.com/roboterclubaachen/xpcc/tree/develop/src/xpcc/architecture...
This can be a little bit hard to grasp because it uses Jinja2 Templates as well as C++ quite extensively. However, feel free to ask questions on the mailinglist if you are stuck. One advice I can give you is to first create some code that sets up the clock frequency and outputs that on one of the pins. As soon as his works you can try to move this to an xpcc driver, or maybe integrate with the existing driver for the lpc11c24.
Much appreciated. I'm not really keen on bitbanging the I2C as I'd prefer to make use of an interrupt driven driver that optimally utililises the built in I2C module(s) in the part
Short note on the subject of driver names: If there is only one driver (e.g. for the lpcs we only have drivers for lpc11c24 at the moment) we normally name it as short as possible. That's why all the drivers for the lpc11c24 are named `lpc`. If you discover, that you cannot make the existing lpc drivers work for the lpc1768, you should at a new driver called `lpc17`, because it can be assumed (or at least hoped for) that it will work for all NXP microcontrollers of the lpc17 series.
OK thanks
I will write a more detailed wiki entry and link it here for the benefit of all. Give me till end of this week.
That is a great idea. Alex: if you want you can have a look at the things I mentioned earlier in this mail and ask on the mailing list if or rather when there are additional questions. That might help in collecting topics that the wiki article should address.
Will do - thanks again! Cheers, Alex
Kevin _______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
participants (3)
-
Alex J Lennon -
Kevin Laeufer -
Niklas Hauser