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]

Two more notes: there are several blog posts and tutorials how to develop on MAC for nRF5x so that shouldn't be a problem. And to "really popular SAMD2x and STM32": I guess you know that Atmel and ST Micro also offer BLE chips, but you ended up on Nordic forum anyway. That probably has a reason...;)

[Bndit]

@endnode, thats correct, I really like Nordic, and maybe I am just rushing for no reason ( starting a startup is stressful ) . I am asking you because you know better, you are not random people on the internet. I think you right and I might use the nrf52. I just have concerns where I used to do the simple things using cool libraries, and here you have to build most of them by yourself in order to get the exclusiveness of using a single chip, and also learn a new IDE, set it up, etc. I hope that the bluetooth software is relatively no that hard(?). Thank you very much.

[endnode]

Bluetooth software not so hard?:) Again that is largely individual: BT LE stack and Nordic's implementation is pretty rational and easy to learn if you are coming from some "bare metal, performance and code size restricted and async" platform but it can be nightmare if you come from some "Arduino IDE where we code embedded apps by pasting colorful boxes into single threaded stream of oversimplified function calls":)

[Bndit]

@endnode So in other words you say that I get a bad user experience only to feel very smart that I am using a SoC, where at the end the processor can do the exact same things and even less? That is exactly what Steve Jobs was about - and also Arduino, you can make fun of it, but you simply open an IDE and blink a led. If I have to do so many things (as turns out) just to toggle a port, where most applications including space ships does not require more then that, then we are just going back to the 90's and it doesn't matter how many threads you have in your MCU.

[endnode]

No, what I'm saying is that if you like that style of programming without deeper understanding of the architecture (and thus not being able to utilize its full potential) but you like to code simply and fast then there are IDEs and nRF5x set-ups like mBed. However in the end you run application on top of another time-sensitive application (= BLE stack) and if you are not careful you simply hit the wall (by adding some busy loops to simulate delay or other intensive function calls) without easy way to debug. So that was a friendly warning, not shaming certain IDE or coding practice. In the end unless you really need low-power SoC just buy RPI Zero or similar platform, cost wise it's close (or even less!) than many nRF52 boards/modules and you can utilize full rich-OS (Linux kernel) with tools like Python. That's what I call simple and fast way.