Jump to content
43oh

zeke

Members
  • Content Count

    1,782
  • Joined

  • Last visited

  • Days Won

    102

Reputation Activity

  1. Like
    zeke got a reaction from bluehash in Vibration causing chip reset?   
    It's completely possible that the design is just not robust enough to get a sandbag in the face for 12 hours.
     
    I do know know why the system needs to survive that kind of abuse. Can you tell us a story about that so we can understand?   In the meantime, how thick is that PCB?  I bet it's 0.062" thick and made out of FR4 material.     If I were designing that PCB then I would make it 0.125" thick with five mounting holes strategically placed at each corner and one in the middle. That way, the circuit would not flex due to resonant vibrations after each sandbag to the face. That's the way we did it when designing seismic recording electronics. Those products had to survive a 250 foot drop onto granite from a helicopter net.   Epic destruction.
  2. Like
    zeke got a reaction from bluehash in Thermostat project questions   
    @@Jake,
     
    Check out this thread to see how it's done on an F5529:
    http://forum.43oh.com/topic/5908-console-with-one-wire-temperature-on-msp430f5529-lp/
     
    Check out this thread to see how it's done on a G2452:
    http://forum.43oh.com/topic/329-reading-the-ds18b20-temperature-sensor/
     
    Let me know how you make out.
  3. Like
    zeke got a reaction from spirilis in Updates and going forward   
    I think you should register 43ohmy.com
    ;-)
  4. Like
    zeke got a reaction from pine in Updates and going forward   
    I think you should register 43ohmy.com
    ;-)
  5. Like
    zeke reacted to bluehash in Forums upgraded to 3.4.7 + Next Steps   
    Update:
    This past week I have been trying to do a soft merge between Stellaris and BFU. It is not going well with alot of duplicate usernames and errors. The guys at IPB are helping me out with it, so not totally lost.
    Once that is sorted out, I'll be first merging BFU to 43oh, then Stellarisiti.
  6. Like
    zeke reacted to RobG in MSP430 Nixie Clock   
    Dave's clock
     

  7. Like
    zeke got a reaction from tripwire in Updates and going forward   
    I think you should register 43ohmy.com
    ;-)
  8. Like
    zeke got a reaction from bluehash in Updates and going forward   
    I think you should register 43ohmy.com
    ;-)
  9. Like
    zeke reacted to jpnorair in A new MSP430 coming [MSP432 ARM]   
    People in the industry have been dropping me hints for a while that an ARM M0+ with MSP peripherals and clock system is on the way.  A few years ago, I lobbied pretty hard for this, so I guess it's nice that things are coming around.  
     
    Assuming that the resulting device gets Energia support, that would be great.  The Atmel ARM CM parts aren't worth using in low power designs (frankly I think they are weak in most respects).  The STM32L parts are great, but I would need to port Arduino to them and do all the requisite community marketing: no thanks.  I have a pretty nice firmware and IoT platform waiting in the wings that does all the low-power optimizations for you transparently (as long as you're running sketches).  So I have my fingers crossed.
  10. Like
    zeke reacted to RobG in Voltage regulator 12vdc to 3.3vdc   
    You can get LM2596 (or high voltage version LM2596HV) based DC-DC converters from eBay for as little as $1. 
  11. Like
    zeke reacted to abecedarian in Updates and going forward   
    Don't know if this would help, but sub-domain / virtual domains are possible?
     
    I.e.:
    stellarisiti.43oh.com | forum.43oh.com/stellarisiti/
    beaglefu.43oh.com | forum.43oh.com/beaglefu/
    ... and so on.
  12. Like
    zeke got a reaction from Rei Vilo in Updates and going forward   
    To make it easier to administrate, I recommend using just 43oh.com for everything. TI is pointing people to that one domain so it makes sense.
     
    Keep the 43oh.com name as the dominant domain. 
     
    You can redirected all the other domain names to their own sub-forum inside of 43oh.com with an apache redirect command. 
     
    People will understand what it means once they notice all the sub-forums dedicated to each processor family.
     
    United we stand. Divided we fall.
  13. Like
    zeke got a reaction from bluehash in Updates and going forward   
    To make it easier to administrate, I recommend using just 43oh.com for everything. TI is pointing people to that one domain so it makes sense.
     
    Keep the 43oh.com name as the dominant domain. 
     
    You can redirected all the other domain names to their own sub-forum inside of 43oh.com with an apache redirect command. 
     
    People will understand what it means once they notice all the sub-forums dedicated to each processor family.
     
    United we stand. Divided we fall.
  14. Like
    zeke got a reaction from nunarciso in log(variable) not working   
    Try assigning the result of the log() to another variable.
     
    int a = 10;
    int b;
     
    b = log(a);
     
    Does that work for you?
  15. Like
    zeke got a reaction from spirilis in Updates and going forward   
    To make it easier to administrate, I recommend using just 43oh.com for everything. TI is pointing people to that one domain so it makes sense.
     
    Keep the 43oh.com name as the dominant domain. 
     
    You can redirected all the other domain names to their own sub-forum inside of 43oh.com with an apache redirect command. 
     
    People will understand what it means once they notice all the sub-forums dedicated to each processor family.
     
    United we stand. Divided we fall.
  16. Like
    zeke got a reaction from pine in One Wire Controller booster   
    This is the Development Support Board for the Hydra design.
     
    I call it The Orb because it's the Hydra's power source. Yeah, I'm being silly with the name. It amuses me. 
     
    It provides power and serial communications to the Hydra board. Since it's XL compatible, it ought to drive most XL LaunchPads as well. 
     
    It features:
    An E585460 LiPo battery - 2000mAh A TPS63020 Buck/Boost regulator A BQ24072 USB driven powerpath LiPo charger A SiLabs CP2102 USB UART (because it just works) LaunchPad-XL pinout It will power a LaunchPad but without +5V (exclusive XL feature) Today, I placed all the components. Tomorrow, I'll start routing the board.
     



     
    The design is done in Altium.
     
    I'm now wondering if I should be putting this stuff in a github repo. What do you all think of that?
     
  17. Like
    zeke got a reaction from PTB in One Wire Controller booster   
    After a few busy months, I've managed to get back to this project.
     
    I've tidied up the layout and added in useful silkscreen information.
     
    I have also renamed the board to Hydra: One Wire DataLogger because it has eight One Wire Master bus ports.
     
    It also has a split personality: It can be either a BoosterPack or a LaunchPadXL.
     
    I say this because I've added jumpers to flip the MSP430 UART between DTE or DCE mode. In one setting, the MSP430 is a DTE (LaunchPad mode). In the other setting, the MSP430 is a DCE (BoosterPack mode). So, I can mate this board to either my Dev support board or to a CC3200 board and it will be able to communicate in both scenarios.
     
    This is what it looks like tonight.
     


     
    Now I just have to get this board fabbed and get cracking on the firmware. That should be an adventure.
  18. Like
    zeke got a reaction from bluehash in One Wire Controller booster   
    After a few busy months, I've managed to get back to this project.
     
    I've tidied up the layout and added in useful silkscreen information.
     
    I have also renamed the board to Hydra: One Wire DataLogger because it has eight One Wire Master bus ports.
     
    It also has a split personality: It can be either a BoosterPack or a LaunchPadXL.
     
    I say this because I've added jumpers to flip the MSP430 UART between DTE or DCE mode. In one setting, the MSP430 is a DTE (LaunchPad mode). In the other setting, the MSP430 is a DCE (BoosterPack mode). So, I can mate this board to either my Dev support board or to a CC3200 board and it will be able to communicate in both scenarios.
     
    This is what it looks like tonight.
     


     
    Now I just have to get this board fabbed and get cracking on the firmware. That should be an adventure.
  19. Like
    zeke got a reaction from Lgbeno in analog.io   
    @Lgbeno:  Cool domain name  :-)
     
    I wished I thought of it.
  20. Like
    zeke got a reaction from timotet in General use triac boards   
    @@swampdonkeykami, I sense your frustration. Please be patient.
     
    I suggest venting your emotions elsewhere then coming back with constructive questions using kinder words.
  21. Like
    zeke got a reaction from abecedarian in General use triac boards   
    @@swampdonkeykami, I sense your frustration. Please be patient.
     
    I suggest venting your emotions elsewhere then coming back with constructive questions using kinder words.
  22. Like
    zeke reacted to JonnyBoats in Steve Gibson promotes the TI Launchpad   
    Steve Gibson of Security Now did an interview about programming here: http://twit.tv/show/coding-101/51
     
    If you go to 35 minutes into the interview he holds up and talks about the MSP430 launchpad.
  23. Like
    zeke got a reaction from veryalive in Saving flash space, by making use of infomem   
    While reading this thread, I noticed that the answers did not comment on a solution for CCS. 
     
    So here are my observations and code samples to make that work in CCS.
     
    First, I trimmed down the font sample code from @@greeeg just to see if it will work.
    #pragma DATA_SECTION(font_data, ".infoB") const unsigned int font_data[] = { 0x0000,0xC101,0x0110,0x3B89,0x9BD9,0x5BDA,0x0F6D,0x4000, 0x4400,0x0022,0x55AA,0x1188,0x0002,0x1008,0x0001,0x4002, 0xEA57,0x6800,0xB24D,0xDA41,0x3818,0x8659,0x9A5D,0xA840, 0xBA5D,0xBA59,0x0041,0x0042,0x4203,0x1209,0x0621,0xB0C0, }; Good! This is just the right size to fill up 64 bytes - the size of INFOB. Any bigger and the compiler fails out with an error message about memory size is over filled or something.
     
    Next, figure out what special names you can use in the DATA_SECTION declaration.
     
    Open up the linker file for your project. In my case, it's called lnk_msp430g2553.cmd. 
     
    You will see this inside of it:
    .infoA : {} > INFOA /* MSP430 INFO FLASH MEMORY SEGMENTS */ .infoB : {} > INFOB .infoC : {} > INFOC .infoD : {} > INFOD so, use the lowercase name in your declaration.
     
     
    And here is my test program that I used to test drive the flash on an MSP43G2553:
    #include <msp430.h> /* "Compressed" font data, in form 0b ABCD EFGH IJKL MNOP {A-P} represent segment bits in each character __J_ _A__ |\ | /| | K H B | L \ | / C | \|/ | >-M--*--D-< | /|\ | N / | \ E | O I F | |/ | \| ~~P~ ~G~~ */ #pragma DATA_SECTION(font_data, ".infoB") const unsigned int font_data[] = { 0x0000,0xC101,0x0110,0x3B89,0x9BD9,0x5BDA,0x0F6D,0x4000, 0x4400,0x0022,0x55AA,0x1188,0x0002,0x1008,0x0001,0x4002, 0xEA57,0x6800,0xB24D,0xDA41,0x3818,0x8659,0x9A5D,0xA840, 0xBA5D,0xBA59,0x0041,0x0042,0x4203,0x1209,0x0621,0xB0C0, }; //const unsigned int font_data[] //__attribute__((section(".infob"))) = //{ //0x0000,0xC101,0x0110,0x3B89,0x9BD9,0x5BDA,0x0F6D,0x4000, //0x4400,0x0022,0x55AA,0x1188,0x0002,0x1008,0x0001,0x4002, //0xEA57,0x6800,0xB24D,0xDA41,0x3818,0x8659,0x9A5D,0xA840, //0xBA5D,0xBA59,0x0041,0x0042,0x4203,0x1209,0x0621,0xB0C0, //0xAACD,0xB85C,0xBBC1,0x8255,0xABC1,0x825D,0x805C,0x9A55, //0x381C,0x83C1,0x81C5,0x441C,0x0215,0x6834,0x2C34,0xAA55, //0xB05C,0xAE55,0xB45C,0x9A59,0x81C0,0x2A15,0x4016,0x2C16, //0x4422,0x40A0,0xC243,0x0055,0x0420,0xAA00,0x0402,0x0201, //0x0020,0x028D,0x009D,0x000D,0x018D,0x000F,0x9188,0x1E01, //0x009C,0x0080,0x0081,0x1580,0x03C0,0x188C,0x008C,0x008D, //0x015C,0x03D8,0x000C,0x1081,0x1388,0x0085,0x0006,0x0A85, //0x4182,0x0E01,0x000B,0x8388,0x0180,0x11C1,0x3150,0x0000, //}; char value; // 8-bit value to write to segment A // Function prototypes void write_SegC (char value); void copy_C2D (void); int main(void) { WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer if (CALBC1_1MHZ==0xFF) // If calibration constant erased { while(1); // do not load, trap CPU!! } DCOCTL = 0; // Select lowest DCOx and MODx settings BCSCTL1 = CALBC1_1MHZ; // Set DCO to 1MHz DCOCTL = CALDCO_1MHZ; FCTL2 = FWKEY + FSSEL0 + FN1; // MCLK/3 for Flash Timing Generator value = 0; // initialize value while(1) // Repeat forever { write_SegC(value++); // Write segment C, increment value copy_C2D(); // Copy segment C to D __no_operation(); // SET BREAKPOINT HERE } } void write_SegC (char value) { char *Flash_ptr; // Flash pointer unsigned int i; Flash_ptr = (char *) 0x1040; // Initialize Flash pointer FCTL1 = FWKEY + ERASE; // Set Erase bit FCTL3 = FWKEY; // Clear Lock bit *Flash_ptr = 0; // Dummy write to erase Flash segment FCTL1 = FWKEY + WRT; // Set WRT bit for write operation for (i=0; i<64; i++) { *Flash_ptr++ = value; // Write value to flash } FCTL1 = FWKEY; // Clear WRT bit FCTL3 = FWKEY + LOCK; // Set LOCK bit } void copy_C2D (void) { char *Flash_ptrC; // Segment C pointer char *Flash_ptrD; // Segment D pointer unsigned int i; Flash_ptrC = (char *) 0x1040; // Initialize Flash segment C pointer Flash_ptrD = (char *) 0x1000; // Initialize Flash segment D pointer FCTL1 = FWKEY + ERASE; // Set Erase bit FCTL3 = FWKEY; // Clear Lock bit *Flash_ptrD = 0; // Dummy write to erase Flash segment D FCTL1 = FWKEY + WRT; // Set WRT bit for write operation for (i=0; i<64; i++) { *Flash_ptrD++ = *Flash_ptrC++; // copy value segment C to segment D } FCTL1 = FWKEY; // Clear WRT bit FCTL3 = FWKEY + LOCK; // Set LOCK bit } Here is a screen shot of CCS as I inspected the information memory section.  
     
    The way I have the screen stretched out causes each memory section to be all on one line ie:
    INFOD (0x1000), INFOC (0x1040), INFOB (0x1080) and INFOA (0x10C0).  

     
     
    Footnote: For reference, here's TI's take on this topic: 
  24. Like
    zeke got a reaction from cde in Saving flash space, by making use of infomem   
    While reading this thread, I noticed that the answers did not comment on a solution for CCS. 
     
    So here are my observations and code samples to make that work in CCS.
     
    First, I trimmed down the font sample code from @@greeeg just to see if it will work.
    #pragma DATA_SECTION(font_data, ".infoB") const unsigned int font_data[] = { 0x0000,0xC101,0x0110,0x3B89,0x9BD9,0x5BDA,0x0F6D,0x4000, 0x4400,0x0022,0x55AA,0x1188,0x0002,0x1008,0x0001,0x4002, 0xEA57,0x6800,0xB24D,0xDA41,0x3818,0x8659,0x9A5D,0xA840, 0xBA5D,0xBA59,0x0041,0x0042,0x4203,0x1209,0x0621,0xB0C0, }; Good! This is just the right size to fill up 64 bytes - the size of INFOB. Any bigger and the compiler fails out with an error message about memory size is over filled or something.
     
    Next, figure out what special names you can use in the DATA_SECTION declaration.
     
    Open up the linker file for your project. In my case, it's called lnk_msp430g2553.cmd. 
     
    You will see this inside of it:
    .infoA : {} > INFOA /* MSP430 INFO FLASH MEMORY SEGMENTS */ .infoB : {} > INFOB .infoC : {} > INFOC .infoD : {} > INFOD so, use the lowercase name in your declaration.
     
     
    And here is my test program that I used to test drive the flash on an MSP43G2553:
    #include <msp430.h> /* "Compressed" font data, in form 0b ABCD EFGH IJKL MNOP {A-P} represent segment bits in each character __J_ _A__ |\ | /| | K H B | L \ | / C | \|/ | >-M--*--D-< | /|\ | N / | \ E | O I F | |/ | \| ~~P~ ~G~~ */ #pragma DATA_SECTION(font_data, ".infoB") const unsigned int font_data[] = { 0x0000,0xC101,0x0110,0x3B89,0x9BD9,0x5BDA,0x0F6D,0x4000, 0x4400,0x0022,0x55AA,0x1188,0x0002,0x1008,0x0001,0x4002, 0xEA57,0x6800,0xB24D,0xDA41,0x3818,0x8659,0x9A5D,0xA840, 0xBA5D,0xBA59,0x0041,0x0042,0x4203,0x1209,0x0621,0xB0C0, }; //const unsigned int font_data[] //__attribute__((section(".infob"))) = //{ //0x0000,0xC101,0x0110,0x3B89,0x9BD9,0x5BDA,0x0F6D,0x4000, //0x4400,0x0022,0x55AA,0x1188,0x0002,0x1008,0x0001,0x4002, //0xEA57,0x6800,0xB24D,0xDA41,0x3818,0x8659,0x9A5D,0xA840, //0xBA5D,0xBA59,0x0041,0x0042,0x4203,0x1209,0x0621,0xB0C0, //0xAACD,0xB85C,0xBBC1,0x8255,0xABC1,0x825D,0x805C,0x9A55, //0x381C,0x83C1,0x81C5,0x441C,0x0215,0x6834,0x2C34,0xAA55, //0xB05C,0xAE55,0xB45C,0x9A59,0x81C0,0x2A15,0x4016,0x2C16, //0x4422,0x40A0,0xC243,0x0055,0x0420,0xAA00,0x0402,0x0201, //0x0020,0x028D,0x009D,0x000D,0x018D,0x000F,0x9188,0x1E01, //0x009C,0x0080,0x0081,0x1580,0x03C0,0x188C,0x008C,0x008D, //0x015C,0x03D8,0x000C,0x1081,0x1388,0x0085,0x0006,0x0A85, //0x4182,0x0E01,0x000B,0x8388,0x0180,0x11C1,0x3150,0x0000, //}; char value; // 8-bit value to write to segment A // Function prototypes void write_SegC (char value); void copy_C2D (void); int main(void) { WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer if (CALBC1_1MHZ==0xFF) // If calibration constant erased { while(1); // do not load, trap CPU!! } DCOCTL = 0; // Select lowest DCOx and MODx settings BCSCTL1 = CALBC1_1MHZ; // Set DCO to 1MHz DCOCTL = CALDCO_1MHZ; FCTL2 = FWKEY + FSSEL0 + FN1; // MCLK/3 for Flash Timing Generator value = 0; // initialize value while(1) // Repeat forever { write_SegC(value++); // Write segment C, increment value copy_C2D(); // Copy segment C to D __no_operation(); // SET BREAKPOINT HERE } } void write_SegC (char value) { char *Flash_ptr; // Flash pointer unsigned int i; Flash_ptr = (char *) 0x1040; // Initialize Flash pointer FCTL1 = FWKEY + ERASE; // Set Erase bit FCTL3 = FWKEY; // Clear Lock bit *Flash_ptr = 0; // Dummy write to erase Flash segment FCTL1 = FWKEY + WRT; // Set WRT bit for write operation for (i=0; i<64; i++) { *Flash_ptr++ = value; // Write value to flash } FCTL1 = FWKEY; // Clear WRT bit FCTL3 = FWKEY + LOCK; // Set LOCK bit } void copy_C2D (void) { char *Flash_ptrC; // Segment C pointer char *Flash_ptrD; // Segment D pointer unsigned int i; Flash_ptrC = (char *) 0x1040; // Initialize Flash segment C pointer Flash_ptrD = (char *) 0x1000; // Initialize Flash segment D pointer FCTL1 = FWKEY + ERASE; // Set Erase bit FCTL3 = FWKEY; // Clear Lock bit *Flash_ptrD = 0; // Dummy write to erase Flash segment D FCTL1 = FWKEY + WRT; // Set WRT bit for write operation for (i=0; i<64; i++) { *Flash_ptrD++ = *Flash_ptrC++; // copy value segment C to segment D } FCTL1 = FWKEY; // Clear WRT bit FCTL3 = FWKEY + LOCK; // Set LOCK bit } Here is a screen shot of CCS as I inspected the information memory section.  
     
    The way I have the screen stretched out causes each memory section to be all on one line ie:
    INFOD (0x1000), INFOC (0x1040), INFOB (0x1080) and INFOA (0x10C0).  

     
     
    Footnote: For reference, here's TI's take on this topic: 
  25. Like
    zeke reacted to roadrunner84 in Use of Timer A interrupts   
    Yes, that'd do the trick as well.
     
    When using the __even_in_range intrinsic, make sure no odd (not-even) value or value above the set range could even occur! As you may have read, the __even_in_range intrinsic changes the if() else if() chain into an "add parameter to the program counter" and a jump look up table. Any value out of the set constraints will lead to undefined behaviour, and maybe even hang your process.
×
×
  • Create New...