64k RAM seems to equate with large package. I can’t find a small physical size part with 64k RAM.
CypressAtmel 48k RAMAtmel 96k 1M FlashWhat do you think the chances are of fitting the Decawave code into 32k RAM? I think moving away from the nRF51822 will make things a lot bigger. But there might be some new/other products I haven’t found out about yet.
On Sat, Nov 15, 2014 at 6:58 PM, David Carkeek <firstname.lastname@example.org> wrote:
com/question/16825/new- version-of-nrf51822-silicon/The answer from the Nordic guy sure makes it sound like there will be a version that has more RAM.This was written 16 days ago:
sparkle-a-bluetooth-le- powered-spark-core-clone/6108/ 54
So, after all the hard work getting SparkLE working with a “handshake MCU”, there has been an interesting development. I found out a few weeks ago (and Nordic Semiconductor just announced this week) that there will be a new version of the nrf51 chipset with 32K RAM. That means no more need for a second MCU on-board!
Here’s the announcement:http://www.nordicsemi.com/eng/
News/News-releases/Product- Related-News/Nordic- Semiconductor-refreshes-its- nRF51-Series-Bluetooth-Smart- ANT-multiprotocol-SoCs-with- more-RAM-and-ultra-compact- packaging-options/(language)/ eng-GBSo we have to get some samples of the new 32k nRF51822 and mount it on the Ray-Tac modules. I’ll also email Ray-Tac to see if they will be building 32k versions.But is 32k enough?If it’s not we can change directions now and make a board with an M3 and separate BLE radio. That might be best anyway.
If I could just compile the current code then I’d have an idea how much RAM it consumes. Maybe it will fit easily. I’m working on the assumption that we may be able to dump a bunch of functionality from the DW library because we only really need the ranging. On the other hand, it looks like the ranging builds upon the basic packet handling, so there may be a limit to how much it can be chopped.