USART 6

[Javier Pedrido]

Hello,

Is there a reason for PA_11 and PA_12 not being mapped as USART pins in MBed 5? I’m getting ‘pinmap not found for peripheral’ when trying to migrate an application that works ok with the previous version.

Regards,
Javier

• This topic was modified 8 years ago by Javier Pedrido.

[Mike Fiore]

Javier,

We removed tjat uart because PA_12 is marked as RFU in the official pinout for the mDot. If you’re willing to edit the PeripheralPins.c file for the mDot, you can add the functionality back. You could make a PR to the mbed-os github repository so that uart gets back into the platform support. Will that work?

Cheers,

Mike

[Javier Pedrido]

Mike,

Sorry, what’s RFU? Yes I could fork the MBED repository and create a pull request with this change. Is there any chance that this modification gets applied to the main repository?

Thanks,
Javier

[Mike Fiore]

Javier,

Sorry for the lingo. RFU = Reserved for Future Use.

If your PR is accepted (and it should be since it’s such a minor change), the changes should make it into the next mbed-os release.

Cheers,

Mike

[Andrew Lindsay]

Yet more functionality removed from the mDot platform when moving from mbed-os2 to mbed-os5.

This really shouldn’t be happening as it annoys and frustrates customers.

Andrew

[Mike Fiore]

Andrew,

The goal was to remove peripherals that either weren’t available on the mDot pinout or mapped to pins used internally. UART6 was an oversight because one of the pins was marked RFU.

Are there other features or functionality that you feel have been lost during the transition from mbed 2 to mbed 5? If so, please let us know.

Cheers,

Mike

[Andrew Lindsay]

Mike,

Deep sleep on the mDot in mbed-os5 was removed and replaced with a warning saying regular sleep was being used. This meant I couldn’t migrate the device to mbed-os5.

Thanks

Andrew

[Mike Fiore]

Andrew,

As I explained earlier, we removed deepsleep due to the fact that it was discovered to be unreliable and was causing a lot of customer frustration. Since sleep mode improvements were made to bring current consumption down to approximately the same level as deepsleep and you gain additional functionality with sleep mode, it was a logical choice.

Can you explain why you can’t use sleep mode instead of deepsleep mode now that the current consumption is similar? Migrating your application should basically be a matter of:

* removing the if (!dot->getStandbyFlag) from around your configuration and initial setup
* putting a while() loop around the functional component of your code

Cheers,

Mike

[Tom Hill]

Hi Mike,

I was looking to upgrade to mbed5, however there was quite a difference in the deep sleep mode and sleep mode in mbed2. So are you saying that this gap has been closed in mbed5? Also the customer frustrations you mentioned with deep sleep mode, does that apply for mbed 2 as well? We picked deep sleep mode primarily because of the lower current consumption in mbed 2.

Thanks,
Yogesh

[Mike Fiore]

Yogesh,

We’ve disabled deepsleep mode on mDots in the new library code because there is a HW issue that makes the deepsleep current draw unpredictable: it may be at the ~50uA level it should be at or it could be in the mA range instead.

That being said, we have been able to bring sleep mode current draw down to the ~50uA range as well, so there really isn’t a downside to using sleep mode instead of deepsleep mode. We are encouraging customers to go down this route and we think it should be an easy choice. The fact that RAM and IO state are retained in sleep mode should allow you to simplify your application quite a bit.

The latest version of libmDot (for mbed 2) will also disable deepsleep on the mDot for the same reasons I stated above. That revision should also have the lower sleep mode current draw I mentioned earlier.

https://developer.mbed.org/teams/MultiTech/code/libmDot/rev/0da384ba484b

Hope this helps!

Cheers,

Mike

[Andrew Lindsay]

It would be better if your customers were able to make the decision to use deep sleep or not themselves.

Have Multitech been taken over by Apple?

[Tom Hill]

Thanks Mike for your response. What version of mbed rtos and mbed lib should I be using with the latest version of libmdot for mbed os 2. Also is there any enhancements with libmdot mbedos 5 that is not in current libmdot. I am trying to make a decision to upgrade to mbed os5.

Thanks,
Yogesh

[Mike Fiore]

Yogesh,

You should use mbed 121 and mbed-rtos 116 as stated by the commit message for the latest version of libmDot.

Here’s a link to the changelog for the Dot libraries. Besides disabling deepsleep mode and reducing the current consumption in sleep mode, the latest libmDot revision doesn’t have any of the features listed for newer versions.

https://developer.mbed.org/teams/MultiTech/wiki/Dot-library-change-log

Cheers,

Mike

[Author]

Posts