Search results

Maybe some additional notes; solutions have been presented already. The actual problem is a mix of memory usage, memory layout and the fact there is no MMU which could catch such faults in a somewhat more visible manner. As outlined, the heap is used heavily. The heap grows from the bottom...

In a way, yes. With optimizations you may have multiple source lines getting merged in a way, which makes at times difficult to say where one line of original source ends and the next starts. To know what is really going on you have to go through the assembly yourself. That also implies knowing...

Somewhere in the whole Teensyduino tree should be the cross toolchain related files (cross compiler and binutils), which includes gcc/g++, ld, as, strip, but also objdump of some kind. This can be used to show the assembly of the resulting ELF binary, using -d or -D, maybe in combination with -S...

Which effectively goes back to malloc() and free(). I tested these on a Teensy 3.2, and while decently fast, it doesn't cover the case of overallocation properly. Having the stack at the upper end of memory probably causes stack corruption and thus the "looks stuck" diagnostic in the test I did...

Ok, sounds like you have full control over the CAN bus. Anyway, maybe some points to think about ... First question is always the overall design. Is the Teensy part of the core functionality or some add-on, i.e. the device where you integrate the Teensy really depends on it or obtains...

Why CAN? Is there anything else connected to the CAN bus, and if so, do you know what protocol to use for proper update procedure? Curious ...

To run something barebone on a Teensy, there is more needed beside hacking programs together, i.e. you need to know how to mess with linker scripts, section placement, init code (usually done in assembler), provide certain low-level basic library functionality etc. After that you have to write...

Recently I had to check into that, but don't have the details at hand right now. I need 3 pins for each ADC, and afaik I need to solder 1 or 2 inputs on the lower side of the T3.2. Means if you need 1 pin per ADC it should be possible without resorting to that; best is to check the pinout...

The ADCs support HW averaging of up to 32 steps per sample, if you want some added quality. However, it won't render the oversampling obsolete entirely. What you can do then is to use the PDB. If I'm correct the ADC library supports this, but I dunno up to what degree. In theory you can read 4...

Datasheet says GND-0.3 to V[DDA]+0.3 Volts (maximum ratings) for any analog input. V[DDA] is rated to 3.6V, so -0.3V to 3.9V, assuming that GND is 0V.

Before I actually started my bare metal stuff on Teensy I was pondering the idea to use Rust on it. I skipped on that in the end because of the implied porting and runtime/size overhead, but that would be the way for me to go if I ever decided to use something closer to a scripting language on...

In return, if done right, (host) drivers for ?HCI are portable, assuming you have enough resources to run them in the first place. That is a big plus in the cost efficiency department, because you don't have to reinvent the wheel each time you move to a different SoC (family). For spare time...

Maybe let me outline this in a bit more detail. The last line assigns a function to an interrupt/exception. At the lowest level there is an exception/interrupt vector table, which is managed by the library code you are using; in the end, if the CAN message IRQ gets triggered, your function will...

Haha, that is awesome! Once my sound project is up and running I was thinking about juicing things up a bit. This is great input for my brain coming up with more strange ideas :D

Ideally, you are right, but this is sometimes easier said than actually done. If I grab a library, put some of my code plus a library call enclosed in disable/enable IRQ, I may already end up with such a scenario. This opens up a set of questions:Is disable/enable IRQ really required in this...

The two links I found pretty enlightening in this whole context were: Cutting Through the Confusion with ARM Cortex-M Interrupt Priorities How to properly enable/disable interrupts in ARM Cortex-M?

Yes. I made saving the status explicit, though (return value in disable, argument in enable), which also gives me greater flexibility in shifting the calls around if I really need it. Usually you keep them on the same level and close together, as you've outlined already. I read into that a bit...

Actually it is virtualization, which implies having multiple threads, among other things. And this is not even theorizing, this has been done already for example in phones, cars, airplanes etc. But this is just a note on the sideline :) I had a look at various libraries, and the ones I'd call...

There is a difference between trying to write a single byte/char and a whole matrix, i.e. if you want to send the entire matrix you have to iterate over all the elements and print them each on their own. The errors you see is the compiler trying to match a print() method closest to the types...

Sorry for the late reply. This weekend I've been a bit busy :D Instead of messing around with your Linux distro you can try to extract an existing x86_64 libpng12.so.0, i.e. from one of the more recent Debian or Ubuntu repositories (assuming that Kali Linux is .deb/Debian based, haven't looked...

Executable access rights etc. are ok? If so, then try "ldd ./teensy" in that directory and see if there are any problems (i.e. missing library links).

Might wanna go the #ifdef route. If you want somewhat cleaner code, check out this post (solution is further down, copy&paste might fail due to G+ having messed up stuff). That allows you to write this #ifdef handling like normal code (if (is_set(...)) { ... }), if you want to keep your code...

If I remember correctly, the default setting for the Teensy 3.2 was 96MHz (overclocked). For your task you don't need that much processing power; might wanna lower the SoC clocking to something less (Tools -> CPU Speed ...).

If I start a new sketch and add the SD library to it, I have 2 #include definitions: SD_tr3.h followed by SD.h. Maybe that is the missing part in your code?

That is the way to go and has been used back in time in the likes of Atari 2600 etc. Contrary to these it is a "tad" bit more complicated due to the complexity of his image (you have to keep track of a good few things to render it line by line). If it really comes to that, maybe some additional...

I'm not really a hardware guy, so there might be different opinions on that. Personally, I would just solder a new K20 chip on the custom board and use JTAG to flash it. Much easier, you don't wreck your Teensy (i.e. can use it for more prototyping work), and you get JTAG for all the not-so-nice...

So I suppose you are using that FlexCAN library referenced elsewhere in this forum? There are a few things I noticed while looking through that code:It sets the CAN controller to Rx FIFO mode. That is important for the interrupt mask and flag handling stuff.The read() method seems to fiddle...

As far as I see it from my uneducated view: Main intention to have ssize_t is the use as a return type to offer a size_t type return value with the addition of -1 to denote some error condition. Following that line of thought it would need to be 1 bit wider than size_t, but in the real world...

Well, your code snippets are missing certain CAN controller related configuration, which also includes interrupt masks and stuff like that. Also, your ISR (tester()) needs to acknowledge the interrupt source, i.e. has to write to the CANx_IFLAG1 register, otherwise the CAN controller will never...

I'd like to mess around with an electric guitar ... First off, I want to have a dedicated pickup for each string along the lines made available via "Ubertar Hexaphonic Pickups". Instead of having complicated wiring going out of my guitar the idea was to digitize all the signals and multiplex...