Another way is to have macro ASM_BKPT() macro and have the callback tied
back to the macro so that anybody who uses "bkpt" instruction and checks
for examples knows that the macro needs to be used instead of directly
using the "bkpt" instruction.
On Thu, May 2, 2019 at 4:57 PM Vipul Rahane
Hello,
So, we are running into an issue where some peripheral needs to get shut
down before the breakpoint gets hit. this only happens when the debugger is
connected and so, it quite isolated in terms on functionality.
There are different approaches we could follow:
1. Have a macro (syscfg)
I agree with Amr Bekhit. The driver can remain the same but we do want
people to know that different parts are supported using that driver and
hence the keywords fields.
On Thu, May 2, 2019 at 5:00 AM Amr Bekhit wrote:
> Just a suggestion, in the pkg.yml file for the lps33hw package. you'll
>
Hi All,
As already mentioned in the previous e-mail regarding the lps33hw driver and
LPS22HB sensor, I would like to point out
that also the LPS22HH sensor is already supported by the lps33thw driver since
the registers map and the functionalities
are the same, only the package type changes
Hi All,
As already mentioned in the previous e-mail regarding the lps33hw driver and
LPS22HB sensor, I would like to point out
that also the LPS22HH sensor is already supported by the lps33thw driver since
the registers map and the functionalities
are the same, only the package type changes
Hi Chris,
I've just tried your latest fix and I still get the same error:
*Error: Two app packages in build: apps/splitty, apps/bleprph*
Regards.
/joseph
Le mer. 1 mai 2019 à 20:35, Christopher Collins a écrit :
> Hi Joseph,
>
> On Mon, Apr 29, 2019 at 04:39:50PM +0200, joseph reveane
