Google Summer of Code
Buongiorno Michal I'd like to congratulate with you about the acceptance of the NuttX project "NuttX Support for RapidControl Applications Development with pysimCoder" a the GSOC! I'm very excited to share with you my experience during this project, and I hope that your contribution can help in develop and sharing pysimCoder with the community. I think that we can organize ASAP a video meeting, perhaps with Prof. Pisa and Brennan Ashton. Best regards Prof. Roberto Bucher
[ANNOUNCEMENT] NuttX Participating in Google Summer of Code
Hey everyone, We had multiple students this year propose projects for the NuttX project under Apache to Google Summer of Code (GSOC), and I'm excited to share one of them was accepted. Michal Lenc will be working on his project titled: NuttX Support for Rapid Control Applications Development with pysimCoder https://summerofcode.withgoogle.com/projects/#4867567685992448 Michal has already been contributing to the project and I am really excited to see what comes from this effort. We have a few formal mentors already but please welcome and help him out, as he works with the project over this summer. --Brennan
Re: Debug nuttx port with IAR
IAR support was, apparently, working in May/August of 2016 when it was incorporated, but I am not aware of anyone that has used it since then. Support was included in the repository for the STM3220G-EVAL (and for a couple of other STM32 boards), but was removed in November 2017 because it was unused and a maintenance problem. It should be possible to recreate that support with the instructions that you found in the stm3220g-eval README file. Unfortunately, no one will be able to help you now other than the original author of the IAR support (Aleksandr Vyhovanec) but he is no longer actively participating in the NuttX project. So I think you are the expert now! For reference, you can see what was removed here: https://bitbucket.org/patacongo/obsoleted/src/60ec01456d8b09f5b813a5fd8865cdbd5a0ccc20/ChangeLog#lines-357 https://bitbucket.org/patacongo/obsoleted/src/master/nuttx/configs/stm3220g-eval/ https://bitbucket.org/patacongo/obsoleted/src/master/Patches/Remove-stm3220g-eval-ide-2017-11-16.patch That is, of course, all available in the GIT history as well. On 5/17/2021 11:56 AM, Bhargav Shah wrote: Hi, I am trying to port nuttx to LPC54018 IoT module. I am able to compile port. Now, I want to flash/load binary to the device using IAR. Tried steps documented here :https://github.com/robbie-cao/nuttx/blob/master/configs/stm3220g-eval/README.txt Did not work. Can anyone help me with steps to debug nuttx wth IAR ? Thanks in advance.
Debug nuttx port with IAR
Hi, I am trying to port nuttx to LPC54018 IoT module. I am able to compile port. Now, I want to flash/load binary to the device using IAR. Tried steps documented here :https://github.com/robbie-cao/nuttx/blob/master/configs/stm3220g-eval/README.txt Did not work. Can anyone help me with steps to debug nuttx wth IAR ? Thanks in advance. -- Regards, Bhargav Shah
Re: Thread creation in Pony Mail Client
Hi Reto, Are we facing some issue with Apache mailing list? He is not the first person to report issues recently. BR, Alan On 5/17/21, Reto Gähwiler wrote: > Hey there, > > I recently created a new thread and opened it directly inside of the Pony > Mail web-client. This was the previous Tuesday or Wednesday (11.5. or > 12.5.2021). The thread is still not visible in the mailing list and I am > wondering whether it was published, waits for approval or vanished in the > void. Any Idea? > > I did so in the past and it also took a while till it would be visible. But > never that long, what could be the reason of that behaviour? > Unfortunately, in this case I would have to retype / think the handed in > content which was about a FAT32 issue we are facing. > > Thanks for your help on this problem, > > Reto >
Thread creation in Pony Mail Client
Hey there, I recently created a new thread and opened it directly inside of the Pony Mail web-client. This was the previous Tuesday or Wednesday (11.5. or 12.5.2021). The thread is still not visible in the mailing list and I am wondering whether it was published, waits for approval or vanished in the void. Any Idea? I did so in the past and it also took a while till it would be visible. But never that long, what could be the reason of that behaviour? Unfortunately, in this case I would have to retype / think the handed in content which was about a FAT32 issue we are facing. Thanks for your help on this problem, Reto
Re: how to handle backwards compatibility?
Hi Frank-Christian,
Third option sounds better, since the difference is only the number of outputs.
You don't need to preserve the old pca9635pw_register(), you can
change it directly to pca963x_register() and change all the boards
that use the pca9635pw_register() to pca963x_register(...,
TYPE_PCA9635/MODEL_PCA9635).
BR,
Alan
On 5/17/21, Frank-Christian Kruegel wrote:
> Hi.
>
> I'm writing several drivers for my custom hardware. One is for a PCA9633
> LED driver. I can use the pca9635pw driver for this and modify it so it
> can be used with PCA9633 (4 outputs), PCA9634 (8 outputs), and PCA9635
> (16 outputs) by adding an additional parameter to the driver initalize
> function. However, this would break existing code.
>
> Since I'd like to give my work back to the community I'd like to ask how
> I should handle this situation:
>
> - clone the existing driver and modify it and keep the original driver
> for existing projects
> - modify the existing driver and ignore the compatibility issues
> - provide a new pca963x_register(..., type) and add something like
> int pca9635pw_register(...)
> {
>return pca963x_register(..., TYPE_PCA9635);
> }
>
> What is the preferred way?
>
> Frank-Christian
>
how to handle backwards compatibility?
Hi.
I'm writing several drivers for my custom hardware. One is for a PCA9633
LED driver. I can use the pca9635pw driver for this and modify it so it
can be used with PCA9633 (4 outputs), PCA9634 (8 outputs), and PCA9635
(16 outputs) by adding an additional parameter to the driver initalize
function. However, this would break existing code.
Since I'd like to give my work back to the community I'd like to ask how
I should handle this situation:
- clone the existing driver and modify it and keep the original driver
for existing projects
- modify the existing driver and ignore the compatibility issues
- provide a new pca963x_register(..., type) and add something like
int pca9635pw_register(...)
{
return pca963x_register(..., TYPE_PCA9635);
}
What is the preferred way?
Frank-Christian
