enl
-
Content Count
346 -
Joined
-
Last visited
-
Days Won
22
Posts posted by enl
-
-
The short, two line tall, window at the bottom lists the errors. Can you expand that and show the errors?
-
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 StoredCountThis 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.
-
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.
-
3 hours ago, BBNOOB said:
When i tried to run the code It came up with errors
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.
-
10 hours ago, dave45 said:
The problems come when I remove the comment slashes from the line, i.e. include the WDT stop line in the compile.
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.
-
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:
-
2 hours ago, Softwaremaker said:
Are you saying NEUTRAL and EARTH are not used/connected into the relay ?
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.
-
16 hours ago, Softwaremaker said:
Sorry for this late jump in here. Can you show me how this is connected from an AC source to the Relay module ? ie . Which wire from the mains are connected to the COM and NO/NC of the relay ?
Thanks !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.
-
4 hours ago, NurseBob said:
My experience with both IAR and CCS is that they refuse to load images to a device when it's different than what the project specifies and they both clearly report it as an error.
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.
-
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.
-
2 hours ago, RahulZ said:
One more point in above solution is with launchpad only as MSp432 mcu is fixed on launchpad
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
2 hours ago, RahulZ said:I can not able to program multiple MSP432 mcu pieces so for this what i need to use ?
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.
-
I don't believe the FR2355 has timerA modules.
The diagram at http://www.ti.com/product/MSP430FR2355 shows only four timerB modules
-
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.
-
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.
-
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.
-
I am sorry that I can't help you with this, but no Mac tho test on. Hopefully someone else will come in with something.
If you find a solution elsewhere or on your own, please follow up here.
-
I'll bite.
Still teaching engineering. and still work as weld engineer (and whatever other label they need) for the same company.
Doing more work on the side. Pumped out about 3K lines of code for a machine control during June and July (and hardware to interface to the existing hardware). Got introduced to a new-to-me form of NDA that essentially makes the two months not exist in my resume. Device used was an MSP430, as it was sufficient and I have them in stock.
CNC'd my lathe (another MSP430... yup I have a pretty big stock of several flavours)
As winter approaches and the temperature today was 5 degrees (40F), I envy where you are. But I would not survive in hospitality. I have avoided it, even in lean times, because I know it would not go well. You have my deep respect.
-
UCSSEL_2 is the selector bit set for the sub-main clock as the clock source for the UCB serial module. I have not looked through the code (and do not use the MSP432 processors) so I I can't give details, and someone else may be able to give you a full answer, but if you see assignments to UCBxBR0 and UCBxBR1, these are setting the baud rate register divider (the BR in the names is for "BAUD RATE").
If no one comes in with more complete information in the next day or two, I can look at the source.
-
I don't have the libs you are looking for, but I would guess that someone may be able to help you in the next day or two. The traffic here has slowed is fairly low these days, but many of the members do check in fairly often. If you don't hear anything in a day or two, I will do some digging. If you find the library you need elsewhere (or find it here somewhere), please do follow up in this thread.
-
22 minutes ago, Oldnotdead said:
If I connect a vm to the reset pin (p2, pin5) I see vcc 3.2v, when I push the reset button it drops to zero and does a reset.
That indicates that the 0ohm resistor is in place, as it should be.
This pretty much leads to the conclusion that either you have an issue with the jumper you are using to ground the reset pin, or there is something really, really weird. If it is something really, really weird, it will make you slap your head with a ball pein hammer when you find it.
One thing to note about the use of a jumper: the stock pin headers on most of the various launchpads I have are suitable for a board connector, but the pins are borderline for a female shell connector on a cable. It seems weird when you first experience it, but the cable terminating contacts require about 1 to 2mm more pin length. In fact, UI need to run a new board for a CNC controller tomorrow, since I used the wrong pin headers (Always double check the components. I didn't realize I had the shorter pin version in the parts rack) and the control connectors are not fully seating, and are working loose due to vibration of the control panel. One of the reasons I still use a wire wrap tool and 30AWG Kynar wire these days.
-
I am presuming that you have the proper ground connection for the various methods you are trying:
Connect a scope probe to the reset pin on the header (P2, pin 5) and push the reset button. You should see the line go from high to low
If not, the pin is not connected to the line. It should reflect the state of the button, but is listed in swru372b as an OUTPUT (tab;l 8 on page 13, and fig 8 pin map) for resetting daughterboards, and though it should be usable as an input based on the schmatic.
What I would guess is not there is the 0ohm resistor R84 that connects the header pin to the line. (see CC3200-LAUNCHXL_SCH_REV4P1-C.pdf, sheet 2, location D2 shows this)
If that isn't it, you got me. I can't see any other way for this to happen (presuming the wire is good, you have the wire connected to actual ground, etc).
-
SInce no other responses have come along, I will get the ball rolling by asking for a bit more detail.
What errors are you getting?
What are you trying to do with the watchdog?
As far as I know (not using the CC32XX series), Energia supports the 3220 launchpad board. See https://forum.43oh.com/topic/13311-connecting-cc3220sf-to-cayenne-mqtt-using-energia/ (Rei Vilo's msg: 6th in the thread)
-
Glad to see you worked it out.
For most standard/common setups, I keep a collection of code snippets, so I don't need to think too hard.
-
There are two answers:
1: Strictly using hardware, you have two independent PWM channels, as long as you aren't using either timer for anything else (the two TIMER_A modules-- timer type A, a 16 bit with counter with a selection of control inputs for counting, output modes, and other options. Other MSP430 devices may include other timer types, such as TIMER_B). There are several pins that can be attached to each for PWM output, but, for practical purposes, they are not independent.
2: Using software, you can have as many PWM as you have output pins, but more than 8 gets more difficult. The max PWM frequency will not be as high as the hardware only solution, and the precicion will be lower, but for many applications, it is quite acceptable. This requires using an interrupt service routine triggered by a timer at the PWM resolution. If you want a PM cycle of 10ms (100 cycles per second) and a n 8 bit resolution (256 PWM pulse widths), you will need the interrupt to trigger every 39 microseconds. This is about the limit for an MSP4302553 at the max clock frequency, if you want to get anything else done, like control the PWM.
I have used this approach a number of times, and have at least one example on this site (8 channel spooky eye controller for hallow'een
). For motor control, this might be quite sufficient, especially if you use a table in memory for control. For a three phase BDC motor, you are likely to be able to use 3 or 4 bit resolution and a PWM cycle of about 500 microseconds. This will give you a max RPM of the order of 18KRPM (300 rev/sec)
As regard to your response to Rei Vilo,: A key skill that anyone working with electronics, microcontrollers, PGA's, and so on, is reading and interpreting data sheets and data books. For a complex device, which the MSP430's are, this is not easy, but is still a needed skill and you will need to do it to complete any project that is not trivial, and a three phase driver is decidedly not trivial. The information for response 1 is directly in the pin map. Response 2 requires experience.
Forum flooded with spam
in Suggestions
Posted
I asked this a year ago and got no response. Most of the spam I have reported has been removed eventually, but sometimes a few days go by.
It appears that this forum is no longer a priority, I would guess, in part, due to the decline in traffic and the MSP430 moving away from the ed and hobby worlds over the last decade as other platforms have moved in. The commercial side of 43oh saw its last update about three years ago.