Search results

If not, I'm going to need to redesign something. The 5V tolerance is a nice feature sometimes. :)

Oh, one more thing: The teensy 4.1 has the SD card slot at the opposite side from where the USB connector is. That can be inconvenient when building props. It's easier to provide access to one side than it is to provide access to both.

The reason for using the Teensy 4.0 is simple: Size. The 4.1 is very nice, but smaller is better when building lightsabers (or any kind of prop really). The OctoWS2811 library can drive pixels on any pin on a Teensy 4.x, and also uses DMA. I don't think there is any reason to only stick to...

I'm working on a shield for the Teensy 4.0 which has: * SD card (UHS-I speed) * motion chip * 3W amplifier * 6 FETs for driving LEDs or cutting power to WS281x strips * battery charger It's called a TeensySaberV4 because... ... it's intended for building props, such as lightsabers ... I've...

Sorry about that. Video should show up now.

I've been using OctoWS2811 for my xmas display for years. Last year I ran 8000 LEDs from two OctoWS2811 adapters, which has worked great. (https://fredrik.hubbe.net/chaosdisplay/ for more information) This year, I'm planning to go for 10000 lights, and I noticed that the OctoWS2811 library now...

Apologies for commenting on the rather old post, but this gave me an idea: How about making a board with castellated edges specifically for bridging the bottom pads to another board? The board would be long and thin, but have no actual components on it, so pick-an-place problems wouldn't be an...

How a high-density flat-cable connector at the end of the board which can connect to a breakout board for all the rest of the signals? This could also work as a solder-free way to attach prop shields, audio boards and other fun stuff.

So this might not be the greatest solution to the permission problems, but I added this to my udev rules to make the relevant /dev/hidraw* file accessible: SUBSYSTEM=="hidraw", DEVPATH=="*/usb*:16C0:04[789ABCD]?.*", MODE:="0666" Using ATTRS{idVendor} or ATTRS{idProduct} doesn't seem to work...

So I had a much older version of the udev rules installed at home. Unfortunately updating the rules didn't seem to help. However, running as root does for some reason. I don't understand how this can be a permission problem since some configuration works, but seems to be what it is anyways. I...

It should work on any of the 3.x. I wrote it using a 3.2.

I don't seem to have an udev rule file at all. (Neither at home nor at work.) Installing the udev file makes things works a lot better at work. CDC works, and I don't need to run as root anymore. I hope it makes everything work at home too, will find out later...

I don't think so, I checked and it says the teensy_gateway was started yesterday. I'm going to reboot my machine later to see if there something else that's stuck somehow. I also took my T3.6 to work to do some testing there, and it's acting strange too. First of all, programming doesn't seem...

So I went back and tried the HelloSerialMonitor example again. First, I tried it on a mac, and that worked just fine. Then I went back to my linux machine and tried all the usb type settings, here are the results: (yes means Serial Monitor is working) serial: yes keyboard: no...

The difference is the drive strength. The difference is in SPI.begin(), the old code says: SPCR.enable_pins(); // pins managed by SPCRemulation in avr_emulation.h The new code says: reg = portConfigRegister(hardware().mosi_pin[mosi_pin_index]); *reg =...

Well, yes. SD.begin(0) returns zero. It gets to this line: if (vol->u16[255] != 0xAA55) return false; but the value in that location is 0xd503, not 0xAA55. I think this is what happened last time I tried USE_TEENSY3_OPTIMIZED_CODE too.

Tried it on a Teensy 3.6, with the same result. Also tried a different USB hub, and I tried killing gvfs-mtp-volume-monitor, but it seems to make no difference. I should be able to try it on mac & windows later or tomorrow.

So I tried the git revisions: This is the last one that works for me: b2dd72f634ec0fff3d8c00d222a28b13e0ead8a9 The next check-in is "Single SPIClass for Teensy 3.x". I tried commenting out some parts of my code (like reading the motion chip, and the WS2811 support) but that didn't seem to make...

Hmm, I don't know what version of teensyduino I had before. How do I find out? (Paul, would it be possible to put version number in the installer filenames?) However, I compared the working SPI installation with stuff from github, and found that the working SPI has this revision...

I'm using a Teensy 3.2 on Ubuntu 16.04.02 64-bit. I can try it on a teensy 3.6 after work.

