Maybe just a tease? :-)
Maybe just a tease? :-)
What's new in the nRF52 series? A lot I can tell you ;)
And in about two months time we will finally be able to talk about it :)
Isn't the nrf51 on a 180nm process? From the TSMC press release they are switching to a 55nm process. So that is a ~10x increase in the transistor budget for the same sized die. Think of all the interesting things you could do with 10x the transistors.
I hope they switch to at least a M0+ to get rid of the interrupt trampoline sillyness.
A low frequency/voltage M0+ for the BLE stack and a higher frequency M[34] for the user app would be an 'easy' way to decouple the stack from the user app.
More universal DMA support (ie DMA for ADC, SPI, UART, etc). With my nrf51 design I'm spending way too much time servicing the SPI and I2C. I should just be able to set up a DMA and clock out a few K of data to the SPI bus without having to take an interrupt on every byte.
Capacitive sense hardware that only needs to wakeup the CPU on touch event would be much appreciated.
Isn't the nrf51 on a 180nm process? From the TSMC press release they are switching to a 55nm process. So that is a ~10x increase in the transistor budget for the same sized die. Think of all the interesting things you could do with 10x the transistors.
I hope they switch to at least a M0+ to get rid of the interrupt trampoline sillyness.
A low frequency/voltage M0+ for the BLE stack and a higher frequency M[34] for the user app would be an 'easy' way to decouple the stack from the user app.
More universal DMA support (ie DMA for ADC, SPI, UART, etc). With my nrf51 design I'm spending way too much time servicing the SPI and I2C. I should just be able to set up a DMA and clock out a few K of data to the SPI bus without having to take an interrupt on every byte.
Capacitive sense hardware that only needs to wakeup the CPU on touch event would be much appreciated.