Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI-Nspire => Topic started by: Vogtinator on November 22, 2014, 09:55:42 am
-
So, as there is gdbstub in nspire_emu and OCD (http://ndlessly.wordpress.com/2012/04/09/introducing-ocd-the-ti-nspire-on-calc-debugger/).
I thought about combinging these two and support native GDB debugging on calc either over serial or USB with NavNet and libti*/libnspire
Would there be interest in this? If yes, USB or serial? Both have some downsides.
-
I know it might be (much) more complex, but what about having the TI-Nspire behave as an RNDIS network device (or similar, the same way as the CAS+ works)? The TI-Nspire uses the BSD usb implementation so it might be possible to use it as network gadget. That way you could have the GDB stuff over a socket.
-
If the usb gadget api functions were known it'd be possible, but for now there are only the usbd_ functions, which don't support gadget mode, do they?
Otherwise it would be easy to implement the MTP protocol for easier file transfer as well.
-
Ah, I didn't check what API functions were exposed. I never really looked into the usb library.
In any case I think it can be very interesting, mainly USB debugging considering that most people don't have an RS-232 TTL level adaptor.
-
Hmmm, why not just hijack the USB controller and run a better USB stack of our own ? I think this would solve the issue of not having control over it (if it's not too much of a complex solution).
Also, having a serial console over the USB port in addition to GDB and a better file transfer protocol would rock.
-
Yeah, a custom USB stack for device mode would be great, but much work. You can read http://wiki.osdev.org/USB (http://wiki.osdev.org/USB) to get an idea on how insanely much work that'd be.
It may be possible to adapt an existing stack though, for example from libraries for microcontrollers.
-
Yeah, I've heard about how much of a pain USB is. <_< I didn't want to implement a stack from scratch lol, that would take years.
-
libusb (https://github.com/libusb/libusb)?
-
That's the wrong side. libusb is for Host (PC) -> Device (nspire). What we're searching for is on the device side.
-
It's definitely possible to debug the calculator through serial. GDB has built in support for attaching to serial.
I actually wrote an implementation of the GDB server protocol for one of my projects with breakpoint support and everything. I'll post it up if I find it.
Incidentally, the project I used this in was in writing a minimal USB stack for the TI-Nspire - the lesson learned: it's hard. If anyone wants the full source code of the project (it's pretty much dead now), I'll be glad to post it. The USB stack has enumeration working but no actual transfer of data.
-
It's definitely possible to debug the calculator through serial. GDB has built in support for attaching to serial.
Yeah, as long as data can be sent and received, GDB supports it.
I actually wrote an implementation of the GDB server protocol for one of my projects with breakpoint support and everything. I'll post it up if I find it.
Is it better than nspire_emu's?
Incidentally, the project I used this in was in writing a minimal USB stack for the TI-Nspire - the lesson learned: it's hard. If anyone wants the full source code of the project (it's pretty much dead now), I'll be glad to post it. The USB stack has enumeration working but no actual transfer of data.
Host or device stack? Host wouldn't be so interesting, as the BSD api is already working. Or does the device side also require enumeration?
-
Is it better than nspire_emu's?
Depends on whether you like GDB better or the nspire_emu debugger better :)
Host or device stack? Host wouldn't be so interesting, as the BSD api is already working. Or does the device side also require enumeration?
It's a device stack.
-
Is it better than nspire_emu's?
Depends on whether you like GDB better or the nspire_emu debugger better :)
I meant nspire_emu's GDB stub.
Host or device stack? Host wouldn't be so interesting, as the BSD api is already working. Or does the device side also require enumeration?
It's a device stack.
Then the source code would actually be quite interesting. Is it for CX, Classic or even both?
-
I'm not sure nspire_emu's GDB is much used, neither is OCD. So you wouldn't find a broader audience, but it would indeed be technically interesting :)
-
Well, the reason I don't use GDB is because it's not supported for the make-prg'd Zehn files (is that still true?), and I use 3.1 for testing stuff (because it's faster, especially with file transfers). If Zehn support is backported to 3.1, I'll probably use it.
-
Well, the reason I don't use GDB is because it's not supported for the make-prg'd Zehn files (is that still true?)
Only on 3.1, if you use 3.6, you can debug all Zehn executables, even in PRG containers.
and I use 3.1 for testing stuff (because it's faster, especially with file transfers). If Zehn support is backported to 3.1, I'll probably use it.
It's not that hard, the easiest way is probably to make the ndless_resources from 3.6 backwards compatible for 3.1. Just a few lines, I'd imagine.
-
and I use 3.1 for testing stuff (because it's faster, especially with file transfers). If Zehn support is backported to 3.1, I'll probably use it.
It's not that hard, the easiest way is probably to make the ndless_resources from 3.6 backwards compatible for 3.1. Just a few lines, I'd imagine.
That would be quite useful indeed, aeTIos and I develop on 3.1 as well.
-
Despite my limited spare time, I had to try it and it was just a bit of copy & you can guess the rest :P
Tested on emulator CX CAS 3.1.0.392 and 3.6.0.something, not on other models so it may even crash on startup which would be annoying.
The ndless_installer from 3.1 still has to be used. Tell me if it works, although some weirdness with lua and similiar things are expected.
You have to rename the file to ndless_resources.tns of course. Then reboot and you're good to go.
It doesn't support ndless 3.1 uninstallation!
-
Hehe nice, I hoped for Ndless 3.6 to be cross compatible since the day it came out. :P This should be mainlined. :)
-
I thought it already was? ???
-
It was possible to run most 3.1 programs on 3.6, but not to use ndless 3.6 on 3.1 OSs.