Re: STM32F103x port
Maciek Borzecki <maciek.borzecki@...>
Hi,
I've uploaded another patchset. Some of the patches have only gone through updates. Specifically clock_control and the base st_stm32 tree patch. I've decided to keep the RCC driver MCU specific. I'm not sure there's a nice and clean way of organizing this so. I think that the device name is unfortunately the only common part we can have for STM32 families, and so the device is initialized using STM32_CLOCK_CONTROL_NAME. GPIO and pinmux drivers have gone through a major change. I've tried to have a common base for GPIO and pinmux drivers, while proving the SoC specific functionality within arch/arm/soc/st_stm32/stm32f1 tree. The way it's implemented, the driver headers (gpio_stm32.h and pinmux_stm32.h) declare a couple of functions that need to be implemented by the soc integration. The divergence in register contents between, STM32F1 and STM32F4 as well as the approach for alternate function setup is too large to my liking. I think that callig SoC specific integration is a good compromise and would allow to keep the code maintainable. There is a chicken and egg problem with the GPIO and pimux, namely the common GPIO diver without the pinmux patch. I did not want to squash the code into one large patch to keep the things civil. Just a thing to remember, that these would have to be merged at the same time. Since I got my Nucleo-64 F103RB, I've added the config for this bard as well. The 'disco' sample has also been updated to be directly usable on the Nucleo board rather than the obscure STM32 MINI A15. I've also added 2 changes (709, 710) that will be unnecessary. A similar fix from Daniel K has been posted. Once that is merged 2 master I'll just rebase skipping my 2 patches. New Changes: https://gerrit.zephyrproject.org/r/709 arch/arm/cortex_m: move fallback NMI handler to common Cortex-M https://gerrit.zephyrproject.org/r/710 arch/arm: move NMI_INIT() helper macro to cortex_m common header https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move quark_se entries to separate file https://gerrit.zephyrproject.org/r/712 clock_control: extend API with clock rate query operation https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement GPIO support https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement STM32 pinmux integration https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new board Updated Changes: https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce STM32F1x SoC family https://gerrit.zephyrproject.org/r/646 clock_control/Kconfig: fix quark_se dependencies https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x: introduce new driver for STM32F10x RCC https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO registers mapping https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common driver for STM32 pinmux https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver for STM32 UART https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver for STM32 GPIO https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add new board https://gerrit.zephyrproject.org/r/653 samples/disco: add 'disco' sample program -- Maciek Borzecki
|
|
Re: [RFC] Sensor API
Dmitriy Korovkin
On Thu, 3 Mar 2016, Vlad Dogaru wrote:
Hi everyone,As for me, it's a very good aproach for drivers in general. At the very least, it reduces interrupt latency. Keeping in mind the fact that some drivers support callback functions, it may be reasonable to off-load callback functionality to triggered fibers. Regards, Dmitriy In this new iteration, the user is given a choice via Kconfig of the
|
|
Re: [RFC v2] uart: add ISR callback mechanism for UART drivers
Daniel Leung <daniel.leung@...>
On Thu, Mar 03, 2016 at 12:30:09PM -0300, Andre Guedes wrote:
Hi Daniel,I have created a JIRA to address this @ https://jira.zephyrproject.org/browse/ZEP-89 ----- Daniel Leung
|
|
Re: STM32F103x port
Tomasz Bursztyka
Hi Maciek,
Can you check if drivers in the patchset that I posted are useful forWould be great to generalize as much as possible now. At least for what's concerning stm32. For instance, maybe gpio/pinmuxer could be generalized as well that way. Tomasz
|
|
Re: RFC: Use error codes from errno.h
Andre Guedes <andre.guedes@...>
Hi,
Quoting Nashif, Anas (2016-03-04 09:34:45) Nice, let's move on with this convention. I'll send patches to gerrit soon.Yes please, Thanks all, Andre
|
|
Re: RFC: Use error codes from errno.h
Nashif, Anas
On 4 Mar 2016, at 07:28, Jesus Sanchez-Palencia <jesus.sanchez-palencia(a)intel.com> wrote:Yes please, Thanks. Anas thanks,
|
|
Re: STM32F103x port
Maciek Borzecki <maciek.borzecki@...>
On Fri, Mar 4, 2016 at 7:44 AM, Pawel Wodnicki <root(a)32bitmicro.com> wrote:
Hej Maciek,That's great. I'll definitely take a look at it. Can you check if drivers in the patchset that I posted are useful for you? Specifically, the UART driver might be reusable across a larger number of MCUs. Browsing the Reference Manuals I noticed some bit differences in UART registers, but nothing that cannot be handled by per MCU-family ifdefs. Cheers, -- Maciek Borzecki
|
|
Re: STM32F103x port
Pawel Wodnicki <root@...>
Hej Maciek,
I added stm32f4 support to your stm32 patch: https://gerrit.zephyrproject.org/r/#/c/671/ Code is tested to run on Nucleo board included it the patch. Cheers, Pawel
|
|
Re: RFC: Counter driver API
Tseng, Kuo-Lang <kuo-lang.tseng@...>
Hi Andre, Tomasz, Jesus,
toggle quoted messageShow quoted text
Thanks for your feedbacks. I updated the API with these feedbacks. Please correct or if I missed any part that needed to be reflected. The updated API looks like below: /** * Start the counter device. If the device is a 'count up' counter the * counter initial value is set to zero. If it is a 'countdown' counter * the initial value is set to the maximum value supported by the device. * * @brief Start counter device in free running mode. * @param dev Pointer to the device structure for the driver instance. * @retval DEV_OK If successful. * @retval DEV_* Code otherwise. */ int counter_start(struct device *dev); /** * @brief Stop counter device. If alarm was set, this function also clears * the alarm setting. * @param dev Pointer to the device structure for the driver instance. * * @retval DEV_OK If successful. * @retval DEV_NO_SUPPORT if the device doesn't support stopping the * counter (e.g. free running counters). */ int counter_stop(struct device *dev); /** * @brief Read current counter value * @param dev Pointer to the device structure for the driver instance. * * @return 32-bit value */ uint32_t counter_read(struct device *dev); /** * Set an alarm. * * @brief Set an alarm. * @param dev Pointer to the device structure for the driver instance. * @param callback Pointer to the callback function. If this is NULL, this function * unsets the alarm. * @param count Number of counter ticks. * @param user_data pointer to user data * * @retval DEV_OK If successful. * @retval DEV_INVALID_OP If the counter was not started yet. * @retval DEV_NO_SUPPORT if the device doesn't support interrupt (e.g. * free running counters). */ int counter_set_alarm(struct device *dev, counter_callback_t callback, uint32_t count, void *user_data); typedef void (*counter_callback_t)(struct device *dev, void *user_data)
-----Original Message-----
|
|
Re: RFC: Use error codes from errno.h
Andre Guedes <andre.guedes@...>
Hi all,
Quoting Jesus Sanchez-Palencia (2016-03-02 16:03:22) Yes, this is the idea.The initial discussion was about using errno.h codes at the driver's layer+1 ! But I would propose that we first get this right for the device driver APIs. DEV_OK = 0Back then, I reviewed the error codes usages and this was what I had in mind: DEV_OK = 0 DEV_FAIL = -EIO /* Input/output error */ DEV_INVALID_OP = -EINVAL /* Invalid argument */ DEV_INVALID_CONF = -EINVAL /* Invalid argument */ DEV_USED = -EBUSY /* Device or resource busy */ DEV_NO_ACCESS = -EACCES /* Permission denied */ DEV_NO_SUPPORT = -ENOTSUP /* Operation not supported */ DEV_NOT_CONFIG = -EPERM /* Operation not permitted */ DEV_NOT_IMPLEMENTED -ENOSYS /* Function not implemented */ The comments besides the error codes come from 'man errno'. Regards, Andre
|
|
Re: RFC: Use error codes from errno.h
Jesus Sanchez-Palencia <jesus.sanchez-palencia@...>
Hi everyone,
On Thu, 3 Mar 2016 13:33:16 -0500 Benjamin Walsh <benjamin.walsh(a)windriver.com> wrote: After all the feedback so far (thanks, btw!), the updated list now looks like:I think -ENOTSUP is a 1-1 match here:What we have on device.h currently is: DEV_OK = 0 DEV_FAIL = -EFAULT DEV_INVALID_OP = -EPERM or -ENOTSUP or -ESRCH DEV_INVALID_CONF = -EINVAL DEV_USED = -EBUSY DEV_NO_ACCESS = -EACCES DEV_NO_SUPPORT = -ENODEV or -ENXIO or -ENOTSUP DEV_NOT_CONFIG = -EIO or -ENODEV DEV_NOT_IMPLEMENTED = -ENOSYS Which leaves us with only 3 left to be decided. By comparing again the original description with the ones from errno.h, what about: DEV_INVALID_OP = -ENOTSUP DEV_NO_SUPPORT = -ENODEV DEV_NOT_CONFIG = -EIO any better? thanks, jesus
|
|
Re: RFC: Use error codes from errno.h
Benjamin Walsh <benjamin.walsh@...>
I think -ENOTSUP is a 1-1 match here:What we have on device.h currently is:This is proposal is very similar to what we had done originally for ENOTSUP Operation not supported (POSIX.1) Perhaps ENODEV would fit better since it device related.DEV_INVALID_CONF = -EINVALENOTSUP
|
|
Re: [RFC] uart: add ISR callback mechanism for UART drivers
Daniel Leung <daniel.leung@...>
On Thu, Mar 03, 2016 at 05:07:31PM +0100, Tomasz Bursztyka wrote:
Hi Daniel,Do you have a particular use case in mind, w.r.t. UART, that requires user data? At this point, the patch is to simply move the IRQ setup code into the UART drivers. This is not a callback in generic terms, but just a an ISR calling another ISR. Since the first ISR does not have any additional user data, the second ISR should not be dependent on having additional information. The UART drivers are done in a way where driver_api is NULL+/* For configuring IRQ on each individual UART device. Internal use only. */so it would have a void *user_data parameter as well if the driver init fails, hence the (api != NULL) check. ----- Daniel Leung
|
|
Re: STM32F103x port
Maciek Borzecki <maciek.borzecki@...>
On Thu, Mar 3, 2016 at 3:43 PM, Maciek Borzecki
<maciek.borzecki(a)gmail.com> wrote: I'm sure all of you already got their emails with incoming reviewPawel spotted that the linker script was missing. This would prevent people from actually building the code. I've pushed an update for https://gerrit.zephyrproject.org/r/645 and the rest got automatically rebased. The problem was caused by filter masks in gitignore, what has been addressed in this review: https://gerrit.zephyrproject.org/r/668 gitignore: make sure that SOC specific linker scripts stay visible No other changes were made to the patches. If you're looking at, or have posted comments to the previous version, have no worries, they all apply to the current patchset. Sorry for not catching that earlier. Cheers, -- Maciek Borzecki
|
|
Re: STM32F103x port
Maciek Borzecki <maciek.borzecki@...>
On Thu, Mar 3, 2016 at 5:00 PM, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com> wrote: Hi Maciek,Thanks for the comments. I'll wait for everyone to post theirs and try to resolve the issues over the weekend. Cheers, -- Maciek Borzecki
|
|
Re: [RFC] uart: add ISR callback mechanism for UART drivers
Tomasz Bursztyka
Hi Daniel,
I am a bit late on that one. I fully agree on such addition. 1 comment below: +/**Could be wise to add a void *user_data private pointer through the callback. It's something we are missing not only here (gpio etc...) +/* For configuring IRQ on each individual UART device. Internal use only. */so it would have a void *user_data parameter as well +{I guess we do this api != NULL check because of the UART_INTERRUPT_DRIVEN option. I guess at some point we will be only interrupt driven anyway. Tomasz
|
|
Re: STM32F103x port
Tomasz Bursztyka
Hi Maciek,
toggle quoted messageShow quoted text
Thanks for the patches, they are very nicely sliced down. It's quite easy to follow. Just be aware of the code style we apply. Basically the 2 main errors are the missing {} (even for one liners if, yes, and the while loop as well) and the variable being declared in the middle of the statement block: it's always at the beginning. It's minor changes. scripts/checkpatch.pl is nice so check before hand. Tomasz
I'm sure all of you already got their emails with incoming review
|
|
Re: Newbie wants to contribute
Perez Hernandez, Javier B <javier.b.perez.hernandez@...>
Hi!
On Thu, 2016-03-03 at 13:05 +0530, Himanshu Maurya wrote: Hello zephyr team!!!You can start by reading our documentation: https://www.zephyrproject.org/doc/collaboration/collaboration.html Any question, just ask in users(a)lists.zephyrproject.org or in IRC #zephyrproject. BTW, please use plain text in emails. Welcome! Javier B. Perez
|
|
Re: RFC: Use error codes from errno.h
Luiz Augusto von Dentz
Hi Daniel,
On Wed, Mar 2, 2016 at 10:46 PM, Kalowsky, Daniel <daniel.kalowsky(a)intel.com> wrote: Perhaps ENODEV would fit better since it device related.-----Original Message-----This is proposal is very similar to what we had done originally for the devices instead of using the DEV_ names. DEV_NOT_IMPLEMENTED = -ENOSYS -- Luiz Augusto von Dentz
|
|
Re: [RFC v2] uart: add ISR callback mechanism for UART drivers
Andre Guedes <andre.guedes@...>
Hi Daniel,
Quoting Daniel Leung (2016-03-02 22:35:24) No, I don't have anything in particular. Probably the bluetooth driversThis is actually a nice improvement on the UART API since it moves theThis is something I have thought about, but there is no concrete plan. and the console_uart driver are a good source of use cases. For instance, they all have their own implementation of a mechanism read data asynchronously. An API such as uart_read(dev, callback, buf, len) might be useful. Regards, Andre
|
|