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

jwyune · 2018-08-01T09:38:49Z

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 · 2018-08-01T09:52:43Z

We tested the boards with GCC_ARM only.

Test results

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

jwyune · 2018-08-02T10:45:08Z

I attached Greentea results for all the six boards.

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

0xc0170 · 2018-08-02T12:06:58Z

targets/targets.json

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


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

Similar to other targets below.

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

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

0xc0170 · 2018-08-02T12:10:03Z

targets/targets.json

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


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

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.

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

@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.

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

jwyune · 2018-08-02T13:46:48Z

@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 · 2018-08-03T10:12:35Z

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 · 2018-08-03T10:35:11Z

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.

ashok-rao · 2018-08-06T13:03:24Z

targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/TARGET_SDT64B/PinNames.h

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


Purse => Pulse (typo)

Thanks for pointing this out.

ashok-rao · 2018-08-06T13:04:32Z

targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/TARGET_SDT64B/PinNames.h

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


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

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

@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?

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

ashok-rao · 2018-08-06T13:11:42Z

targets/TARGET_Maxim/TARGET_MAX32620C/TARGET_SDT32620B/PinNames.h

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


Same comments as above regarding default peripherals. Thanks.

ashok-rao · 2018-08-06T13:12:29Z

targets/TARGET_Maxim/TARGET_MAX32625/TARGET_SDT32625B/PinNames.h

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


Same comments as above regarding default peripherals.

ashok-rao · 2018-08-06T13:13:20Z

...GET_NORDIC/TARGET_NRF5x/TARGET_NRF51/TARGET_MCU_NRF51822_UNIFIED/TARGET_SDT51822B/PinNames.h

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


Same comment as above for default peripherals.

ashok-rao · 2018-08-06T13:13:50Z

targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/TARGET_MCU_NRF52832/TARGET_SDT52832B/PinNames.h

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


same comment as above regarding default peripherals.

ashok-rao · 2018-08-06T13:15:04Z

targets/TARGET_Realtek/TARGET_AMEBA/TARGET_SDT8195B/PinNames.h

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


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

jwyune · 2018-08-06T13:52:07Z

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

cmonr · 2018-08-14T01:07:59Z

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.

jwyune · 2018-08-15T09:13:01Z

@cmonr @ashok-rao We are launching our boards very soon, and delay in "mbed--os" would be a big problem for us, because it also delays "Mbed Enablement" certification process. Delay here is actually hurting our business at the moment.

How about this? I can easily remove everything related to RTL8195, and you can get everything else merged first. Note that we don't have more work to do with other boards. Please let me know what you think. I made this PR two weeks ago, and we really need this to be approved as soon as possible.

ashok-rao · 2018-08-15T11:05:06Z

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 · 2018-08-15T16:27:50Z

@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 · 2018-08-16T01:14:09Z

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.

jwyune · 2018-08-16T02:17:33Z

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 · 2018-08-16T02:49:50Z

@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 · 2018-08-16T03:12:28Z

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

ashok-rao · 2018-08-16T08:54:53Z

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

jwyune · 2018-08-16T09:00:41Z

@ashok-rao

cmonr · 2018-08-16T13:02:08Z

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 · 2018-08-16T13:18:31Z

targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/TARGET_SDT64B/device.h

+#ifndef MBED_DEVICE_H
+#define MBED_DEVICE_H
+
+


Is there a reason for all of this white space?

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

cmonr · 2018-08-16T14:54:14Z

/morph build

mbed-ci · 2018-08-16T15:47:58Z

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 · 2018-08-16T17:39:52Z

Exporter Build : SUCCESS

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

mbed-ci · 2018-08-17T14:51:03Z

Test : SUCCESS

Build number : 2567
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7669/2567

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

0xc0170 · 2018-08-23T15:51:20Z

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 · 2018-08-24T03:49:09Z

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

Jiwon Yune added 6 commits August 1, 2018 18:13

SDT64B added

e587791

SDT8195B added

4a06f59

SDT32620B added

df3afa7

SDT32625B added

0634be8

SDT51822B added

784d17f

SDT52832B added

209a9dc

0xc0170 requested a review from ashok-rao August 1, 2018 10:06

0xc0170 added the needs: review label Aug 1, 2018

0xc0170 previously requested changes Aug 2, 2018

View reviewed changes

SDT64B in targets.json simplified

0046800

0xc0170 mentioned this pull request Aug 6, 2018

realtek rtl8195am Add MCU_target #7704

Closed

ashok-rao reviewed Aug 6, 2018

View reviewed changes

Generic pin names added

04fc7aa

cmonr added scope: new-target needs: work needs: preceding PR labels Aug 9, 2018

cmonr removed the needs: review label Aug 14, 2018

cmonr removed the needs: preceding PR label Aug 16, 2018

SDT8195B removed

f50e7e9

fixed errors related to MAX32625_NO_BOOT

515e35e

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

cmonr approved these changes Aug 16, 2018

View reviewed changes

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

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

0xc0170 removed the ready for merge label Aug 17, 2018

juhaylinen mentioned this pull request Aug 20, 2018

REALTEK_RTL8195AM IPv6 build fails #7829

Closed

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

Merge pull request ARMmbed#7669 from SigmaDeltaTechnologiesInc/master

6ac13f2

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

cmonr added the release-version: 5.9.7 label Aug 24, 2018

		#ifndef MBED_DEVICE_H
		#define MBED_DEVICE_H

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

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

Conversation

jwyune commented Aug 1, 2018

Description

Pull request type

jwyune commented Aug 1, 2018

jwyune commented Aug 2, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jwyune commented Aug 2, 2018

0xc0170 commented Aug 3, 2018

jwyune commented Aug 3, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ashok-rao Aug 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jwyune commented Aug 6, 2018

cmonr commented Aug 14, 2018

jwyune commented Aug 15, 2018 • edited Loading

ashok-rao commented Aug 15, 2018

cmonr commented Aug 15, 2018

andrewc-arm commented Aug 16, 2018

jwyune commented Aug 16, 2018

cmonr commented Aug 16, 2018

jwyune commented Aug 16, 2018

ashok-rao commented Aug 16, 2018 • edited Loading

jwyune commented Aug 16, 2018 • edited Loading

cmonr commented Aug 16, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cmonr commented Aug 16, 2018

mbed-ci commented Aug 16, 2018

Triggering tests

mbed-ci commented Aug 16, 2018

mbed-ci commented Aug 17, 2018

0xc0170 commented Aug 23, 2018

cmonr commented Aug 24, 2018

ashok-rao Aug 6, 2018 •

edited

Loading

jwyune commented Aug 15, 2018 •

edited

Loading

ashok-rao commented Aug 16, 2018 •

edited

Loading

jwyune commented Aug 16, 2018 •

edited

Loading