Search results

Since execution is a round robin, it could also be a linked list that would just grow as needed. I decided not to do that to avoid dynamic memory allocation whenever possible, but the unfortunate side effect is a compile-time limit on the number of threads.

I committed the change to github along with a few other tweaks. I don't know if it will make it into Teensyduino this time around.

I suppose the easiest thing would be to just increase the number in github. It should have very minimal impact. Do you guys think 16 is good for the maximum number of threads?

There's a trick that's used in most threading systems. You pass the class instance as a parameter: MyClass serobj; void runThreadStatic(void *obj) { ((MyClass *)obj)->runThreadMethod() } void setup() { threads.addThread(runThreadStatic, &serobj); }

I'm the module author. Thanks for debugging this setup. If you send me the specific steps you used to get this working I can add it to the README.

1. The library, as currently written, doesn't halt the Teensy on startup. So your "starting" point is not reliable. Right now, you have to either use "halt()" in your code or place a breakpoint and do a continue "c". Do you think maybe it should just halt on startup? I think that mirrors what...

I changed the API for setBreakpoint and removed the numbrer. Just call: debug.setBreakpoint(testme) The code was in a comment in the examples so I missed it. The first Warning is not a problem. I'll have to do more research to eliminate it.

I'm guessing you've got the USB Serial names reversed. Arduino thinks COM52 is the first serial port. Did you try changing the Port from the menu?

I presume this is Windows? Is the file teensy_debug.exe in the right location? I wonder if the mixed use of "/" and "\" might be a problem? In any case, all teensy_debug does is try to figure out what serial port to use and call up gdb in a separate window. You can do that manually as well as...

The installer is looking for a directory "hardware/teensy" inside your Arduino directory. If it's not there, it complains. Since you have a non-standard install, it's probably best to just set up manually. Look at the README.md file and follow the steps in "Installing overview".

Thanks for the heads up about the warnings. I'll fix that. I suppose "O0" is not really needed. I just put it in so that the compiler won't optimize away functions and lines in my trivial examples.The "Og" supplied by the compile line should suffice. Perhaps it's confusing and I should take it out?

