Jump to content
43oh

chicken

Members
  • Content Count

    907
  • Joined

  • Last visited

  • Days Won

    85

Reputation Activity

  1. Like
    chicken reacted to steve_m in Launchpad e-paper clock with Motorola F3 display   
    Hi,
     
    I wanted to play with the low-power abilities of the MSP430, so I put together a simple clock using the e-paper display from a Motorola F3.
    See the full documentation in my wiki, as well as the
    I recorded. The code can be found on github. 


     
    Steve
  2. Like
    chicken reacted to dellwoodbu in Stellaris Launchpad as a Programmer   
    You can use the LaunchPad to program standalone chips that you purchase and install on your own PCB.  There is a how-to at http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
     
    I'd suggest putting a standard ARM connector on any board you create and interface that to the pins on the LaunchPad http://www.keil.com/support/man/docs/ulinkpro/ulinkpro_hw_if_jtag10.htm  This is what the programmers from Keil, IAR and others use this gives you flexibility if you want a different "standard" programmer later.
     
    The chip you buy from TI will identical to the chip on the LaunchPad in terms of how you program and how you get code on to it.  See LMFlashProgrammer, This plus the bootloaders in ROM means that production boards (debug not needed) don't need to waste space and money on JTAG connectors.  You can use serial or USB or other interfaces.
     
    The TivaWare examples generally use the ROM_ functions.  These are in ROM so no flash space gets used by them.  They also execute at full device speed.  Flash executes at 40Mhz max then you get a read buffer and some minimal performance loss vs the ROM.
     
    Yes again, the TM4C1233H6PM is "identical" to the LX4F.  The TM4C is a later revision of the same silicon.  It has a few errata fixes but the base function is the same.
     
    Don't be scared by the ROM.  If you don't want to use it at first then you can pretend it is not there and then you just concern yourself with the code you write that goes in flash.
     
    The latest builds of openocd now have integrated the support for the ICDI interface on the LaunchPad so lm4flash should not be needed anymore and you can do much more in depth debugging with openocd and gdb.  Tivaware ships with makefiles for GCC as well as the project files for CCS.  I believe Mentor Sourcery CodeBench is also supported in Linux and project files are in TivaWare.
     
     
     
    dellwood
  3. Like
    chicken got a reaction from bluehash in More MSP430 target boards on sale   
    Just came across this post on TI's MSP430 blog:
    http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/06/07/who-wants-more-tool-deals.aspx
     
    MSP-TS430PEU128 for $20
    128-pin ZIF socket target board for MSP430F677xIPEU and MSP430F67791xIPEU Flash parts in a 128-pin QFP package (TI package code: PEU).
    http://www.ti.com/tool/msp-ts430peu128
     
    MSP-TS430DL48 for $20
    48-pin ZIF socket target board for some MSP430F Flash parts in a 48-pin SSOP package (TI package code: DL).
    http://www.ti.com/tool/msp-ts430dl48
     
    MSP-TS430PW28A for $55
    28-pin ZIF socket target board for some MSP430F Flash parts in a 20- or 28-pin TSSOP package (TI package code: PW)
    http://www.ti.com/tool/msp-ts430pw28a
     
    MSP-TS430PZ100 for $55
    100-pin ZIF socket target board for some MSP430F Flash parts in a 100-pin TQFP package (TI package code: PZ).
    http://www.ti.com/tool/msp-ts430pz100
     
    The product pages show the regular prices ($89-$119), but clicking "Buy from TI" will give you the discounted prices.
     
    Wonder if SSOP sizes are standardized.. if so I'm tempted to get the DL48 as a general breakout tool.
  4. Like
    chicken got a reaction from reaper7 in StellarPad: sbi() + sbi() 4.6x Faster than digitalWrite()   
    Well, you moved most of the overhead of digitalWrite/Read outside of the loop with sbi/cbi. Include the calculation of _port and _mask into the second loop and we're probably getting closer.
     
    When you look at the source of StellarisWare / driverlib, you will see that GPIOPinWrite/Read are a single command:
    return(HWREG(ulPort + (GPIO_O_DATA + (ucPins << 2)))); and
    HWREG(ulPort + (GPIO_O_DATA + (ucPins << 2))) = ucVal; respectively.
     
    I'd venture to guess that moving those lines directly into wiring_digital.c instead of calling ROM_GPIO already makes a big difference. Given that we save a call, the size penalty should be small.
     
    Another thing I notice is, that we first create a bitmask out of the single pin and that mask then get's shifted by 2 in the code above. Maybe the two operations can be combined. Though I guess creating another look-up table just for this minor improvement is not worth the trade-off.
  5. Like
    chicken got a reaction from Vad33 in Strange millis() behaviour   
    I see the same behavior with the official 0101E0009 build and the Stellaris Launchpad.
     
    Looks like there was a major overhaul of wiring.c since then that might fix the issue. Unfortunately I couldn't get the newer version to work for me. Grabbing wiring.c alone seems to completely screw timing (i.e. Serial doesn't work anymore), and grabbing larger parts of the hardware folder causes compile errors about a missing syscalls.h.
     
    PS: You might have more luck getting an answer over on Stellarisiti http://forum.stellarisiti.com/
  6. Like
    chicken got a reaction from bluehash in radioshack clearance   
    They have two PanaVise models on sale online:
    http://www.radioshack.com/shop/rsk_onsale_results.jsp?categoryId=2032058&cp=2056569.2032058&f=Taxonomy%2FRSK%2F2032058&znt_campaign=Category_CMS&znt_medium=RSCOM&znt_source=CAT&znt_content=CT2056569
     
    Didn't see any Arduino related items on sale.
  7. Like
    chicken got a reaction from bluehash in Products using MSP430   
    Another Fluke another MSP430:
     

     
    Fluke 113 Utility Multimeter  
    MSP430F448 - lots of pins thanks to the integrated LCD controller.
  8. Like
    chicken got a reaction from soccou in Strange millis() behaviour   
    For test purposes, you could set the initial milliseconds value to something else than 0 in line 48 of wiring.c:
     
     
    volatile unsigned long wdt_millis = 0;  
    e.g. 0xffff0000 should give you about a minute before roll over.
  9. Like
    chicken reacted to soccou in Strange millis() behaviour   
    @@chicken,
     
    wow, I really appreciate your support. Thank you for your time on this one.
     
    I will try to test this tomorrow.
     
    Scott
  10. Like
    chicken got a reaction from danigom in Problem with I2C RTC DS1307 Module   
    Actually, one last thing: Pull the jumper to the LED on P1.6, powering the LED might conflict with the I2C communication.
  11. Like
    chicken reacted to danigom in Problem with I2C RTC DS1307 Module   
    I am sorry, I was wrong. The program compiles with the following modification (I don't know why yesterday didn't):
    uint8_t i = 0; //The new wire library needs to take an int when you are sending for the zero register With this modification I get two different results. When I supply the module with +5V It doesn't show any communication: 

     
    But when I supply the module with 3.3V I get this (something curious happens):

     
    On the other hand, i've tried with the following sketch: 
    #include <Wire.h> void setup () { Serial.begin(9600); Wire.begin(); } void loop() { Wire.beginTransmission(0x68); Wire.write((uint8_t) 0); Wire.endTransmission(); Wire.requestFrom(0x68, 7); uint8_t ss = Wire.read(); uint8_t mm = Wire.read(); uint8_t hh = Wire.read(); Wire.read(); uint8_t d = Wire.read(); uint8_t m = Wire.read(); uint8_t y = Wire.read(); Serial.print("raw RTC data "); Serial.print(ss); Serial.print("\t"); Serial.print(mm); Serial.print("\t"); Serial.print(hh); Serial.print("\t"); Serial.print(d); Serial.print("\t"); Serial.print(m); Serial.print("\t"); Serial.println(y); delay(1000); } And I also get two different things, when i supply the module with 5Volt I get nothing, but when I supply it with 3.3V I get this: 
     

     
    I think this demonstrates that the module is incompatible. Isn't it? 
  12. Like
    chicken got a reaction from danigom in Problem with I2C RTC DS1307 Module   
    Don't give up yet, we haven't even identified the actual issue

    If that won't compile, please respond with the actual error message. Otherwise it's hard to guess what went wrong.
     
    That being said, there are several things that could go wrong, including some know issues with I2C in the last official release of Energia. Here a basic test program that you could use in a fresh Energia sketch to at least rule out issues with the library and Energia itself.
    #include <Wire.h> void setup () {     Serial.begin(9600);     Wire.begin(); } void loop() {     Wire.beginTransmission(0x68);     Wire.write((uint8_t) 0);     Wire.endTransmission();       Wire.requestFrom(0x68, 7);     uint8_t ss = Wire.read();     uint8_t mm = Wire.read();     uint8_t hh = Wire.read();     Wire.read();     uint8_t d = Wire.read();     uint8_t m = Wire.read();     uint8_t y = Wire.read();       Serial.print("raw RTC data ");     Serial.print(ss);     Serial.print("\t");     Serial.print(mm);     Serial.print("\t");     Serial.print(hh);     Serial.print("\t");     Serial.print(d);     Serial.print("\t");     Serial.print(m);     Serial.print("\t");     Serial.println(y);     delay(1000); } Hope that compiles, just writing/copying blindly without Energia right now
     
    Make sure to power cycle the LaunchPad (i.e. unplug / replug the USB cable) to rule out any hardware issues from previous attempts.
     
    If you still get garbage (e.g. all 255 or 0), then it's time to check your wiring.. or listen to the others and get a 3.3V compatible module, but where's the fun with that?
  13. Like
    chicken got a reaction from danigom in Problem with I2C RTC DS1307 Module   
    When you press Reset on the LaunchPad, does it display "RTC is not running!"?
     
    Also, for better debugging you can try to insert the following lines into your loop:

    Wire.beginTransmission(0x68); Wire.write((uint8_t) 0); Wire.endTransmission();   Wire.requestFrom(0x68, 7); uint8_t ss = Wire.read(); uint8_t mm = Wire.read(); uint8_t hh = Wire.read(); Wire.read(); uint8_t d = Wire.read(); uint8_t m = Wire.read(); uint8_t y = Wire.read();   Serial.print("raw RTC data "); Serial.print(ss); Serial.print("\t"); Serial.print(mm); Serial.print("\t"); Serial.print(hh); Serial.print("\t"); Serial.print(d); Serial.print("\t"); Serial.print(m); Serial.print("\t"); Serial.println(y); And while looking at the code, I noticed a pretty unusual hack that actually might be a freak cause of the issue:
    int i = 0; //The new wire library needs to take an int when you are sending for the zero register .. Wire.beginTransmission(0x68); Wire.write(i); Wire.endTransmission();  That's one ugly way to do a cast. AVR being an 8bit might interpret the int as 8 bit, MSP430 will treat it as 16bit. This might confuse the RTC. Try replacing the first line (line 19 in the original library) with
     

    uint8_t i = 0;
  14. Like
    chicken got a reaction from danigom in Problem with I2C RTC DS1307 Module   
    Does it compile?
     
    If not, what's the error?
  15. Like
    chicken got a reaction from Register in Problem with I2C RTC DS1307 Module   
    Taking a quick look at the code, you'll need to change at least the following:
     
    Remove this line, MSP430 can access data stored in ROM just fine without.

    5: #include <avr/pgmspace.h>  
    Related to this, remove PROGMEM directive here: (you might prefix the line with static)
     
    23: const uint8_t daysInMonth [] PROGMEM = { 31,28,31,30,31,30,31,31,30,31,30,31 }; and access to the array has to be rewritten, original:
     
    31: days += pgm_read_byte(daysInMonth + i - 1); .. 62: uint8_t daysPerMonth = pgm_read_byte(daysInMonth + m - 1); changed:
     
    31: days += daysInMonth[i - 1]; .. 62: uint8_t daysPerMonth = daysInMonth[m - 1];  
    And finally, replace this section with #include "Energia.h"
     
    13: #if (ARDUINO >= 100) 14:  #include <Arduino.h> // capital A so it is error prone on case-sensitive filesystems 15: #else 16:  #include <WProgram.h> 17: #endif
  16. Like
    chicken got a reaction from danigom in Problem with I2C RTC DS1307 Module   
    Looks like the RTCLib is using native AVR code, i.e. it needs some fixing to be portable beyond Arduino.
     
    Are you using the Adafruit library?
    https://github.com/adafruit/RTClib
  17. Like
    chicken got a reaction from dubnet in Strange millis() behaviour   
    Found an error in my micros() implementation, double-counting some microseconds.
     
    By coincidence, it now compiles to exactly the same size as the old wiring.c.
     
    I did some basic verification with MSP430G2553. As this is a rather central piece of code, it would be great if others could verify with different MSP430 variants before I send a pull request to the Energia project.
     
    For testing, replace /energia/hardware/msp430/cores/msp430/wiring.c with the version in the attached archive.
    TimerFixes v2.zip
  18. Like
    chicken reacted to ScottyB in Design puzzle in abstracting GPIO with port support   
    Roadrunner,
     
    I am a big fan of abstraction and automation.  I see plenty of room for accidental defects using the iomacros (i.e. P1OUT, P1REN, etc).  A good abstraction could help push the defect discovery process back to compilation.  So, I've been thinking about ways to solve your challenge.
     
    Like Rick, I'm going to solve the problem with templates.  But I'm going to take it a step farther.  I'm going to make it simpler on the library user's end, but at the cost of a more complicated library.
     
    For example, this--or something similar--is what I want to do:
    int main(int,char**) { // disable watchdog, setup clocks removed to simplify legability typedef define_pin<port1,6> green; // P1.6 typedef define_pin<port1,0> red; // p1.0 enable_output<green,red>(); set_high<green>(); set_low<red>(); while(1) { delay_300ms(); // delay 300ms toggle_pins<green,red>(); } } Here's how I did it:
    // need to add reinclusion protection #include msp430.h #include <stdint.h> // convinience / dispatch type template<typename PORT, uint8_t PIN> struct define_pin { typedef PORT port; enum pin_ { pin = (1 << PIN) }; }; // port definitions struct port_none { ; }; struct port1 { static inline void enable_output(const uint8_t& bits) { P1DIR |= bits; } static inline void set_high(const uint8_t& bits) { P1OUT |= bits; } static inline void set_low(const uint8_t& bits) { P1OUT &= ~bits; } static inline void toggle(const uint8_t& bits) { P1OUT ^= bits; } }; struct port2 { static inline void enable_output(const uint8_t& bits) { P2DIR |= bits; } static inline void set_high(const uint8_t& bits) { P2OUT |= bits; } static inline void set_low(const uint8_t& bits) { P2OUT &= ~bits; } static inline void toggle(const uint8_t& bits) { P2OUT ^= bits; } }; // // ENABLE OUTPUT // // default template template<typename PORT1> inline void enable_output1_impl(const uint8_t& p1) { PORT1::enable_output(p1); } // default template template<typename PORT1, typename PORT2> inline void enable_output2_impl(const uint8_t& p1, const uint8_t& p2) { PORT1::enable_output(p1); PORT2::enable_output(p2); } // default template template<typename PP1, typename PP2=port_none> struct enable_output { enable_output() { enable_output2_impl<typename PP1::port, typename PP2::port>(PP1::pin,PP2::pin); } }; template<typename PP1> struct enable_output<PP1,port_none> { enable_output() { enable_output1_impl<typename PP1::port>(PP1::pin); } }; // specialized template<> inline void enable_output2_impl<port1,port1>(const uint8_t& p1, const uint8_t& p2) { port1::enable_output(p1 | p2); } template<> inline void enable_output2_impl<port2,port2>(const uint8_t& p1, const uint8_t& p2) { port2::enable_output(p1 | p2); } // // SET HIGH // // default template template<typename PORT1> inline void set_high1_impl(const uint8_t& p1) { PORT1::set_high(p1); } // default template template<typename PORT1, typename PORT2> inline void set_high2_impl(const uint8_t& p1, const uint8_t& p2) { PORT1::set_high(p1); PORT2::set_high(p2); } // specialized templates template<> inline void set_high2_impl<port1,port1>(const uint8_t& p1, const uint8_t& p2) { port1::set_high(p1 | p2); } template<> inline void set_high2_impl<port2,port2>(const uint8_t& p1, const uint8_t& p2) { port2::set_high(p1 | p2); } // default template template<typename PP1, typename PP2=port_none> struct set_high { set_high() { set_high2_impl<typename PP1::port, typename PP2::port>(PP1::pin,PP2::pin); } }; // specialized template template<typename PP1> struct set_high<PP1,port_none> { set_high() { set_high1_impl<typename PP1::port>(PP1::pin); } }; // // SET LOW // // default template template<typename PORT1> inline void set_low1_impl(const uint8_t& p1) { PORT1::set_low(p1); } // default template template<typename PORT1, typename PORT2> inline void set_low2_impl(const uint8_t& p1, const uint8_t& p2) { PORT1::set_low(p1); PORT2::set_low(p2); } // specialized templates template<> inline void set_low2_impl<port1,port1>(const uint8_t& p1, const uint8_t& p2) { port1::set_low(p1 | p2); } template<> inline void set_low2_impl<port2,port2>(const uint8_t& p1, const uint8_t& p2) { port2::set_low(p1 | p2); } // default template template<typename PP1, typename PP2=port_none> struct set_low { set_low() { set_low2_impl<typename PP1::port, typename PP2::port>(PP1::pin,PP2::pin); } }; // specialized template template<typename PP1> struct set_low<PP1,port_none> { set_low() { set_low1_impl<typename PP1::port>(PP1::pin); } }; // // TOGGLE // // default template template<typename PORT1> inline void toggle1_impl(const uint8_t& p1) { PORT1::toggle(p1); } // default template template<typename PORT1, typename PORT2> inline void toggle2_impl(const uint8_t& p1, const uint8_t& p2) { PORT1::toggle(p1); PORT2::toggle(p2); } // specialized templates template<> inline void toggle2_impl<port1,port1>(const uint8_t& p1, const uint8_t& p2) { port1::toggle(p1 | p2); } template<> inline void toggle2_impl<port2,port2>(const uint8_t& p1, const uint8_t& p2) { port2::toggle(p1 | p2); } // default template template<typename PP1, typename PP2=port_none> struct toggle_pins { toggle_pins() { toggle2_impl<typename PP1::port, typename PP2::port>(PP1::pin,PP2::pin); } }; // specialized template template<typename PP1> struct toggle_pins<PP1,port_none> { toggle_pins() { toggle1_impl<typename PP1::port>(PP1::pin); } }; This is a great example, I think, of generic programming using dispatch tags and specialized templates.
     
    This code works great to operate on 1 or 2 pins at a time.  It needs to be extended (easy, but tedious) to handle more.  Maybe 8 or 10.  Also, needs to be extended to enable input, enable resistors, and read input.  Again, easy and tedious.
     
    But what about comparing the resulting assembly to C based iomacro only?  The same code, only using P1DIR and P1OUT, produces the EXACT same assembly output.  (Note that I am using mspgcc and have optimization turned on.  But, I wouldn't expect it any other way.  Well written, abstract C++ is often as optimal as boring old C.   ;-)  )
     
    I'm sure if I thought about it longer, I could change the function call to 'enable_output(green,red)', even if only through a macro.
  19. Like
    chicken got a reaction from Serginho in [Energia Library] Bosch BMP085 Template Library   
    I finished up my first Energia project, a template library for the Bosch BMP085 temperature and pressure sensor. It uses I2C and supports temperature in Celsius and pressure in Pascal.
     
    https://github.com/astuder/BMP085-template-library-Energia
     
    I connected the GY-80 breakout commonly found on eBay, but it should also work with most other BMP085 breakouts, like the ones from Adafruit or Sparkfun.
     
    Note that I had to patch Energia to make 1-byte read work on MSP430G2553 with Rev1.5 LaunchPad. I also had to remove the LED2 jumper, probably due to too weak I2C pull-up.
     
    Update:
     
    Tested on LaunchPad 1.5 with MSP430G2553, StellarPad Rev A and Arduino R3.
     
    Energia requires patches 226 and 235 in twi.c for I2C to work properly on MSP430G2553
    https://github.com/energia/Energia/pull/226/files
    https://github.com/energia/Energia/pull/235/files
     
    Updates:
    - Tested with Energia 0101E0010 with MSP430G2553 and F5529, no more I2C patches needed.
    - Tested with BMP180 and Software I2C http://forum.43oh.com/topic/3777-energia-library-bosch-bmp085-template-library/?p=44410
    - Fixed I2C for Energia 0101E0016 by removing ugly hacks from the past from the library code. Tested only with MSP430G2553
  20. Like
    chicken got a reaction from bluehash in [Energia Library] Bosch BMP085 Template Library   
    Now tested on StellarPad and Arduino.
  21. Like
    chicken got a reaction from jpnorair in MSPMATHLIB math library   
    Just came across this announcement of a math library optimized for MSP430:
    http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/05/07/mspmathlib-amping-up-the-performance-of-msp430-but-not-the-power.aspx
     
    Unfortunately only for MSP430F5xx and F6xx and FRAM devices. Any idea what kind of peripheral these have to accelerate math?
     
    MSPMATHLIB maim page here:
    http://www.ti.com/tool/mspmathlib
  22. Like
    chicken got a reaction from bluehash in MSPMATHLIB math library   
    Just came across this announcement of a math library optimized for MSP430:
    http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/05/07/mspmathlib-amping-up-the-performance-of-msp430-but-not-the-power.aspx
     
    Unfortunately only for MSP430F5xx and F6xx and FRAM devices. Any idea what kind of peripheral these have to accelerate math?
     
    MSPMATHLIB maim page here:
    http://www.ti.com/tool/mspmathlib
  23. Like
    chicken got a reaction from Rei Vilo in MSPMATHLIB math library   
    Just came across this announcement of a math library optimized for MSP430:
    http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/05/07/mspmathlib-amping-up-the-performance-of-msp430-but-not-the-power.aspx
     
    Unfortunately only for MSP430F5xx and F6xx and FRAM devices. Any idea what kind of peripheral these have to accelerate math?
     
    MSPMATHLIB maim page here:
    http://www.ti.com/tool/mspmathlib
  24. Like
    chicken reacted to SJoshi in Modifying Energia compiler options   
    Hi all,
     
    I was wondering if modifying the compiler flags was easily possible? 
     
    I have a program that is really tiptoe-ing the maximum program size for my FR5739, and when I add some extra functionality, it goes overboard by 1-2k. 
     
    I think some of this is due to some extra bloat that Energia adds, but for the simplicity of getting up and running, alongside the sweet already-created libraries, it's totally worth it. 
     
    So, before I go out and re-design a board with a different chip, I was wondering if there were some freebies I should look into. I think I've removed as much extra code as is feasible, and played around with adding/removing libraries, but the impact is negligible. 
     
    One thing I would like to try is the msp430-strip command... I don't know what that will do, but I've seen that with --strip-unneeded -g -x, the results on the .o files seems to be good... I don't yet know how this will translate to the actual elf or hex files though.
     
    Has anyone tried this before?
     
    Thanks,
    -SJ
  25. Like
    chicken got a reaction from Pradeepa in No lab exercises in stellarisware   
    Did you already check out the Stellaris Launchpad Workshop?
    http://processors.wiki.ti.com/index.php/Getting_Started_with_the_Stellaris_EK-LM4F120XL_LaunchPad_Workshop
     
    Files for lab exercises are in the Workshop Material section of the page.
     
    Regards
    Adrian
×
×
  • Create New...