Jump to content
43oh

bobnova

Members
  • Content Count

    161
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by bobnova

  1. I read through a couple of your linked articles, they are going to be useful to me. Thanks!
  2. It's triggering, it's just exiting soon enough that the debug doesn't show it being in the loop. I changed the code slightly to have P1_0 output to an LED (red on the launchpad) and toggle every time the interrupt fires: #include <msp430.h> #ifndef TIMER0_A1_VECTOR #define TIMER0_A1_VECTOR TIMERA1_VECTOR #define TIMER0_A0_VECTOR TIMERA0_VECTOR #endif volatile int i = 0; volatile int digit1; volatile char value; void main(void) { WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer if (CALBC1_1MHZ ==0xFF || CALDCO_1MHZ == 0xFF) { while(1);
  3. I'm not sure what you mean by the frequency of the interrupt. The interrupt should run every time the input signal changes in the direction specified by P1IES. The interrupt will run even in LPM4.
  4. I don't think you'll be able to get the interrupt frequency in LPM4 as all the clocks are stopped. If you stay in a power mode that keeps the clocks running you can set up a timer to keep track of time for you. I'm slowly working my way towards getting that figured out properly, not there yet though. CPU clock frequency is probably the default (1MHz?) if you haven't changed it. Alternatively you could have the Port1 ISR toggle an output pin and then look at that pin with a scope to get the frequency, if you have a scope. If you don't have a scope, I recommend getting a scope.
  5. Yeah, you've done what I tend to do, counting from the right you need to include pin 0. You're polling P1_3. That's the major downside to doing it without digitalRead, confusion about 0.
  6. Oh yes, you can get far more precise and a higher or lower overall frequency too. That's datasheet / UserGuide material though. I did some playing with copy/pasted code a while ago but don't remember enough to help you much. The stellaris / Tiva-C boards have PWMWrite in Energia, which allows you to set the resolution, frequency and duty cycle in one go (takes a while and causes glitches, though). Sadly the 2553 doesn't have that function in energia.
  7. Fixed the code (I think), thanks for the heads up. I'd only used it with single pins and no ==, just "if (this & that)", which works fine as I guess it changes the priority. For giggles I tested on a launchpad and you're definitely correct. Now I know. That'll save me some serious headaches in the future I bet. I've been exploring hex notation a little bit, but don't have an intuitive grasp on which bit positions are what hex numbers and such. You're the second person to suggest I dig deeper into using hex in the last 18 hours though, so I probably should! I'm just dragging myself ou
  8. I don't know if there is an equivalent, then again I didn't know those existed in the first place. I've been learning the direct port manipulation methods. On the speed end of things, I tested a G2553 at 16MHz with my scope. This sketch: void setup() { pinMode(P1_0,OUTPUT); } void loop() { digitalWrite(P1_0,HIGH); digitalWrite(P1_0,LOW); } Toggles the pin at ~119kHz, 8.39
  9. Make an unsigned char variable (let's call it pinData), when the interrupt fires make the first line "pinData = P1IN". Then you can disable interrupts and examine the state of the port at the moment the interrupt fired at your leisure. Or make a variable for each of the digits, first firing grabs the first one, second firing grabs the second, then disable interrupts and look at things. If you disable interrupts inside the interrupt it should return to the main code in the spot spot it was when the interrupt fired. That's my understanding anyway.
  10. Based on the code I don't think the interrupt is happening, the main code should sit inside the while(1){} and never leave to turn the LED back on. Just noticed this, been reading datasheets and such, you've enabled the interrupt on Port2 and have an ISR aimed at PORT1_VECTOR, I bet that's the issue. The interrupt happens alright, but it doesn't trigger any code. Change it to PORT2_VECTOR and I bet it'll work.
  11. PC SATA power connectors for power, routed to marked power rails for 3v3, 5v, 12v, ideally with PTC fuses inline for overcurrent protection. Better, tighter, connections. FTDI would be nice.
  12. The biggest differences between the two styles mentioned in your first post, based on my experimentation with both of them: 1) The (oldRead+newRead)/2 uses far less RAM than holding 16 samples in RAM. 2) The 16 samples and divide by 16 gives you the average of the last 16 samples. 3) The (oldRead+newRead)/2 gives you the running average from the beginning of time till now. It will never catch up completely to now. I'd use old+new/2 for the slow moving sensors, battery voltage, temp, and o2 sensor. MAP and TPS I think I would go with the first method, as you want to add more fuel now
  13. I'm just barely starting to learn interrupts as well, so I may or may not be useful here. That said, have you tried it with P2OUT = 0; alone in the interrupt routine rather than checking the other pins? That will tell you if the interrupt is firing at least. My experience so far has been that if it's not working I probably made a mistake in anything I typed as 0b01011010 type lines. Or of course in the wiring. I don't see any errors in the code itself, which is the other thing that makes me think it may be the interface between code and the outside world. As a separate note, the dis
  14. Have you updated the EZ-FET firmware on the FR5969?
  15. Might want to check out Dangerous Prototype's "Dirty PCBs" too. 8-12 10cm x 10cm PCBs for $25. 8-12 5 x 5 boards is $14.
  16. When I tried that one the LM4 Launchpad both serial ports became active, but ran at whatever the most recently declared speed was. In the above code they'd both end up going at 38400. Whether that is the case with this board or not I don't know, nor do I know if it was a hardware issue (clock source maybe?) or an energia issue. Both at 38400 should work just fine though.
  17. There we go, that's perfect. Serial.whatever for talking to the computer. Serial1.whatever for the camera. For using software for the computer and hardware for the camera what I was thinking was to remove both jumpers and make jumper wires to attach the softwareSerial ports to the programming section and more jumper wires to attach the HW serial pins to the camera. Hardware for both is easier/better, though. One thing to note on multiple HW serial things is that at least on the LM4/TM4 launchpad they all have to run at the same baud rate.
  18. What I was thinking is write the program and make the hex in Energia, then flash it with Flasher before you send it out so that you can send them the hex and flasher and .bat later. Now that you've found a version of flasher that works after Energia runs the flash, that is even easier.
  19. Is this for devices that are already in the field and expecting the Energia firmware revision? If not, why not just update/flash with Flasher before you ship them out? Then the customer won't be confronted with revision messages.
  20. Can you do a quick re-wire and use the hardware serial for the camera and software serial to communicate with the computer? I don't have a F5529 to test with, but my bet is on it being related to softwareSerial. Not that I've used that, either.
  21. Yeah if you want them to work with it at a low level, the TM4C129 may not be the best choice. Its datasheet is around 2000 pages, and covers only that one MCU. From that standpoint spending more money on something simpler looks more attractive. If it matters to the addon of your choice, the MSP430G2553 and MSP430FR5969 both run at 3.6v rather than 3.3v. Mine do, anyway. It may well not care, most 3.3v devices can deal with up to 4v or so before they flare and die.
  22. I wrote up an unboxing + firmware updating post for the blog of a group I'm part of. It can be found here: http://humboldtmcu.blogspot.com/2014/08/unboxing-and-updating-texas-instruments.html It's aimed at Energia users, as I'm only just barely starting to transition to CCS and Energia is what I used to do the updating.
  23. Given the cost of the boosterpack ($20 and out of stock) plus a F5529 ($13), you might consider buying the TM4C129 Tiva-C Connected Launchpad instead, it's $20 and has native Ethernet, plus a very large/fast microcontroller and a ton of pins. I realize we're on 43oh and it's a Tiva thing, but still.
  24. I definitely recommend laying your hands on an oscilloscope of some sort. It doesn't have to be an expensive, "good", one. A $65ish DSO201 handheld thing is fine, or a similarly priced USB scope. It may not be especially accurate, but it'll be decently consistent and that's good enough for a lot of work. Another alternative is to buy a used standalone scope, mine came from the university of washington and appears to have last been calibrated in 1977. Despite that, it works great and is surprisingly accurate and precise. It was $35 + $35 of shipping. I've never used the sound card method,
  25. That would be ideal for my purposes, too.
×
×
  • Create New...