ARMmbed / mbed-hal-nrf51822-mcu

mbed HAL port for nRF51822
9 stars 12 forks source link

referenced target dependency 'mbed-hal-nrf51-generic' not available #43

Open bearsh opened 8 years ago

bearsh commented 8 years ago

I'd like to use the mbed OS stack on various custom targets (different devices all using a nrf51822 module). Therefor the mbed-hal-nrf51-generic target might fit my needs (at least the name does indicate that) as e.g. the mbed-hal-nrf51dk specifies pins which only exists on the dk hardware. But unfortunately the mbed-hal-nrf51-generic is not published :unamused:. In the end, I'd like to name my hardware specific pins in the target used by yotta target.

0xc0170 commented 8 years ago

I can't locate this module in the tree (example blinky, for mkit-gcc or nrf51dk-gcc), neither in the yotta registry.

Isn't this HAL module generic HAL for nrf51822 device family: https://github.com/ARMmbed/mbed-hal-nrf51822-mcu ?

cc @marcuschangarm

bearsh commented 8 years ago

it looks like the be a generic HAL module, so exactly what I am looking for. so if there no such module, either let's create one (a really generic HAL module) or delete the reference in module.json. I'm definitely for the first option as I thinks that's what most users of a low cost module are after, unless I completely misunderstand the concept behind this HAL inheritance...

ciarmcom commented 8 years ago

ARM Internal Ref: IOTSFW-1912

0xc0170 commented 8 years ago

The generic is not needed, if we look whats in mbed-hal-mkit, it's just init hal function definition and device header file, which I believe are same for all our nrf51 based targets. We should have a look, and eliminate this.

The target hal repo should be replaced by target + config.

ghost commented 8 years ago

ATM it's pretty impossible to use your own nrf51 based targets due to the inverted dependency structure of this module. Any idea when that will be resolved? I have to maintain my own fork of this just so I can use a blenano

0xc0170 commented 8 years ago

due to the inverted dependency structure of this module.

Can you be more specific?

We got a concept for new target structure. In the meantime, we can improve what we have.

cc @pan- @emidttun

bearsh commented 8 years ago

I think he means what is caused by:

# Need to setup PLATFORM_SPECIFIC_HAL_LIB which will be added as a link
# dependency. This link dependency could have been automated by yotta, but
# requires an extra step for now.
if(TARGET_LIKE_BBCMICRO)
    set(PLATFORM_SPECIFIC_HAL_LIB mbed-hal-bbcmicro)
elseif(TARGET_LIKE_SEEEDTINYBLE)
    set(PLATFORM_SPECIFIC_HAL_LIB mbed-hal-seeedtinyble)
elseif(TARGET_LIKE_MKIT)
    set(PLATFORM_SPECIFIC_HAL_LIB mbed-hal-mkit)
elseif(TARGET_LIKE_NRF51DK)
    set(PLATFORM_SPECIFIC_HAL_LIB mbed-hal-nrf51dk)
elseif(TARGET_LIKE_NRF51_GENERIC)
    set(PLATFORM_SPECIFIC_HAL_LIB mbed-hal-nrf51-generic)
else()
    message(FATAL_ERROR "Missing PLATFORM_SPECIFIC_HAL_LIB")
endif()
ghost commented 8 years ago

yes, there and in the module.json file. you have to add it in both places.

bearsh commented 8 years ago

furthermore atm with this structure the mbed-hal-XX component defines 'too much'. to use my own target I either have to fork this module or let my target depend on e.g. mbed-hal-mkit. but doing so, all the 'device features' (device.h) are set. to be more specific, my target e.g. doesn't support DEVICE_ERROR_PATTERN as it doesn't have any Leds. a possible short therm solution would be to simply publish the *-generic target where only a minimal set of features is defined... but now I wondering if how to re-enable features then?

marcuschangarm commented 8 years ago

@bearsh Would this module be useful for you? https://github.com/ARMmbed/mbed-hal-nrf51-generic

I forgot to make it public but it should be now.

bearsh commented 8 years ago

@marcuschangarm probably yes, but a first look at it showed it also defines DEVICE_ERROR_PATTERN which, if I remember correctly, needs some Led pins defined

marcuschangarm commented 8 years ago

I don't have leds on my board, so all LED0-4 are defined to be NC.

bearsh commented 8 years ago

well yes, but in my opinion still not ideal... while trying it out, I also came across other pin names which need to be set it the target.config: LED{1..4}, TX_PIN_NUMBER, RX_PIN_NUMBER, RTS_PIN_NUMBER, CTS_PIN_NUMBER which seems a little bit odd to me

emidttun commented 8 years ago

Seems like the real problem is in the difficulty in creating a new target rather than the missing generic one. Is it possible to use for example nrf51dk- and only use pin names, not LED assignments and so on?