Jump to content
43oh

johnnyb

Members
  • Content Count

    12
  • Joined

  • Last visited

Reputation Activity

  1. Like
    johnnyb got a reaction from Philipp in Post your Thrift Store finds   
    Dumpster diving is illegal here. Lots of people put useful items by the curb with a free sign. I used to put free stuff on Craigslist but that attracts to many hoarders. Now I put a price and don't take any money when someone values item enough to pick it up.
  2. Like
    johnnyb reacted to cubeberg in Pogo Pins for testing & programming   
    So recently I picked up 20 pogo pins from eBay - 10pcs P50-E2 Dia 0.68mm Length 16mm 75g Spring Test Probe Pogo Pin.  I've been using them to test out my relay boards without attaching headers.  
     
    They fit into female headers very nicely - and will absolutely fit through regular holes intended for headers.  They're nothing like the huge pins you see on Sparkfun.  I'm using them with a Rev 1.4 LP that already has female headers.
    They're working pretty well for testing right now - although getting them to fit into all of the holes is a little tricky sometimes.  Even though the pins are pretty snug in the headers, they move around a bit and a pin or two will end up not quite fitting into the whole.  It's usually pretty easy to fix - just nudge the pin a bit and it drops into place.  For a better testing jig - it's probably best to solder them into a board - I may make something small from OSHPark 
     
    The head of the pins is cone shaped and fits nicely into holes drilled for a header without going through - perfect for this type of setup.
     
    Thought you guys might enjoy some pictures!



  3. Like
    johnnyb reacted to JWoodrell in 43oh PCB Logo   
    well the scan test boards came in and it was a mixed bag.
     
    the silkscreen codes got mangled by them (whole sections blocked in, and other missed, I'm not sure what happened, but I have an E-mail in to them, the gerber files were fine that I sent them)
     
    the copper layer codes under the soldermask may work with a lighter color mask (like red) but in purple they are too dark to see. so fail here
     
    the copper layer code shows some shape degradation from the etching process and the smaller one has the fine feature spots eaten away degrading the code beyond use.  the large code shows the degradation  but the spots are big enough to have survived.  however QR codes have to have a light colored border, the large code scanned when I edited that into the picture, although the small one still no scan.
     
    the soldermask codes are both scannable and quite clear and defined. so win on that one.
     
    the 43oh logos on the back worked well and the binary digits are quite clear on both, however the hybrid one shows it will have issues if there is any misalignment between the silkscreen layer and the soldermask layer (which there will always be some) so i think it should be killed, and use 100% soldermask logo as shown, or 100% silkscreen.  but it is workable.
     
    on a sidenote none of the codes would scan "live" while holding the phone up to them, because its running off a lower res video image, I took a picture with the phone and fed the still image into the qr code app and they processed.
     
    so for "live" scanable codes I would say they need to be at least 50% larger,depending on the lens and camera quality as well as the app on any given phone
     
    (these photos were taken with my Iphone, and the border was edited into the copper layer code)


  4. Like
    johnnyb reacted to RobG in 8x8 RGB Matrix Booster Pack   
    3bit color (no PWM)
     

     


  5. Like
    johnnyb got a reaction from LariSan in SwitchPad: LaunchPad Gender Changer   
    Nice board. I like both of those solutions but find I use the few female-male jumpers I have or make one by joining a female-female and male-male jumper.
  6. Like
    johnnyb reacted to David Bender in SwitchPad: LaunchPad Gender Changer   
    Hi All,

      I got fed up with male headers on the LaunchPad, so I made up a small PCB to gender change the LaunchPad. It has the nice side effect that it is easy to switch my LaunchPad among different projects. Check it out

     

    https://analog10.com/posts/000_switchpad.html

     

    Thanks,

    Dave

     



  7. Like
    johnnyb reacted to LariSan in LaunchPad Proto Plate- from Ponoko   
    I had a few of these "protoplates" made-- I fell in love with the one from AdaFruit for the BeagleBone and really wanted one for the LaunchPad and had some made. 
    (I have to thank Bart, if he's on here, for really making my first Ponoko trial-run so smooth). 
     
     
        So here is where you can order the sheet.
    It's 14 total plates on the Plastic- Acrylic- Clear- 3mm- P3 sized sheet, which comes out to be about 3.50 for each plate- total about 46.50 (Bart had free shipping since he's a regular user at Ponoko). 
     

      I'm sure there is a more efficient way to arrange these to get more on the same sheet (there was a lot of extra plastic that wasn't used). This was a trail run for me. 
     
    It comes in a large sheet, where you only need to pull off your plate
      I left the backing on the plate--     Added the breadboard:    
    these breadboards from Mouser (I get them in packs of 10 so it comes out to be about 4.95 a piece)
      The hardest part was to figure out how to connect the LaunchPad to the sheet.  Even though it's nice that the rubber feet were already included... it turned out to be inconvenient. 
    The BeagleBone and the Arduinos have screws that allow you to use standoffs.  In this case after trying: hot glue, epoxy, these scrapbooking "zots" (super strong adhesive tapes in dot shape) and double stick tape and found out that all of them don't adhere to the rubber well.  What's worked is Crazy Glue.      Put it on the LaunchPad, set it down and let it dry...    then I peeled off the backing.        I'll get to test these in a workshop soon, but so far I like them, but plan on changing a few things.  I have about three extra that I wouldn't mind sending to anyone who wanted to see it.    It's hard to know which direction is up... I have two sleds and one is right handed and the other is left handed... I guess if I just removed the logo all together I could have it be either right or left handed      This is what I think my next one will look like, but I'm completely open for any suggestions!     Hope that's helpful, I've included the files to make the edits in my dropbox (it's in illustrator and the forum doesn't like the format for some reason). https://www.dropbox.com/sh/6tho7jrplryvyhl/PJAJ22XqpQ
    Final- LaunchPad Proto-Sled v1.0- Bart.zip
  8. Like
    johnnyb reacted to ILAMtitan in Newbie with 20X4 LCD Screen & LaunchPad   
    Sadly, it's not something as simple as reading a few DIO lines and decoding them.
     
    I happen to have a Kill-A-Watt that's already in pieces, and it's easy to see that it's a highly cost optimized device (it even has a single sided PCB).  There are three pieces of silicon on the board, a four channel opamp, a small EEPROM, and a chip on board MCU (one of those dreaded epoxy glob jobs).  This means that all the measurement and display logic is done by a proprietary device.  It essentially takes in analog signals, and outputs the results straight to the LCD.
     
    Now, the LCD in this isn't the normal serial LCD that most of us are familiar with getting off of SparkFun.  Those are nice and take simple UART commands, and control the actual driving of the segments for you.  On many embedded devices, the LCD segment driver is built into the MCU itself, with no UART lines to probe for reverse engineering.  The MSP430 has these embedded LCD drivers in some of the larger devices.  The low cost driver less LCDs also don't just take a DIO line, they need charge pumps.  I'm not an expert on this topic (I just connect the thing and it works) but the LCD driver will output an AC voltage that then polarizes the segments in the LCD to turn them dark. More info on how the 430 does it can be gleaned from here: http://www.ti.com/lit/an/slaa272/slaa272.pdf
     
    In addition to this, these drive lines are also usually muxed.  So you would have to work out which ones are the COMM lines, and which ones are the segment drive lines.  Then you could potentially convert them to DC with a filter, and then into an MCU to decode. It's tough, but doable.
     
    Your other alternative is to build your own version rather than hack onto the Kill A Watt.  This lets you develop a more extensible platform, as well as use more TI devices
    Quick warning and disclaimer: working with mains voltage is super dangerous, and probably shouldn't' be done by anyone.
     
    TI already has a bunch of application notes on this, but a good place to start if you might be thinking about doing this on a launchpad is this one: http://www.ti.com/lit/an/slaa391/slaa391.pdf
    And the energy watchdog (the TI version of the Kill-A-Watt that sadly isn't available anymore) has schematics in the users guide that can be a great starting point: http://www.ti.com/lit/ug/slau362/slau362.pdf
     
    Hope your project goes well!
  9. Like
    johnnyb got a reaction from Troll_Dragon in A couple of Development Boards for sale.   
    I appreciate you offering deals to the community. I'm still working my way up Joe tinkerer.
  10. Like
    johnnyb got a reaction from zaraudio in hello for socal   
    Welcome.
  11. Like
    johnnyb reacted to DanAndDusty in Strange problem: LED1 and LED2 react differently to same code   
    Hi Potatochan,
     
    looking at your code the problem you have is not to do with the for loop (which you are using as a software delay) but with the fact that your port isn't in a "known state"..  In pseudo code you have....
     
    Put the WatchDogTimer on hold.. (Tell the watch dog.. Go on hold. If you don't do this your 430 will reset regularly)
    Tell the 430 that in Port 1 bits 0 and 6 are used for output.
    Loop forever    
        Toggle bit 6 of port 1      If the LED on bit 6 is on turn it off, if its off turn it on    
        count to 5000                Counting is purely as a delay    
        Toggle bit 0 of port 1      As with the other toggle.. but for the other LED
    Continue the loop
     
    As you can see.. all the interactions with P1OUT are dependent on what was there before.  You noticed them in sync and not in sync not because of what I was looping to, but because of what they were on before.
     
    Im guessing you run the code (maybe stepping through) then edited the number, re-uploaded and run the code.  Depending on where you stopped the code the LEDs could have been on or off semi randomly.  The solution is to put the port into a known state.  After the line that sets P1DIR your problem would be solved if you put in P1OUT = 0; Which says take every bit low.
     
    As to the counting loop being optimised out as pabigot said.. think about when you played Hide and Seek as a child.. (Im hoping this game is universal ) The game starts with 1 child counting to a number maybe 100.  This was purely to give a delay before they started hunting.  Now some children counted slow and some counted fast, and some were clever and thought that the counting achieved nothing and could be optimised to "1, 2, skip a few, 99 100".
     
    The compiler when in release mode can optimise your code and decide "That counting achieves nothing so I can safely ignore it".. so your code behaves differently in release mode from debug mode.  The solution here is to use __delay_cycles(xx) where xx is the number of cycles to pause.  At 1MHz using __delay_cycles(1000000) will always wait 1 second, __delay_cycles(100000) will always delay 1/10th of a second.  I can't remember the default speed of the 430 I think its either 1MHz or 1.1MHz.. I always set the clock to one of the calibrated speeds at the sametime as I put the WDT in hold mode.  The lines to do this are....
     
    BCSCTL1 = CALBC1_1MHZ; // Set range DCOCTL = CALDCO_1MHZ; // Set DCO step and modulation    
    The way I would have written your code would be....
     
    #include <msp430.h> #define LED_RED BIT0 // The Red LED is on P1.0 #define LED_GREEN BIT6 // Green LED is P1.6 void main(void) { WDTCTL = WDTPW + WDTHOLD; BCSCTL1 = CALBC1_1MHZ; // Tell the 430 to run at a calibrated DCOCTL = CALDCO_1MHZ; // Clk speed of 1MHz P1DIR = LED_RED + LED_GREEN; // We want outputs on Red and Green LEDs only P1OUT = 0; // Start with both LEDs off while(1) { P1OUT ^= LED_GREEN; // Toggle state of the green LED __delay_cycles(500000); // Delay for 1/2 a second (clock is at a known 1MHz) P1OUT ^= LED_RED; // Toggle the red LED } }  
    I think this code would do what you want.  Things to notice are...
     
    1) The #defines at the top.  These tell the compiler "Whenver you see LED_RED in the code replace it with BIT0". BIT0 is itself a #define for 0x1, BIT6 is a #define for 0x40.  These take a little longer than using 0x41 instead of LED_RED + LED_GREEN, but this delay is done by the compiler on your PC before the code gets to your 430.  So the 430 gets the exact same code as with what you had written and so runs with exactly the same efficiency, but for someone reading your code it is obvious which LED is being toggled at which line.
     
    2) Setting the clock to calibrated speeds.  The 430 has a very flexible clocking system that run run the CPU at almost any speed upto 16MHz, the devices have certain speeds calibrated into them at the factory, i.e. the MSP430G2553 has 1MHz, 8MHz and 16MHz if I remember correctly.  We are saying run at a known speed of 1MHz.  If you wanted 16MHz use CALBC1_16MHZ and CALDCO_16MHZ.  If you did this though you would have to alter your __delay_cycles line to __delay_cycles(8000000) for a 1/2 second delay.
     
    3) Changing your for(;; ;-) to while(1).. This one is personal taste.  Each says "Loop forever".  Personally I think the while(1) is easier to understand but many many other people prefer the for(; ;-) method so you will see both in examples round the net.
     
    I meant this as a quick response and got carried away as usual..  I hope it helped.
     
    Dan
     
    P.S. One further thing to add.  Putting the CPU into a known good state is a good practice to get into.  For example when you start using interrupts each interrupt has an interrupt flag that says this interrupt has occured.  Good practice says to always clear this flag before enabling the interrupt.  It is a good habit to get into and saves much hair pulling, keyboard bashing later on (I know.. I learned this one the hard way)
  12. Like
    johnnyb reacted to roadrunner84 in Greetings from So Cal   
    I personally use IAR kickstart, but CCS is the "official" TI IDE, the compilers are comparable in features and quality.
    If you want a less steep learning curve, you might consider Energia, which is the MSP430 port of the IDE used in Arduino boards.
    If you're really brave, build your own toolchain using an editor of your liking (eclipse seems popular) with the mspgcc compiler/linker chain.
  13. Like
    johnnyb reacted to jsolarski in Greetings from So Cal   
    Welcome to the forums.
     
    IDE? whats wrong with a text editor and a mspgcc? lol
     
    But I would agree with bluehash, and use CCS, most code written on the forums will work with it, or with very little modification
  14. Like
    johnnyb reacted to bluehash in Greetings from So Cal   
    Welcome. CCS is your best IDE to start with. it's a huge download though.
×
×
  • Create New...