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

SDT64, 8195, 32620, 32625, 51822, 52832B added to targets #7669

Merged
merged 10 commits into from Aug 17, 2018

Conversation

Projects
None yet
6 participants
@jwyune

jwyune commented Aug 1, 2018

Description

We are adding six new boards to mbed-os. The list is as follows:

  • SDT64B
  • SDT8195B
  • SDT32620B
  • SDT32625B
  • SDT51822B
  • SDT52832B

Pull request type

[ ] Fix
[ ] Refactor
[x] New target
[ ] Feature
[ ] Breaking change
@jwyune

This comment has been minimized.

jwyune commented Aug 1, 2018

We tested the boards with GCC_ARM only.

Test results

  1. Blinky (https://github.com/ARMmbed/mbed-os-example-blinky): all six boards successful
  2. iBeacon (https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-ble-Beacon/): SDT51822B and SDT52832B successful
  3. Ethernet (https://os.mbed.com/docs/v5.9/reference/ethernet.html): SDT64B successful
  4. Wi-Fi (https://github.com/ARMmbed/mbed-os-example-wifi): SDT8195B successful

@0xc0170 0xc0170 requested a review from ashok-rao Aug 1, 2018

@jwyune

This comment has been minimized.

jwyune commented Aug 2, 2018

I attached Greentea results for all the six boards.

SDT64B.txt
SDT8195B.txt
SDT32620B.txt
SDT32625B.txt
SDT51822B.txt
SDT52832B.txt

@@ -635,6 +635,23 @@
"network-default-interface-type": "ETHERNET"
}
},
"SDT64B": {
"core": "Cortex-M4F",

This comment has been minimized.

@0xc0170

0xc0170 Aug 2, 2018

Member

why this target do not inherit from MCU K64F ? IT looks like it would benefit and override few details .

This comment has been minimized.

@0xc0170

0xc0170 Aug 2, 2018

Member

Similar to other targets below.

This comment has been minimized.

@jwyune

jwyune Aug 2, 2018

I will simplify "SDT64B", but we cannot simplify the codes for the other boards. I will explain the reason in the next comment.

This comment has been minimized.

@0xc0170

0xc0170 Aug 2, 2018

Member

Thanks, please do !

Ideally, K64F and some other targets contain base target (MCU_xxx) that we can inherit from. So if there are targets that do not have this hierarchy, they do not allow us to inherit from and set-up own target

@@ -4061,6 +4105,25 @@
"network-default-interface-type": "WIFI"
}
},
"SDT8195B": {
"core": "Cortex-M3",

This comment has been minimized.

@0xc0170

0xc0170 Aug 2, 2018

Member

Why this targetr does not reuse realtek - I can see new files here (HAL implemention) - arent these the same as for realtek?

This comment has been minimized.

@jwyune

jwyune Aug 2, 2018

If I just do "inherits": ["REALTEK_RTL8195AM"], I get pin name declaration errors. We see the same error for all the boards, except for SDT64B.

This comment has been minimized.

@0xc0170

0xc0170 Aug 2, 2018

Member

I see the problem here

@ARMmbed/team-realtek This target is a platform and can't be used as base (MCU_RTL..... would be needed here?). Please review

This comment has been minimized.

@jwyune

jwyune Aug 2, 2018

@0xc0170 There is another issue with K64F. The folder that contains EMAC for K64F is also "TARGET_K64F" (https://github.com/ARMmbed/mbed-os/tree/master/features/netsocket/emac-drivers/TARGET_Freescale_EMAC/TARGET_K64F). This can be pretty confusing to users, because if you want to use the ethernet driver, you need to add "extra_labels_add": ["K64F"].

Target "K64F" should have added "extra_labels_add": ["K64F"], but they didn't have to, because their target name also "happens" to be the same.

This comment has been minimized.

@0xc0170

0xc0170 Aug 3, 2018

Member

Is that EMAC implementation generic for any K64F or targetting just frdm-k64f board? If generic, folder should be named TARGET_MCU_K64F (no addition should be needed there, but MCU_K64F is not yet a target but at least there are folders that contain MCU files). Can you create an issue for this? This should be reviewed

Jiwon Yune Jiwon Yune
@jwyune

This comment has been minimized.

jwyune commented Aug 2, 2018

@0xc0170 We couldn't simplify the targets.json codes for the other boards. If we inherit REALTEK_RTL8195AM, MAX32620FTHR, NRF51_DK, and NRF52_DK, pin declaration error would occur, because mbed-os would look for pin names in those folders, not in the SDT*B folders.

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Aug 3, 2018

I'll create an issue for REALTEK_RTL8195AM if t here can be MCU_ target created that one of these new targets could inherit from to get boilerplate.

Regarding NRF51_DK - that one is OK for now, would need refactor.

NRF52_DK - inherits from MCU_NRF52832 - MCU_NRF52832 should be your parent then, to inherit from.

@jwyune

This comment has been minimized.

jwyune commented Aug 3, 2018

We are using neither of NRF51_DK nor NRF52_DK. SDT51822B inherits from MCU_NRF51_32K_UNIFIED, and SDT52832B from MCU_NRF52832. Those two boards meet the requirements.

GPIO5 = PTC6,
GPIO6 = NOT_CONNECTED,
//Purse Width Modulation (PWM)

This comment has been minimized.

@ashok-rao

ashok-rao Aug 6, 2018

Contributor

Purse => Pulse (typo)

This comment has been minimized.

@jwyune

jwyune Aug 6, 2018

Thanks for pointing this out.

UART2_TX = PTC17,
UART2_CTS = PTC19,
UART2_RTS = PTC18,

This comment has been minimized.

@ashok-rao

ashok-rao Aug 6, 2018

Contributor

Can you please define default peripherals for each type? Ex: UART_TX = UART0_TX , I2C_SDA = I2C1_SDA and so on..

This comment has been minimized.

@jwyune

jwyune Aug 6, 2018

Where can I find the names for default peripherals? I see LED1, 2, 3, and USBTX, RX, but others don't seem to have that. For example, https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_Maxim/TARGET_MAX32620C/TARGET_MAX32620FTHR/PinNames.h

This comment has been minimized.

@jwyune

jwyune Aug 6, 2018

@ashok-rao I'll define the following list:
USBTX, USBTX, LED1, LED2, LED3, LED_RED, LED_GREEN, LED_BLUE, SERIAL_TX, SERIAL_RX, I2C_SCL, I2C_SDA, SPI_MOSI, SPI_MISO, SPI_SCK, SPI_CS, PWM_OUT

Anything else?

This comment has been minimized.

@ashok-rao

ashok-rao Aug 6, 2018

Contributor

That should do it! Thanks! (Same for all the below).

SPI3_SS0 = P5_3,
SPI3_SS1 = P5_4,
SPI3_SS2 = P5_5,

This comment has been minimized.

@ashok-rao

ashok-rao Aug 6, 2018

Contributor

Same comments as above regarding default peripherals. Thanks.

SPI3_SS0 = NOT_CONNECTED,
SPI3_SS1 = NOT_CONNECTED,
SPI3_SS2 = NOT_CONNECTED,

This comment has been minimized.

@ashok-rao

ashok-rao Aug 6, 2018

Contributor

Same comments as above regarding default peripherals.

SPI3_SS0 = NOT_CONNECTED,
SPI3_SS1 = NOT_CONNECTED,
SPI3_SS2 = NOT_CONNECTED,

This comment has been minimized.

@ashok-rao

ashok-rao Aug 6, 2018

Contributor

Same comment as above for default peripherals.

UART2_TX = NOT_CONNECTED,
UART2_CTS = NOT_CONNECTED,
UART2_RTS = NOT_CONNECTED,

This comment has been minimized.

@ashok-rao

ashok-rao Aug 6, 2018

Contributor

same comment as above regarding default peripherals.

I2C1_SDA = PB_3,
I2C2_SCL = NOT_CONNECTED,
I2C2_SDA = NOT_CONNECTED,

This comment has been minimized.

@ashok-rao

ashok-rao Aug 6, 2018

Contributor

Same comment for default peripheral, but looks like only I2C needs to have one in this case.

Jiwon Yune
@jwyune

This comment has been minimized.

jwyune commented Aug 6, 2018

@ashok-rao I added generic pin names for all the boards. Thanks.

@cmonr

This comment has been minimized.

Contributor

cmonr commented Aug 14, 2018

Just making a note here that before this can come in, the config will need to derive off of a base target, which is what #7704 will provide.

@cmonr cmonr removed the needs: review label Aug 14, 2018

@ashok-rao

This comment has been minimized.

Contributor

ashok-rao commented Aug 15, 2018

Sounds good to me .. @cmonr , @0xc0170 : What do you guys say? I don't see any blockers with the other targets in this PR except the RTL8195 having dependency on 7704..

@cmonr

This comment has been minimized.

Contributor

cmonr commented Aug 15, 2018

@jwyune Thank you for the time pressure info. We can go ahead with your plan to get this PR in sooner rather than later. Once #7704 comes in though, we would appreciate refactoring so that they derive from the new target.

@andrewc-arm

This comment has been minimized.

andrewc-arm commented Aug 16, 2018

Hi, I agree to @jwyune suggestion. Let's submit all the board code except Realtek. After this, we can proceed to Mbed Enabled process. Thanks.

Jiwon Yune Jiwon Yune
@jwyune

This comment has been minimized.

jwyune commented Aug 16, 2018

Hello, @andrewc-arm @ashok-rao @cmonr

I removed everything related to RTL8195, but I see a few test fails. How can I reproduce the failed results locally to fix those?

@cmonr

This comment has been minimized.

Contributor

cmonr commented Aug 16, 2018

@jwyune Take a look at the .travis.yml file at the base of the Mbed OS directory. Inside of it, you'll find all of the commands that are run in Travis CI.

The cloud_client_smoke_test looks like it's internal only, but it looks like it's failing for similar reasons that the other tests are, being that there's a Json key error with 'MAX32625_NO_BOOT'

@jwyune

This comment has been minimized.

jwyune commented Aug 16, 2018

@cmonr That's bizarre, because I changed nothing, but removed everything related to RTL8195.

@ashok-rao

This comment has been minimized.

Contributor

ashok-rao commented Aug 16, 2018

Looks like travis is passing now.. let's wait for CI to finish.. @cmonr ..can you trigger it please?

@jwyune

This comment has been minimized.

jwyune commented Aug 16, 2018

@ashok-rao
crossed-fingers

@cmonr

This comment has been minimized.

Contributor

cmonr commented Aug 16, 2018

Will start in a bit. The Test CI queue was reeealy long in the last 48 hours.

Path forward for now. Comments will be addressed once dependent PR is mergedm, but this PR will not wait in the short term.

@cmonr cmonr added needs: CI and removed needs: work labels Aug 16, 2018

@cmonr

cmonr approved these changes Aug 16, 2018

#ifndef MBED_DEVICE_H
#define MBED_DEVICE_H

This comment has been minimized.

@cmonr

cmonr Aug 16, 2018

Contributor

Is there a reason for all of this white space?

This comment has been minimized.

@jwyune

jwyune Aug 16, 2018

Not really... This file was directly copied from TARGET_K64F.

@cmonr

This comment has been minimized.

Contributor

cmonr commented Aug 16, 2018

/morph build

@mbed-ci

This comment has been minimized.

mbed-ci commented Aug 16, 2018

Build : SUCCESS

Build number : 2819
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7669/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

@mbed-ci

This comment has been minimized.

mbed-ci commented Aug 16, 2018

@mbed-ci

This comment has been minimized.

@cmonr cmonr added ready for merge and removed needs: CI labels Aug 17, 2018

@cmonr cmonr merged commit 8e25d2d into ARMmbed:master Aug 17, 2018

15 checks passed

AWS-CI uVisor Build & Test Success
Details
ci-morph-build build completed
Details
ci-morph-exporter build completed
Details
ci-morph-mbed2-build build completed
Details
ci-morph-test test completed , RTOS ROM(+0.0%) RAM(+0.0%)
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
jenkins-ci/cloud_client_smoke_test Test job was successful
Details
travis-ci/astyle Passed, 584 files
Details
travis-ci/docs Local docs testing has passed
Details
travis-ci/events Passed, runtime is 9750 cycles (-540 cycles)
Details
travis-ci/gitattributestest Local gitattributestest testing has passed
Details
travis-ci/licence_check Local licence_check testing has passed
Details
travis-ci/littlefs Passed, code size is 8372B (+0.00%)
Details
travis-ci/tools-py2.7 Local tools-py2.7 testing has passed
Details

pan- pushed a commit to pan-/mbed that referenced this pull request Aug 22, 2018

Merge pull request ARMmbed#7669 from SigmaDeltaTechnologiesInc/master
SDT64, 8195, 32620, 32625, 51822, 52832B added to targets
@0xc0170

This comment has been minimized.

Member

0xc0170 commented Aug 23, 2018

Just a note, this caused issue referenced above #7829 - ipv6 builds fail as there are dhcp files added in this PR. What was the intention ? We are reverting them to fix the regression.

@cmonr

This comment has been minimized.

Contributor

cmonr commented Aug 24, 2018

@0xc0170 I added a release version label for the last patch, since 5.9.6 is already made and undergoing testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment