-
What are your go-to NPN and PNP transistors for controlling loads from a microcontroller? I figure it's probably better for me to use the same "common parts" that others are using, so I have the parts to follow other people's designs, and others can follow mine without buying obscure parts or adapting the design to more common ones.
I want to handle loads of 300ma to a couple of amps for the NPN (ie, most will be high enough that a ULN2[8/0]03 isn't going to be happy running it continuously), running at 50-100% duty cycle (with PWM, in most cases).
Are there any IC's like the ULN2003/etc, but with higher current specs (and presumably fewer channels per package, or a different package) that you have experience with and can recommend?
For PNP transistors - well, what are your go-to transistors (not just interested in higher current)?
What about PNP arrays like the ULN2003? They are obviously in production, and I can find them on google - but what are the ones people are actually using with arduino/etc?
-
-
-
-
-
-
-
+hansamann has a good point - for people who've shied away from microcontrollers, having to solder pin strips on is going to discourage a good portion of potential users (particularly the web-developer type - the ones I know are so steeped in software that they can't work out how to use a shower, let alone a soldering iron). At the same time, I'd rather they not be preinstalled (at least not on the Espruinos I buy), and I think a lot of the more experienced hardware/microcontroller people wouldn't want that either. Maybe the solution to this and sensors is for there to be a starter kit with the headers pre-installed and some cheap sensors and stuff to get started with, plus a breadboard (these suck imo, but if you can't solder, you kinda need something like this) and some dupont line?
-
Are there plans to extend setWatch() to allow reacting to an analog input value? Does the chip the Espruino uses even have a good way to do that? Or is it better to wire up something to convert that event into a digital pulse and set a watch on that?
For example, to put a watch on the results of an analog sensor, so if it went over a certain value, it'd call the function? (This is easy enough to handle w/discrete components - a '339 and a pair of dividing resistors to make a reference can handle detecting if it's above or below a threshold)
Or to use one of those ultra-cheap chinese "vibration sensors" to detect shocks? (the 20 cent ones that look kinda like blue resistors. When tapped or shaken, the resistance changes randomly). This I think could also be used with a 339 to get a digital output from it in the event of changes.
-
I have noticed flickering in PWM-controlled LEDs (external LEDs driven off a ULN2803, also on an external breakout board) when running off a benchtop power supply with stable output voltage and controlled by bluetooth It happened only after some time had passed, and I could see the current change as it did (these were 1W leds >.>). I'd set them with analogWrite(pin,1); so they should have been on full time anyway....
So there may be a deeper issue here. I won't say my results are meaningful until I've re-run it with proper heatsinking on the LEDs and driver (they both get pretty hot) - I have a heatsunk setup assembled, but have not driven it from Espruino yet.
I have ruled out loose connections, though, as the flickering does not react to jiggling the wires.
-
That is unfortunate - it seems the surface mount USB connectors just don't hold up well without a case to keep them in place. Particularly since you also had problems with BT, so you can't just hook it up to a power supply and use the bluetooth..
Uhm, is that just the lighting, or are there scorch marks all over the bottom of that Espruino? You should be able to solder without it blackening the board - If those are scorch marks, I think your soldering iron is getting too hot (though I don't know that this is related to any of the issues you've had).
-
Yeah - I knew about the backticks (and used them for the js code - or I thought I did), but didn't think to use it on the logs - I was in a hurry since I was posting it while not before I left for work.
What's strange is how it gets 11 writes off (in two bursts) shortly after things have started going off the rails.
-
The timer bug can be reproduced with this code:
var fs; var interv; var t=-1; var rh=-1; function onInit() { setTimeout("doInit();",2000); } function doInit() { fs=require("fs"); fs.appendFile("timetemp.log","Espruino restarted") interv=setInterval(function(){dologs();},5000); setBusyIndicator(A13); } function dologs() { console.log("trying to log..."+getTime().toFixed()); var ti = getTime(); if (!fs.appendFile("diskerrator.log","DHT11,"+t.toString()+","+rh.toString()+",Time,"+getTime().toFixed()+"\n")){ console.log("FAIL before "+ti+" after "+getTime()); } } save();
Ran it overnight, and woke up to it broken. Manually cleared the interval, and typed getTime() a few times. These were typed a couple of seconds apart at most:
ERROR: Unable to write file : DISK_ERR FAIL before 45778185.87560272216796 after 45778190.38722991943359 trying to log...45778199 ERROR: Unable to write file : DISK_ERR FAIL before 45778211.53864669799804 after 45778216.05158138275146 trying to log...45778225 ERROR: Unable to write file : DISK_ERR FAIL before 45778237.20124530792236 after 45778241.71224975585937 trying to log...45778250 ERROR: Unable to write file : DISK_ERR FAIL before 45778262.85095405578613 after 45778267.36160087585449 trying to log...45778276 ERROR: Unable to write file : DISK_ERR FAIL before 45778288.36543083190917 after 45778292.84815883636474 trying to log...45778302 ERROR: Unable to write file : DISK_ERR FAIL before 45778314.20237731933593 after 45778316.91917991638183 trying to log...45778319 ERROR: Unable to write file : DISK_ERR FAIL before 45778324.45648479461669 after 45778326.43975925445556 trying to log...45778329 ERROR: Unable to write file : DISK_ERR FAIL before 45778333.97615909576416 after 45778336.01252174377441 clearInterval(inter); =undefined getTime(); =45802702.42679214477539 getTime(); =45814433.28411769866943 getTime(); =45828450.28250503540039 reset(); =undefined _____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://espruino.com 1v58 Copyright 2014 G.Williams =undefined >getTime(); =46298892.14406204223632 >getTime(); =46307856.84639739990234
(in above, I had to remove the > prompt, otherwise the forum mangled it)
Last entries in the log:
DHT11,-1,-1,Time,11087 DHT11,-1,-1,Time,11092 DHT11,-1,-1,Time,11097 DHT11,-1,-1,Time,11102 DHT11,-1,-1,Time,11107 DHT11,-1,-1,Time,11112 DHT11,-1,-1,Time,11117 DHT11,-1,-1,Time,11122 DHT11,-1,-1,Time,11127 DHT11,-1,-1,Time,11132 DHT11,-1,-1,Time,11137 DHT11,-1,-1,Time,11142 DHT11,-1,-1,Time,11147 DHT11,-1,-1,Time,11152 DHT11,-1,-1,Time,11157 DHT11,-1,-1,Time,12697 DHT11,-1,-1,Time,12697 DHT11,-1,-1,Time,12697 DHT11,-1,-1,Time,12697 DHT11,-1,-1,Time,12697 DHT11,-1,-1,Time,12697 DHT11,-1,-1,Time,16339 DHT11,-1,-1,Time,16339 DHT11,-1,-1,Time,16339 DHT11,-1,-1,Time,16339 DHT11,-1,-1,Time,16339
-
-
-
I thought they were called JST connectors, and I see that "JST connectors" are very popular for LiPo batteries, but I ordered some of those, and they do not fit. The connectors are a little larger, and they've got a groove between them, instead of a ridge.
The documentation also called them JST-PHR connectors, but there aren't any connectors with that standard available on amazon - only a small number of special charging cables with obscene markups (I'm not going to pay $5 for a single female connector, when other similar sized connectors are $5 for 10 sets of male+female connectors!) or batteries with that connector - and only one page of results across all of amazon, so if they're commonly used for that, they must be called something else.
So what am I supposed to be ordering to get these connectors?
-
JumJum - What else was your board doing before this?
I have found that if I'm writing to the SD card, and it fails, it seems to break the timer until restart, causing it to advance at a rate far faster than 1 second per second (maybe as fast as 1s per ms). It sounds like you encountered this, since the timer was showing 183,456,363 seconds is 2123.3 days
Actually, this is consistent with the getTime() switching to milliseconds, if you had it running for ~2.12 days after the point at which the timer started doing that.
-
Wait, so if I do...
var x; function onInit() { x= require("icbm").connect(I2C1); x.launch(55.7,37.6); } save();
It will not have the modules loaded if I paste it into the left side, and after saving it, it will need them on the SD card. But if I do it on the right side, and send it like that, the modules will get loaded by the IDE and be save()ed, and I won't need to have them on the SD card? (I never use the right-hand side of the IDE because it's hard to read on on a retina class screen without a way to scale up the text - I just do everything in sublime text and copy/paste it into the left side).
If there are two versions of a module with the same name, the one on the website, and the one on the SD card (say, because I'm updating it), which one will be used if I send it through the IDE?
At what point in the process would the IDE tell the Espruino to load that?(for example, would this force it to load off the SD card, or does it do it at the end?):
var x; function onInit() { x= require("icbm").connect(I2C1); x.launch(55.7,37.6); } Modules.removeAllCached(); save();
I'm just trying to make sure I understand how this module loading system works. It's a little disconcerting how it isn't made clear when the IDE is summoning a module from the internet and adding it to the Espruino's module cache. For that matter, is there a location on the local filesystem that the IDE will check before it goes online?
-
Oh, well, that makes life easier! It also means I need to be somewhat more aware of what is and isn't loaded when I save(). For example my DISK_ERR generator, if you paste in the whole block of code, the module won't be loaded when it saves, because onInit() hasn't been called, and the require()'s are in the init functions, as I ran into when the SD card mysteriously failed (that's how I knew it happened - it started complaining that the modules were missing when I restarted it).
-
-
Yeah, I've only seen it when I'm doing fs writes. It's as if the SD card failure breaks the timer somehow...
Seems to work fine just sitting there reading dht's.
Edit: Just got another failure, this one much faster - and I got the whole trace this time because it froze entirely at the end
http://drazzy.com/espruino/v58devfailure2.txt
(note that I'd created a demo array to show my friend the WS2812's, that's why there's a graphics object in the trace)
-
-
Happened really fast the first time, now seems to be running stable for a while
Edit: Now closing in on 5 hrs running continuously. Heading to bed.All of these errors were appearing in rapid succession, meaning it was trying to log much more frequently than it should have been - the onslaught was such that the trace and everything else got pushed out. Is there a way to make the IDE log to a file, so I wouldn't miss the results of trace() and the events surrounding the initial event?
In any event, there is no way that the espruino was running for 44494 seconds, nor had it been running for ~25k seconds when the failure occurred.
!!?!?!
http://drazzy.com/espruino/v58devfailure.txt
I'm rather confused by the early failure, followed by a very stable run....
-
Yeah, will definitely contribute module for it. It'll be a pretty simple module, though. I like writing modules.
I got a breakout board with the EEPROM in DIP-8 package (socketed), so no soldering onto the prototyping area for now. Will probably get some SOIC-8 ones if this works out well, and do just that. The I2C EEPROMs, in the largest sizes I see available, are limited to 4 per I2C bus (each one has 2 pins dedicated to setting address) - which means one could just fit the maximum loadout of I2C EEPROM's onto the prototyping area.
One of the things that I'm imagining doing with this is having the Espruino check that the modules it needs are present on the SD card, in node_modules directory - and if they're not, extract them from the EEPROM and write them to the SD card (so when we pull the SD card to get the recorded data, we can just put in a blank micro SD card in it's place, hit reset, and have it sort itself out).
You say things like "at the moment" - does that mean that you're planning to change something that would make this more graceful in the near future, or just that someone might at some point do so?
I also do male pins facing up. It's more convenient IMO, and I don't like the way the male ends of dupont jumpers look - they don't inspire faith, even though they work.
I'm getting stackable headers for the next one - will probably still keep the males on top, but the females will keep it off the table (currently, I have a piece of tape on the bottom in case some bit of conductive debris gets under it), and would make it convenient to make a board that it would sit on that interfaced it with other things.