Jump to content

sutekh137

Members
  • Content Count

    14
  • Joined

  • Last visited

  1. Yeah, it started by them asking for a note to justify, and then became a rejection after an order was accepted, saying I had requested too many samples recently. They're not wrong. *smile* I want to say the LM1084 allows inputs over a very wide range, at least up to 12V (I use a car battery, for example). I think I also got some LM1085s and LM1086s -- pretty much the same but I think they have different current limitations. Looks like the LM1084 can handle 5 amps of output current, and input voltage can be dropped down from 2.6 to 27 volts. So it can handle a very large range. As I said, I have used 6, 9, and 12v to run my 3.3/5v hybrid wirings. A lot of components out there work for 5V due to the Arduino boards running on that (at least a lot of them do). You can also get the drop-out regulators in an "ADJ" flavor, meaning you can add your own resistors to make it drop down to whatever you wish. Thanks, sutekh137
  2. Hm, I will have to see if I can order anything again! I maxed out number of samples several times in quick succession as I worked through "basic" project ideas involving temp, amplification, etc. The voltage regulators are really nice, because I can regulate 3.3 and 5V from a single 9V battery (or my 12V car battery source) to do things like running the MCU and a 5V LCD. No worrying about voltage dividers or rolling your own transistor based regulation. I highly recommend their three-pin drop voltage regulators like the LM1084. Thanks, sutekh137
  3. I have put both LaunchPad chips on breadboards, it works fine. Push it in over a breadboard split and go nuts. The key is to pull the RST pin UP, meaning to Vcc (as opposed to grounding it). Grounding RST is what resets the chip, so pulling it up via a pullup resistor (something like 47K ohm should do) brings the chip to life. And hooking up Vcc and GND to the appropriate pins, of course. From there, you can still program the chip, in place, with a Launchpad. Basically, you just use the emulation side of the Launchpad (those jumpers along the dashed line) and connect to Vcc, GND, RST, and TEST. Stick those connections in the breadboard at the right spots, connect the Launchpad to USB, and the chip will be visible to flash as if it were in the Launchpad socket. Good luck! PS: You can get sample chips from Texas Instruments, including the 553 and 452. So, you can get some spares, if you like. Don't go too crazy with free samples -- I can attest to the fact that they WILL shut you down if you ask for too many sample shipments. I got a nice variety of drop-out regulators, temp sensors, amps, and more MCUs without issue, and can buy more if I need them (most ICs are pretty cheap...)
  4. Indeed, I was surpised when it worked. Rather, I was surprised when I hooked up the ammeter and saw that it really WAS dropping to a less-hungry power situation (I figured it was just staying full power and not really dropping, but not throwing errors, either). I think I tried the other LPMs and noticed a different current reduction at each, so I just went as deep as I could with still having the thing play (and wake up) properly. I know I am out of my league when dumb luck lets me get something built better than I had planned. *smile* Maybe it will "break" with a future Eneriga update or something, and that will provide more clues as to how this is working now! Thanks for the info about ...exit(). If anything DOES draw me further into MCU programming, it will be interrupts. Though many books and docs talk about how the interrupt paradigm is odd and strange to get used to, I immediately likened it to event-driven Windows programming -- which is what I do for a living. A Windows application UI is, in a way, just a massive display of interrupt widgets linked to many, many ISRs. The fact that they need to be used more carefully and thoughtfully in the MCU world was just sort of common sense to me. I leave my "sloppy" work for PCs with massive processors, huge clock speeds, and GBs of RAM... Thanks, sutekh137
  5. You know, I am not really sure why it wakes up. As you can see with the most basic ISR I attach, it doesn't even need to have anything in it: void ISR_ButtonPressed() { // Just here to wake up from low power mode (if even attached). // It does not appear that any live code needs to occur. return; } I DID try to add some sort of weird vector thingamabob like the "__bic_SR_register_on_exit()" you mention, but got compile errors (I don't think all of my includes were correct). However, yes, it does work. I'm not sure why. By attaching interrupts to every key before dropping into LPM and then detaching after, that stub ISR serves to wake things up. And even if it didn't, I could probably figure out how to make the __bic_SR_register_on_exit() stuff work, seeing as how the _BIS_SR(LPM4_bits | GIE); seems to work (or is that only because it has something in the Energia include files doing the heavy lifting for me?). As you can tell, I'm quite the n00b, hence my asking more about what Energia lacks. In any case, I doubt a hobbyist like me will ever get to the point where I need more than it can offer. *smile* Here's a link to the YouTube video of showing the keyboard drop into LPM after ~5 seconds. ...gets to the point at around 2:30, sorry I get long-winded, and yes, I did add an LM386 amp all on the same board (need to do another video showing the finished product and polyfraudia)! Thanks for the discussion! I am learning just via osmosis when I am around such clever folks! Thanks, sutekh137
  6. Can you elaborate on the issue with LPM? I use LPM4 to put my little keyboard to sleep, and it works fine (in Energia). I call: _BIS_SR(LPM4_bits | GIE); and then pressing any key fires an interrupt that brings the keyboard back to life and finishes the loop. I do have to play a fair amount with attach and detach commands for the interrupts, but that is because I want the tones to be smooth and want to be able to change octaves while the note is playing. I can completely verify that the LPM4 stuff works. When it goes to sleep, the current it is taking drops lower than my ammeter can even read (down from a few ma). And since straight "raw" code will compile fine in Energia (at least the samples I have tried), what exactly is it missing? Just curious. For the full code of my 85-tone keyboard you can check it out here: https://github.com/sutekh137/Energia/blob/master/Keyboard/Keyboard.ino or with fraudulent polyphony: https://github.com/sutekh137/Energia/blob/master/PolyFraudic/PolyFraudic.ino Thanks, sutekh137
  7. Here is the begin() method in the LCD_5110 library for Energia (current from GitHub): void LCD_5110::begin() { pinMode(_pinChipSelect, OUTPUT); pinMode(_pinReset, OUTPUT); pinMode(_pinDataCommand, OUTPUT); pinMode(_pinSerialData, OUTPUT); pinMode(_pinSerialClock, OUTPUT); pinMode(_pinBacklight, OUTPUT); pinMode(_pinPushButton, INPUT_PULLUP); digitalWrite(_pinDataCommand, LOW); delay(30); digitalWrite(_pinReset, LOW); delay(100); // as per 8.1 Initialisation digitalWrite(_pinReset, HIGH); write(_commandLCD, 0x21); // chip is active, horizontal addressing, use extended instruction set write(_commandLCD, 0xc8); // write VOP to register: 0xC8 for 3V
  8. Ah, I see, a COMPLETE hardware solution. Very cool. I'll definitely remember that if I go all the way to freeing up a pin (which could happen when I hook up a 4x4 matrix keypad = pin eater). As far as the "software" reset (well, using a pin, but driving RST through low/high cycling), the Arduino library I found uses a delay of 500 ms between LOW and HIGH and the LCD_5110 for Energia uses 100 ms (with a correct reference to the datasheet in the comments). So, I'll play around, and hope I don't break anything. *smile* Thanks, sutekh137
  9. Hm, in looking more closely at the LCD_5110 lib, I think my use of zero for the button pin is a bad idea. Not sure what happens when you try to set pinMode() on pin zero? I think I will tweak that lib to check for that property being zero (and also make getButton() not hang, probably) throughout the library cpp. I suppose I could even make a new constructor for folks who don't want to use getButton(). In any case, I see all kinds of tweaks I can make to initialization (you are right -- it is very finicky according to the comments over on SparkFun for the unit!) including the init commands that are sent and delays between taking RST low then high. Adding your hardware solution certainly won't hurt, looks kind of fun! Thanks again, sutekh137
  10. Thanks for the responses! Both very good ideas... I was going to try messing with the "begin" code (e.g. delays) last night, but had zero time to project. semicolo, I should definitely go look at the datasheet and work on a circuit...great idea. I had not heard the screen was so finicky about RST, but since the backlight works fine (but no text), it feels like something resett-y is in order. I hope I'm not damaging my screen, cheap as they are (they are down to around 3 bucks these days...pretty sweet! And less soldering than a standard 16x2 LCD, a good thing when you suck at soldering like I do. *smile*). Your circuit is extremely elegant, I'm quite jealous! Basically, this is just acknowledging that the RST on the LCD needs a pull-up, much like the LP itself? Is that right? I didn't run across anyone else mentioning the need to do that, but it makes sense. By the way, I assume I can add that circuit to either "side" of the LCD board, correct? It's nifty that they put pin-holes on both sides. My LCD has the same order of pins as in your picture, but most docs I found early on have a different order... Thanks so much! sutekh137
  11. Hey all, I recently got a Nokia 5110 LCD working using the LCD_5110 lib from GitHub. Works great, so thanks to giants whose shoulders I stand atop! I moved my chip (G2553) directly to the board as I have done several times before (with a pullup resistor on RST), and I loaded a little demo program on it with my "loader" board (just TEST, RST, GND, and VCC hooked up to the emulation side of an LP). Program loads and runs fine, but when I remove the loader and cycled power (I was just changing battery sources from a 6V pack to a 9V battery -- they are dropped to 3.3V), the LCD does not init properly. Sometimes resetting (disconnecting the RST pullup) would make it come back, sometimes not. The weird thing is that the sketch IS running, because the ISR to toggle the backlight DOES work -- but no text displays on the screen. When it gets this way, I hook up the loader again, flash the same program, and then everything works fine. If I unhook the loader and cycle the power, though, I am back to no text on screen. Am I initializing the screen incorrectly or doing something wrong in terms of power cycling and/or resetting? [incidentally, you'll see in the constructor for LCD_5110 that I use zero for the getButton() pin -- I don't need a button-getter, and would rather use my own button handling code instead of calling the LCD's getButton() method. What is the best way to call the constructor in that case? The zero works (compiles, anyway), and it looks like getButton() just hangs the program if I ever call it (so I won't). But surely I am missing something to use such an inelegant methodology...] Any help would be appreciated! Thanks, sutekh137 Sketch: //System/library includes. #include <LCD_5110.h> // Defines... #define TOGGLE_BACKLIGHT PUSH2 // Instantiate the Nokia 5110 LCD class (non-SPI): // LCD_5110 lcd(Chip Select, Serial Clock, Serial Data, Data/Command, Reset, Backlight, getButton() Trigger) LCD_5110 lcd(12, 13, 14, 15, 18, 19, 0); boolean glBacklight = false; void setup() { // Button will toggle back light using an ISR. pinMode(TOGGLE_BACKLIGHT, INPUT_PULLUP); attachInterrupt(TOGGLE_BACKLIGHT, ISR_ToggleBacklight, FALLING); lcd.begin(); lcd.setBacklight(glBacklight); lcd.text(0, 0, "Hello!"); delay(1000); lcd.clear(); lcd.text(0, 5, "Light off"); } void loop() { lcd.setFont(0); lcd.text(0, 5, glBacklight ? "Light on " : "Light off"); lcd.setFont(1); lcd.text(0, 2, " MSP430"); delay(200); } void ISR_ToggleBacklight() { delayMicroseconds(1000); if (digitalRead(TOGGLE_BACKLIGHT) != LOW) { return; } glBacklight = (glBacklight == 0); lcd.setBacklight(glBacklight); return; }
  12. /me imagines putting a FALLING interrupt on GND and a RISING interrupt on Vcc...or would that be the other way around? Hm, I guess it wouldn't ever trigger, anyway, would it? I know all the P<n> pins work for invoking ISRs because I use them all on my 13-key tone keyboard (plus 2 octave changers and audio out) to come back from LPM4 when the keyboard has gone idle. I attach and detach interrupts like a crazy person! Thanks, sutekh137
  13. Cool, Rickta, thanks for the idea! I need to get more into the guts of things, but Energia makes things so darn easy, I haven't had to yet. *smile* I'm still definitely Noob class! Thanks, sutekh137
  14. I'm not sure if you mean a periodic auto-save or an auto-save every time the sketch is uploaded. I'd prefer the latter, as that keeps what your chip is doing in sync with the code, and acts as a nice checkpoint for saves (for me, anyway, I am a change-try-change-try sort of developer). I once spent an evening working on a sketch, and for the last save (upon exit) I said "no", because for some reason I assumed it saved when a sketch was uploaded. Needless to say, I lost a bunch of work, and while my chip was in a pretty good state, I didn't know how to dis-assemble the code back to source (if that is even possible). Auto-save upon sketch upload would be very cool, and it could be a preference. Thanks, sutekh137
×
×
  • Create New...