Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    Automate got a reaction from bluehash in ConnectedByTCP Flood Lights   
    You could use RobG's ethernet board with IPv4 if you also use the TCP/Greenwave gateway.  Someone here has started reverse engineer the commands that are needed. http://cocoontech.com/forums/topic/25691-home-depot-now-selling-affordable-wireless-ledcfl-bulbs/page-2#entry208279
  2. Like
    Automate reacted to luke in ConnectedByTCP Flood Lights   
    I just received a bunch of wireless controlled floodlights from HomeDepot.  Just search though HD's site with "Connected TCP" for product info.   I got the starter kit with 2 A19 bulbs and a gateway plus I ordered 6 floods.  They work great although I wouldn't really describe their light color as soft white.  We'll see if I get used to it.   The A19 bulbs however look really great.
    You can control them using iOS, android or any web browser.  Doing some very preliminary research shows that the underlying tech is made by GreenWave Reality using NXP's JenNet-IP's IPv6 stack.
    All in all remarkably cheap solution for retro fitting scene control with individual light granularity.
    The only bummer is that they don't have a wall switch yet.  They have a remote (which I am sure is always going to be lost) and as I said you can use the iPhone etc., but I am afraid it may be cumbersome for non-tech savvy folks.  
    We (as in anyone but me ) need to come up with a MSP430 based touch pad wall switch to control this baby.
    Does anyone have any experience with NXP JenNet-IP?
  3. Like
    Automate reacted to anandjm in A Simple USB to TTL Convertor   
    I recently purchased a Cubietruck/Cubieboard3 (http://cubieboard.org/2013/10/30/cubieboard3-cubietruck-is-all-ready/) and since I want to customize the kernels, I needed a USB to TTL Serial converter at 115200bps. Being a weekend I was too lazy to go out to the electronics hardware market, and since I wanted it immediately I did not want to buy it online. So I felt I should be able to use one of my Stellaris Launchpad boards for this purpose. Here is the code for USB to TTL Serial conversion. A better option would be to code directly in "C" with the USB library in Tivaware/Stellarisware, but this code is so simple that I would not waste my time doing it right now. The code should work with any hardware supported by the Wiring framework. 
     -----Code starts here----------
    //Red-Blue Combination is most visible for data status indication const int read_LED = RED_LED; //Red LED blinks on data read const int write_LED = BLUE_LED; //Blue LED blinks on data write int read_State=LOW, write_State=LOW; void setup() { pinMode(read_LED, OUTPUT); pinMode(write_LED, OUTPUT); Serial.begin(115200); Serial1.setPins(UART1_PORTB); //Comment if you need to use the alternate port PC4/PC5 Serial1.begin(115200); Serial.println("Simple USB TTL Converter - Stellaris/Tiva Launchpad"); } void loop() { if (Serial.available()){ digitalWrite(write_LED,HIGH); Serial1.write(Serial.read()); } if (Serial1.available()){ digitalWrite(read_LED,HIGH); Serial.write(Serial1.read()); } digitalWrite(write_LED,LOW); digitalWrite(read_LED,LOW); } ------Code Ends here -------
  4. Like
    Automate reacted to petertux in interphone hack   
    a little context first. I live in an appartment building that has a metallic door at the entrance. in theory one can make that open either by using a pin tumbler lock, an optical keycard or you can call someone by dialing the appartment number on the interphone. none of which are adequate: the yale lock is broken and 'costs too much to repair' to quote the administrator, the optical keys are both fragile and too big for my pockets and training my cat to open the door when I call would be too much of a challenge.

    so how about 'improving' that interphone? once someone calls the appartment number the in-house interphone starts receiving power (9V DC) and the resident is expected to push a talk button, identify the guest and optionally activate the door opening button. it proved that all these steps need to be followed:
    wait for call talk_enable wait (at least) 100ms talk_disable wait 100ms open_enable wait 100ms *door opens* open_disable see first picture for the signals - CH1 - output, CH2 - trigger
    in the first revision of this project I was using a large 12V battery in the house. that was connected to a RC relay that is able to send a signal to a msp430f5510. that uC was waiting for the 9V wake-up call, control the button presses via two mosfets and it was also using the RC signal to 'authenticate' the person outside. the TX was supposed to be my ez430 chronos watch sending OOK signals. but unfortunately the radio signal was not powerfull enough, even if the tiny radio was cranked up to max and the distance was not that big.

    oh well.

    somehow I didn't want to have a power hungry dsp processing chip in the house for voice recognition (that was my initial plan b ).

    so given the fact that the only signal from the outside is the 9V wakeup call I decided to 'authenticate' the user by timing 2 consecutive calls. nobody in their right mind would call my number, hang up and call again in a strict (0.2sec) timeframe, right? right?

    here comes the latest revision. the same uC connected to a coin-cell battery for a whoopingly tiny 1.39uA quiescent current (LPM4 ftw). this power source is used because I don't want to load that interphone system since it's a black box to me. plus I need the uC to be able to time activity on the 9V power line between 2 calls, when there is no power on it. this scenario also comes with the nice benefit that the interphone unit remains completely stock and my pcb is just placed in parallel with it.
    see pic 2.  the current pcb is inside the in-house interphone enclosure, the old devel version was stuck to the wall (pcb on the right - actually that pcb was an early revision of the solar charger project).

    all I have to do now to enter the main door is to call my number twice in a given timeframe. the timeframe is either given by time spent after the first call (current implementation) or by counting seconds after the talk button was 'depressed' by the uC (a slight click is heard in the speakers in that moment).

    no more keys, cards or talks to the administrator. I just hope thieves can't read my code [1].

    [1] https://github.com/rodan/interphone

  5. Like
    Automate reacted to Rei Vilo in [Energia Library] Fuel Tank BoosterPack   
    Please find a library for the Fuel Tank BoosterPack with an example and the accompanying reference manual.
    FuelTank - Reference Manual.pdf
    The library has been tested on a Stellaris LaunchPad, with the shunts R9 and R10 in place so the I
  6. Like
    Automate reacted to t0mpr1c3 in Contiki port for G2553 (no uIP)   
  7. Like
    Automate reacted to grahamf72 in Using the internal temp sensor on F5529   
    I've used the following code on the cc430f6137.  Although I don't have a '5529 to test on, I've checked the msp430f5529's datasheet, and it has the same TLV calibration constant addresses, and it also has the ADC12, so I can't see any reason why this code shouldn't also work on the '5529.
    static const uint16_t *ADC15TEMP30 = (uint16_t *)0x1A1A; static const uint16_t *ADC15TEMP85 = (uint16_t *)0x1A1C; int16_t GetTempX10(int oversampling) { uint32_t reading=0; analogReference(INTERNAL1V5); //use the 1.5V internal reference for(int i=0; i<(1<<oversampling); i++) reading+=analogRead(TEMPSENSOR); //do 2^oversampling reads reading>>=oversampling; //and divide by 2^oversampling, we are left with the average from 2^oversampling reads. return map(reading,*ADC15TEMP30,*ADC15TEMP85,300,850); //convert our reading to temp x 10 & return } The code is pretty straightforward. According to the datasheet, the calibration values using the 1.5V reference are located at 0x1A1A for the 30c, and 0x1A1C for 85c. For some reason the header file for the cc430f6137 doesn't define a variable pointing to these constants, I assume the msp430f5529 doesn't either, so we create a couple of pointer variables pointing to the calibration constants.
    We then set our reference to the 1.5V internal reference. You don't have to use 1.5V - you could use the 2V or 2.5V reference (and change the address of the calibration constants accordingly), but the 1.5V constant will give the best accuracy.
    I decided to do the oversampling because I was getting jittery results, this smoothed it out considerably, so you can pass a parameter to the function and it will do 2^oversampling reads. Eg, GetTempX10(0) will do 1 read, GetTempX10(3) will do 8 reads. The advantage of using a 2^ for oversampling is that it allows us to use bit shifts instead of divides, resulting in smaller faster code. So we just read analogRead a few times, adding the result along the way, then shift the result right to get the average value. 
    Once we have averaged the result, it is then a simple matter of converting this to a temperature using the calibration constants. Energia provides a nice simple function that makes this conversion easy - map.  Map converts a number from an input range (our calibration constants) to an output range (our temperature).  Because map doesn't do bounds checking it will yield an accurate result if the reading is outside the start & end range.  You'll note that for the output range I have used 300 & 850 - that allows the use of purely integer math to get an output with 0.1c precision. If you want the output in fahrenheit, all you need to do is change the 300 & 850 for the fahrenheit equivalents of 30 & 85c. ie, 860 & 1850. If you only want 1 degree precision, use 30 & 85 instead of 300 & 850.
  8. Like
    Automate got a reaction from exemaspilasem in Beagle Bone down to $30   
    Not BBB
  9. Like
    Automate reacted to jpnorair in 300m Range RF PCB discussion   
    A member recently asked me a bunch of questions through private messaging.  I'm posting the dialog here in case anyone else is interested.
    there's nothing at 2.4 GHz that is going to give you more than 100m range.  The NRF24L01 is good for about 20m.  What are your requirements for power & long range?
    To communicate further than 300m, you need to worry about multipath.  Multipath is interference coming from the signal bouncing-off things.  The receiver sees copies of the same signal, and it can be difficult to decode.
    There are some ways to reduce multipath interference.
    1. Use lower frequency.
    2. Use a modulation that has redundancy, like wideband FSK.  Alternatively, use DSSS.
    3. Use lower data rate.
    I've never heard of anyone using MRF49XA.  You may want to try Semtech SX127x, which is indeed the device used by SigFox.  There are many, new, low power RF IC's coming out.  The ones most interesting are: Semtech SX127x, SiLabs Si4463, TI CC1200, and ST SPIRIT1.  All have slightly different advantages, although I use SPIRIT1 primarily. 
    You can probably forget about communicating faster than 50kbps, maybe 100 at most.  Higher data rate reduces range.  You can do some tests to figure out what works best for you -- multipath is your biggest problem, and it is nonlinear, so you might find that there is 10% packet loss at (for example) 50kbps and 90% packet loss at 60kbps.  You should just test and find out -- make sure to adjust digital RX filter bandwidth together with datarate!
    Yes, use an external dipole.  Monopole is OK too, but only if you know how to tune the design on your board.  So just use the dipole.
    Of those chips, use whichever chip is easiest for you.  Make sure to use wideband FSK (set Fdev larger than baud rate) with FEC enabled on CC1200 or SPIRIT1.  On SX127x, make sure to use a combination of spreading (DSSS) and FEC.  Without going into great detail, I will say that SPIRIT1 is the best chip to use if you are an expert.  It is like a race car that is extremely fast, but difficult to drive.  SX127x is like a fast car that is easy to drive, so I recommend it for you.  If you cannot achieve 300m with SX127x, then you are doing something very wrong .
    I think the only difference is that 1272 is for 862, 866 MHz bands only, and 1276 can use 169, 433, 862, 866.  1272 is probably cheaper.  For small volumes, 1276 is probably better, because you might want to try different bands.
    RX filter is a setting on the transceiver.  If your RX filter is narrower than the emission spectrum (known as power spectral density, PSD), you will not receive all the power of the signal.
    In systems with monopole antennas, it is important to have an uninterrupted ground layer.  It dipole systems, this is less important.  However, you also want a ground layer underneath the transceiver and front-end analog circuits.  For 866 MHz you will want the spacing to be no more than 0.8mm.  For 433 you can get away with 1.6mm.  You also want to sink a lot of vias between ground layers.  This prevents ground loops.
    Therefore, 2-layer is OK, but it is difficult to design a PCB that is good for RF with only 2-layers.
    Yes, 0.8mm PCB if you use only 2 layers, and you use 866 MHz.
    You should probably use 433 MHz, anyway, since range is important.  169 MHz would also be an option, although it is a new band so it can be difficult to find ready-made parts for it.  169 MHz on a dipole will go 300m easily!
  10. Like
    Automate reacted to moallen in BeagleBoardXm Home Energy Monitor   
    Over the past 10 years I've used various micro-controllers and devices to monitor and control my home heating and cooling system, water heater, sump pump, humidifier, AC power, lights, as well as a custom security system. After downsizing and moving into a condo a couple years ago, I also downsized my system toys, much to my wife's relief. But I am currently using a BeagleBoardXM to monitor our gas furnace and relevant weather datapoints. I thought I would share some of this project with anyone who might be interested.
    The heart of the monitoring system is a BeagleBoardXm running Ubuntu 13.04 headless. The program itself is written in Python 2.7.4. Data passed to the program consists of whether the furnace's gas burner is on or off, the temperature and humidity inside our home and the temperature, wind chill and wind speed outside. These 6 data points are uploaded to Xively every 60 seconds where they are automatically graphed for web analysis. In addition all data is logged to the BeagleBoard's SD card everytime the status of the furnace changes.
    To be more specific about the hardware, a 24VAC relay is connected to the furnace's gas valve. It's normally closed contacts are connected to a digital input pin on a Xbee radio module. The Xbee is  set up in I/O line passing mode. When the furnace fires, pin D3 goes High, which is reflected on another Xbee, also running in I/O line passing mode, connected to a USB port on the BeagleBoard. This Xbee then sends a 13 byte packet to the serial port which is read by the Python program.
    I could add more appliances to the Xbee in our utility room, for example, the water heater, clothes washer/dryer and AC power. But for now I'm keeping things minimal.
    To measure the temperature and humidity inside our home, I'm using a Phidgets 8/8/8 Interface Board. Phidgets temperature and humidity sernsors are connected to a couple of its analog inputs. Here again I could add more sensors.
    To get outside conditions, I'm pulling down metadata from WeatherBug.com, parsing its 30 some data elements and retreiving just temperature, wind chill and wind speed. Those seemed to be the things most relevant to how much my furnace runs.
    Then as I mentioned, these 6 data elements are uploaded to Xively.com for online viewing. This has come in handy when we are away to make sure things are running OK at home. Here's a link to my account: https://xively.com/feeds/97217%C2'> It may not always be updating, as I fiddle around with the program.
    I use MobaXterm to SSH into the BeagleBoardXm and WinSCP for more extensive file management, both from my Windows machine through our home network. I did find it necessary to setup a static IP adress for the BBXm.
    Some of the Python packages this project uses are: PySerial, Mechanize and Phidgets. I'm using an embedded class from: github.com/mattvenn/cosm to format the data elements into a format suitable for uploading to Xively. Interestingly, Pachube was bought by Cosm and finally by Xively during the years I have been using them to graph my data.
    I also managed to get my sound working and may use it for audible warnings or messages. Perhaps more to come...

  11. Like
    Automate reacted to GastonP in Chronos and Fraunchpad on offer for the holidays!!!   
    Hey all!
       I have received an email from the Official MSP430 Blog where they announce a Holidays offer. They are taking 54% off the regular price for just this last two weeks of the year!!!
    So if you always wanted a Chronos or a Fraunchpad and the price tag was your restraint... now you have no more excuses. Woohoo!!!
    I just bought my very first Fraunchpad, and the discount code works... and I'm feeling tempted to get another Chronos... mmmmmmmmm
  12. Like
    Automate got a reaction from bluehash in New TI LaunchPad site   
    Under the Community & Support tab there is a section for "News from 43oh.com"
    [ Admin Edit : 43oh Blog link: http://43oh.com/2013/12/ti-updates-its-launchpad-portal-one-word-refreshing/ ]
  13. Like
    Automate reacted to energia in New Energia release 0101E0011 - 12/17/2013   
    I am happy to announce that release 0101E0011 just went up on energia.nu.    I want to thank everybody for their support and contributions. Energia would not have been possible without such an awesome community!   The highlights are: Lots of bug fixes Major update to the CC3000 WiFi BoosterPackLibrary for the MSP430F5529 and TivaC/Stellaris LaunchPad Updated ARM tools to gcc-arm-embedded Initial C2000 support (thanks to Trey German for all his hard work on getting Energia ported to the C2000) CCSv6 Energia Sketch import Support for MSP-EXP430G2 LaunchPad Support for MSP-EXP430F5529LP LaunchPad Support for EK-TM4C123GXL (TivaC) LaunchPad Support for EK-LM4F120XL (Stellaris) LaunchPad Runs on Windows (XP/7/8), Mac OS X and Linux (32/64 bit) Happy Making!
  14. Like
    Automate reacted to p2baron in [Energia library] x10rf   
    already posted this on the Stellaristi forum but this also works on MSP430 devices.
    Just change BLUE_LED to RED_LED in the examplle sketches.
    Hi All,   Wanted to share a library I've created to broadcast x10 messages using a cheap 433Mhz OOK device. There are a lot of (Arduino based) libraries dealing with X10. I couldn't find any RF libraries that works without a 'firecracker' (CMA17) device so I've created one. I am not a coder and this is my first Energia library ever so use at your own risk.     The library can emulate x10 switches and x10 security devices and also RFXMeter and RFXSensor devices manufactured by RFXCom. (www.rfxcom.com) Tested on a TI Stellarpad (LM4F120H5QR) and Energia 0101E0010. It should also work with other boards.   Examples are provided with the library.
    You can find it on Github: https://github.com/p2baron/x10rf
      Regards, PP
  15. Like
    Automate reacted to gonya707 in AD9850 (DDS function generator) for Energia   
    This is the Energia version of the library I shared here. You can find this function generator module easily in eBay for about $5
    It has the same functions but this time the library features a object-oriented structure, which allows to manage several AD9850 modules at once. It works perfectly for both MSP430 and Stellarpad boards (tested), you just need to change the given pin numbers when you create the AD9858 class instance.
    class AD9850{ public: AD9850(int givenW_CLK, int givenFQ_UD, int givenDATA, int givenRESET); void init(); void doReset(); void osc(double Freq,double phase); void sweepUp(double minFreq, double maxFreq, double inc, int cyclesPerDelay); void sweepDown(double minFreq, double maxFreq, double inc, int cyclesPerDelay); void sweepLoop(double minFreq, double maxFreq, double inc, int cyclesPerDelay); void powerDown(); private: int W_CLK; int FQ_UD; int DATA; int RESET; }; This is a main code example for the Stellarpad:
    #include "ENERGIA_AD9850.h" void setup(){ pinMode(PE_5, OUTPUT); pinMode(PA_5, OUTPUT); pinMode(PA_6, OUTPUT); pinMode(PA_7, OUTPUT); AD9850 device(PE_5, PA_5, PA_6, PA_7); device.init(); device.doReset(); // min frequency = 1Hz, max frequency = 10000Hz // 1Hz steps, waiting 1000 Cycles between changing frequency. device.sweepLoop(1, 10000, 1, 1000); } void loop(){} //do nothing And the result will be something like this:

    You can download the codes attached to this post. Please unlock cpp and .h this time sorry for the inconvenience.
    You can temporally download them here. 
  16. Like
    Automate reacted to developer_bt in SOLVED! DHT22 Temp & RH% One-Wire Sensor on Energia   
    I found the problem! It is about configuring the system clock which is used to generate delays for functions: delay() and delayMicroseconds(). The change should be made in the core library wiring.c. You can use the change in the previous post but for a 80Mhz may simply make only the following changes: change wireing.c, (energia_dir)\hardware\lm4f\cores\lm4f\wiring.c
    // //SysTick is used for delay() and delayMicroseconds() // //ROM_SysTickPeriodSet(0x00FFFFFF); ROM_SysTickPeriodSet(ROM_SysCtlClockGet() / 100); ROM_SysTickEnable(); I hope to someone would be of help 
  17. Like
    Automate reacted to gonya707 in AD9850 Library (DDS function generator)   
    Hi there. First of all I'm not sure if I should post this here or inside another section fo the forum, apologies if I made a mistake.

    Probably some of you already know this IC, the AD9850. Its a sine and square wave generator with output frequencies between 0Hz and...more than 60MHz! Due to its very low price (around $5 on eBay) and usefulness, it is definitively a module everybody should have if you can't afford a function generator. This library comes with several functions you might find useful:
    /* Starts AD9850 operation changing its value to "all zeros". * Refreshes previous status from the microcontroller.*/ void AD9850_Init(void); /* Reset operation for the AD9850. This function must be called before using AD9850_Osc * first time in the execution (check page 12 on datasheet) */ void AD9850_Reset(void); /* Sets the DDS sine and square oscillator to the detailed "frequency" and "phase" variables. * "frequency" will be turned into a 32 bit word, so the frequency will have a resolution of 0.0291 Hz * with a 125 MHz reference clock. "phase" will be a 5 bit word instead so the resolution is * 11.5 degrees, or pi/32 radians. */ void AD9850_Osc(double frequency, double phase); /* Enables power down mode. This method is used for a quick "all outputs" disable. * The effect is the same as AD9850_Osc(0,0), but it takes less clock cycles */ void AD9850_PowerDown(void); /* Performs a frequency sweep increased in "inc"Hz steps. The frequency order is from low to high * and resets to the lower frequency when maximum frequency is reached. */ void AD9850_Sweep_Up(double minFreq, double maxFreq, double inc, int cyclesPerDelay); /* Performs a frequency sweep decreased in "inc"Hz steps. The frequency order is from high to low * and resets to the higher frequency when minimum frequency is reached. */ void AD9850_Sweep_Down(double minFreq, double maxFreq, double inc, int cyclesPerDelay); /* Performs a frequency sweep increased in "inc"Hz steps. The frequency order is from low to high, * but it changes to from high to low when the maximum frequency is reached and so on. */ void AD9850_Sweep_Loop(double minFreq, double maxFreq, double inc, int cyclesPerDelay); Inside your main code you only need to include the library and init the module:
    //AD9850 config SysCtlPeripheralEnable(PORT_ENABLE); GPIOPinTypeGPIOOutput(PORT, W_CLK|FQ_UD|DATA|RESET); AD9850_Init(); AD9850_Reset(); //frequency = 10000Hz, phase = 0 rad AD9850_Osc(10000, 0); And that's it. You can download the codes attached to this post. I hope you find them useful.
  18. Like
    Automate reacted to Fred in Fuel Tank (LiPo) BoosterPack   
    It seems that Farnell (Element 14) and TI have been working on a LiPo BoosterPack.
    Press release

  19. Like
    Automate got a reaction from elpaso in Chronos: (open) where to start?   
    Congrats, you made DP.  http://dangerousprototypes.com/2013/12/03/ti-ez430-chronos-watch-getting-started-on-custom-firmwares/
  20. Like
    Automate got a reaction from bluehash in A Shell For The Stellaris & Tiva   
    From HAD
    When [antoker] is working on a microcontroller project, he often has to write short bits of test code to make sure everything in his circuit is working properly. This is a time-consuming task, and a while back he started on a small side project. It’s a command line interface for a microcontroller that allows him to send short commands to the uC over a serial connection to play around with the ADC, UART, and GPIO pins.
    [antoker]‘s tiny Unix-like environment is based on modules  that can keep track of the time, print the current commands and stack to a terminal, and query things like the current speed of the uC and the available Flash and RAM.
    This tiny shell also has scripting capabilities and a jump function, making this a true programming language, however minimal it is. Right now [antoker]‘s work is available for the TI Stellaris and Tiva series microcontrollers, and a video of a scripted Larson scanner is available below

  21. Like
    Automate got a reaction from bluehash in Embedded Systems Thanksgiving and Black Friday Deal List   
    Maker Shed free shipping code "FRIDAY" good through 12/1
  22. Like
    Automate got a reaction from bluehash in Embedded Systems Thanksgiving and Black Friday Deal List   
    Circuit Cellar webshop 20% off store wide http://ow.ly/i/3R68x
  23. Like
    Automate got a reaction from bluehash in Embedded Systems Thanksgiving and Black Friday Deal List   
    Fluke deals.  Starts Black Friday through 12/2
  24. Like
    Automate reacted to stanley in [Energia Library] Enrf24 nRF24L01+ Library   
    Wrote a blog on the process of getting nRF24L01 working with Stellaris Launchpad and Arduino UNO running on RF24 library...
    They are only a few combinations to try if they are not working :-
    Air rate / speed :- 250Kbps, 1Mbps or 2Mbps
    Channels : both sides MUST matched the same channel
    txaddress matches rxaddress ( or vice versa )
    CRC : Either OFF or 8bit or 16bit ( Mirf & enrf24 uses 8bit CRC, RF24 uses 16bit CRC or manually set it )
  25. Like
    Automate reacted to grahamf72 in Using the CC430 Experimenters Board in Energia   
    Yesterday my CC430 experimenters board arrived, so this afternoon I had a play to see if I could get Energia talking to it.  After editing the boards.txt, and creating new variants for both boards (the satellite and the base board), and modifying the relevant pins_energia.h files, and a quick and dirty tweak to the hal_lcd files that came with the source-code to the CC430's pre-loaded app,  I have finally managed to compile & upload some basic sketches to both the base-board & satellite board.
    At the moment this is the state of my playing:
    1. Turning on/off the onboard LED's
    2. Reading the onboard pushbuttons
    3. Using the LCD screen with the hal_lcd library that was included with the source-code for the pre-loaded app.
    4. Uploading sketches from Windows.
    Not Working:
    1. delay() takes about 10x longer than it should - presumably millis() is also running slow, so it seems the clocks aren't getting configured correctly.
    2. serial doesn't work - I'm not sure if this is a clocking issue related to the above problem, or if it is a more serious problem.
    3. Uploading from Mac OSX - I'm using 10.9 and getting errors about there being no free FET.
    Not Tested:
    Pretty much everything else that energia is capable of doing 
    No attempt made to try to get working:
    SPI, I2C - I haven't touched the 5529 configuration for these, so they are pointing to the wrong pins. The default pins for these functions aren't exposed on the satellite board, and on the base-board they are shared with the LCD, so to use these functions will require mapping - I haven't looked into how feasible that is yet.
    Radio - I haven't made any attempt at porting this yet.
    I haven't tried to enable the use of the pins that are used for the LCD as GPIO ports. I haven't studied the board in enough depth to know if this is possible.
    I'm quite happy with my progress thus far. Although ultimately I'd like to get the board completely up and running in Energia, I don't know if that will be even possible, but it is giving me a good challenge.  I welcome feedback and especially welcome any hints on how to fix the problems listed above. 
    Attached is a zip with some of the files I've been tinkering with. In the zip file you'll find the following:
    Energia folder containing simple test sketches and the hal_lcd library - this goes in your Energia user directory.
    boards.txt file - this goes into the ./hardware/msp430 folder of your Energia installation.
    variants folder - put the contents of this into the ../hardware/msp430/variants folder of your Energia installation.
    CC430Experimenters Board.zip
  • Create New...