-
Notifications
You must be signed in to change notification settings - Fork 7.4k
drivers: sensor: Add Atmel SAM QDEC (TC) Driver #1043
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
22c5d42
to
fae689a
Compare
From the point of view of the existing support for Atmel SAM Family in Zephyr the driver code looks good. The only open question is if SENSOR_POSITION parameter should have a unit. In case of QDEC we measure angular rotation. @galak, @MaureenHelm could you please review this PR. |
@bogdan-davidoaia could you please review this PR? |
a053cce
to
457699c
Compare
zephyrproject-rtos#1043) - Call k_sched_lock() and k_sched_unlock() in callbacks to prevent other tasks from accessing the callback map/ring buffer at the same time. This becomes important for network functionality as the zephyr network stack uses multiple tasks, which can still call add/signal/remove_callback(). Signed-off-by: James Prestwood <[email protected]> * moved LOCK/UNLOCK to zjs_util.h Signed-off-by: James Prestwood <[email protected]>
I have updated this PR to CMake and resolved merge conflicts. |
@jpfaff sorry for the super late answer. Somehow the initial mails got lost in my inbox and only now did I see this PR since it got some updates. For POSITION I'd change it to ANGULAR_ROTATION or ANGULAR_POSITION for clarity and express it in radians since we already have angular velocity expresses in radians/second for the gyro channels. |
@bogdan-davidoaia no worries. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I don't think drivers/sensor is the correct place for this. (not sure what is)
- We need device tree support to get properties like sam_name & steps_per_unit.
- Can you split out the pinmap update into its own patch from the driver.
The quadrature decoder driver indeed doesn't fit too well anywhere in the API. There was a short discussion on the devel list in August regarding the issue and the proposal was to add it to the sensor API (the other possibility would be to extend counter API).
So far we've always kept pinmap in the same commit as the driver. It can be considered part of the SoC support. I just want to mention that having a separate commit for pinmap means change of style. On a related note, should we provide pinmap also for sam4s, sam3x series? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some extra comments (assuming that we want to add this driver to the sensor API and not to the counter API).
drivers/sensor/qdec_sam/Kconfig
Outdated
default 24 | ||
help | ||
Step per unit allows to set the sensor position granularity. | ||
In case of a rotary encoder this equals to steps per revolution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Steps per unit will likely be understood by the user as steps per radian. I think we need to explain this parameter better. Something among the lines of:
"For angular position this parameter tells the number of steps per revolution (one complete turn). For linear position number of steps per unit of length. Currently only angular position is supported."
This is assuming that in the future we may want to add 'linear position' channel and want this driver to be prepared for it.
degree -= 360; | ||
} | ||
} | ||
sensor_degrees_to_rad(degree, val); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calculating the value first in degrees and then converting it to radians means that we loose precision. We probably should make all the calculations in radians directly.
include/sensor.h
Outdated
/** 1.0 micro-meters Particulate Matter, in ug/m^3 */ | ||
SENSOR_CHAN_PM_1_0, | ||
/** 2.5 micro-meters Particulate Matter, in ug/m^3 */ | ||
SENSOR_CHAN_PM_2_5, | ||
/** 10 micro-meters Particulate Matter, in ug/m^3 */ | ||
SENSOR_CHAN_PM_10, | ||
/** Angular position in radians */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this parameter supposed to change in the range 0 to 2π, -π to π? Is the range unlimited? We probably should clarify this in comment.
@mnkp I agree with all your comments.
|
not really, lots o the sensors in drivers/sensors are part of the SoC. If you are using the sensor.h, then that belongs into sensors. |
ee5b12f
to
f95e5fd
Compare
6b38c09
to
ff730a4
Compare
23c2a89
to
d3d7d54
Compare
Signed-off-by: Jonas Pfaff <[email protected]>
Tested on Atmel SMART SAM E70 Xplained board Origin: Original Jira: ZEP-2478 Signed-off-by: Jonas Pfaff <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #1043 +/- ##
======================================
Coverage 53.2% 53.2%
======================================
Files 436 436
Lines 41353 41353
Branches 7937 7937
======================================
Hits 22002 22002
Misses 16127 16127
Partials 3224 3224
Continue to review full report at Codecov.
|
what is the story with this PR? Is this going to be updated and is it still required? If nothing happens within the next week, it will be closed. |
Hi, will anything happen to this PR soon? We need to use other QDEC and I don't want to generate code conflicts or implement things already done? |
Hi,
Not from my side. The project I did this for is dead and I personally have
no time for it.
Take whatever you can use. If needed I can delete the PR, just let me know.
…On Tue, Aug 7, 2018, 14:48 Pawel Dunaj ***@***.***> wrote:
Hi, will anything happen to this PR soon? We need to use other QDEC and I
don't want to generate code conflicts or implement things already done?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1043 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AC0Y1eeGj-012Iraj87cwcLiqF1qYj8fks5uOYyGgaJpZM4Owug3>
.
|
Thanks, I will try to reuse the API since it was already discussed. |
Hi @jpfaff , you can delete the PR now to avoid any conflict in the future. I will create and issue and PR with our QDEC. |
Tested on Atmel SMART SAM E70 Xplained board
Origin: Original