Jump to content

roadrunner84

Members
  • Content Count

    1,370
  • Joined

  • Last visited

  • Days Won

    33

Reputation Activity

  1. Like
    roadrunner84 got a reaction from abecedarian in Connecting 12V to MSP430 I/O Pin   
    An optocoupler is a combination of an LED and a phototransistor in one housing. So you'll need to drive the optocoupler as if you were driving an LED (use a resistor to limit the input current as stated). The other end will act as a transistor, so depending on the type you'll have to hook it up between your 3v3 and your input or between your input and your ground, then use the opposite pull-up/down resistor to create a defined level on the pin when the optocoupler is not conducting.
    The big advantage of an optocoupler over a FET solution is ESD and surge protection; instead of blowing the entire circuit, you'll just blow the optocoupler.
  2. Like
    roadrunner84 got a reaction from KatiePier in How to create text style   
    Figlet, a free and open tool.
  3. Like
    roadrunner84 got a reaction from Fmilburn in How to create text style   
    Figlet, a free and open tool.
  4. Like
    roadrunner84 got a reaction from bluehash in How to create text style   
    Figlet, a free and open tool.
  5. Like
    roadrunner84 got a reaction from MSPLife in How to create text style   
    Figlet, a free and open tool.
  6. Like
    roadrunner84 got a reaction from yosh in Custom MSP430-Board for EasyDriver   
    How about replacing the top lid with a same sized heat sink?
  7. Like
    roadrunner84 got a reaction from bluehash in Custom MSP430-Board for EasyDriver   
    How about replacing the top lid with a same sized heat sink?
  8. Like
    roadrunner84 reacted to chicken in [Energia Library] Hardware Counter Library for MSP430   
    From time to time, threads pop up where someone tries to count very fast pulses in the hundreds of kHz or even MHz range. There is a solution for the hardcore C-coders among us, but to my surprise there was no Energia library for this simple problem.
     
    I herewith present the CounterLib for Energia
    Download
    Source code and detailed instructions are also available on GitHub:
    https://github.com/astuder/CounterLib-Energia
     
    Currently the library supports MSP430G2553, MSP430F5529 and MSP430FR5969.
     
    To create an instance of the counter, simply declare it as a global variable like this:

    Counter<> MyCounter; // create a counter that counts pulses on pin P1.0Once created, the counter has 5 functions:start() initializes the timer peripheral and I/O pin and starts the counter stop() stops the counter, but does not reset the counter value read() reads the current value of the counter reset() resets the counter to 0, the counter keeps running readAndReset() reads the current value and resets the counter to 0 And a basic example, which should work for signals lower than 65 kHz:
    Counter<> MyCounter; // create counter that counts pulses on pin P1.0 void setup() { Serial.begin(9600); MyCounter.start(); // start counter } void loop() { MyCounter.reset(); // reset counter to zero delay(1000); // wait one second Serial.println(MyCounter.read()); // read number of pulses during the last second delay(1000); // wait another second } The library also supports dividers to measure much faster signals. For more detailed instructions see GitHub. 
    The library uses the external clock input of the timer peripheral. This enables the library to measure very fast signals (MHz range). On the downside, each timer only has a specific pin assigned, and the G2553 only has one timer with an external pin. It is also possible, that other Energia libraries or built-in functionality use the same timer, which won't work.
     
    Here's a list of the timers supported by the library and their pins:

    | Timer | G2553,| | | | | | G2452,| F5529 | FR5969 | FR6989 | | | G2231 | | | | |------------|-------|-------|--------|--------| | CL_TimerA0 | P1.0 | P1.0 | P1.2 | P1.2* | | CL_TimerA1 | n/a | P1.6 | P1.1* | P1.1* | | CL_TimerA2 | n/a | P2.2 | n/a | n/a | | CL_TimerB0 | n/a | P7.7*| P2.0* | P2.0 |Pins marked with * are not broken out on the LaunchPad or are difficult to access. 
    The library probably works on many other MSP430's, but you'll need to adjust the #defines in the library. Please report back if you successfully tested with other devices, so that I can extend the library.
     
    Please report any bugs.
     
    And also let me know if you break any speed records. So far I only tested it up to 750 kHz.
     
    Edit 9/3/15: Added support for FR5969. Thanks @@Fmilburn
    Edit 9/4/15: Refactored to make it easier to add more MCUs. Several bug fixes, thanks to all the eagle-eyed members of 43oh
    Edit 3/13/16: Replaced attached ZIP file with link to GitHub to always give up-to-date version
  9. Like
    roadrunner84 got a reaction from Taggsladder in Voltage divider with zener protection problems   
    Because the reverse current of a zener is not exactly zero, so there's a tiny current leaking through the zener causing it to act as a non-linear resistor in parallel with your second resistor.
    I don't think you can solve this problem using just passives. You could maybe use an opamp as an analog buffer, powering it from the same source as your controller will effectively clip your output voltage from the opamp to the maximum voltage allowed by your controller.
  10. Like
    roadrunner84 reacted to zlalanne in Deploying MSP430 Firmware using Ansible   
    Hello all!
     
    If anyone else is interested in devops tools like ansible/vagrant/docker or linux administration this project might interest you.
     
    I recently started learning about ansible a tool used to configure/orchestrate servers. So I thought I would try and use that to push firmware updates out to MSP430s. I came up with a solution that allows me to run a command on my machine which then copies the firmware to Rapsberry Pis and then flashes any MSP430 LaunchPads connected to them.
     
    I first had to compile the msp430 dll and the latest version of mspdebug for the ARM architecture (rather than x86). Essentially this allows me to program MSP430s from a Raspberry Pi using mspdebug. I talk about the steps here:
    http://zacklalanne.me/automated-deployment-of-msp430-firmware-part1/
     
    Then I wrote an ansible playbook to automatically deploy the dll and mspdebug as well as the firmware to the connected Raspberry Pis which then push the firmware to the MSP430s.
    http://zacklalanne.me/automated-deployment-of-msp430-firmware-part2/
     
    Don't think this is too realistic for an actual production environment but getting it all to run was a good learning exercise in compiling code on linux and system administration.
     
  11. Like
    roadrunner84 got a reaction from bluehash in Terminal Programs - survey   
    I only use PuTTY, it fits all my needs, including VT100 terminal emulation and fancy stuff like that.
  12. Like
    roadrunner84 reacted to tripwire in [FIXED!] JTAG interferes with SensorTag external flash access   
    Here's a heads-up for anyone that wants to use the external SPI flash memory on the SensorTag: it's not accessible while a debugger session is active.
     
    Unfortunately the pin on the SensorTag's CC2650 which outputs the SPI clock to the flash memory is also used as the JTAG TDI pin:
     

     
    While you're debugging using the Debug DevPack the CC2650 is unable to clock data out to the flash chip. That means the flash will just sit there doing nothing and the CC2650 will end up reading zeroes from the SPI bus.
     
    To use the flash you need to be certain that no JTAG communication is occurring during execution of your firmware.
     
    The easiest way to do this is just to disconnect the Debug DevPack and power the SensorTag from a coin cell or external power supply.
     
    Alternatively you can use the Debug DevPack to power the SensorTag, but then you have to follow this procedure:
    Load your updated firmware onto the SensorTag using the Debug DevPack (I just run it in the CCS debugger) Terminate the debug session once you reach the start of main() Disconnect the Debug DevPack from USB Detach the SensorTag from the DevPack Connect the Debug DevPack to USB Reattach the SensorTag to the Debug DevPack Be careful not to miss step 2, or the DevPack will resume JTAG communication when everything is connected up again. I found that out the hard way...
     
    Also, the order of the last two steps is to avoid an issue with powering up the Debug DevPack while it's connected to a SensorTag with no coin cell. The advantage of that is that you don't need a coin cell (I've drained two already...)
     
    This makes testing code that uses the flash really difficult, as there's no way to use the debugger. I've been using a combination of UART logging, LED flashes and beep codes from the onboard buzzer to keep track of where the code is up to.
     
    The other thing I'm doing is detecting whether the flash is available during startup and skipping the flash accesses if it's not there. That lets the rest of the code run in the debugger without problems.
     
    The command sequence I'm using to detect the flash is:
    Repeatedly send a Read Status Register command (0x05, 0x00) until the received BUSY flag is clear Send a Read Mode Reset command (0xFF, 0xFF) Send a Release From Power Down command sequence (0xAB, 0x00, 0x00, 0x00, 0x00) Flash is available if the device ID value 0x12 is received in the last byte of the Release From Power Down sequence This sequence is arranged to work irrespective of the state of the flash chip. If JTAG is active the code will immediately fall through step 1 (BUSY flag is zero), but the received device ID at step 4 will be zero too. Step 2 covers against any remote chance that the device has ended up in dual-SPI mode. Step 3 wakes the chip if it has been put in suspend, and returns the device ID regardless.
  13. Like
    roadrunner84 reacted to Lgbeno in New MSP430 Wireless Sensor Node   
    I've wanted to create a batteries included, very low cost wireless sensor kit for quite a long time now.  I've made some attempts in the past but up until this point they were either too expensive to produce and too limited in expandability.  I think that I've finally struck the balance that I'm going to be pleased with.
     

     
    The device is a little larger than a single AA battery, that is what it is powered off of.  It has an NCP1400 Boost converter to bump up the voltage to 3.3V.  The processor is MSP430G2553IRHB (32QFN) and it is attached to a HopeRF RF75 radio.  There are 15 GPIO available through a 0.1in female header that is sandwiched between the battery holder and the circuit board.  It plugs into a Launchpad for programming.  Footprints are available to solder on a Si7020 temp sensor, a 32kHz crystal and two LEDs.
     
    I have the pins_energia ready and now looking at what it takes to make the @@spirilis enrf24 library work with it.  I'll also create my own library with some analog.io tie ins as well as a special surprise.
     
    My goal is to sell these for $9.99 after I can get them debugged.  Would anyone be interested in one?
  14. Like
    roadrunner84 got a reaction from mark0 in NOOB: Code review and feedback - chicken coop door and solar tracker   
    You do know that it's really hard to mash though a lump of code this size and seek for errors without feedback on any other thing in the system?
    I'll try to look into your code, but don't expect miracles. For a better feedback, try to slim down your code, test that the problem still occurs, then post the slimmed down code and explain the exact sequence of events that lead to the incorrect behaviour.
  15. Like
    roadrunner84 got a reaction from yyrkoon in Linux stack size.   
    Any application has a separate stack from any other application. So if one application was running with a large stack, that just means it's using more memory. To other applications it does not matter whether this memory is stack (auto memory) or heap (free space).
    I barely ever find the need to use alloca() ever, in particular when using C instead of C++ (yes, those are not 100% compatible!)
    C has this cool thing that you can use a variable as the size for your arrays. Since variables can only be declared at the start of a block, you mostly use function parameters for this.
    int foo (unsigned int bar) { int baz[bar] = {0}; // only legal in C, not it C++ ... }
  16. Like
    roadrunner84 got a reaction from spirilis in Linux stack size.   
    Any application has a separate stack from any other application. So if one application was running with a large stack, that just means it's using more memory. To other applications it does not matter whether this memory is stack (auto memory) or heap (free space).
    I barely ever find the need to use alloca() ever, in particular when using C instead of C++ (yes, those are not 100% compatible!)
    C has this cool thing that you can use a variable as the size for your arrays. Since variables can only be declared at the start of a block, you mostly use function parameters for this.
    int foo (unsigned int bar) { int baz[bar] = {0}; // only legal in C, not it C++ ... }
  17. Like
    roadrunner84 reacted to greeeg in RGB 4x4 button thing   
    Built a second prototype to test out the smaller 0404 LEDs. I thought they might have better colour blending because the LED dies are closer. But the silicone buttons already do alot of that. They don't appear to make much difference.

    The LED dies are of similar sizes, so the 0606 size is the same brightness of the 0404.


    At the brightness I'm running at makes the TLC a little warm, but not too much. On the next PCB rev I'll add some thermal vias on the TLC's exposed thermal pad.

  18. Like
    roadrunner84 got a reaction from OzGrant in Swapping pins for OneWire   
    Yeah. For option 1 you need to replace all calls like ds.foo() by ds->foo(). For option 2, I forgot to add "void " in front of SetPin(...
  19. Like
    roadrunner84 got a reaction from Antscran in MSP430F550x based frequency meter   
    For those of you who rather play with C than assembler, a translation as true to the ASM as possible:
    __interrupt TimerA0_ISR(void) // Note that the implementation of an ISR is compiler dependent { ++R10; } __interrupt TimerA1_ISR(void) // Note that the implementation of an ISR is compiler dependent { ++R11; } void main(void) { // Timer TA1 is set by default P1SEL |= BIT6; TA1CCTL0 = CCIE; // interrupt enabled // Timer TA0 SMCLK/1 TA0CTL = TASSEL_2; // clock source SMCLK TA0CCTL0 = CCIE; // interrupt enabled TA0CCR0 = 60000; //Measure R10 = 0; R11 = 0; TA0R = 0; // clear timer counter TA1R = 0; // clear timer counter TA0CTL |= MC0; // start timer TA1CTL |= MC1; // start timer while(R10 != 400); // Wait TA0CTL &= ~MC0; // stop timer TA1CTL &= ~MC1; // stop timer // R10 TA0 = 400 * 60000 = 24000000 // R11 TA1 = Result }
  20. Like
    roadrunner84 reacted to greeeg in RGB 4x4 button thing   
    Started looking into a enclosure for this project. ( Typically this would be done before designing the PCB.... )
    But I'd like to make use of some of the rapid prototyping tools I've invested in.
     
    Something I should have done before sending the board off to the fab.. Verified that the holes lined up. (they didn't on board version 1)
    By exporting a copper layer as a dxf or svg, you can then import your PCB into your favorite CAD tool. Luckily Adafruit provide the 3d CAD file for the rubber elastomer buttons.


     
    Good to see that everything lines up. Next step is a simple 2 part case.
  21. Like
    roadrunner84 got a reaction from bluehash in UART communication - Can't type anything in PuTTY.   
    Please fill in your post.
     
    Putty displays ONLY that what comes back from the remote end, so if the remote and is not doing echo (printing back anything you type), you will not see it, but it is sent.
    In the configuration of your current session, under "Terminal" you can force Putty to do local echoing, which will show things you type. If both local echoing is on, and the remote end does echo, you'll see every character you type displayed double.
  22. Like
    roadrunner84 got a reaction from cubeberg in UART communication - Can't type anything in PuTTY.   
    Please fill in your post.
     
    Putty displays ONLY that what comes back from the remote end, so if the remote and is not doing echo (printing back anything you type), you will not see it, but it is sent.
    In the configuration of your current session, under "Terminal" you can force Putty to do local echoing, which will show things you type. If both local echoing is on, and the remote end does echo, you'll see every character you type displayed double.
  23. Like
    roadrunner84 reacted to bluehash in New BeagleCore on KickStarter - $44   
    KickStarter Link 43oh Blog Specs:
    size: ca. 32 mm
  24. Like
    roadrunner84 reacted to spirilis in Tools to reset a Metawatch?   
    Isn't the metawatch based on an MSP430F5438A or somesuch? 
    Sent from my Galaxy Note II using Tapatalk
  25. Like
    roadrunner84 got a reaction from OzGrant in Swapping pins for OneWire   
    Maybe a stupid suggestion, but, did you put in the curly brace open?
    //Original code #include "TM4C_DS18B20.h" DS18B20 ds(PIN_OW); //New Code #include "TM4C_DS18B20.h" setup() { // <--- THAT brace should be there!! DS18B20 ds(PIN_OW); ... } Also, if you declare it in the setup() scope, it is NOT available in the loop() scope!
    You could declare it in the global scope and create it in the setup() scope, maybe.
    #include "TM4C_DS18B20.h" DS18B20 *ds; setup() { static DS18B20 _ds(PIN_OW); // create a static instance, so it's available after setup() is finished ds = &_ds; // point ds to the address of _ds, so it's available to loop() ... } Another option is to crudely make an override routine to set another pin AFTER construction.
    //In DS18D20.h, inside the class under public, add this line SetPin( uint8_t pin) { _OWPIN = pin; } //At least, if you're using the library I found //Use this in your code #include "TM4C_DS18B20.h" DS18B20 ds(0); setup() { ds.SetPin(PIN_OW); ... }
×
×
  • Create New...