Take over Serial is a bit tricky. It works by using a "#define" to redirect "Serial" to "debug" in TeensyDebug.h. The "debug" object will format data so that GDB will print it. If any of your sketches use the Serial device, they have to do this or include "TeensyDebug.h", which does this (line...

I fixed support for Teensy 3 to git. It should work now using the Flash Patch feature to set/clear breakpoints in Flash. You can have a maximum of 5 breakpoints. Stepping line-by-line over the end of a function (and returning to the previous one) does not seem to work reliably. Stepping within...

I just found this project and wanted to mention a similar project I've been working on that does allow dynamic breakpoints and code stepping: https://forum.pjrc.com/threads/61373-Using-GDB-with-Teensy-without-hardware-debugger-first-Beta?p=243823#post243823

For what it's worth, this is not too bad: https://www.gdbgui.com/ You can create a file `customize.py` in the `....hardware/tools` directory with the below (changing the path for 'g') and it should start that up instead of the xterm. import os def customRun(gdb, dev, elf): g =...

It's a bug. I updated the install script to accommodate a missing /usr/local/bin/arduino.

RAM in many embedded systems, including Teensy, is divided into three parts: 1. Static variables - fixed size at the start of RAM (may also place code here) 2. Heap - allocated with new() and malloc() starting at end of static and growing up 3. Main stack - starts at the end of memory and grows...

This is a bug with the shenanigans I have to pull to get GDB to work calling code dynamically. I just committed some changes that may fix this most of the time. As for the T3, I had a plan using FP_REMAP and associated functions and it's mostly coded and works so-so. I would devote more time...

An excellent suggestion. Added `debug.isGDBConnected()`.

It wasn't documented (I just added it), but object `debug` inherits from class `Print`. Thus it supports print, println, etc. to print to the GDB console. debug.print(testvalue, HEX);

I updated Github today with these fixes: 1. Reduce serial polling to 0.5 milliseconds. This should increase responsiveness. Will look at alternatives @defragster suggested. 2. Fix `p func()` that allows you to call most functions from GDB when it is stopped. 3. Improve install script. 4. Fix...

Breakpoints are slow because TeensyDebug only processes GDB commands every 5ms. When a breakpoint is hit, Teensy notifies GDB right away. GDB sends a number of commands (clear breakpoints, get registers, set breakpoints, continue). Each one is processed every 5 ms. Thus, we're looking at at...

All it does is: 1. copy the source files (*.cpp, *.h) to a directory named TeensyDebug in your library directory 2. customize and copy boards.local.txt and platforms.local.txt to ...Arduino/hardware/teensy/avr (a) change platforms.local.txt to use "teensy_debug.exe" instead or "run.command"...

Run the install program with the -i option as in: teensy_debug -i=c:\Arduino-1.8.12

That extra "noise" could be some other library sending data over the serial port that GDB is using. In any case, I moved the discussion to it's own thread since the origin of this thread is not not very relevant...

I moved the discussion to a new thread since this is not really related to the original question: https://forum.pjrc.com/threads/61373-Using-GDB-with-Teensy-without-hardware-debugger-first-Beta?p=243219#post243219

I put together a library that allows GDB (included in Teensyduino) to perform source-level debugging on the Teensy without debugging hardware (no need for JTAG, SWD, etc). It uses GDB's Remote Serial Protocol to communicate with Teensy over a Serial connection (physical or USB). No extra...

I was really excited when I first saw gdb-py. It's too bad it is missing the python library, as you noticed. It probably should have been statically linked. It's useless as it stands. Python is not strictly needed. It was just easier for now to code the wrapper that uploads the code and then...

I just realized that there is a tool "arm-none-eabi-gdb-py", which is GDB with an embedded Python interpreter. If `run.command` (the Python component that adds the menu & opens GDB automatically on a Mac) can be ported to this, then all external dependencies can be removed.

I put together some code that allows GDB to perform source-level debugging on the Teensy without an external debug interface (no need for SWD, etc). It uses GDB's Remote Serial Protocol to communicate with Teensy over a Serial connection (hardware or USB). This is a beta release for comments and...

That's what I'm hoping to do. I've got something minimal working and it's all looking very doable on the Teensy 4. Hopefully I will put it on github over the weekend for testing/feedback. I also figured out the hardware pings. We can use the "monitor" command to trigger the Teensy to do things.

Everything is doable except to set/clear hardware pins. The gdb remote protocol (https://sourceware.org/gdb/current/onlinedocs/gdb/File_002dI_002fO-Remote-Protocol-Extension.html#File_002dI_002fO-Remote-Protocol-Extension) doesn't seem to support anything like arbitrarily running code on the...

I just realized that the Teensy 4 places all user code in RAM so setting breakpoints in this way should work fine.

GDB stubs on Teensy proposal I gave this some thought over the weekend and I think live debugging is possible even if C_DEBUGEN cannot be changed. The idea is to use a GDB stub to remotely debug the Teensy and instead of using BKPT, using SVC. This proposal will enable limited breakpoints and...

That's unfortunate. The previous threads also suggested using Flash Patch Control Register FP_REMAP to do something similar to a breakpoint by remapping the instruction to a fault of some sort (or, it occurs to me, to the SVC instruction). However, the Cortex M7 that the Teensy 4 uses does not...

I was hoping that the Debug Monitor ISR would help with a low level project. After reading https://forum.pjrc.com/threads/26358-Software-Debugger-Stack and https://forum.pjrc.com/threads/28058-Teensyduino-1-22-Features?highlight=C_DEBUGEN. I'm having difficulty following the instructions to turn...

Great catch! I have committed your suggested change to github.

Compiling Rust code is possible, but not within the Arduino IDE [1]. You need to create a Makefile. For example, if you want to include a function from rust, you would code it as follows: #![no_std] #[no_mangle] pub extern "C" fn run_main() -> isize { 42 as isize } use...

Looking at it now, it does seem like the priority thread support is not implemented very efficiently. If I recall, I added it at a later time. It was really just a way to give a boost to threads that had been suspended via a lock. Maybe it's best to just get rid of priorities. It doesn't make...

Very interesting. You can, of course, add your own implementation of the TeensyProf_open(), TeensyProf_close() and TeensyProf_write() functions to send the output to where you want. They're very simple and emulate the standard library open(), close() and write(). I have included 4...

You can look at TeensyFile.cpp for the very simple format used. You can also configure it to write out the file using hexadecimal and then use something like hex2bin to convert it to a file.

Yes. Don't use -pg on c or S files. Have you tried it with the Arduino app, as described in README.md? Also, I'd like to see the complete command line options used for each compile to see if it's different than how my system compiles it. It doesn't seem like the errors shown have anything to...

I suppose we could test more frequently, but it may not make a difference. gprof is a sampling profiler so it relies on statistical distributions. If you run it for 1 minutes (60000 samples), it will catch the biggest offenders at the risk of missing out on small fry. For more details on why...

That's a sophisticated Makefile. As a first pass, remove FLAGS_COM from C_FLAGS and S_FLAGS. You probably don't want to put instrumentation on the core teensy files. Can you remove the "@" silencing prefixes and post the output of a clean build so we can see exactly all the commands and...

One theory: I believe this happens when you use the "-pg" option in the link stage. This is why the "boards.txt" file adds a new parameter "profile" with "-O0 -pg" and then only adds it in "platform.txt" in the compile stage of C++ files. If you just add it to the "optimize" parameter in...

I think it would still be useful to see per-thread CPU usage, but profiling is probably more useful. FYI, I just created a new TeensyGProf that's even better than TeensyProf. See https://github.com/ftrias/TeensyGProf On the forum...

Unsatisfied with the limits of this library, I decided to do a more complete implementation of gprof. I used this previous work by Erich Styger as a guide: https://mcuoneclipse.com/2015/08/23/tutorial-using-gnu-profiling-gprof-with-arm-cortex-m/. Clearly, I have too much time on my hands. The...

I forgot to mention this other modification: Modify `imxrt1062.ld` in the directory Arduino.../Contents/Java/hardware/teensy/avr/cores/teensy4. All references to `.text.itcm` must be changed to `.text`. Gprof expects the code to be in a segment named `.text`.

I should have explained more. When compiling ends, it copies the elf file to /tmp/build.elf. Then the program uploads and runs as normal. When the profiling ends, the Teensy (using the library) sends a specially formatted data to the serial port. There is a python program listening to the serial...

I created a project to partially support gprof-style profiling of applications on Teensy 4. This shows how much time is spent in each function. In theory, this could also work on Teensy 3, but it doesn't have enough memory to do it well so I didn't implement that yet. This is the repository...