greeeg
-
Content Count
561 -
Joined
-
Last visited
-
Days Won
53
Everything posted by greeeg
-
@@Caesar I've actually just been doing something similar, I've been working on a simple fw_updater for use with AVRs over USB CDC. The basic requirements being needs a simple GUI. Assuming you have a good grasp of programming, you can try writing your code in visual C++, The .net framework provide easy tools to develop GUI's. (I'm assuming you're on windows) Here is a short video series I found that walks through how to make a basic Serial Transmit/Receive GUI application. Otherwise You could always look at processing, It's probably the easiest/fastest way to get a GUI to communic
-
@@sven222 121.1 bpm is not particularly fast for the 32KHz crystal. Every second a timer clocked by the 32Khz crystal will count 32,768 times. We can work out how many clock cycles the timer will run for to achieve a 121.1bpm output. 121.1 [beats per minute] / 60 = 2.018 [beats per second] Clock cycles = 32768 [cycles per second] / 2.018 [cycles] = 16,235.177 cycles. Now we can't set a timer to 0.177 cycles. so we'll round down. CCR = 16,235. Now rounding introduces error, lets see how big this error is by working backwards. 32,768 / 16,235 = 2.01835 Hz 2.01835 * 60 = 12
-
Sorry, I actually thought I was linking to the much longer article the Jack wrote. That one must have been an earlier article. http://www.ganssle.com/reports/ultra-low-power-design.html This goes much further in depth, with some actual long term results. Some good stuff, including some hidden traps, like current draw from cheap decoupling caps.
-
This is one reason I love working with the sharp memory LCD. You can see the circuits physically running, I'm assuming its because of how they're made inside the liquid crystal display. @@chicken Can you see a visual contrast difference when using VCOM vs not? Off topic, But an interesting read discussing battery life from CR2032 cells. http://www.embedded.com/electronics-blogs/break-points/4429960/How-much-energy-can-you-really-get-from-a-coin-cell-
-
@@Lacto Yes, Once one block has been written it will start writing to the next one. That's good to hear that you're application will work with these limitations, However most projects I've seen with FatFS, including my own experience, Just spend a few extra dollars on a larger MCU. So it may be hard to find many examples. The Petiet FatFs library is actually a very well structured and documented library. http://elm-chan.org/fsw/ff/00index_p.html (There is some example application code at the bottom of this page) I would recommend reading the example code for the generic example.
-
@@djarami Interesting. It sounds like you might be connecting to the Debbuggers UART, not the Application UART. For reference, I was unable to get any of my Launchpad G2's to work with their Application UART channel. ( I'm on windows 10. LP's: 2x v1.5, 1x v1.4, both bought early ) When I've tried to connect every application; from putty, Arduino, to CCS's built in terminal all seem to freeze up until I unplug the LP. The Debugging on the larger Launchpads is much better, I used jumpers to bridge across, everything worked fine then.
-
@@djarami I took a look at your code changes. Seems that you have fallen into a rookie mistake. The original code made use of ACLK, (with a 32kHz crystal) You want to use the code without an external crystal, so you've switch the code to use the internal 1MHz DCO. running into SCLK. Unfortunately the LPM3 disables this clock source, since it uses more power than ACLK. So you need to alter the sleep mode to LPM0, which just disables the CPU. __bis_SR_register(LPM0_bits + GIE); // Enter LPM0 The code is working on my bench with this one modification, when you press 't'
-
@@Lacto, You are right, petietFS does not NEED a sector buffer. (requiring 512 bytes of RAM.) However be aware that there are many limitations due to this restriction http://elm-chan.org/fsw/ff/pf/write.html Cannot create file. Only existing file can be written. Cannot expand file size. Cannot update time stamp of the file. Write operation can start/stop on the sector boundary. Read-only attribute of the file cannot block write operation. These are some serious limitations. Especially for a datalogger. So while it IS possible, it's not without it's limitations. A major disadvantage
- 5 replies
-
- 1
-
-
- #SD
- #MSP430G2553
- (and 1 more)
-
For completeness, here is the link that should have been in the OP, http://www.xanthium.in/RS485-communication-using-MAX485-and-MSP430-Launchpad The tutorial on your site looks well written and has a wealth of information. I suspect the link is missing because new (under a number of posts) cannot post links to reduce spam. However, like @@yyrkoon, I have some concerns, Why post an identical topic 5 times? This post does not add any additional information, infact because the link is missing there is really no information. Your original website post was back in June... this just feels l
-
Looks like TI have restocked their supply. @@titof49 Digikey is showing supplier stock. and the TI store while not listing the product individually, enables you to add the combo SensorTag + debugger to your cart. https://store.ti.com/CC2650STK-DEBUGDEVPACK-SensorTag-Debug-DevPack-Bundle-P46544.aspx Update, the store doesn't seem to let you checkout with it in the cart.
-
@@Fmilburn Yes ISR's should be kept short. But as @@igor has already pointed out it's to do with execution time, not necessarily number of lines. The main things to avoid are function calls, blocking functions (delay_ms()!!? (some people do do this....)), or potentially large or unbounded loops. The idea behind the state machine is that you can change the behavior of the timer interrupt, (waiting for the button to be held down, or waiting with the LED on.) and it really doesn't take that much execution time at all. Better yet, you can easily determine the worst and average execution ti
-
Hi @@Jake, I've answered your PM here, so that others can benefit if they have similar problems. From what you described in the PM, you're still working on this problem. I have tidied up the code you sent me and added a state machine into the interrupt to handle the logic. These are two states Waiting for a button held continuously for over 2 seconds Waiting for 60 seconds with an output held high. This code has been tested on my Launchpad G2331. let me know if there are areas you don't understand. #include <msp430.h> #define LEDR BIT0 #define LEDG BIT6 #define BUTTON BI
-
@@dasnny Unfortunately the Energia Library functions don't seem to be able to achieve this. However you should be able to enable a timerA module clocked at 32kHz to generate a ~70Hz PWM. 32,768 / 70 = 468.11 Choose period to be 468 ticks. (CCR value) Actual PWM freq = 32,768 / 468 = 70.01 Hz Of course this can create a change on a pin, meaning the change is at 70Hz, but would create a 35Hz square wave. Select a tick period of half to achieve 70Hz.
-
@@Rei Vilo I think the MSP432 MIGHT be compatible, They're both xds110 debuggers. You need an extra cable though IDC 10pin 0.05" dual row.
-
@@titof49 I noticed this recently too. Looks like TI sold out. Shop around one of their distributors? If it's really urgent buy a standard XDS100 debugger, From what I've read this should be compatible. (only 4x the price.) http://www.digikey.com.au/product-detail/en/TMDSEMU100V2U-ARM/296-37054-ND/3431136
-
Your timer currently count to CCR0. CCR0 is set to 49,999 When your timer reaches 49,999 an interrupt occurs. and the next timer value is 0. CCR1 is set to 24,999 When the timer value reaches 24,999 it will cause an interrupt. Hence you're leds blink at the same rate. It takes the timer the same amount of time to count from 0 to 49,999 = 50,000 ticks and 25,000 to 24,999 = 50,000 ticks. How do you fix this. I would recommend the following. (but there are multiple ways.) Set TA0 to run in continuous mode, instead of up mode. (Your code comments mistakenly say continuous, but
-
Can you tell me which processor you are using, it will make this explanation more specific. Why we need to check TA0IV. First, T0A2 interrupt does not exist. This is the purpose of TA0IV (Timer A0 Interrupt Vector) Interrupts require a fair amount of hardware (priority encoders, etc). To keep this manageable, the MSP430 are conservative with their interrupts. Lets look at the interrupts inside a MSP430G2955 There is only 15 unique interrupt vectors! Note that the CPU in the G2955 supports 32 interrupt vectors. Let's look at it's timer. Timer0_A3. This means that this timer c
-
This has been brought up a few times, when msp430-elf was initially released. A flag that generally reduces code size. -minrt There is also some information here: http://forum.43oh.com/topic/1603-mspgcc-output-binary-sizes/ Energia will use the gcc-sections commands to remove untouched functions from the final binary. If you're not specifying them with your msp430-gcc-elf build then you will get large code sizes.
-
@@maelli01 This is how I powered my '6 pin MSP430'. http://blog.greg.so/2012/01/making-6-pin-msp430-value-line-device.html
- 1 reply
-
- 1
-
-
I believe that if you are using a different debug server version, the firmware will be updated every time you switch between the two. This isn't exactly seamless. Occasionally it will fail, and you need to retry a few times before it will work. If you've ever used the pickit3 this operates in a similar way (different firmware for different IC families) But is entirely seamless. The only thing the user notices is it takes longer to connect the first time. One fix is to only use Energia with one set of launchpads, and CCS with the others? I have different versions of libmsp430 scatt
-
@@MSPLife The only other thing I can think off is regarding your initialization of CCR's TACCR0 = 50000-1; TACCR1 += 25000-1; Suppose TACCR1 is not initialized to 0 on reset. Or is TIM_TRIG_ADC_CFG() is called multiple times. If TACCR1 > TACCR0 Since you reset the TAR when it reaches CCR0, then it will never reach CCR1. I would suggest changing these lines to TACCR0 = 50000-1; TACCR1 = 25000-1; This might not produce the desired result. Both the interrupts will fire at the same rate, just offset by half a cycle. This is how your original code operated. A0 IFG _______^__
-
@@chicken I'm interested in the design decision to add the RC feedback into done. From the sharp memory LCD I can see that they show pulses into EXTCOMIN, however since it appears that it's the rising edge that cases the VCOM inversion. They also don't specify a maximum pulse length... The TPL5111, according to the datasheet will automatically de-assert the DRVn pin after 50ms. When in continuous mode. I can see that your RC circuit reduces this down by orders of magnitude, but also consumes a comparatively large amount of current. If the system will work with a 50ms pulse length won'
-
@@MSPLife Have you debugged the operation of the interrupts? I've assumed you are using the G2231, shouldn't really matter thought. My thinking is that since TIMER0_A1_VECTOR is a shared interrupt you generally should be checking the corresponding Interrupt Vector, to determine the exact source of the interrupt. void TIM_TRIG_ADC_CFG(){ CCTL0 &= ~CCIE; CCTL1 &= ~CCIE; TACTL = TASSEL_2 + MC_1; // Set the timer A to SMCLCK, Continuous TACCR0 = 50000-1; TACCR1 += 25000-1; CCTL0 |= CCIE; CCTL1 |= CCIE; // Clear the timer and enable timer interrupt __enable_interrupt(); }
-
@@chicken You should be able to use a newer launchpad with the energy trace features. (or a FET430.) to measure the current! That should have the bandwidth to show the current during the pulses. Ironic that the RC circuit uses more current than the IC itself. You could daisy chain two TPL5111's to create a square wave 50% duty cycle pulse train right? I understand this increases the BOM cost more than 1 RC pair, but if we're going for ULP....
-
I believe it's a trade-off and does depend on your application. On the MSP430 Series I've never used driverlib. Frankly the peripherals are easy enough to understand and use with a few direct accesses to memory mapped IO. But I have used it on the MSP432 and some PIC32/PIC24 projects. It can speedup development, if it's well documented and you understand the benefits and limitations. driverlib will generally create more readable code. But does come with an overhead on small MCUs for example toggling a pin on an arduino using digitalWrite( !digitalRead(PIN)) yeilds terrible performance
