Hacker News Reader

Comment by scoot | Hacker News Reader

"While the BBC micro:bit has Bluetooth Low Energy (BLE) hardware it only has 16k of RAM. The BLE stack alone takes up 12k RAM which means there’s not enough room to (currently) run MicroPython.

Future versions of the device may come with 32k RAM which would be sufficient. However, until such time it’s highly unlikely MicroPython will support BLE." [1]

That's a shame. I mean, I know it can be accessed by programming the hardware directly, but for most of the kids receiving these that puts BLE out of reach, when remote sensor, remote control & mesh network type capabilities would have opened up another whole class of projects that these could have been used for.

Would another 16K of memory really have pushed the price out of range, or was this more a question of the hardware design being finalised before the software stack?

[1] http://microbit-micropython.readthedocs.io/en/latest/ble.htm...

View on HN

respectfully, that's missing the point.

The beauty of the BBC Micro is the stark hardware specification -- the limits are the point. That scarcity leads to different usage, different behavior, different learning patterns.

If one wants to go poking around with modern languages, multi-tier applications, color-coding IDEs, etc. there is no shortage of modern computers available.

But instead, if one wishes to learn the fundamentals of computing, and the joys of working around the limits to extract the most performance possible, I would argue the BBC Micro is a superior choice to modern systems inherently due to the low spec.

It was a mere 40 years ago that 16kbyte of RAM was a luxury item.

IIRC, Wozniak wrote Applesoft Basic interpreter in 2k for the Apple ][ ROMs. He lost the source, re-wrote it, and saved a few bytes.

Learning assembly was a necessity for the purpose of speed and efficiency (which are often inseparable). Understanding what's happening at a low level -- all the way down to the metal -- is key. Single thread. No real OS. Flat memory model, all addressable (anyone remember the fun of self-rewriting code? or direct-memory mapped graphics or I/O ?)

I've rambled enough. Hopefully I've made a point.

> respectfully, that's missing the point.

On the contrary, it seems you have missed my point, or at least, nothing that follows that statement directly contradicts it.

Speaking of which, you state that the BBC micro:bit (the BBC Micro was a very different computer) is good for education, which I would certainly hope, since that's what it was designed for. However suggesting that teaching assembly language to 11 year olds is a good way to encourage them to explore and engage with the platform is missing the point (of the micro:bit).

High Level language statements can be easily translated to ARM assembly language(http://www.toves.org/books/arm/), easier than x86 in my opinion. 11/12 year olds should have no problem understanding it, after they've played around with the provided options for programming the micro bit. (https://www.microbit.co.uk/create-code)

scoot, I offer my apologies. You are correct -- I read too much into what you said (limitations on bluetooth due to RAM scarcity), and took off on a tangent.

I remember small machines. A PDP11 got hung and the manager called me. I thought a bit, talked him through the debugger and got him to put in a jump to avoid a check. Hit RUN and back in business! We don't do things like that anymore.

I agree that the BBC Micro would be a great learning computer. The gap between a hobby program and commercial software is small - you don't get the training wheels feeling as with some other environments. Unfortunately the Micro:bit is not self hosting and not at all a suitable replacement for the BBC Micro, in my opinion.

That would increase the price significantly since they would need to move to nordicsemis new M4 devices. And yes, 16K RAM is pretty huge by segment standards.

Your best chance is if someone can optimize the BLE stack to use less RAM. After all, people have written ipv6 stacks that need a fraction of that.

The nrf51 is available with 32K RAM, but only in combination with 256K of flash, designated with the AC suffix (AA: 16K/256K, AB:16K/128K, AC:32K/256K). The 32K chip has been shipping on Adafruit's boards for a while, and is now even shipping on some of the generic Chinese dev boards and modules, so I assume it's widely available.

I imagine the main reason for going with the cheaper chip is that micropython was a pretty late entry to the list of supported coding environments, and the hardware was probably already pretty settled before the port started. Also BLE+4K of ram is probably usable in the other official (compiled) languages, and micropython does otherwise work aside from something that's a fairly advanced feature. So it would have been a tough sell increasing the cost of every board when most students and lesson plans will never use BLE and there are other languages available if they do want it/need it.

Why does the fact it can't run micropython and BLE at the same time put BLE out of reach?

The point is you want to be able to program on the board rather than having it be useless without attaching it to a PC. For that you need both IO and an onboard compiler or interpreter.

MicroPython is right out; it would almost fit Lua, but as it is it looks like your only option for independent development would be Forth.

You can flash it over Bluetooth?

No. The point is being able to do development live without needing to upload a new image every time you want to try something new.

Reply on news.ycombinator.com