Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    Automate reacted to Foghorn in Generic Button Debouncer   
    I implemented Jack Ganssle's State Button Debouncer Algorithm as C/C++ platform independent libraries. This is a fairly robust algorithm that can play nicely with interrupts (if the library is set up to be used that way) and can also work with setups where the button pins are polled on a regular interval instead.
    The library can debounce buttons on an 8 bit port in parallel and is efficient in that it only requires 14 bytes of RAM per instantiation, is malleable in that the amount of RAM consumed by each instantiation can be reduced if desired, and uses no computationally expensive operations such as multiplication and division to perform the debouncing.  If you would like a detailed explanation of the theory behind the algorithm, feel free to follow the link provided below: 
    The rest of the documentation can be found inside of the header files within the zipped file below. 
    Updated the button debouncer to revision 1.1.
    Now instead of specifying pullups or pulldowns are being used for an entire port, you can pick and choose which button pins will have pullups or pulldowns respectively.
    Also, there is no additional performance or extra RAM penalty for this approach. So, enjoy the extra functionality.
    Button Debouncer Rev 1.1.zip
  2. Like
    Automate reacted to StupidPig in Yet another DIY reflow oven implementation   
    After using a hot air station for my smd work for about two years, I think it is time to upgrade my tools to increase my productivity, so I'm looking for adding a reflow oven to my workbench. I searched the web and found many threads about DIY reflow oven, and there are a couple kits looks pretty neat, but somehow all the kits are no longer available for purchase, so I just have to make my own.
    First is the oven. I brought a cheap one from Amazon. Well, it's cheap, but already better than the one I has in my kitchen.

    Then I start working on the controller. Originally I was planning to use Nokia 5110 LCD for the display, but just when I'm going to start the project, I received an email from the store stating that RobG's 2.2" Touch LCD is back in stock! What a prefect timing! So, my controller end up using a MSP430G2553 + RobG's 2.2" touch LCD.

    The board under the LCD is just simple contains the socket for the 2553, a 3.3v regulator, and headers for the LCD, relay, and thermocouple sensor breakout board. The power input is via a mini USB port, and there is also a NPN transistor to power the SSR relay using 5V instead of 3.3V, as I think I read from the web that the SSR i brought form ebay is not quite working with 3.3V trigger.
    The thermocouple breakout board is using MAX31855, brought from Adafruit. I brought the type K thermocouple from them too.

    Time to put everything together. the front panel of the oven control, the temperature selection knob, and the mode selection knob is removed. I keep the bottom timer knob and use it as the main power switch. The SSR is mounted onto a big heatsink, then put on the bottom of the oven. A hole is drilled to route the thermocouple into the oven chamber. A cheap USB charger is also put inside the oven to used as the power supply, but the temperature keep reporting error occasionally when using that charger, so it end up goes to the rubbish bin. No more error when I use my LG phone charger.


    I did my first run and so far looks good. The controller right now just sit on top of the oven, and I'll need to comes up with a way to mount it on the front of the oven panel area.

  3. Like
    Automate reacted to energia in Building low power into Energia   
    I just finished the first version of low power implementation. 2 new functions were introduced: sleep(uint32_t milliseconds) and sleepSeconds(uint32_t seconds).
    sleep() has a resolution of 2 ms while sleepSeconds() has a resolution of 250ms. So calling sleep(1) will actually get you 2 ms. calling sleepSeconds(1) will get you 1.25 seconds. sleep() will go to LPM3 2ms at the time while sleepSeconds() will go to LPM3 250ms at the time. For this reason sleepSeconds() is a lot more efficient. sleep() depending on the MSP430 will get you between 15uA for the FR5969 and 25uA for the G/F5-Series. sleepSecond on the other hand will get you between 700nA for the FR5969 and 2uA for the G/F5-Series. If you would like to give this a try then replace the flowing files in your Energia installation. Make sure that you create a backup of your original files first.
    Replace: hardware/msp430/cores/msp430/Energia.h with https://raw.githubusercontent.com/energia/Energia/master/hardware/msp430/cores/msp430/Energia.h
    Replace: hardware/msp430/cores/msp430/wiring.c with https://raw.githubusercontent.com/energia/Energia/master/hardware/msp430/cores/msp430/wiring.c   Below is an example Sketch for the G-Series that spends most of it's time in LPM3 and briefly flashes the green LED every x seconds/milliseconds. /* * To reduce power consumption all unused pins should be set as output low. * Setting pins as output can potentiall cause conflicsts. * Therefor this below functions set all pins to input pulldown as a good alternative. */ void setInputLow(uint8_t port, uint8_t pins) { volatile uint8_t *out; volatile uint8_t *ren; /* Get the output register */ out = portOutputRegister(port); /* Get the internal resistor pull up/down register */ ren = portRenRegister(port); /* If the port is not a port then return */ if(out == NOT_A_PORT || ren == NOT_A_PORT) return; /* Enable the internal pull up/down resistors */ *ren |= pins; /* Clear output register bits to select pull down */ *out &= ~pins; } void setup() { /* IMPORTANT: Set all unused pins to input low to reduce power consumption. * The XTAL bits, P2.6/7 on the G-series and P5.4/5 on the F5529 and PJ4/5 on the FR5969 * should NOT be set as input low since this significantly increases current draw and * the crystal will fail to start. * The example below shows the pin settings for the G2553. * P1.6 is the Green LED and P2.6/7 are the the Crystal pins. */ setInputLow(1, BIT0 + BIT1 + BIT2 + BIT3 + BIT4 + BIT5 + BIT7); setInputLow(2, BIT0 + BIT1 + BIT2 + BIT3 + BIT4 + BIT5); // setInputLow(3, BIT0 + BIT1 + BIT2 + BIT3 + BIT4 + BIT5 + BIT6 + BIT7); // setInputLow(4, BIT0 + BIT1 + BIT2 + BIT3 + BIT4 + BIT5 + BIT6 + BIT7); // setInputLow(5, BIT0 + BIT1 + BIT2 + BIT3 + BIT4 + BIT5 + BIT6 + BIT7); // setInputLow(6, BIT0 + BIT1 + BIT2 + BIT3 + BIT4 + BIT5 + BIT6 + BIT7); // setInputLow(7, BIT0 + BIT1 + BIT2 + BIT3 + BIT4 + BIT5 + BIT6 + BIT7); // setInputLow(8, BIT0 + BIT1 + BIT2 + BIT3 + BIT4 + BIT5 + BIT6 + BIT7); /* Set the GREEN_LED as OUTPUT */ pinMode(GREEN_LED, OUTPUT); } void loop() { /* Briefly flash the RED LED every x seconds */ digitalWrite(GREEN_LED, HIGH); // turn the LED on (HIGH is the voltage level) delay(10); digitalWrite(GREEN_LED, LOW); // turn the LED off by making the voltage LOW delay(10); /* Sleep for 2 seconds. Around 1.5 uA of current */ sleepSeconds(2); /* Sleep for 500 ms. Around 25 uA current */ // sleep(500); }
  4. Like
    Automate reacted to spirilis in Ethernet Booster Pack v3   
    Ok, my totally reworked version of RobG's G2553 example.
    A number of changes have occurred here to Rob's core code:
    1. Some minor bugs in the Sn_IMR macros in w5500.h were fixed (although I don't use them)
    2. A "piecemeal I/O" infrastructure has been added-
    BSS bloated by 32 bytes as we now track a local copy of the RX_RD and TX_WR variables, since these variables can be written to but not read back; reading back their values actually gives us the original values, until Sn_CR_RECV or Sn_CR_SEND respectively are submitted; the whole idea behind this "piecemeal I/O" is that we're not doing this, we don't want the buffers to change yet.
    u_int _tx_wr_cache[8], _rx_rd_cache[8]; /* Used for "piecemeal" writes & reads when * we update TX_WR or RX_RD but the WizNet still * gives us the old value until we perform a CR * command action on the socket. */ A pair of functions update this value for a specified socket:
    void refreshTXBufferCache(u_char s); void refreshRXBufferCache(u_char s); For the most part you don't have to worry about it, as I've peppered those calls inside the existing stuff like socket() et al.  But do know that if you submit an Sn_CR_SEND or Sn_CR_RECV yourself, you may want to update the internal "state" of those cached variables if you happen to be using the Piecemeal I/O functions.
    The piecemeal I/O functions consist of:
    void writeToTXBufferPiecemeal(u_char s, u_char* array, u_int length); void fillTXBufferPiecemeal(u_char s, u_char value, u_int length); void readFromRXBufferPiecemeal(u_char s, u_char* array, u_int length); void flushRXBufferPiecemeal(u_char s, u_int length); // u_int getTXVirtualFreeSize(u_char s); u_int getVirtualRXReceived(u_char s); writeToTXBufferPiecemeal writes the specified array of length bytes to the buffer, updates TX_WR both on the chip and in the local cache, but does not send the data just yet.  It always starts writing from the current value of the "local cached copy" of TX_WR, so that you can continuously append to the buffer without committing the packet.
    fillTXBufferPiecemeal is similar, but it writes a single byte length # of times.  I added a fillMemoryArray() call likewise to support that.
    readFromRXBufferPiecemeal is as you'd expect... it reads those bytes, updates Sn_RX_RD and a local cached copy of it.  Further reads from that use the local cached copy of RX_RD as the address to start from.
    flushRXBufferPiecemeal merely advances RX_RD without reading; advancing the "local cached copy" likewise.
    getTXVirtualFreeSize computes the "amount of free space available" using the chip's copy of TX_RD and our local cached copy of TX_WR.
    getVirtualRXReceived computes the "amount of unread data" using the chip's copy of RX_WR and our local cached copy of RX_RD.
    Also to make it feel more unix-y, I've added these:
    u_int ntohs(u_char *array); void htons(u_int val, u_char *array); which are used extensively within the DHCP code.
    There is a printf-style debugging infrastructure used extensively throughout the dhcplib code, and you can use it in your own software as well.
    See wizdebug.c and wizdebug.h.  It has a hierarchical "debug level" of aliases called wiznet_debugN_printf() where N goes from 1 to 6, and if the WIZNET_DEBUG #define is less than N, that function is #define'd away as a simple ";", with WIZNET_DEBUG 0 removing it entirely.
    From wizdebug.h:
    /* Debug levels: * 1 - Basic information from libraries * 2 - Error reporting from libraries * 3 - Gratuitous information from libraries * 4 - Pedantic information from libraries * 5 - Extraneous detail from base socket library * 6 - Low-level I/O dump from SPI transfer functions * * Each debug level includes information from all levels below. */ #define WIZNET_DEBUG 4 void wiznet_debug_init(); void wiznet_debug_printf(char *format, ...); void wiznet_debug_putc(unsigned int); void wiznet_debug_puts(const char *); #if WIZNET_DEBUG > 0 #define wiznet_debug1_printf(...) wiznet_debug_printf(__VA_ARGS__) #else #define wiznet_debug1_printf(...) ; #endif #if WIZNET_DEBUG > 1 #define wiznet_debug2_printf(...) wiznet_debug_printf(__VA_ARGS__) #else #define wiznet_debug2_printf(...) ; #endif #if WIZNET_DEBUG > 2 #define wiznet_debug3_printf(...) wiznet_debug_printf(__VA_ARGS__) #else #define wiznet_debug3_printf(...) ; #endif (etc and so forth)
    You may want to inspect wiznet_debug_init() in wizdebug.c to make sure it supports your UART or other peripheral correctly.  Likewise, the source is all there, you can change it to spit the data out over SPI or I2C or whatever if you'd like.
    The printf function is based on @@oPossum 's code... minor addition is a "%h" type exists to print 8-bit hex only, whereas "%x" does 16-bit hex.
    The '\n' char is expanded to '\r\n' for UART use; see the bottom of wiznet_debug_printf() for that code, which can be changed.
    Also note that none of this has been tested on CCS yet, so I'll be looking for folks to try it out.
    Ok... DHCP library.
    dhcplib.h has a tunable: 
    /* User-tunable options. */ #define DHCP_LOOP_COUNT_TIMEOUT 500 The main while() loop in dhcp_loop_configure() does a _delay_cycles(250000) if nothing else is happening, and it will time out after DHCP_LOOP_COUNT_TIMEOUT iterations.
    The dhcp library has one simple function for the user to call:
    int dhcp_loop_configure(uint8_t *); // Perform DHCP configuration, optionally reporting back DNS server The uint8_t * pointer argument is a user-supplied buffer where 4 bytes will be written containing the first DNS server entry reported by the DHCP server; if this argument is NULL ( (uint8_t *)0x0000 ), the DNS server info will be ignored.
    If this function returns -1 (0 = success, -1 = error), an extern global called "dhcplib_errno" may be analyzed to discover the cause; a function:
    char *dhcp_strerror(int); // Return descriptive string of dhcplib_errno value has been provided to interpret this, passing a "char *" casted pointer to a const char string declared inside dhcplib.c.
    If dhcp_loop_configure returns successful (return value = 0), then your IP, subnetmask and gateway will be automatically configured in the WizNet's system registers.
    Also, the code currently has socket #7 hardcoded as a #define in dhcplib.h
    Code: robg-w5500-with-dhcplib.zip
  5. Like
    Automate reacted to chicken in Products using MSP430   
    MSP430F5435A and CC2560 in the remote control of the new Amazon Fire TV

  6. Like
    Automate reacted to BRey in [Energia Library] LowPowerLab RFM69 adapted to Energia   
    I have posted my adaptation of the LowPowerLab HopeRF RFM69 (Semtech SX1231) wireless module library: https://github.com/brey549/RFM69.git  The RFM69 modules are improved versions of the popular RFM12b units (Jeelabs, openenergymon, etc) and offer up to 100mw output as well as digital RSSI() and OOK modes.  I have successfully tested MSP<>MSP, Stellaris<>Stellaris,MSP<>Stellaris,MSP<>Arduino,Stellaris<>Arduino.
    I only had to change the attachInterrupt() call in RFM69.cpp & add #define overrides for the interrupts() & noInterrupts() functions in RFM69.h  I have extensively tested the library on both the MSP430G2553 & the Stellaris LM4F modules and only using the default SPI ports(Pins 7,14,15) . I chose Pin 6 for the interrupt in and Pin 8 for the SlaveSelect.
    I tried many different approaches for Interrupt disable/enable; and these are the only approaches that have held up under heavy packet traffic:
    For the MSP430:
    #define interrupts() P1IE |= BIT4; // turn on/off our interrupt !!MUST MATCH IRQ PIN!!
    #define noInterrupts() P1IE &=~BIT4; // Method used by attachInterrupt()
    This has the disadvantage that it must be changed in code to match a pin change.
    The Stellaris proved illusive, several recommended/coded approaches just wouldn't hold up under stress (the "Gateway" example receiving from 4 or 5 high rate nodes-eventually the board freezes mid-reception); I found this method in the HardwareSerial library:
    #define interrupts()        ROM_IntMasterEnable();  // Stellaris fast enable/disable
    #define noInterrupts()      ROM_IntMasterDisable();
    The "Node" & "Gateway" examples work "out of the box" note that LPL uses Pin 9 for the LED; I just pulled the jumper plug off the RED_LED and added a jumper lead to Pin 9.  I have pounded my Launchpads with millions of packets but programming is not my field so let me know of any fixes or improvements.
    PS: These HopeRF modules are pretty small, I use these Breakout boards: https://github.com/uChip/RFM69W_BOB  (available from Oshpark 3/$6.75)
  7. Like
    Automate reacted to energia in Building low power into Energia   
    I took a while but I finally got around to spend a couple of days looking at low power modes using the awesome feedback in this thread. The key of course is to not break any existing API's. That led to the introduction of a sleep() API. It's not fully baked yet but I have some interesting numbers below.
    1: Empty loop: 5.3 mA
    2: loop with delay(10): 800 uA
    That's pretty low power already if your code spends most of it's time in delay(). The new sleep API improves the current consumption significantly. Right now it uses the 32k crystal only but the idea is to fall back on the VLO if there is no XTAL. This will basically be done by looking at the oscillator fault bit. Sleep goes down to LPM3. You might ask, why not put LPM3 mode in delay(). This was the plan initially but it would potentially break to many Sketches if the user would not be aware of the change in behavior.
    3: loop with sleep(10): 30 uA
    This set WDT to wakeup every 2 milliseconds and hence the resolution is 2 milliseconds.
    4: loop with sleepSeconds(1): 1.3 uA measured with a FLUKE multimeter so I am positive that this is pretty accurate.
    This sets WDT to wakeup every 1 second. 
    You can also call delay with > 1000. It will call sleepSeconds() for the whole seconds and the sleep() for the remainder. The full seconds will draw 1.3 uA and the remainder 30 uA.
    To give some color to what this means in terms of battery live. I have an Anaren 900MHz wireless BoosterPack transmitting sensor data every 10 sec. The time it takes to transmit and the current draw associated with it can be neglected vs the time spend in LMP3. To take worse case let's say we consume 2.5 uA on average. With a CR2032 coin cell battery with a capacity of 225mA the sensor node can operate for 63000 hours or 2625 days or roughly 7 years :-) The battery live was calculated using the "battery life calculator" up on the Digikey website. This calculator already takes in account external factors that can affect battery life by applying a 0.7 multiplication.
    There is still plenty of room for improvement but I think this is pretty interesting already.
    Once sleep is implemented for all boards I will look at attachInterrupt() as suggested in this thread.
    Thanks for all the help and feedback!
  8. Like
    Automate reacted to jpnorair in Opinions on LoRa (wireless - long range, low power, sub 1GHz)   
    It is a good product.  Semtech has a long history of producing excellent low-power RF transceivers.  Companies like Semtech do not usually just embark on wild projects like LoRa without someone contracting them to do so, and I don't have confirmation on this, but I am pretty sure that SigFox is who contracted Semtech to design LoRa and the associated transceivers.  So, there is an installed base that you can refer-to, which shows at least that the technology works quite well.
    The main downside of LoRa is that there is not a ton of information about it, so it is going to be difficult to achieve multi-vendor interoperability if you are using the LoRa modulation.   I'm not even sure what it is, but based on the limited descriptions I would guess it is some sort of M-FSK -- in fact, I think it is 64-FSK.
    The second downside of LoRa is that narrowbanding often works better than DSSS does in the lower bands like 169, 433, etc.  For 862, 866, and certainly US-915, DSSS is either a wise choice or a fundamental requirement, so for these upper bands LoRa makes a lot of sense.
  9. Like
    Automate reacted to jpnorair in Opinions on LoRa (wireless - long range, low power, sub 1GHz)   
    In review, it looks like LoRa uses a proprietary sort of CSS modulation (chirp spread spectrum), although it could be implemented as a sort of MFSK as well -- difficult to say.
    The basic premise is sound: with good coverage, you don't need mesh routing.  Mesh routing is mostly academic, very few production systems use it.
    At 1kbps, which is roughly the data rate he is using, a sensitive FSK device such as CC1200 or ST SPIRIT1 can actually achieve superior range to LoRa if a good error coding scheme is used.  With sophisticated error correction -- maybe not possible on MSP430 but certainly no problem for ARM CM3 -- I have observed 1 mile range in open outdoor conditions with 433 MHz, regular FSK set to a higher data rate, and using even less transmit power (for example, 1mW vs 100mW of AngelBlocks).  For AngelBlocks, the advantage of the LoRa implementation is that the US 915 MHz band is an interference nightmare.  Without sophisticated frequency hopping or a good spread-spectrum technique, the message just isn't going to get through.
  10. Like
    Automate reacted to spirilis in Multiple hardware interrupts   
    Yup that sounds right.  Likewise if a higher-numbered pin triggered while a lower-numbered pin was executing its interrupt function, it would be handled within that single loop of the ISR (else if it were a lower-numbered pin than the one currently being handled, it would retrigger the ISR after the ISR exited & then get handled).

    Sent from my Galaxy Note II with Tapatalk 4
  11. Like
    Automate reacted to pabigot in Multiple hardware interrupts   
    For Energia it appears so as @@spirilis has described. For the MSP430 more generally the priority is determined by how the interrupt handler is implemented.
    If two or more pins on the same port trigger at the same time, the interrupt routine would be executed. If any of the corresponding bits in PxIFG remain set when the routine is exited, then the ISR will be immediately re-entered (if interrupts remain enabled). This repeats until PxIFG is cleared. If you determine the pin for the interrupt by reading PxIV (in newer chips) then the lower numbered pins will be processed first (automatically clearing the corresponding PxIFG bit), the same order as Energia uses.
    If you write your own handler you can test the bits in whatever order you need. There are odd cases where this is useful: e.g. if one pin is a clear-channel assessment or carrier detect indicator, another pin is a start-of-frame-delimiter indicator, and you're processing a radio transmission or reception, you can be fairly certain the CCA or CD came before the SFD and might want to process the events in that order even if the pin assignment and PxIV behavior would suggest they came in the reverse order.
    More interestingly, if two or more pins on *different* ports trigger at the same time, the handler for the port with the highest priority in the vector table is executed first, and re-executed until its PxIFG is clear. Then the handler for the lower-priority port is executed.  (If you were to be so unwise as to enable interrupts while in an interrupt handler, a subsequent higher-priority interrupt would interrupt your ISR.  Most times, you won't want to do that.)
    Be aware that the priority of ports varies across MCUs (e.g. on the MSP430G2553 PORT2 is higher priority than PORT1, while on the MSP430F5529 PORT1 is higher priority than PORT2). You need to check the MCU datasheet if cross-port ordering is important to your application.
  12. Like
    Automate reacted to pine in TI Exosite Portal data visualization with F5529LP, TMP006 and TP-Link WR703N   
    From the recent email received from TI announcing their new Connected LaunchPad line, I noticed the free partner service offered to Exosite.
    It is really cool to have the services of this kind, easy to configure for such a sophisticated communication platform.
    My only problem is I don't have one of those new shinny Connected LP.. actually TI won't sell those to where I live. But that doesn't stop my drive to test out this new exciting cloud!
    Firstly, an F5529LP with TI TMP006 temperature booster pack was selected as the test rig. This was a small project from last month that also with a 1602 LCD.

    The coding is done in Energia. Although the LCD shows a lot of info, including sensor temperature and die temperature, together with their min / max, the data output from serial is currently limited to the sensor temperature only.
    The F5529+TMP006+LCD package is connected to a TP-Link WR703N wireless router with OpenWRT. Every 4 seconds the LP send the sensor temperature through serial to the OpenWRT. This router is installed with ser2net package and a lua program is running to capture that value, and then send to Exosite. (Yes that is a Haagen Dazs behind the LP.. to make sure temperature below 0C worked as well as no shortage of dessert tonight..)

    The whole Exosite experience is pretty nice. It only takes less than half hour from opening a new account to have the site ready to receive data, that already include reading the documentation on how to send data with their simple HTTP protocol. 
    For the 703N router, apart from the package ser2net, a small lua program that required the lua socket package (easily installed in the standard way - opkg install luasocket), included below is used to capture the output from ser2net, do some legwork, and finally send data to Exosite:
    local host, port = "", 2002 local socket = require("socket") local tcp = assert(socket.tcp()) tcp:connect(host, port); while true do local s, status, partial = tcp:receive() print(s or partial) if status == "closed" then break end local socket = require("socket") local host = "m2.exosite.com" local sock = assert(socket.connect(host, 80)) sock:send("POST /api:v1/stack/alias HTTP/1.1\r\n") sock:send("Host: m2.exosite.com\r\n") sock:send("Content-Type: application/x-www-form-urlencoded; charset=utf-8\r\n") sock:send("X-Exosite-CIK: secret-exosite-token-here\r\n") sock:send("Content-Length: 8\r\n\r\n") sock:send("s=") sock:send(s) sock:send("\r\n\r\n\r\n") repeat local chunk, status, partial = sock:receive(64) print(chunk or partial) until status ~= "closed" sock:close() end tcp:close() It is quite an enjoyable experience to have little things connected to the Internet 

    In summary:
    TMP006 -(I2C)-> LP5529 -(serial)-> 703N/ser2net -(socket)-> 703N/lua -(http)-> Exosite
  13. Like
    Automate reacted to dellwoodbu in Tiva version 2.1   
    It also includes support for the new EK-TM4C1294XL Connected LaunchPad.  Out of the box cloud connected.
    Support with working examples for CC3000 on EK-TM4C123GXL and the new Connected LaunchPad.  
    NFC support on the boost-dlptrf7970abp with both launchpads
    Built in support with examples for the QVGA 3.5" Kentec BoosterPack on the new Connected LaunchPad.
    Built in support and example for the boostxl-battpack Battery Booster.
    Probably missing some other good stuff that i am currently forgetting as well.
  14. Like
    Automate reacted to AnalysIR in Porting IR code from Arduino IDE to Energia MSP430F5529 - Clock accuracy   
    Delighted to report great progress  on this front....at last!
    We have now managed to get AnalysIR decoding IR signals using Energia & the Tiva C LaunchPad (EK-TM4C123GXL  aka TMC123).
    The launchPad is doing a great job recording both the IR bitstream and the modulation frequency simultaneously.
    We have also managed to to get the MSP430F5529 working with Energia & AnalysIR. It is decoding IR signals, but only at 16MHz.
    Unfortunately, the measurement of Infrared modulation frequency is not accurate enough. As per the previous posts above, the accuracy running this @ 25MHz is not good enough.
    Once we get better calibration of the clock via Energia, this should improve.
    As it stands the Tiva C LaunchPad is by far the best value system for our needs @ US$12.99 including shipping - its hard to beat!
    It is also interesting to note that the level of code changes required to 'port' our code across from the Arduino platform to the Energia was minimal. A few compiler defines for pin names and some trivial stuff.
  15. Like
    Automate reacted to Xuan in Fixing damaged dell power adapter using MSP430G2211   
    This is all about learning OneWire communications. I'm able to make a small "adapter" playing the "man in the middle" hack between dell laptop and its power brick to provide "fake" wattage information. For me I'm using it to "fix" a power adapter which has a damaged identification chip. Of course it can also be used to use non-dell power adapter (on your own risk of damaging the laptop, or even burn your house, who knows...)
    All the code and pcb design can be found at https://github.com/HclX/DELL_POWER_SPOOFER.git and my http://hclxing.wordpress.com/2014/02/26/hacking-a-dell-power-adapter-final-not-really/
    Some pictures:

    pcb layout:

    final populated pcb, toner transferred and hand soldered, some of the parts are salvaged from old dvd rom pcb:

    dc jack from a broken dell laptop, it took me a fair amount of work to cut the pcb into that shape using my dremel so I can solder the dc jack

    connecting with a working power adapter

    to prove it's working, i'm faking my working 90W adapter as 65W 

    There is still work to do like enabling push button to import data from the connected working adapter, or switching between multiple imported data, making use the led indicator, ...
  16. Like
    Automate reacted to spirilis in WizNet W5200 C library   
    This is a code library implementing a sockets-oriented interface to the WizNet W5200.  It's been a long time coming, and the plan is to implement DHCP support soon; almost there, had to rewrite the lib from scratch to allow piecemeal I/O with various socket types first.
    For now, the code includes working examples for the MSP430G2553 and MSP430F5529 LaunchPads.  It needs a lot of documentation work though so don't fret if you can't get them working :-)
    More to come...
    Link: https://github.com/spirilis/w5200sock
    After DHCP support is working on the older W5200, I am going to adapt this into a W5500 library called w5500sock.  As it stands right now though this library should be sufficient for building TCP and UDP clients and servers, managing several simultaneously along with doing repeated DNS lookups (A records only, i.e. dnslib_gethostbyname() is the only implemented client function so far).
    Much of the API is designed to allow the MCU to write or read data piecemeal without having to allocate any large buffers of its own to manage the data.  See dnslib.c for good examples... there are flags for the various recv, send and flush calls which do "virtual" reads of the data without signalling the readiness to receive new packets, and the wiznet_send() and wiznet_sendto() calls take an argument as to whether the packet should be committed yet.  This enables low SRAM usage for e.g. the G2553.  I think the API is too fat for the G2452 though, so G2553 at a minimum.
  17. Like
    Automate reacted to pabigot in Getting started: Best BSP?   
    Thanks for the compliments.
    There is an llvm back-end for msp430, at one of those annoying web sites that require a secure connection and provide an invalid certificate.  I don't know if it's active, and haven't heard from the maintainer in a couple years, but it did use the binutils variant from the mspgcc toolchain.  I don't know how much it depended on that; AFAICT Red Hat wasn't asked to fix all the bugs in the upstream binutils that mspgcc addressed over the years, and the linker script infrastructure is completely different.
    I'm moving more towards ARM for my experimentation as it's a far more mature platform in terms of both CPU architecture and toolchain support.  Any BSP430-like infrastructure I come up with there will be in C++11.  I like the MSP430's low power capabilities, but the former EnergyMicro is competitive, and the higher clock rates and shorter startup times on the ARM mitigate against its sometimes higher active current draw.
  18. Like
    Automate got a reaction from bluehash in Screw terminal TI Breakout BoosterPack   
    For those that don't like soldering or fooling with pin jumper wires.
  19. Like
    Automate reacted to glitovsky in New Tool for Code Composer and MSP430   
    Hi Everyone,
    We'd like to announce a new tool we've developed for those using MSP430 with Code Composer Studio called
    CCS Map analyzer:  http://www.argenox.com/products/ccsmapanalyzer/
    This tool is completely free and currently supports Windows XP/7 and potentially Windows 8 (yet to be tested).
    We've released it since we were constantly being asked by customers about Flash and RAM utilization during development and for years
    we've seen the lack of tools that make it easy to provide this information.
    You can quickly see the routines that are taking the most space in Flash, instead of manually parsing the MAP file.
    We know of a few issues that wer'e currently working to fix, but we would love to have feedback from the community, as well
    as some more documentation.
    Feel free to download and share with us any issues, comments or new features by dropping us an e-mail at support[at]argenox(dot)com
    Argenox Team
  20. Like
    Automate reacted to Atas in Anaren CC110L RF BoosterPack with msp430 launchpad as Chronos eZ430 Access Point   
    I loved the eZ430-Chronos.
    On the Internet many projects made ??on the basis of this development tool. But one thing I did not like is that you need a computer to manage their programs. And without a computer Chronos watch can not control anything. So I bought Anaren CC110L RF BoosterPack (868 Mhz).
    But this kit does not work with Chronos. I looked a lot of information and code on this forum and on the internet. But always something was wrong, I did not want to rewrite the SimpliciTi protocol. And finally... 
      I did emulation of RF USB dongle. The project uses the unmodified Chronos Control Centre and firmware of sportswatch. But blurobin and wireless firmware update does not work. To me, this part is not important. I used code composer studio. And now I have a working SimpliciTI on msp430g2553 with CC110L. And Run many examples which are in SimpliciTi installation directory.

    Here is a video how it works.

    Thanks to @gwdeveloper, with post SimpiciTI Tutorial for CC2500
    Project attached CCS SimpliciTI MSP430 CC110L Anaren busterpack.rar
  21. Like
    Automate got a reaction from Remixed123 in A new Tiva C LaunchPad about to be Announced!!!!!   
    More info released http://www.ti.com/ww/en/launchpad/launchpads-tivac-ek-tm4c1294xl.html#tabs
    $20 with Ethernet but not in stock yet
  22. Like
    Automate got a reaction from PTB in A new Tiva C LaunchPad about to be Announced!!!!!   
    More info released http://www.ti.com/ww/en/launchpad/launchpads-tivac-ek-tm4c1294xl.html#tabs
    $20 with Ethernet but not in stock yet
  23. Like
    Automate reacted to pine in To stop drolling in front of those Arduino Yun web pages...   
    .. finally made the switch and flashed OpenWrt to a TP-Link WR703N router, added a 16G memory flash stick, and connected to my first F5529 LaunchPad. Here is a picture of the setup.  
    The version of OpenWrt is 12.09. To connect with the MSP Launchpad, need to install the acm driver by
    opkg install kmod-usb-acm And also installed "screen" for serial client by
    opkg install screen Apart from the missing bridge library that come with the Yun, i'm quite satisfied with this setup, especailly the tiny form factor of the whole package.
    The LaunchPad seems to enjoy running with her new Internet companion!

  24. Like
    Automate reacted to Remixed123 in A new Tiva C LaunchPad about to be Announced!!!!!   
    Here is the teaser - promo video
    It looks like it's based on the TM4C129
    The query string in the link announces this for all to see....mcu-tivc-ek-tm4c129xl-em-lp-en
  25. Like
    Automate reacted to computerwiz222 in Noritake 24x6 character VFD Free Samples   
    I had some fun with this display. I crafted up a driver in C# and ran it under Mono on my RaspberryPi.
    I managed to stream some data at the custom RAM characters to get a spinning globe animation and a couple of "loader" animations. I wrote up a crude little gif converter.
    I also had a ton of fun attempting to dump the firmware on the microcontroller which I can only assume I was successful at (based on the nice strings in the image :]).
  • Create New...