USART 6

Home Forums mDot/xDot USART 6

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #15407
    Javier Pedrido
    Participant

    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

    #15409
    Mike Fiore
    Blocked

    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

    #15410
    Javier Pedrido
    Participant

    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

    #15411
    Mike Fiore
    Blocked

    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

    #15416
    Andrew Lindsay
    Participant

    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

    #15417
    Mike Fiore
    Blocked

    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

    #15424
    Andrew Lindsay
    Participant

    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

    #15426
    Mike Fiore
    Blocked

    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

    #15555
    Tom Hill
    Participant

    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

    #15575
    Mike Fiore
    Blocked

    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

    #15580
    Andrew Lindsay
    Participant

    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?

    #15582
    Tom Hill
    Participant

    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

    #15584
    Mike Fiore
    Blocked

    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

Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.