Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    tripwire got a reaction from mbeals in checking a character string in a buffer   
    If Line is an array of char, then the reason this won't work is a bit more subtle than that.
    C and C++ don't support equality comparison of native arrays. That means that (Line == "[start config]") doesn't compare each element of Line with the corresponding elements of the "[start config]" string literal. Instead, Line and "[start config]" both decay to pointers to their first elements. Then the values of those pointers are compared. The two arrays are at different locations in memory, so the two pointers will never match.
  2. Like
    tripwire got a reaction from JWoodrell in checking a character string in a buffer   
    If Line is an array of char, then the reason this won't work is a bit more subtle than that.
    C and C++ don't support equality comparison of native arrays. That means that (Line == "[start config]") doesn't compare each element of Line with the corresponding elements of the "[start config]" string literal. Instead, Line and "[start config]" both decay to pointers to their first elements. Then the values of those pointers are compared. The two arrays are at different locations in memory, so the two pointers will never match.
  3. Like
    tripwire reacted to pabigot in Why is MSP430's Stack Poniter(SP) always alligned to even address?   
    What @@spirilis said about 16-bit operations needing to be aligned is correct and applies to word operations regardless of addressing mode. The insight with the stack pointer specifically is that, at any moment when interrupts are enabled, the MCU must be able to push the program counter and status register onto the stack as words to execute an interrupt. Thus the stack pointer must at all times be 16-bit aligned.
    Also as noted, word access to odd-byte-aligned data gets the wrong answer. Sometimes when working with mapped structures (e.g., network packet headers) you might find the structure declaration annotated with __attribute__((__packed__)) which indicates that the native alignment requirements might not be satisfied (e.g., if some idiot defines a structure that begins with three uint8_t followed by uint32_t). Use of a packed structure on the MSP430, even if it happens to be aligned for some particular instance, has a huge impact on code size as the compiler has to build the multi-byte values up by independent byte read and swap operations.
    So only used the packed annotation on structure declarations when you absolutely have to; and, where possible, lay out your structures so they're naturally 16-bit (or, better, 32-bit) aligned.
  4. Like
    tripwire reacted to greeeg in Why is MSP430's Stack Poniter(SP) always alligned to even address?   
    Just to add. Robomon, you sound like your mistaking the stack Pointer, SP, for indirect addressing. The SP is a special register. It is linked to special function when push/pop/call/ret/reti instructions are executed.
    Your byte array would be compiled down to an indirect access, using a register like so:
    mov.b @r10,r11 or equiv. mov.b 0(r10),r11
    Where r10 specifies an address (doesn't have to be word aligned), and after executed r11 would be equal to the data contained at that address.
  5. Like
    tripwire reacted to Fred in Wolverine Launchpad   
    Mine just arrived. Unfortunately I won't get a chance to play with it as I'm away this weekend.
  6. Like
    tripwire reacted to KwaiChang in Wolverine Launchpad   
    Here are some pictures. It is running off the supercap in the picures.
  7. Like
    tripwire reacted to Fred in Wolverine Launchpad   
    I can't see that YouTube video as I'm at work, but found these links on TI's site for the LP on its own (price?) and also bundled with LCD ($29):
    Nice price for the bundle, but it seems you can't pre-order it yet.
    Some nice info if you follow the document links - e.g. about the on-board supercap.
    http://www.ti.com/lit/ug/slau535/slau535.pdf (LP)
    http://www.ti.com/lit/ug/slau553/slau553.pdf (LCD booster)
  8. Like
    tripwire reacted to Rei Vilo in Energia question from a CCS user   
    Actually, Energia is two main things:
    a very basic and pretty limited IDE based on Processing, a framework or hardware abstraction layer that provides access to all the pins and ports. The real benefit for Energia comes from the framework. The same code can run in any LaunchPad, MSP430 or Stellaris or Tiva C, as long as you use the provided libraries to manage the pins and ports, and memory consideration put aside.
    How to get the best of both world and combine the Energia framework and the advanced features like debugging from CCS?
    Have a look at CCS6, still in beta, that can import Energia projects.
    Unfortunately, CCS isn't available on Mac OS X, so I'm using Xcode as front-end with the embedXcode template.
    Can Energia be used for serious projects?
    I think so. See this interesting thread Is Energia just for prototyping or can it be used for actual product releases? at the sister forum Stellarisiti.
  9. Like
    tripwire reacted to HanzZ in QSimKit - MSP430 simulator   
    Hi again,
    this new version took me quite a long time, because I had to write and defend first part of my diploma thesis about this project. After I succeed two weeks ago, I've started developing QSimKit again and released this new version 0.0.3. I will have more time for development now, so I will start releasing more often again .
    Changes in version 0.0.3:
    QSimKit GUI:
    Drawing optimizations Fixed bug when breakpoints got lost when switching between C and ASM Fixed crash when DebugData cannot be loaded Added dialog for adding breakpoints on any change on particular memory address Fixed bug when peripherals have not been removed from left panel when creating new project MSP430:
    Add support for USCI-SPI Add support for USART-SPI Timer optimizations Fix of divider handling in all modules  
    The main feature planned for the next version is support for all series as defined here.
  10. Like
    tripwire reacted to dubnet in Wolverine Launchpad   
    Saw this over on TI's E2E forum.  Looks like after about 2 years since it was shown in a trade show in Germany, the Wolverine Launchpad will be launching in the next 3-4 weeks.
  11. Like
    tripwire reacted to jpnorair in What are you doing right now..?   
    If you do these things, the reference design should work as advertised.
    1. Do what you can to copy the reference circuit layout, that will simplify things.
    1b. Don't put inductors parallel to each other.  Put them in a straight axial line, or perpendicular.  Otherwise you get transformer behavior.
    2. Use a 4 layer board.  Just do it.  Ground layer right under RF filtering components.
    3. vias connecting ground layers... all over the place, but particularly at edges.  You do not have nearly enough in that image.
    How are you connecting to the antenna?  That is another list of considerations.
  12. Like
    tripwire reacted to simpleavr in What are you doing right now..?   
    Saw chicken's dAISy project. Thought it was cool.
    Ordered this $10ish RT2832U DVB-T USB stick from dx.com, came in 3 weeks. Install gnu-radio, rtl-sdr, gqrx and dump1090.
    Now watching planes over my house.
    I am inside and using the stock antenna, can capture at most half a dozen planes.
    Will build an elevated outdoor antenna when it's warmer. Should catch tenths of planes.

  13. Like
    tripwire reacted to cubeberg in What are you doing right now..?   
    Generating gerbers for a super-secret project  @@bluehash knows what I'm talking about - unfortunately the rest of you will be out of the loop for a bit!

  14. Like
    tripwire reacted to triqqor in TI Innovation Challenge - India   
    This is the link to a video demo of my Team's project for Phase-1 of TI Innovation Challenge - India Analog Design Contest.
    We managed to come up with a fully working Indoor Navigation System using Visible Light Communication. 
    Do take a look and give me your feedback.
    Kevin Jerome

  15. Like
    tripwire reacted to jpnorair in Ideal RF PCB stackup   
    There are many ways to get a good result, but components cannot be inside the board, and vias add reactances, so we need to find ways to put the traces on the outer layers.  Fortunately, there are ways!  ST has a nice app note, I think it covers pretty much everything.  
    The main thing you need to think about is the fact that the traces on the board can act as antennas if you do not design properly.  They can also cause impedance mismatch, causing less power to go to your antenna if you don't do them the right way.  This becomes a bigger and bigger problem as MHz gets higher.  For example, at 434 MHz, you don't run into too many issues.  900 MHz, still not too bad, but getting to the point transmission line behavior is important.  1575, 1850, 2450... things get serious.
    To design the traces "the right way" you should design them as coplanar waveguides or microstrip transmission lines, tuned to 50 Ohms.  The problem with a 2-layer board is that the transmission line traces need to be really wide to allow 50 Ohm impedance.
    I searched on google and I found this website with transmission line calculators for coplanar waveguide, microstrip, and slot (you probably don't need the slot part).  I can also tell you a "magic number" -- at 434 MHz on normal FR4, with 0.16mm spacing, with 4-layers, with a ground plane directly below, and with a ground plane around the trace -- the magic trace width is 0.47mm.
    Microstrip Line Calculator
    Coplanar Waveguide Calculator
    Slot Line Calculator
  16. Like
    tripwire reacted to Druzyek in RPN Scientific Calculator   
    This is a scientific calculator I built that uses RPN notation. Features:
    BCD number format with 1-255 places Internal accuracy configurable from 6 to 32 decimal places Two separate 200 level stacks Optional scientific notation Functions: (a)sin, (a)cos, (a)tan, y^x, x root y, e^x, ln, 10^x, log, mod 20x4 character LCD 42 buttons The source code is available on https://github.com/druzyek/RPN_Calculator.

    The interface shows 4 levels of the stack, similar to some HP calculators. While I was writing the code for BCD calculations, I used a console program to test the routines. You can download it from GitHub if you want to test out the functionality: rpnmain_pc.c It will compile for Windows if #WINDOWS is defined or for Linux with the ncurses library if #LINUX is defined.
    On Windows: gcc -o rpncalc.exe rpnmain_pc.c On Linux: gcc -lncurses -o rpncalc rpnmain_pc.c Numbers are stored in unpacked BCD format on an external SRAM chip. I wanted to access this memory using variables but there is no convenient way to do this since every variable requires a function to access it. A simple functions like:
    X+=Y*Z-Q; would become something like this (assuming we are passing pointers):
    RAM_Write(X,RAM_Read(X)+(RAM_Read(Y)*RAM_Read(Z)-RAM_Read(Q)); To simplify things, I wrote a preprocessor program that looks for any variables that need to be stored in external RAM and converts access to them to function calls. External variables are all stored as pointers, so the PC version will work exactly the same with or without the preprocessor. To mark variables as external, #pragma directives are used. These are usually ignored by the compiler if they are not recognized, so they are a convenient way to communicate with the preprocessor. Here is an example:
    //Before processing void puts(unsigned char *msg) { #pragma MM_VAR msg for (int i=0;msg[i];i++) putchar(msg[i]); } int main() { #pragma MM_OFFSET 200 #pragma MM_DECLARE unsigned char text1[30]; unsigned char text2[30]; #pragma MM_END text1[0]='A'; text1[1]=0; puts(text1); } //After processing void puts(unsigned char *msg) { #pragma MM_VAR msg for (int i=0;RAM_Read(msg+i);i++) putchar(RAM_Read(msg+i)); } int main() { #pragma MM_OFFSET 200 #pragma MM_DECLARE unsigned char *text1=(unsigned char*)200; unsigned char *text2=(unsigned char*)230; #pragma MM_END RAM_Write(text1+0,'A'); RAM_Write(text1+1,0); puts(text1); } The trig and log functions are computed using CORDIC routines. This is a very efficient way to compute these functions for processors that cannot multiply or divide quickly. Instead, a lookup table is used with adds and shifts, which are much faster. I was able to speed the shifting up even more by using another lookup table that let me right shift 4 digits at a time. One way to measure the accuracy of calculations is with the calculator forensic found here: http://www.rskey.org/~mwsebastian/miscprj/forensics.htm. After setting accuracy to 24 places arcsin(arccos(arctan(tan(cos(sin(9)))))) evaluates to this:

    The settings page allows the accuracy to be set from 6 to 32 decimal places. With the default of 12, trig functions calculate in about a second. With 32 decimal places calculations take 3-4 seconds. After setting the accuracy, the program finds the largest element in the CORDIC table that is still significant, so that no time is wasted on elements that have no effect on the answer. The settings page also shows the current battery charge.

    When I began this project I wasn't sure how much I could fit into 16kB of firmware space. In the end it grew bigger than this and I had to use two MSP430s to hold everything. Part of this is due to all of the functions used to access external memory. The interface code also added a lot more to the size than I expected but I was able to add checks for most of the functions and add some meaningful error messages.

    My design uses two MSP430G2553s connected over UART. One of them (the master) reads the keyboard matrix, updates the LCD, and manages the interface. The other is connected to the data lines of 128k of parallel SRAM and does all of the calculating. The address lines of the SRAM are driven by two 74HC595 shift registers controlled by the second MSP430. The 17th address pin is controlled by the first MSP430 and allows the program to switch between two separate stacks. Here is the schematic: 

    The keypad is formed from 42 tactile buttons arranged in a 6x7 matrix and read with a 74HC165 shift register by the master MSP430. The LCD and keyboard share the same pins since they are never used at the same time. Here is the layout of the keys.

    The LCD is an HD44780 compatible 20x4 character LCD. It is rated for 5v but the logic works fine at 3.6v. The contrast needs to be close to 5v for anything to show up on the screen, so I used a 555 timer and some diodes to supply around -1.2v to the contrast pin. The result is very solid and clear.
    The calculator runs on four AA batteries regulated by an LM1117 configured to supply around 3.5 volts. To run at 16MHz the MSP430s need at least 3.3 volts. The wiggle room between the two voltages will let me see when the batteries are starting to wear down. By the time the voltage gets down to 3.3v, the batteries will be down to 1.15v or so, which can be considered dead.
    The PCB is made from perfboard. The top of the board contains female headers so that the keyboard and LCD can be unplugged. Part of the board had to be cut away so that it will fit in the case with the batteries. Although it is quite small, I ended up using over three meters of wire.

    The case is soldered out of copper clad. I used a lot of solder on it and it feels very sturdy. I will give it a coat of paint tomorrow before assembling everything.

  17. Like
    tripwire reacted to grahamf72 in Unable to retrieve complete NMEA string from serial communication   
    You have a couple of issues, and you are actually lucky it is working as well as it is.
    Firstly, your buffer is 20 bytes, but you are putting 21 bytes into it. When you declare your array variable "char gps[20]" you are creating a space big enough to put 20 characters. These 20 characters can be addressed with the subscripts 0 to 19. Your last serial line and also your line where you print the characters, you are accessing gps[20] - this is actually the 21st element of gps, which is 1 more than it has been defined to hold.  You are actually accessing data in RAM beyond your array, which is probably one of Energia's global or private variables. You either need to only read up to gps[19], or you need to declare gps to be 21 characters in size.
    Now, your main problem is with the logic with your reads.  You first check to see if there is data available by calling Serial.available().  But if there is serial data available, you then proceed to immediately read 21 bytes.  Serial.read() is not blocking - it will return immediately whether there is data available or not. The trouble is, the MSP430 is much faster than the serial port, so by the time it gets part way through the reads it has finished reading all of the data that is available. Serial.read() then starts returning 0xFF because there is nothing to read, and you fill the last few bytes of your gps[] array with 0xFF's which print as the modified y characters you are seeing.
    You need to amend your logic so that you check if there is data available before every read. Something like the following:
    void loop() { // print the string when a newline arrives: while(Serial.available()) { char first = Serial.read(); if(first=='$') { gps[0]= first; i=1; while (i<20) { if (Serial.available()) { gps[i]=Serial.read(); i++; } } for (i = 0; i < 20; i++) { Serial.print(gps[i]); } Serial.println(); } } } You'll note that I also moved the position of the Serial.println and took out the delay(500) - previously it would output a blank line every half second, by moving it where I did, it only prints the newline after it has successfully received and printed a line of data. The delay was a nasty one - if more data came in during the delay than what Energia's buffer could hold (16 bytes if memory serves correctly), then extra data would be lost.
  18. Like
    tripwire reacted to spirilis in I2C code sending address only.   
    Haven't looked in detail yet from a computer, but IIRC the I2C master expects to see an ACK indicating a slave is present at that address; a NAK during the timeslot after the address is transmitted should cause the transaction to abort.
    Sent from my Galaxy Note II with Tapatalk 4
  19. Like
    tripwire reacted to pjkim in Online game based on MSP430 assembler: microcorruption   
    Saw this on Hackaday. There is a new online game based on hacking virtual MSP430 based electronic locks. In the game you have a debugger to analyze the lock code. Once you understand the code, you enter a password to unlock your prize.
    I program in C and have used the C level debugger but I have always wanted to be able to understand machine level code. This game includes a tutorial to get you started.
    You can find the site at https://microcorruption.com/login
    Could the virtual "Lockitall" be entered as another device that contains an MSP430?
  20. Like
    tripwire reacted to enl in RTFM - Read The Fabulous Manual   
    I will straddle the fence here....
    The TI documentation is much better than par for the industry, with a lot of examples in a variety of formats, and there is a ton of ancillary documentation as well.
    Where the documentation falls short is primarily on the C side. While still better than many (anyone else remember trying to produce useable code forthe 8051 30+ years ago?), there is a lack of straightforward material documenting the C interface. WHen the basic instruction in most tutorials is 'look at the header file', there is a problem. I spend a lot more time than I would like cross referencing between the data sheet, the programmer guide, examples, and the header files, for relatively simple tasks. The first serial code I worte for the '430 took much, much longer than it should have, as the setup for the UART requires accessing several control registers with names that are inconsistant between the documentation in the header files and poorly documented in the device data sheets.
    It is not a game stopper to me. I've been there. But when I don't want to go to Energia or another programming interface that provides extra layers of seperation from the hardware, it does mean that I spend more time trying to figure out the C interface for things that don't match cleanly with the hardware data sheet or are spread out between several data sheets.
    For a beginner, even an experienced programmer, the gap between the hardware docs and getting a working system is daunting. Much introductory material is cookbook with insufficient exposition. Not saying I can do better, but referring to the header files for the compiler isn't sufficient for a begginner, especially when the headers are essentially unannotated (Which constant do I use to set Aclock to the VLO??? Which constants   go with which control registers to use Aclock as the clock for the UART???). A beginner doesn't want to, and may not have the background to, work this out skipping back and forth between three or four documents when the basic concept maybe new.
    I am not criticising. I remember spending days getting an 8051 to talk to a terminal via RS232 (much of which was spent waiting for the devices to erase, verify erase, and reprogram, and tweaking the cross assembler to actually build correct object), but a good guide to the C programmer interface would remove a lot of barriers (annotated with references to the data sheets, etc). I don't have the time ot do it, and am not sufficiently expert in the details of the '430, either. Maybe it could be built in the compilers forum by community in a document-the-API thread? Or as part of the tutorial thread?
    Edit: fixing the worst of the typos
  21. Like
    tripwire reacted to zeke in RTFM - Read The Fabulous Manual   
    This is a community of techies that are working on a diverse range of projects daily. We fight many different battles on our quest to succeed with hardware and software.
    Together, we share our hopes, dreams, expectations, frustrations, losses and wins so that we feel like a community. A healthy community shares with its members so that it lives together, grows together, learns together, fails together and succeeds together. That is a thriving community.
    I think the problem with the newbies is that there is so much information out there that it is easy for them to become overloaded. The result is confusion.
    Most people don't get what they want because they don't know what they want.  They are confused which causes inaction which causes stagnation which causes frustration, discouragement and sometimes depression. Their questions indicate that they are frustrated and that they are stuck mentally. They are asking for a reset on their thoughts "What do I really want?"
    So, in my opinion, instead of RTFM'ing them, it may be better to start asking them questions. Then they will begin to unravel their minds and expectations until their thoughts become less confusing and frustrating for them.
    I know that TI puts out a boatload of documentation. It's hard to find a specific detail in that boatload of details especially when you are new to it all and you don't know how to effectively search it yet.
    When educating someone, the pattern I try to follow is this: teach, rebuke, correct then training. All with a lot of patience.
    1. Teach the knowledge so that the student becomes aware of what (s)he doesn't know
    2. Rebuke them for their belligerent misunderstanding i.e.: identify the ignorance and fill it with knowledge
    3. Correct them for their misunderstanding i.e.: the simple misunderstandings "No, an AND gate doesn't act like that. *Remember* what I said earlier?"
    4. Train them. i.e.: Practice, Practice, Practice!!!!
    Patient unraveling of their confusion using questions, I think, is the correct response to your question. Rebuke is not.
    What do you think?
  22. Like
    tripwire reacted to greeeg in 120 LED Ring Clock   
    Hey, It's been along time since I've posted. but I've been keeping busy with uni and working on some cool projects for the last year.
    This is something I'd like to share with you guys, it's not finished yet but the hardware is more or less complete. It is an RGB LED ring clock.

    The clock is comprised of 2 rings of 60 LEDs each. the LEDs are WS2812 parts, which include a built-in driver.
    The PCB is one of the interesting parts of this clock. I designed the board in altium as a single 6 LED segment. and then left pads at each end to allow them to be soldered onto another segment.

    Using seeed's 10pcs PCB program I was able to create the full ring.
    Currently I am using a MSP-EXP430FR5739 board to drive it, using some very in-efficient assembly code that requires a 20MHz clock.
    I'd like to optimise the code to use an internal SPI module? or timer to bring that clock speed down.
    Hopefully also design a control segment with LEDs on one side that could replace one of the current segments in the ring.

    Edit: I've built up a simple controller based on the G2121. yes, 1kb Flash, 128b of RAM!
    I decided to test my asmebly skills and use naken430 the msp430 assembler. Here is my code
    I also added a ring of perspex to help difuse the LEDs
    Here is a video of the clock in action.
    edit: 06/03/14
    Version 2_02!
    Major differences:
    "double" so you need only 5 pcs to make a full ring, the pieces fit in 5x10cm Uses new 4 pin WS2812b parts
    PCBs arrived, been tested and is functional, but has some very small issues.
    Known Errata:
    Doesn't account for very small milling tolerance, means small gaps at joins No silkscreen for LED footprint, only shows orientation Edge connectors a few mm from the edge. Vias connecting to pour have star connections, should be direct connection Thin soldermask trace around OSHW logo is to thin 1 LED under OSHW logo isn't concentric with the rest of the LEDs (<1mm off)  
    There is also a special controller board in the mail, this will be tested and documented when it arrives.
    edit 2/06/13
    Please see this project for lot of photos and additional information about version 2_02
    Version 3!

    Boards have been designed, and I have some prototypes on the way. Designed mainly to upgrade the MSP430 used in the last design to a more capable one.  Boards arrived Some small errata found, pads to small for regulator, JTAG pins in wrong order. New board has been design to fix these issues. There is a tindie page where you can register any interest in buying.
  23. Like
    tripwire reacted to mochouinard in HD44780 LCD Library (16x2 and other models)   
    Actually, I wanted it to be that way. And wont be changing it
    All MSP430 program are REALLY small anyway, there is really no need to shorten the name of functions and variable. I do work on million of line of code software... And in those shorter name for some stuff that come few thousand time are useful. But in this case, it doesn't. You will can run out of flash within a few minute at typing even with those long name anyway...
    It actually welcome to have longer descriptive information for function name. The goal was not just to make it work, but also provide details information for all the configuration option. Even option that had was set by default, I created define name for it so it clear what information is used. It not needed to use them, but it make it clearer for people starting with it to understand what going on.
    And by that, the code I made can read alot like the datasheet of HD44780. I used the same time range specified, the same name for the different function you can call... I've actually decided to write it this way because other people lcd lib were not written this way and not functional, and what they did didn't fully match the datasheet... So it was hard to understand what they did wrong.
    My goal was also to keep the footprint small. So compiled with mspgcc, the size is 420byte. Lot of optimization is left to be done, but I'm ok for the moment.
    It not perfect, but does the job for me and is a much better design to actually compare with the datasheet.
    But what great, is everyone can provide their own flavor here I did this for me and to help my dad (who had issue with current people code especially because they just seem to do something but with no flexibility / details of what they are actually doing).
    There is things I don't like in my code rightnow, and the primary one is the fact you need to edit the .h to change the pin / port usage. I need to find a memory efficient way to make it configurable from the main C file, maybe by using a structure... Anyway not sure yet on how to do that part.
  24. Like
    tripwire reacted to jrychter in I2C master using the USI module: a tiny library   
    I've written a tiny library that implements I2C master functionality on MSP430 devices that only have the USI module (for example, MSP430G2412 or MSP430G2452). It's small, simple, works well for me, and might help others in their projects.
    Blog post at http://jan.rychter.com/enblog/msp430-i2c-usi-library-released
    Github repo at https://github.com/jwr/msp430_usi_i2c
    Have fun!
  25. Like
    tripwire reacted to pjkim in Members will now be warned for incorrect post content format.   
    I am in complete agreement regarding preservation of links. It is very frustrating to find a post on something you are working on to find that the links have been lost to "link rot." One thing that I don't agree with is websites requiring you to login to see attachments. I understand that will force people to register for an account but that inflates the userbase with people who have little interest otheriwse in the website. If they have something to contribute or want to post questions, they have other reasons to register and selects for a more active community of users. Just my two cents.
  • Create New...