Home
Help
Search
Login
Register1
Mechanical & Automation Engineering / Re: Servo drives exploding after changing EMI filter
« Last post by coppercone2 on Today at 05:36:59 am »Would those not need to be big capacitors in the filter?
Recent Posts
2
Repair / Re: Question about voltage in U.S. house built in 1890
« Last post by Whales on Today at 05:34:13 am »The electrical wiring in that house is not ground referenced, meaning neutral is not connected to ground; that's a big no no.
It sounds more like the ground wiring is not ground referenced. The neutral wiring may or may not be grounded.
If a house full of appliances has its ground wiring disconnected and floating: measuring it to be halfway between active & neutral sounds like a plausible symptom.
I recommend you get a sparky to check this out niemand. They'll have the tools and skills to diagnose the problem quickly.
Out of curiosity I'd love to see pictures of your fuse boards, BUT, given what you have described any metal cased appliances in your house may be unsafe to touch. Even the metal cased fuse boxes might be UNSAFE to touch or open. Could also just be a high-impedance phantom voltage, but don't take the risk.
3
Microcontrollers / Re: Cortex-M hardware stack overflow detection
« Last post by Berni on Today at 05:29:37 am »Most of the bigger ARM Cortex chips have a MPU in them and that will provide more effective memory protection.
Tho the MPU is rarely used since people don't bother to set it up (Unless you have a RTOS that does it for you) and its effectiveness does depend on how your memory is structured. Just stick to good coding practices (like checking array sizes) and if you want to be safe run some static code analysis tools over your source code. These will catch more memory related bugs since a lot of the time the code will garble the existing data in RAM that it should have access to anyway (so the MPU will not detect it)
I suppose the most common bug that would eat up the whole stack would be a infinite recursion loop. But that will likely run off the end of the RAM area and then hardfault with a bus exception.
I personally only ever used the MPU to disable caching on some areas used for DMA buffers so that i didn't have to constantly be doing the cache flushing dance around those areas.
Tho the MPU is rarely used since people don't bother to set it up (Unless you have a RTOS that does it for you) and its effectiveness does depend on how your memory is structured. Just stick to good coding practices (like checking array sizes) and if you want to be safe run some static code analysis tools over your source code. These will catch more memory related bugs since a lot of the time the code will garble the existing data in RAM that it should have access to anyway (so the MPU will not detect it)
I suppose the most common bug that would eat up the whole stack would be a infinite recursion loop. But that will likely run off the end of the RAM area and then hardfault with a bus exception.
I personally only ever used the MPU to disable caching on some areas used for DMA buffers so that i didn't have to constantly be doing the cache flushing dance around those areas.
4
FPGA / Re: VUnit, UVVM, OSVVM: What are similarities and differences?
« Last post by lasplund on Today at 05:25:13 am »
Ok, here's a few. I admit that I'm spoiled by Python, and you might argue this is not needed/can be done differently:
* Lack of yield` alike mechanisms to create well readable co-routines
* `generate` limitations to architecture level
* Lack of built-in language constructs to separate synthesis from simulation specific statements (I'm aware of vendor specific pragmas). This is also related to the above generator concept of the pythonic `yield` combined with decorators or factory classes.
* No possibility to procedurally create interfaces (inline)
Agree, these are areas where pure VHDL is lacking support but there are solutions, at least to some extent. These are also areas where the frameworks in the OP differ.
* Rather than co-routines VUnit implements the actor model (message passing) to provide a high-level and powerful approach to asynchronous programming. This is a well-understood and supported construct in the SW world, Python included, and that's why it was brought to VUnit.
* Agree, it would be nice with a more dynamic way of generating logic.
* IEEE actually standardized a pragma: -- rtl_synthesis on/off. However, the vendors had already their pragmas in place so the standardized version wasn't generally adopted. It is also possible to define an is_simulation function that can be used to selectively execute code.
* When it comes to variants of DUTs, whether it's interfaces or something else, test(bench) parameterization is the way to go. VUnit advocates that generics/parameters are passed to the top-level testbench such that relevant combinations can be generated and applied by the Python test runner. Every such parameterization of a test(bench) is called a VUnit configuration. This is not to be confused with VHDL configurations. They can also be used but they don't scale well as the number of combinations grows (see https://vunit.github.io/blog/2023_08_26_vhdl_configurations.html).
5
Test Equipment / Re: Rigol's New Function Generator and DMM: DG800Pro / 900Pro / DM858
« Last post by csuhi17 on Today at 05:25:01 am »I have found two bugs so far.
Unfortunately, I don't use it much, the FY6800 is often enough for me.
One is when the dolphinfish attack, the device becomes unusable.
I don't know what's causing it, but I can't change the setting of channel 1, only channel 2, but it has no output, it responds to the buttons. This is thesecond time it has come up.
Third, only now at the counter.
The other is that at and around 1Hz square wave there is a small sine wave, the location and frequency of which depends on the frequency.
and the duty must be between 20-95%.
It can also be found for the pulse, but only if the trailing is 3.0ns.
It doesn't do it at 3.1ns.
Due to the lack of memory, it is not visible, but I measure it as a 312.5Mhz with the DHO924. I don't have a faster scope.
Unfortunately, I don't use it much, the FY6800 is often enough for me.
One is when the dolphinfish attack, the device becomes unusable.
I don't know what's causing it, but I can't change the setting of channel 1, only channel 2, but it has no output, it responds to the buttons. This is the
Third, only now at the counter.
The other is that at and around 1Hz square wave there is a small sine wave, the location and frequency of which depends on the frequency.
and the duty must be between 20-95%.
It can also be found for the pulse, but only if the trailing is 3.0ns.
It doesn't do it at 3.1ns.
Due to the lack of memory, it is not visible, but I measure it as a 312.5Mhz with the DHO924. I don't have a faster scope.
6
RF, Microwave, Ham Radio / Inside a Tektronix sampling module
« Last post by EggertEnjoyer123 on Today at 05:24:10 am »I bought this "bad" 80E03 sampling module from a hamfest last month. This is what the insides of the plugin look like under a microscope.
7
EEVblog Specific / Re: EEVbog 1613 -Audiophile REPAIR: Chord Hugo DAC
« Last post by Greybeard on Today at 05:19:08 am »Come on... you know it.Dave, I'm quite sure that you can do it much better than here in the video (soldering).
Sorry...
What was wrong with the solder joints?
I think just a bit too little solder, too many attempts with too little flux, not enough "shine"...
Don't the joints look a bit ugly?
8
Power/Renewable Energy/EV's / Re: Enphase 5p Battery specs - What is AC round-trip and DC round-trip efficiency?
« Last post by DougSpindler on Today at 05:12:28 am »Would you please explain what tare loss is.
9
Microcontrollers / Re: Cortex-M hardware stack overflow detection
« Last post by ataradov on Today at 05:09:48 am »But the issue here is that there is no way to distinguish stack overflow from a legitimate memory access.
10
Microcontrollers / Re: Cortex-M hardware stack overflow detection
« Last post by SiliconWizard on Today at 05:02:03 am »I agree with Bruce though, memory protection is increasingly available on even entry-level MCUs and can definitely be put to good use, *even* if you don't write fancy "multi-thread" stuff wtih an RTOS.
That's something many of us are not used to yet on MCUs, but I'm definitely getting into that.
That's something many of us are not used to yet on MCUs, but I'm definitely getting into that.