EX

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: EX

Postby Giovanni » Thu Mar 17, 2016 9:33 pm

steved wrote:In principle this is absolutely right; however I found on a 32F051 application that adding the EXT driver took up about 1K of my 100 bytes of previously unused code space. So I had to manage the interrupt myself (easy enough with the lower level APIs).
Adding the EXT driver would be proportionally less demanding on the larger processors.
Not sure how practical it would be, but could there be a project-wide choice of either using the EXT driver, or of implementing dedicated coding?


The problems that I can see are:

1) The peripheral driver would no more be portable but it would need to deal with HW directly (EXTI, ISR etc). You would make a gyro driver for STM32 not a generic one.
2) If a peripheral driver takes an EXTI ISR then the EXT driver could not be used because it would conflict.

This is why I suggest to keep notifications out of the peripheral drivers.

About EXT, it is not set in stone, any better idea for such functionality?

Giovanni

User avatar
Korken
Posts: 270
Joined: Wed Apr 02, 2014 4:09 pm
Location: Luleå, Sweden
Has thanked: 5 times
Been thanked: 6 times
Contact:

Re: EX

Postby Korken » Thu Mar 17, 2016 10:47 pm

>> Most MEMS use I2C those cannot be polled from ISR regardless all other points.
Indeed, as stated before, this should not be considered the main problem as any hack implementation can poll a sensor - but it is not efficient nor latency deterministic.
The importance lies in getting the difficult ones right, hence my push for the EXT link. :)

>> If you thing you NEED ISRs probably you are not using much of the RTOS, just IMHO.
For sensors reads, no, an RTOS is not needed. Not sure if I get your point?
You actively do not want the RTOS to do this as it adds a point of possible latency.
For low performance applications and during calibrations it is not a problem to not follow the sampling theorems but for the rest it is paramount.
I personally only see the RTOS as, in this case, a bridge to get the readouts setup and then to let ISRs do the rest (and signals the RTOS when there is data), where the data processing is then done by the RTOS together with decision and other data related threads.
This however depends on the specific application, but we should not handicap the system just to force the usage of an RTOS where it does not make sense for some applications (especially when we easily can add support for the most advanced case with one optional interface). :)

This is just my opinion though, that I hope is shared, to maximize the impact of the MEMS part of EX.


EDIT: New posts.
>> 1) The peripheral driver would no more be portable but it would need to deal with HW directly (EXTI, ISR etc). You would make a gyro driver for STM32 not a generic one.
>> 2) If a peripheral driver takes an EXTI ISR then the EXT driver could not be used because it would conflict.

I see your point now, but we need to find a way to allow it from the EX.
As stated before, as simple as adding an optional I-class function is enough because after this the user can make the last little implementation for connecting it to an ISR.
Perhaps this is a good middle ground?


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 17 guests