Here's a script I use a lot that creates a temporary directory, cds you into it, then cleans up after you exit. Ctrl-D to exit, and it takes you back to the directory you were in before.
Similar to what another user shared replying to this comment but mine is in bash + does these extra stuff.
#!/bin/bash
function make_temp_dir {
# create a temporary directory and cd into it.
TMP_CURR="$PWD";
TMP_TMPDIR="$(mktemp -d)";
cd "$TMP_TMPDIR";
}
function del_temp_dir {
# delete the temporary directory once done using it.
cd "$TMP_CURR";
rm -r "$TMP_TMPDIR";
}
function temp {
# create an empty temp directory and cd into it. Ctr-D to exit, which will
# delete the temp directory
make_temp_dir;
bash -i;
del_temp_dir;
}
temp
Thanks for your reply, that certainly a method I will try using.
But in the case of my problem I think it won't work. Since adc_data is in the consequent of the implication, it will again be sampled in the prepone region and so take on the value before adc_data_en was asserted high, don't you think?
In my code I set adc_data to its new value and at the same time set adc_data_en high. Perhaps I'm not supposed to do things this way? Is the usual practice to set something like adc_data to it's new value some time before the enable is asserted?
This is for an ADC. What I'm trying to do: when adc_sample goes low, grab hold of a value. Then when adc_data_en goes high, compare it with adc_data. Here's what I have so far:
``` property adc_deduces_voltage; bit [7:0] true_voltage;
@(negedge adc_sample) (`true,true_voltage=input_channel) ##1 @(posedge adc_data_en) // Values are sampled in the prepond region. This would be before // adc_data_en is high, giving us old values. To make up for this, wait // for one more clock cycle so that sampled values will be just after // adc_data_en is high. ##1 @(posedge clock) (adc_data == true_voltage, $display("Pass. Actual: %d, ADC: %d", true_voltage, adc_data); endproperty assert property (adc_deduces_voltage); ```
Note the comment I inserted. The hacky bit of my code is waiting for the next rising edge of the clock so that I can avoid the issue of things being sampled in the prepone region.
Any thoughts on improving this? Is there a better way to do this?
Also, what if I wanted to do something like: wait for negedge adc_sample, then posedge adc_data_en then 20 clock cycles later carry out checks?
CubeIDE does some checks which means clone bluepill boards don't work with it - you can't flash or debug. The methods I found online to get around this didn't help except for a stackexchange answer that got me most of the way. I figured I'd rewrite the answer with some small changes and add in a few details I needed to make it work.
The gdb and OpenOCD that CubeIDE uses do the verification checks, so an alternative is to install separate versions of these and get CubeIDE to use them instead.
- Install
Eclipse CDTfrom the Eclipse store within CubeIDE. - Install OpenOCD and
gdb-multiarch(using whatever package manager your OS has). - Under "Debug Configurations", choose "GDB OpenOCD Debugging" to create a new debug profile. See this image from the stackexchange answer and check that the debug profile looks like it.
- Config options for OpenOCD:
-f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /path/to/bluepill_ocd.cfgWherebluepill_ocd.cfgis/usr/share/openocd/scripts/target/stm32f1x.cfgwith the lineset _CPUTAPID 0x1ba01477changed toset _CPUTAPID 0x0which disables checking the CPU ID which the clone has different from the original. - Delete
__HAL_AFIO_REMAP_SWJ_NOJTAG()withinstm32f1xx_hal_msp.cor it will enter a reset loop after callingHAL_Init(). Not really sure why the reset loop happens. You'll have to delete this line every time you generate code from the device configuration tool (CubeMX).
Debugging should work now.
I'm using an Arduino and through a library working with an IC (MCP2515, a CAN controller) over SPI. The IC indicates interrupts by causing a falling edge on an interrupt pin.
Components are connected using jumper wires on a breadboard.
- When a logic analyzer is not attached, the IRQ gets called a few hundred times. It should only be called once. I thought it must be noise on the external interrupt pin but a pull-up doesn't help. I've tried the internal pullup and an external one.
- Trying to see if there is a ton of interrupts from the IC, or an error internal to the Arduino, I attach my logic analyzer. Now it works perfect.
Any idea what might cause such a weird issue? Looking around I haven't found anything.
EDIT: I found a Reddit post for a different circuit where a user suggested placing a small capacitor to make the edges of a signal rise slower. This has fixed my problem.
Since I've already created a post: does anyone know why I was getting an unending number of interrupts? Why would the edges of the interrupt signal changing too fast cause something like this?
For the IRF1404Z, under the absolute maximum ratings, continuous drain current is given as 140A. If it was for something like picoseconds, it doesn't seem meaningful labeling it 'continuous current'?
Not sure if this is a dumb question but this has me quite puzzled.
The legs on TO220 packages are very small. How is it that there are e.g MOSFETS rated as being able to continuously conduct ~100A? e.g IRF1404Z
From what I understand such large currents need busbars on PCBs and these appear a lot larger than the legs on these components.
Thank you, will give that a go :)
I'm making a driver for a small 15V, hall sensored, 9-slot BLDC motor I got off of AliExpress. It has u,v,w inputs. Three hall outputs and Vcc, Gnd for them. No datasheet :)
I understand the working principle: I'll have to use the hall sensors to figure out the location of the rotor, then power the appropriate windings.
Trouble is, I don't know how the windings for the three phases are arranged within the motor. So I don't know which pin to give power to, because I don't know which windings within the motor will then be powered.
How can I figure out where the windings are for each phase?
I'm guessing I've got to manually spin the motor and do some detective work with back-emf measurements and hall sensor outputs to figure this out?