I'm sure it has, *somewhere*, but not documented anywhere that I've seen. The official audio library is hardcoded for 16-bit 44.1kHz. Not #defined, but actually hardcoded throughout, so that's a no-go. (*) I found that out with one of my...
In playing with it myself, including some tweaks to the official HardwareSerial library, I discovered that a Teensy 4.1 at least, does *not* put stop bits between consecutive breaks! So you can buffer up four BREAKs in a row, followed by one...
Turns out that standards-compliant DMX *is* possible with the Teensy 4.1 UART alone. Multiple BREAKs do *not* have stop bits in between, so it can produce any length with character-level resolution.
This code:
#define LED_SETUP() pinMode(13...
I missed another 10-bit mask in the peek function, probably because I don't plan to use it. But I removed that too, mostly for completeness.
Anyway, after modifying HardwareSerial.{h|cpp} as attached here, this code:
#define LED_SETUP()...
This seems to have stalled:
https://forum.pjrc.com/index.php?threads/expansion-to-hardwareserial.77966/
and the datasheet says on pages 2899 - 2900 (functional description) and 2920 - 2932 (registers) that it's possible...
So it's pretty much running for the entire 10 hours. No short critical time and then nobody cares. There goes that theory.
As far as anyone can tell, it was perfect for all of the previous shoot, and then immediately on the next startup, it's...
There are moments of dead time, but not huge amounts. While it's powered up, it spends probably half of its time running motors. This is a device that controls the speed and position of a number of stepper motors, and those stepper motors...
How much of that 10 hours is dead time at the end? So it could have stopped then, unnoticed, and then powered off?
The picture looks to me like theatrical gear, and that stuff often does get turned on and tested way early, left on for the show...
Does the system get rebooted anyway, so the user might not necessarily notice? Or possibly accepted the "fact" that "systems need rebooting", because of shoddy code in commercial consumer systems for so long, and so didn't think to report *that*...
For each event that happened to hit the time window I'd expect lots of events, mostly shorter, that didn't.
A shorter press of the button would put the unit into upload mode and require a power cycle to recover back to running the normal program...
If you're REALLY sure that it will NEVER be used, I guess you could short it to 3.3V too. Good luck EMI'ing *that*! Or a wet or dirty board.
But it would also mean that the button now shorts the supply, so you really do need to be sure that it...
Can you offer a free-return warranty? Pack it back up as received, put a new label on that you pay for, and drop it off. See what shows up.
How expensive would that be for you? Is it worth a couple, to find out what they actually got?
Each individual unit, yes. But if the design hasn't changed and the hardware QA is good, then the chance of shipping a dud is still low.
Of course, nothing prevents a complete test before shipping, then reset so that just the wrong type of...
The answer depends on whether using secure mode, which is only possible on lockable Teensy, and only used if you run the programs which burn your key into the hardware and permanently lock into secure mode.
Secure mode uses a secure sha256 hash...
I was thinking the same. It can only erase, not put something else there.
However, what happens if the program is indeed corrupt? Does it execute garbage code? Is there a checksum or other verification? If it does have an integrity check...
The BREAK is longer than one character because if it wasn't, it would be hard for a receiver to tell the difference between noise and a zero character on one hand, and a valid frame start on the other.
Now, there was some discussion a couple...
I know I'm way late to this party, and not to diminish the actual intent of this request thread, but if you also control the XMOS code, then you can use I2S or something else between it and the Teensy, instead of USB. MUCH simpler that way!
I'd...
That said though, I still want explicit functions for Idle and Break, at the very least to use according to my code examples here. Yes, that's not completely standards-compliant DMX, but for my specific project, it doesn't have to be. And I can...
I'd seen this already in some of the documentation, as a reason to not use the same UART for dull-duplex DMX. The baudrate hack for TX completely wrecks RX! So that was part of my motivation for a different method.
If a second bit-banged...
TL;DR:
Use a USB to headset adapter for each electret mic individually, directly connected with no circuitry in between. They're literally designed for each other. Signal to Sleeve, Ground to the first Ring. Done!
If you have multiple mics...
It doesn't matter if your signal processing is acoustic, analog, or digital. The mathematical rules and limitations are the same regardless, but different domains make some operations easier and others harder.
(Digital makes it far easier to...
Yes, it is related. I was going to cross-link after responding to those, but you beat me to it.
Correct, as I acknowledged over there. (DMX requires a minimum 23-bit break, typically 44-bit, with no stop bits to break it up) So that's a bad...
I responded to the GitHub issue, and closed it as "no action required", but I'll re-type it here for those that read this and not that.
Yes you're right. Re-reading the official DMX spec, I see a minimum break time of effectively 23 bits...
Corrections/improvements to the online documentation:
https://www.pjrc.com/teensy/td_uart.html
Please add SerialX.write(buffer, size) to the online documentation. The overload exists, according to Arduino IDE's autocomplete, but the online doc...
I'm curious why you're putting mics in parallel in the first place. I assume it's an array, which has its own acoustic behavior that I assume is useful for you. But just mashing sources together with no explicit mixing design, is a pretty...
According to Arduino IDE's autocomplete, SerialX.write() has more overloads than the online documentation says. Can the online doc be updated?
https://www.pjrc.com/teensy/td_uart.html
Specifically, there are (const char *buffer, size_t size) and...
No, I just never considered them. I had always understood '485 and '422 to be 5V things, and that was just that. You made me look up some more actual specs and, sure enough, it works down to 1.5V differential (3V pk-pk) in addition to 6V max...
Nice! I hadn't seen that in the documentation, but it's possible that I just missed it. Thanks!
I'm concerned about parasitic capacitance, but maybe 250kbaud is still slow enough to not worry about it?
---
And I still have the question of a...
It appears that those don't exist. The part number would be 74*HCT07* or thereabouts, but it seems that nobody makes that with a push-pull output. Open-drain exists, but that doesn't help. Lots of inverters though: 74*HCT14*
Not the end of...
Well, this changes things: I just noticed that the RS485 transceivers run at 5V per the '485 spec, while the Teensy's I/O is 3.3V and *not* 5V tolerant.
So I need some level conversion too, which tips the balance in favor of:
An external AND to...
There are several libraries for asynchronous DMX, where the driver basically freewheels in the background to produce a constant spew of the latest values, and the user code simply pokes new values in at random and moves on. That's fine for a...
For low-speed signals, like analog faders and knobs, even rotary encoders, a hand-soldered ratsnest works just fine. That's how I got started, before Arduino ever existed, and still do on occasion for a fast-turnaround one-off. One...