One of the failure modes I frequently need to look for is an intermittent connection. Having the test run continuously while gently flexing the cable and reporting the results only when you press the encoder a second time might be of value.
Cool adaptation! I would definitely go for something with more horse power. Like and ESP32 or maybe even an S3. More RAM and PSRAM. And not much price difference.
@@GadgetReboot A C3 is also fine for this. And WiFi opens up a lot of possibilities. For example: check wiring with in walls. Having them "talk" to each other" to check if the hidden wire is still OK.
Great idea, rpi pico w, micropython/circuitpython/C, dual oled or just output on a pc or webpage, why not have the output pins on all the time, just need 40 inputs, even the pythons can do webserver, circuitpython can also do hid over usb.
The main reason to only turn on one output at a time is so I can be sure which one is causing the input to detect a specific output so we can tell which wire is actually connected to which pin. If they are all activated and we simply detect a signal at an input, it could be coming from any of the 40 outputs so we don’t really know the pin mapping.
I do make a total of three arrays at start up to store pin mappings and two types of test results so they can be differentiated but then there’s other temporary variables nowhere near as big as that within functions. I didn’t think it would really be a problem but of course I just don’t know enough about the overhead of Arduino and what’s involved in the stack with even calling functions or nested functions maybe that builds up too much, so what I’d really be curious to try is using a device with larger code space and memory space with the same code and re-enable the things that caused nano to crash and see if the chip with more resources handles it better
Really cool project. Have you considered moving the I2C expanders from the board to the modules? This should allow you to use a much simpler interface between them, and if you add some logic to transmit a module type code when you connect a module, I imagine the whole thing would become plug-n-play. Would probably make it a whole lot more expensive, though.
that’s an interesting idea to just have the power and bus going to the plug-in modules, but of course it would also complicate those plug-in modules because those are also used for general purpose breadboarding so then they would have extra components and complexity when only being used as a jack. But maybe it would be still good to have the bus and power pins available on an expansion header to add more options on another board.
Looking at the serial monitor output it seems you are creating 40 element arrays when the cable under test is e.g. 8 conductors. This is not helping your suspected memory issues. Perhaps allocate array space dynamically, making the arrays only as big as needed for the selected test? Then free them as soon as you're done with them.
One thing everybody forgets is to check for free memory before creating the array. I as thinking of memory overrun or writing outside the bounds of the array. I do like playing with the ESP chips as they will give you an idea of why the chip reset.
@@TheEmbeddedHobbyist Agreed. When I said "allocate array space dynamically" what I had in mind was something like: int* myArray = (int*)malloc(numberOfElements * sizeof(int)); instead of int myArray[40]; In theory malloc should fail in a manageable way if there's not enough memory. As for blowing the array bounds, well, all l can say is always check 0 >= x < numberOfElements before saying myArray[x] 😉
@@sootikins i would check that it has not returned a null pointer before trying to use it. My common mistake with the ESP8266 when running RTOS is to kill the canary, by not giving my threads enough space. 😞 Nice clocks, lovely Westminster chimes.
@@TheEmbeddedHobbyist Thanks for the compliment on my clocks! I'm especially pleased with the "chimer". I was being lazy saying "fail in a manageable way" - heh. Yes, check the pointer right after malloc and fail gracefully (maybe even spit out a debug message "insufficient memory" if being fancy!) if it's null. Random thought: none of his numbers seem to be >255 so array size can be halved right off the bat by using unsigned char instead of int. I've not yet tried RTOS on ESP. I'm still having fun playing with either NodeMCU / Lua or Arduino on my ESP projects.
@@sootikins I'm currently a RTOS and eclipse IDE fan boy. that's if old folk are allowed to call themselves a fan boy. if you know a show that was on BBC radio 4 years ago, I'm a TOG.🙂
Nice project. I did something similar 30 years ago. If you wish to cooperate just make a reply. And yes a MCU with more memory would be advicable, I would use a ESP32.
One of the failure modes I frequently need to look for is an intermittent connection. Having the test run continuously while gently flexing the cable and reporting the results only when you press the encoder a second time might be of value.
i created something like this.. and that also reads resistance, detect miss wire, detect open .nice project.
Could you share your code/project?
How awesome are these videos keep up the fantastic work 👌👌👌
I love it. That's very cool. Way more sophisticated than me cramming 40 leds on a pcb lol. Very nice work!
Cool adaptation! I would definitely go for something with more horse power. Like and ESP32 or maybe even an S3. More RAM and PSRAM. And not much price difference.
I have an ESP32 C3 set aside for experimenting. I haven’t used them yet so maybe this would be a good learning opportunity.
@@GadgetReboot A C3 is also fine for this. And WiFi opens up a lot of possibilities. For example: check wiring with in walls. Having them "talk" to each other" to check if the hidden wire is still OK.
Great idea, rpi pico w, micropython/circuitpython/C, dual oled or just output on a pc or webpage, why not have the output pins on all the time, just need 40 inputs,
even the pythons can do webserver, circuitpython can also do hid over usb.
The main reason to only turn on one output at a time is so I can be sure which one is causing the input to detect a specific output so we can tell which wire is actually connected to which pin.
If they are all activated and we simply detect a signal at an input, it could be coming from any of the 40 outputs so we don’t really know the pin mapping.
@@GadgetReboot could reduce 40 pins to 20, test 40 strand cable in 3 steps
You could just create an array at start-up that is large enough of the max connector size and just reuse it every time.
I do make a total of three arrays at start up to store pin mappings and two types of test results so they can be differentiated
but then there’s other temporary variables nowhere near as big as that within functions.
I didn’t think it would really be a problem but of course I just don’t know enough about the overhead of Arduino and what’s involved in the stack with even calling functions or nested functions
maybe that builds up too much, so what I’d really be curious to try is using a device with larger code space and memory space with the same code and re-enable the things that caused nano to crash and see if the chip with more resources handles it better
Really cool project. Have you considered moving the I2C expanders from the board to the modules? This should allow you to use a much simpler interface between them, and if you add some logic to transmit a module type code when you connect a module, I imagine the whole thing would become plug-n-play. Would probably make it a whole lot more expensive, though.
that’s an interesting idea to just have the power and bus going to the plug-in modules, but of course it would also complicate those plug-in modules because those are also used for general purpose breadboarding so then they would have extra components and complexity when only being used as a jack. But maybe it would be still good to have the bus and power pins available on an expansion header to add more options on another board.
Boa tarde, teria como fazer uma lista de todos os componentes que foram usados, obrigado.
Looking at the serial monitor output it seems you are creating 40 element arrays when the cable under test is e.g. 8 conductors. This is not helping your suspected memory issues. Perhaps allocate array space dynamically, making the arrays only as big as needed for the selected test? Then free them as soon as you're done with them.
One thing everybody forgets is to check for free memory before creating the array. I as thinking of memory overrun or writing outside the bounds of the array.
I do like playing with the ESP chips as they will give you an idea of why the chip reset.
@@TheEmbeddedHobbyist Agreed. When I said "allocate array space dynamically" what I had in mind was something like:
int* myArray = (int*)malloc(numberOfElements * sizeof(int));
instead of
int myArray[40];
In theory malloc should fail in a manageable way if there's not enough memory. As for blowing the array bounds, well, all l can say is always check 0 >= x < numberOfElements before saying myArray[x] 😉
@@sootikins i would check that it has not returned a null pointer before trying to use it.
My common mistake with the ESP8266 when running RTOS is to kill the canary, by not giving my threads enough space. 😞
Nice clocks, lovely Westminster chimes.
@@TheEmbeddedHobbyist Thanks for the compliment on my clocks! I'm especially pleased with the "chimer".
I was being lazy saying "fail in a manageable way" - heh. Yes, check the pointer right after malloc and fail gracefully (maybe even spit out a debug message "insufficient memory" if being fancy!) if it's null.
Random thought: none of his numbers seem to be >255 so array size can be halved right off the bat by using unsigned char instead of int.
I've not yet tried RTOS on ESP. I'm still having fun playing with either NodeMCU / Lua or Arduino on my ESP projects.
@@sootikins I'm currently a RTOS and eclipse IDE fan boy. that's if old folk are allowed to call themselves a fan boy.
if you know a show that was on BBC radio 4 years ago, I'm a TOG.🙂
Nice project. I did something similar 30 years ago.
If you wish to cooperate just make a reply.
And yes a MCU with more memory would be advicable, I would use a ESP32.