Jump to content

enl

Members
  • Content Count

    345
  • Joined

  • Last visited

  • Days Won

    22

enl last won the day on June 18 2017

enl had the most liked content!

About enl

  • Rank
    Level 2

Profile Information

  • Gender
    Not Telling
  • Location
    Northeast
  • Interests
    Machining, welding, electronics, woodwork, making, education, tools, toys

Recent Profile Visitors

1,909 profile views
  1. The short, two line tall, window at the bottom lists the errors. Can you expand that and show the errors?
  2. Lets work through a few things here... Frequency is the number of complete cycles per second. This can be determined a number of ways. The scheme you seem to be going for is to time a cycle. This would be from an edge to the next instance of the same type edge- rising to rising, for example. This will produce a count that is a time. The base unit may be microseconds at a 1MHz clock, but it is a time- the period of the signal. The frequency unit will be the reciprocal of this. Lets say that the count is 140. This means that 140microseconds (140E-6 seconds) lapsed from one rising edge to the next rising edge. The frequency will be 1000000/140 (1E6 clocks/second / 140 clocks to get the unit 1/second, or Hz) = 7143Hz. That's the concept. The code you have does not do this. When the interrupt occurs in CAPture mode, the count in the timer is copied to the CCR. This is what you need to pull. As long as this has not rolled over, the count tells you the period of the measured signal. You never read this. You have: Result += StoredCount; // Store accumulated count in Result StoredCount = 0; // Zero StoredCount TA0CTL |= MC1; // Start timer TA0CTL |= MC0; // Start timer StoredCount++; // Increment StoredCount This has several issues, including: you set storedcount to zero every interrupt, then increment it. The net result is that the value will be 1 at the end of the handler, every time, and 1 when the handler is entered, every time except if it has be set elsewhere.. Also, you generally would not want to stop and start the timer in the handler like this. The external signal goes on. The timer stops. The acquired time will be wrong. An outline of what you might do (copied directly from the documents for a system I implemented last year. The system is safety critical in a manufacturing plant and was reviewed and tested exhaustively) Up count the timer interrupt on overflow: this is so you can detect the overflow and deal with it, either with an overflow count or as an out-of-range. This interrupt is hardware supported for just such a purpose Interrupt on capture: grab the value of the CCR and store it in your volatile. Exit sleep mode so your loop in main can grab the stored value and do it's thing. If counting overflows, the overflow counter gets copied at the same time, and reset. No need to reset the CCR. You don't look at it anywhere else. You do NOTHING on overflow except increment the overflow count. There are several ways to go about maintaining the counter. You can reset it when the CCR capture occurs, or you can let it free run, and the ACTUAL value to use is the difference between the current capture and the prior one. There is a little more work if you are counting overflows. Resetting in code introduces synch error. If it is not supported by hardware- I can't remember (and am too lazy to look up) if the 2231 can do the reset of the timer count on CAPture events- the differencing option is the better choice.
  3. Several things here: where are/what are the declarations for the variables you are using? The types matter here. You seem to be using the capture mode, but you are not ever pulling the captured value from the TACCRx in the interrupt handler. A capture event copies the value from the count register to the CCR Please explain a bit about what your method is here. (as an aside, much of the documentation you have is not useful- it should express what the statements mean in terms of the solution. For example: "CounterValue++; // Increment CounterValue" What does countervalue represent? What are you counting? The next line, same. and so on. Good docs make it a LOT easier to help) As to the questions: What do you mean "make overflow work"? "Can i make the frequency meter up to 10Mhz". Sure. With high enough system clock. It will have poor resolution at the high end if you are doing it by timing from edge to edge (what capture mode will let you do). At low frequency, this is very effective. At higher frequency, it is better to count edges for a fixed period, but that needs to be done with hardware counting, as the interrupt latency, even at 16MHz system clock, will limit you to less than about 1MHz counting in software, and that is tough to hit. This would require a device that has two timer modules (one to time an interval, the other to count using INCLK (TASSEL_3-not available on the g2231) "Can i somehow check if the code is working" Easiest if you find a means to provide a test signal to the input pin. There are a lot of ways (555 timer circuit, leach a 32768Hz signal if that is available on board, 50 or 60Hz grid frequency with the appropriate signal conditioning, a phototransistor in front of a flickering light source, like a PWM'd LED,and so on), but without knowing more about what you have available, I really can't tell you any more than that.
  4. To follow up with @Rei Vilo the actual errors are important here, as is the processor (though I would presume G2553 given where you put the question). Also, the interface module you are trying to use (I2C I would hope, since the MMA8452Q only communicates with I2C), what header files you included, what processor you selected in CCS project setup, and so on.
  5. Yes. That will cause trouble. Energia sets up the WDT itself. It is used for timekeeping to support the time functions. DO NOT disable it for Energia. If you are NOT using Energia, you (probably) need to disable the WDT, periodically kick it, or set it up for your application if you will use it as a standard timer. The purpose of Energia, or Arduino, is to provide a layer of abstraction between tasks like device setup and processor initialization and the programmer so less experienced users don't get buried in the details, as well as provide a suite of utility functions and classes that abstract the hardware in useful ways. The price paid is that some modules are populated by system setup and become unavailable for explicit use. The WDT is one. Most users will not miss it.
  6. If I recall correctly: I do not think you need to do any watchdog setup with Energia. The Energia core sets it up as for use as the timebase for time functions. Any changes you make to the setting outside the Energia envelope will cause issues. See:
  7. They are not connected to the relay. They go directly to the load. To turn the load on or off, you need only interrupt one current carrying wire. You usually want to interrupt the HOT lead, so when the switch is off, no part of the controlled device presents a voltage that is a hazard. (This, of course, does not consider parts that store energy, like capacitors) (If you have further questions, ASK. Better to ask than someone get hurt or property get damaged. But please do tell us where you are located. The systems in the US/Canada, UK, rest of the EU, India, etc, all differ, and often differ within a single country based on region) Background: The underlying assumption here is that the source has one line that is essentially at ground (earth ground), and the other is HOT, meaning it it at 120V or 240V (AC RMS) relative to ground. In the US and Canada, this is ensured by connecting one wire at the service entry to the earth ground (this is called BONDING), such that one current carrying wire is within a fraction of a volt of ground (called the NEUTRAL-- formerly called GroundED in the US), the other is 120V RMS relative to ground. Similar systems are use in much of the world. For example, in most of the EU (and UK, which may soon be a separate entity), one stab is grounded at the entry, and the other is therefore 230V relative to ground. When there isn't a stab for the earth ground connection (safety ground), there is some provision in all modern systems. If I recall, the common one in the EU is the bracket (clip?) on the perimeter of the plug. The intent is that the EARTH GROUND (safety ground) only carries current when there is a problem, and that the safety device (fuse, circuit breaker, ground fault interrupt) should interrupt the circuit when that happens. Since the NEUTRAL current carrying wire does not present a safety issue, as it is near or at ground potential, we let it be. The GROUND (safety ground) conductor should NEVER, EVER be interrupted while EITHER THE HOT OR NEUTRAL is connected, which is why modern plugs have a longer stab for this. It connects first, and disconnects last. The line that should be switched is the HOT, which is not at or close to earth ground potential. I could (obviously) go on about why it is done this way, but I will cut it short by saying that it is the easiest way to minimize the number of ways that a fault can occur, and make it practical to protect against faults. ********************* Public safety message: bond your grounds properly. When using a portable generator, ALWAYS use a ground fault interruptor, be sure the ground is connected to a good ground tie (driven rod, metal building frame, etc) and the, when powering a building or gear in a building, tied to the building earth ground bus.
  8. Presuming you are trying to switch the power to an AC-powered device, such as a lamp or small appliance: You generally want the COM and NO (normally open) contacts. When the relay coil is not energized, these are OPEN (disconnected) so the load will be off. If you want the load to be ON when the relay coil is not energized, use COM and NC. If you want to switch between two loads, the loads go on NO and NC, and the source goes to COM. In general, the HOT current carrying wire goes to the relay COM, and the NEUTRAL (grounded) is left unswitched. The EARTH (safety) ground is not involved and should be passed straight through to the EARTH ground lead of the load, if it has one. The color conventions vary in different parts of the world, and not all commercial cords follow the conventions-- they are usually enforced in fixed wiring such as in a home of commercial building, but cords for plug-connected appliances are often not compliant. Several of the conventions are in messages above-- for example, in the US and Canada, the NEUTRAL conductr is WHITE insulated, and the screw or terminal on many devices like outlets is silver, the HOT conductor is BLACK (by preference. RED, BLUE, or any other distinct color than green may be used) and screw or terminal is often brass/copper color, and the EARTH (safety ground) wire is GREEN. The BLACK (or equivalent) should be switched.
  9. This is why I said it is odd, but I have never tried it myself with devices that are so closely related. I don't know if it actually was programmed with the wrong device specified, but I can see no reason there would be damage IF it was programmed this way.
  10. Odd that it programmed without an error due to the incorrect device. I would figure that there shouldn't be any issues, though. (this may not be clear.... sorry) The device selection for CCS gives the compiler information to select the device specific header file (which is a big part of information about what modules are available), as well as memory size and layout (so the compiler can do the allocation appropriately and know if there isn't sufficient memory-RAM or code memory- for the build). If you had tried to use a module that isn't available in the 2453 or the build needed more memory than the 2453 has, build would fail (probably). If you didn't, the devices are the same in all meaningful ways (address space, peripheral addresses, and so on. In particular, the code protection and JAG lockout) Apparently, there isn't a check that the device is what was specified.
  11. To elaborate: The MSP432p401r has two headers (J8 and J102, both being 5X2 pins) next to a row of ten jumper blocks (labelled GND, 5V, 3V3, ... TDO, TDI). The jumpers bridge the dashed line that separates the programmer/debugger side of the LP from the on board MSP432. If you remove the jumpers (ALL ten of them,) the on-board MSP432 will be completely isolated from the programmer, and J102 can be used to program an external unit. See sections 2.3.1 and 2.3.4 of http://www.ti.com/lit/ug/slau597f/slau597f.pdf That depends on how many units you need to program. For small numbers (tens to low thousands), the LP may be sufficient, if the target is designed to make it easy (accessible connector, no pin conflicts, and so on). For larger numbers, batch programmers are available. You still need to provide the appropriate interface in the target for this, and even of the units are flashed before the boards are made up, it is good practice to have a way to re-flash if the firmware is updated.
  12. I don't believe the FR2355 has timerA modules. The diagram at http://www.ti.com/product/MSP430FR2355 shows only four timerB modules
  13. enl

    LCD for MSP430G2

    slac467 zip archive at www.ti.com/lit/sw/slac467i/slac467i.zip has a number of examples (IIRC, there are several SPI, I2C and asynch serial examples). slac435 is the sample code for the launchpad, but all of the samples use timerA0 and software, rather than the hardware serial. It has been so long since I built my toolkit, I can't recall which samples I stole from (I just ref'd slac467 and slac080 in my docs) THere are resources on this forum like There are a lot of examples around the web, such as https://www.embeddedrelated.com/showarticle/420.php Definitely see slau144 section 15 for full detail of the USCI block.
  14. enl

    LCD for MSP430G2

    Depends on the size you want (physical and lines/chars per line), but there are a lot of options. I have used a numbers of them, including these in the last 6 months: Parallax 27977 2 lines X16 chars (pricey-- about $30), which is 5V supply, but the serial functions ok at 3.3V. Noritake GE256X64B-7032B 256X64 pixel (currently on clearance at Noritake site... about $15) A couple from Adafruit that appear to be out of stock (a 20X4 and a 16X2, using the HC44780) Several models of Noritake VFD's There are a ton of models available from the usual places for less money, most with the similar knockoff controllers, of which I have used few, but can make no recommendations. On the launchpad, I generally use lightly modified sample code from the TI samples for conventional (asynchronous) serial, rather than a full library. I can post some snippets if you can't find anything. You might also want to take a look at Energia.
  15. Rei Vilo hit the main point I will ask WHICH blink example you are referring to. There are a number of them. Background: the basic structure is that you turn on the LED, have a delay, turn off the LED, and another delay. What you did include your message does not show the delay... it is what turn on hte LED. There is a delay somewhere, and that is where you want the random value. You may want to restrict the random value to a certain range to keep the random blinking reasonable in appearance.
×
×
  • Create New...