-
Didn't know that there are some JFETs with an integrated flyback diode. I'll add that to the todo list. And I also need to investigate the impact on symmetrical JFETs.
-
Same with some BJT, as you know. So I wonder, what if we add a thin diode symbol bitmap, and concatenate it to the normal symbol when required? In fact, from the capture of Yuriy_K's firmware, I guess he's doing that and the diode is in different color?
-
Feliciano, The color of the diode does not play a special role here. For ATMega644-1284 it is easier to draw a few more additional symbols with a built-in diode - this will not significantly increase the size of the firmware. For ATMega328 with a limited memory size, the diode symbol option like Karl-Heinz is more preferable, but this forces the remaining symbols to be shifted to the left to make room for a possible diode, which I don’t really like.
-
Didn't know that there are some JFETs with an integrated flyback diode. I'll add that to the todo list. And I also need to investigate the impact on symmetrical JFETs.
This is becoming more complex. I've tested a few JFETs with an additional diode between source and drain. For a n-ch JFET an optional flyback diode would work out of the box. And it would also determine source and drain. Reversing the diode also reverses source and drain. The detection of a p-ch JFET is totally messed up by a flyback diode, i.e. drain and source are the opposite of what they should be, and I_DSS and V_GS_off are much too high (because of the source/drain reversal plus the diode). -
indman, the color of the diode itself is not a deal-breaker, but being in different color makes me think it was generated by another method and printed (to the screen) as needed. I think that would be a nice feature to have, that's my real suggestion. The symbol itself would require a few extra Bytes, my major concern would it be the code-size for inserting it to the right of the other symbol. And if slim, it won't affect much. Or, I don't know whether it would possible to overlap the other bitmap, or between the numbers, to avoid the shift.
And regarding to having the body diode or not by default, I and noticed it's present in some of the m-firmware bitmaps. For the majority of MOSFET I know of, they has it, so I'm not sure on which one would it be the best default option (but indeed in m-firmware we have both options to choose from). I haven't looked at kh's for that part yet, though.
-
And regarding to having the body diode or not by default, I and noticed it's present in some of the m-firmware bitmaps.
Yes, it is. Look carefully at the title of the description: who created these character sets?
-
Of course madires and you, dear.
And now I found the explanation of what I'm seing, on an old Yuriy_K's post, which if the code size confirms it, it could be a reasonable alternative, as long as the symbol's letters are kept to the left of the wires (and of course we choose a diode-less symbols bitmap). -
And as a matter of fact, a couple of posts down, you can notice inductor, crystal, and batteries symbols in the font set, instead of the symbol set. I guess that saves a little memory too. Maybe madires would like to check those alternative approachs again?
-
Each new symbol display variant increases the complexity and we already have a few variants (-> maintainability).
-
Back to JFETs with an integrated flyback diode. Yuriy_K has such an n-ch JFET. But are there also p-ch JFETs with a diode?
-
From what I see, for transistors he uses the standard symbols, and optionally takes the upward or downward diode from custom extra characters of the font, and prints it under the upper-right terminal number. For other components, takes a more traditional approach, but with a different character code. Attached some examples for differents scenarios.
Whether easy or not to implement, and/or the code-size versus tradicional solution, and/or the feasibility for 32KB, you're the expert.
-
From what I see, for transistors he uses the standard symbols, and optionally takes the upward or downward diode from custom extra characters of the font, and prints it under the upper-right terminal number.
No, on the first photo in post #9362 we see that Yuriy_K has found a nicer way to display this additional diode.Whether he will share this way or not we do not know. All the previous examples you have shown do not make me want to apply them. -
Everything I need, I try to do myself. All my homemade testers were made for 2.2" - 2.8" color displays. In your eighth decade, it is difficult to work with small displays. The latest solution is a refinement of an earlier idea. Need some work on the symbols and font...
-
The latest solution is a refinement of an earlier idea.
Yes, everything is clear now, thank you. You draw an additional diode using 3 lines.
A perfectly reasonable approach, but it does require some work on the existing character sets we currently have. -
Congratulations, Yuriy_K, for being active for so long
-
Yes, everything is clear now, thank you. You draw an additional diode using 3 lines.
A perfectly reasonable approach, but it does require some work on the existing character sets we currently have.
And the symbol size has to be three times the font size for a perfect match. For example, for high resolution displays the default font is 16x26. So the symbols should be 3 * 26 = 78 pixels high. Since symbols are resized in the display driver (only for high resolution displays) by a default factor of 2, the height can be reduced to 78 / 2 = 39 pixels. Alternatively we could go for a resize factor of 3 and use the font's height of 26. But this would look too pixelated. -
It took a while but I managed to understand why a flyback diode screwed up the D/S detection of a p-channel JFET and therefore also a few measurements of parameters. The intrinsic diode of a p-channel depletion-mode MOSFET should have the same impact (never tested because I don't have any of those). The fix is fairly simple, just a few lines of code. So the next version of the m-firmware will include the fix and also show an optional flyback diode for JFETs.
If you like to beta-test, edit semi.c, function CheckDepletionModeFET(), in the block for p-channel depletion-mode FETs and look forCode: [Select]/*
* Compare gate voltages to distinguish JFET from MOSFET
*/
/* set probes: probe-1 -- Vcc / probe-2 -- Rl -- Gnd / probe-3 -- Rh -- Gnd */
R_PORT = 0; /* pull down drain via Rl & gate via Rh */
...
Directly above that insert:Code: [Select]/* consider intrinsic or optional flyback diode (causes low Diff_2) */
if (Diff_2 < (Offset / 2)) /* diode */
{
/* swap Diff_1 and Diff_2 */
/* to fix reversed D/S issue caused by diode */
U_1 = Diff_1;
Diff_1 = Diff_2;
Diff_2 = U_1;
}
/*
* Compare gate voltages to distinguish JFET from MOSFET
*/
And also modify function Show_FET() in main.c to call Show_FET_Extras() without any condition (remove the if (...)). -
There may be something else, this insert does not give the desired result for searching for a diode. Diode search for N-ch JFET stopped working.
Diode = SearchDiode(Anode, Cathode);
if (Diode != NULL) /* got it */ = NULL
-
You've inserted the patch into the section for n-channel depletion-mode FETs which causes the new problem. The section for p-channel FETs is a bit further down and starts with:Code: [Select]
/*
* check if we got a p-channel JFET or depletion-mode MOSFET
* - JFETs are depletion-mode only
*/
if (Flag != SIGNAL_FET) /* no n-ch dep-mode FET found */
... -
Now everything is working fine. To avoid confusion in the place of correction, I am attaching the modified files. Check who needs...
JFET N-ch 2SK212
-
Back to JFETs with an integrated flyback diode. Yuriy_K has such an n-ch JFET. But are there also p-ch JFETs with a diode?
I have not found a single mention on the Internet of any JFET p-ch witch a diode.
-
Me neither. All I've found was some paper about a high voltage SiC JFET with integrated flyback diode.
-
Hello people, getting crazier and crazier, I am trying to update the firmware from version 1.40 to 1.52, since I had to return the programmer, since I have not been able to make it work, I set up the connection this way,
I tried loading an Arduino bootloader from Arduino and perfect, I loaded the ArduinoISP.ino file onto the Arduino master board and placed it in Arduino as ISP mode. and it works well, now when I have loaded previous versions of firmware to the GN328, it always starts like this. To know that the connection worked
But the next step was to upload my compilation, which I couldn't do, so I started changing Arduinos uno and mega, and the target chip and nothing. So I thought that my build now was really garbage.
I said I'm going to load the one I'm using that I had downloaded from the web, which is the one I'm using, but the same problem continues and I have configured AVRdude in many ways and it still gives me the same result
The truth is that unfortunately I never captured the screen of how I configured it, with the programmer that they had lent me it loaded, but the screen remains blank, now nothing, nor loads. any ideas friends
-
Hello people, getting crazier and crazier, I am trying to update the firmware from version 1.40 to 1.52, since I had to return the programmer, since I have not been able to make it work, I set up the connection this way
You should have a 12-22pF a capacitor from pin 9 to ground and from pin 10 to ground. Oscillator may be unstable without them.
Also, putting a 0.1uF capacitor across pins 7 & 8 might be a good idea. -
Hello people, getting crazier and crazier, I am trying to update the firmware from version 1.40 to 1.52, since I had to return the programmer, since I have not been able to make it work, I set up the connection this way
You should have a 12-22pF a capacitor from pin 9 to ground and from pin 10 to ground. Oscillator may be unstable without them.
Also, putting a 0.1uF capacitor across pins 7 & 8 might be a good idea.
Yes, they are not in that image but I put the two capacitors in it 22pf