BTW, an easy workaround for this would just be rejecting any requests
that aren't in the 0x8..0x77 range on the nRF52. That's valid on any
chip, to be honest, though only an issue on the nRF52.
I'll see if I spot anything on the logic analyzer tomorrow, though, but
I think this is internal to
I'll hook a logic analyzer up again tommorow with and without the
invalid address range and see what the difference is, but it seems like
a single incorrect address usage is sending the I2C block into the weeds
for some reason. Nordic's SDK has the same behaviour with the SD and
their drivers.
What I am going to say is obvious, but has anyone hooked up an i2c analyzer to
see what is actually going on in the two cases? I dont see why the peripheral
would act differently based on the address itself; something must be happening
on the bus causing the peripheral to act differently.
When
And just to highlight the point, here is the results
using 0x03 at the starting point on an identical setup:
i2cscan
9116:Scanning I2C bus 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- --
Hi Greg,
Well, unexpected but the problem is indeed the faulty address
requests at the beginning and correctly setting the start
address to 0x08 causes the LSM303 to respond:
133728:Scanning I2C bus 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: --
Hey Kevin, all,
I've done quite a bit of I2C, and Sterling pointed out this thread for me
to add some thoughts.
First up, the probe should start scanning at 0x08 (rather than 0x03). Per
the I2C spec, Rev 6, Section 3.1.12, the first and last 8 addresses (in
7-bit addressing) are reserved. Thus
I think there was some discussion re: HAL PWM but I cannot quite recall the end
result. Maybe that this would be a driver instead of a HAL? I agree; PWM is
very commonly used so having PWM support (in either driver or HAL form) should
be added.
> On Dec 26, 2016, at 10:26 AM, Kevin Townsend
Hi Will,
Thanks for the feedback.
1) Unless you are the highest priority task, other tasks can run which could
cause delays, and thus you are not waking up at the desired time.
Yeah, everything is based on the assumption that priority is resolved by
design, and that the scheduling
There is nothing in the OS to delay until a specific OS time or to cause the
scheduler to periodically wake up at a certain rate. There are different ways
to go about doing this and it really depends on what you want. Using a task to
guarantee timing can be tricky. Some things to be aware of
Dear podling,
This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.
The board meeting is scheduled for Wed, 18 January 2017, 10:30 am PDT.
The report for your podling will
Hi Fabio,
Thanks for the feedback and suggestion.
I didn't think to have separate sync and read tasks. It does add a
decent amount of code when this could be solved with one or two lines
and a built in helper class, but it's a workable and reliable solution
today.
I also tested the code
Hi Kevin,
One pattern I have used for solving the problem would be to create one
extra task simply signaling the first task and looping on the required
timeout. That guarantees to some extent that the first task is always
waken up at a fixed rate. Something on the lines of (disclaimer:
non-tested
12 matches
Mail list logo
