We really want to work with Nordic, but they makes it hard.

[Bndit]

It seems like a really great company, but after exploring and asking , and searching for a good BLE solution, I just can't find a good fit.

So you want a GOOD processor, and BLE . If you go with the nrf8001 and external MCU you get a pretty old BLE solution, nobody knows if its going to be here next year, AND it requires so many components around it including 2 crystals, which summed up to a price of a BLE module ( around 6$)

If you go with the more advanced solutions such as nrf51 series, you find out that the processors are just there to say : hey we have an ARM inside.

1. No DAC option ( any new ARM has it)
2. No RTC
3. No flash emulator to save stuff between resets / eeprom.

and the list is pretty long, and thats not including long development time.

This is not a rant, quite the opposite, it seems like a great company (and its not from China/ Thailand or whatever) , but every solution you check has at least 1 huge drawback .

Am I completely wrong here ?

[endnode]

Your summary for nRF51 seems to be inaccurate, can you elaborate with some examples what you lack in points 1/2/3 and which competition can offer it? Chip has many HW peripherals, has RTC and TIMER (several of them) and has 256kB of flash. Also why you don't consider nRF52 which is more power effective, has more flash/RAM/peripherals and cost difference is small? To be honest I haven't met better low-power Bluetooth processor on the market, can you hint what can give you more then nRF52?

[Bndit]

Thank you, maybe I am really wrong here. Any new ARM processor has DAC, and really advanced PWM options(not just frq and d.c but phase control and more) , check the SAMD21, a popular one, or any STM, they all have built in DAC, touch processors, full RTC with real dates, and much more options when it comes it I/O . Memory is not the issue, its about what it can do and the supported libraries. How is the new series solves these problems?

[endnode]

Righ, nRF5x chips don't have direct analog outputs, only PWM. It's OK for things like low-res sound output, for HD you should use I2S and dedicated amplifier. It is also OK for any step-motor or similar application. If you need something more accurate or specific then you need to connect discrete solution. When it comes to RTC and calendar/day-time feature: you can write it on top of any 32-bit RTC in 1 day on 500B of code (or 2 days and 1kB, is that important?) but if you want it in HW then again, either external specific component or nRF5x isn't platform for you. It looks like your specific application is one of these few percent which Nordic generic low-power radio chips cannot serve today. It's a pity, on the other hand you cannot design chip for 100% of users. If you find some good competition, let us know!

[Bndit]

Thank you very much. So you say that other then the DAC, we will get everything else on the NRF52 , with more work on our side to write libraries? How developing with Xcode/on a mac is working ? can we blink a led within an hour or is it requires tones of hassles ? I will skip the DAC if its the only thing that is missing from our list, but I have concerns regarding development time to fill this gap.

[endnode]

When it comes to nRF52 hardware features you don't need to seek here, just read it on-line in Nordic Infocenter. When it comes to SDK and "libraries", I can only say that there seems to be examples for all peripherals and also some useful modules, I had always faster development time with nRF5x then with STMicro SDKs for STM32 family, but that's very individual. If you are going to develop the code, you need to download the SDK and dive into it. If you are not the developer, then ask your dev. team to conduct proper feasibility. You seems to be pretty rushing and counting every day of development effort but isn't it even more risky to ask random folks on the internet "how easy is it to develop something with certain platform"?