I'm still having a problem with the SPI library. It's causing freezes in my lightsaber code. (https://github.com/profezzorn/TeensySaber) I know it's related to the SPI code, because if I copy an older version of the SPI library into the beta folder, everything works fine. My code is pretty...

If I load the HelloSerialMonitor example and select "MTP Disk (experimental)" I get no printouts in the TeensyMonitor. (It works if I select "Serial" or "MIDI".)

No need to bother Paul. The "emulated serial" is a simpler and non-standard (I think) usb serial port implementation. It still works with the serial monitor, but will not show up as a CDC device. (Because it's not.) If it doesn't work on your machine, that's a bug.

I have narrowed down the freezing problem to the SPI library. If I replace the new SPI code with the old SPI code, the freezing problem goes away. Also, when the freezing occurs, the SD card is locked up (SD.begin() fails) until I cycle the power.

No, it should be using the "emulated serial" automatically.

I'm getting random freezing in my code while playing wav files from sd cards with this beta. (I did not get them with before.) My code is available here: https://github.com/profezzorn/TeensySaber I'm running on a Teensy 3.2 with a teensysaber board, but a prop shield + sd adapter will work too.

Sorry for the delay. I'm trying this out, and the MTP part seems to work, but the serial monitor seems to stop working. I don't think the problem is on my side, because even if I don't enable the MTP responder in my code, the serial monitor still doesn't work. I also tried switching to "MIDI"...

In case anybody is interested, I've actually made my own prop-like shield: http://fredrik.hubbe.net/lightsaber/v2/ Right now I have a few for sale here: https://www.fx-sabers.com/forum/index.php?topic=51903.0 Unfortunately I don't have the volume and experience that Paul does, so they are a fair...

The best way to run something else is to put it in mtp_yield();

If I'm reading the standard right, this is still undefined behavior, the compiler just doesn't complain about it anymore. As far as I can tell, casting to a struct and then using is no longer supported in C++-11, so there goes 39 years of backwards compatibility.... Anyways, it looks like unions...

Can you explain why this is better than just using a define? Or is it just hiding the aliasing so that the compiler can't see it?

Nice, I'll have to take a look at SdFat.h, seems better than SD.h.

1. I'm not sure what the right way to work around those warnings is. 2. The SD library doesn't expose the size and free space of the SD card, so currently the code always says the card is 1Gb with 512Mb free. 3. Make sure the SD.begin() call matches the whatever pin you use as SD_EN...

It's intended to be a library. Not sure how you make one though. Also not sure if makes sense for me to do it or someone else (Paul?) as I'm probably not going to put a lot of effort into this in the future. (It already works well enough for my purposes.)

This is in fact the primary reason I recommend 5v-tolerant chips whenever possible. 5v-tolerant chips are generally more robust. (Especially if you don't use 5 volts in your circuit.)

Oh, I forgot: To try it out you also need to add entries to your boards.txt file to make "MTP Disk" show up in the "USB Type" menu. The entries you need looks like this: teensy36.menu.usb.mtp=MTP Disk teensy36.menu.usb.mtp.build.usbtype=USB_MTPDISK...

While working on TeensySaber, I felt a need to access the storage without having to to pull out the sd card and put it in an sd card reader. Since the promised MTP responder seems to be taking a while, I wrote one myself. It requires applying a small patch to the teensy core libraries to work...

I would get rid of the flash serial chip, the screw holes, and some of the useless headers near "Audio In". Then I'd move the audio output from the left to the right side, and remove the GND/5v from the left side since they are also present on the right side. With a little luck there would then...

I'm actually stacking the old SD adapter, it only needs three wires to make it work, but three PCBs stacked on top of each other is getting fairly big for what I'm trying to do.

I've been working with the prop shield to build a lightsaber, and I love it. (Details here) However, there are a two quirks that I've had to work around, which would be awesome to address in upcoming revisions: 1) The serial flash is nice, but too small. An sdcard slot would be better I think...

Love this! (going to try it out later today) Can I ask though: What pins can't use PWM with this? What pins can still control the frequency?

I too have this problem, because I want to use DMA to write to an LED string, while at the same time using the totally awesome prop shield AND possibly an sdcard as well. (The Wiz8xx+sdcard shield.) I have the OctoWS part paired down to only write to one string with no problem. I just inverted...