[GitHub] ccollins476ad commented on a change in pull request #655: Support for APOLLO 2 and emspi HCI transport

[GitBox <gi...@apache.org>]

ccollins476ad commented on a change in pull request #655: Support for APOLLO 2 and emspi HCI transport
URL: https://github.com/apache/mynewt-core/pull/655#discussion_r150302637
 
 

 ##########
 File path: apps/bleprph-emspi/pkg.yml
 ##########
 @@ -0,0 +1,44 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+# 
+#  http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+pkg.name: apps/bleprph-emspi
+pkg.type: app
+pkg.description: >
+        Simple BLE peripheral application.  It uses the emspi transport (EM
+        SPI protocol).
+pkg.author: "Apache Mynewt <de...@mynewt.apache.org>"
+pkg.homepage: "http://mynewt.apache.org/"
+pkg.keywords:
+
+pkg.deps: 
+    - boot/bootutil
+    - boot/split
+    - kernel/os 
+    - mgmt/imgmgr
+    - mgmt/newtmgr
+    - mgmt/newtmgr/transport/ble
+    - net/nimble/host
+    - net/nimble/host/services/ans
+    - net/nimble/host/services/gap
+    - net/nimble/host/services/gatt
+    - net/nimble/host/store/config
+    - net/nimble/transport/emspi
 
 Review comment:
   I agree - it is kind of ludicrous to create an entirely new app just to change the transport.
   
   I don't know if making the MCU dependent on the emspi transport would work.  The problem there is it prevents someone from using a different transport with this MCU (e.g., ram or uart).
   
   The metapackage idea is not bad.  It would need to know about every transport, and therefore get updated whenever a transport is introduced or changed, but that is probably unavoidable regardless of how we solve this.
   
   Another idea is to just leave it up to the target to bring in the transport dependency.  For combined host-controller, the target would depend on:
   ```
       - net/nimble/controller
       - net/nimble/transport/ram
   ```
   
   For emspi, it would just depend on:
   ```
       - net/nimble/transport/emspi
   ```
   
   ...and so on.  This would put a lot more responsibility on the target.  I'm not sure if that is a good thing or not.  On one hand, it makes sense, because the target remains just a container for dependencies and settings.  On the other hand, it feels like we are just using the target as a convenient catch all for things like this.
   
   The metapackage might make a lot more sense.  I probably need to think about it more or come up with an example.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services