NXT port -- is it viable?

[JakubVanek]

Hi all,

Question

I would like to ask for your opinion on how likely it is that the NXT port can be brought up to the level of the EV3 port. If there is a good chance that his can be done, it's possible I'll be working on this in the future (not sure yet though).

Context

My motivation behind this is to have a unified programming environment for introductory robotics courses between NXT and EV3. The current solution is a combination of NXC compiled for NXT (BricxCC/NBC) + NXC cross-compiled for EV3 (NXC4EV3, alt. NXT3). However, we might be looking forward to switching to Python because the introductory algorithm course running in parallel is using it too.

My current primary concern is if the hardware present in NXT isn't too limiting. Are 64K of RAM and 256K of flash enough? From what I found about MicroPython HW requirements, it should be mostly OK, but the PyBricks runtime is going to use some part of that.

With regards

Jakub

[JakubVanek]

Oh, I see that #122 exists.

[laurensvalk]

Thanks @JakubVanek --- I think it's still fine to use this separate issue to discuss technical viability, while using #122 to discuss what the user experience should be.

Are 64K of RAM and 256K of flash enough?

That should be fine. It's about the same as on City Hub (32K, 256K).

For comparison, Move Hub has 16K RAM and 128K flash. This is getting problematic. It's going to need a feature stop (not enough flash), and we had to reduce user heap recently (not enough RAM).

[laurensvalk]

This is a very old demo that may or may not still work. It was essentially a test to run Pybricks using low-level drivers that I extracted from LeJOS.

[JakubVanek]

Are 64K of RAM and 256K of flash enough?

That should be fine. It's about the same as on City Hub (32K, 256K).

For comparison, Move Hub has 16K RAM and 128K flash. This is getting problematic. It's going to need a feature stop (not enough flash), and we had to reduce user heap recently (not enough RAM).

Thank you, this looks promising. I recently briefly saw an issue where the core of the problem was running out of memory and I was afraid that NXT would be affected by this too.

[laurensvalk]

I would like to ask for your opinion on how likely it is that the NXT port can be brought up to the level of the EV3 port. If there is a good chance that his can be done, it's possible I'll be working on this in the future (not sure yet though).

It depends on what you mean by the level of the EV3 port, but much of it is certainly possible. While some of the high level stuff from #122 is certainly important, a lot of the NXT experience is already defined, including the end-user API for motors and sensors, and most of the brick too. This therefore even includes some of the implementation as well.

Since you forked it, you have probably studied some of the Pybricks source code in some detail already. As you might have seen, we have pbio for high-level hardware-independent drivers such as generic PID controllers. And then we have pbdrv for hardware specific drivers. For this proof of concept, we've made pbdrv call functions from the LeJOS C API. Now that we know that it can work, it could perhaps be done more directly instead of having this additional abstraction layer.

While we don't currently intend to focus on NXT actively, we're certainly happy to discuss more technical details at some point if you're serious about considering working on this.

[JakubVanek]

I would like to ask for your opinion on how likely it is that the NXT port can be brought up to the level of the EV3 port. If there is a good chance that his can be done, it's possible I'll be working on this in the future (not sure yet though).

It depends on what you mean by the level of the EV3 port, but much of it is certainly possible. While some of the high level stuff from #122 is certainly important, a lot of the NXT experience is already defined, including the end-user API for motors and sensors, and most of the brick too. This therefore even includes some of the implementation as well.

I didn't have anything specific in mind, I just remembered that the NXT port is not fully supported/advertised. I haven't thought about the APIs yet, this will simplify the design phase.

Since you forked it, you have probably studied some of the Pybricks source code in some detail already. As you might have seen, we have pbio for high-level hardware-independent drivers such as generic PID controllers. And then we have pbdrv for hardware specific drivers. For this proof of concept, we've made pbdrv call functions from the LeJOS C API. Now that we know that it can work, it could perhaps be done more directly instead of having this additional abstraction layer.

I have studied it only briefly a while ago, however I was a bit confused about what goes where (at the time, I was curious about how sensor hotplug is handled). This explains it, I will look into pbdrv more.

While we don't currently intend to focus on NXT actively, we're certainly happy to discuss more technical details at some point if you're serious about considering working on this.

Thanks! I need to think this through yet, but if I decide to go with it, I'd be grateful for any help.

[skyloft7]

I currently have an NXT sitting at home, a port of MicroPython would be cool,
https://github.com/pybricks/nxt-firmware-drivers looks promising.

[dlech]

Closing as duplicate of #122.