Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by abecedarian

  1. @@spirilis might be the best one to answer this but I think his was oriented at the NRF24L01+.
  2. After waking up this morning, I put a blink sketch on a G2553 LP in order to emulate the signal a Hall effect sensor or similar might output to the system. I connected that to the 432 and the LED on the 432 toggles on only one edge. So I need to correct myself: "CHANGE" is not working in the sketch I posted above. Must've been an illusion. Anyhow, I tried the two-pin, two-interrupt thing, and kept the G2553LP as a "signal generator"- On the 432: const int encoder0PinA1 = 11; const int encoder0PinA2 = 12; volatile bool Aflag; //////////////////////////////////////////////////
  3. Okay... put something together... a little simplified, but using the EMT abilities... and "CHANGE". One part eschews using Serial for debugging and sets up the "Aflag" variable and configures pin 11 as in input with an interrupt handler using CHANGE, the handler does a "NOT" on the Aflag variable when called, and loop() sets the RED LED to the Aflag state. The other is a "thread" which sets up another pin (12) to automatically turn on and off every 1/10 second. So, create new sketch in Energia and put the following in it: const int encoder0PinA = 11; volatile bool Aflag; void setup(){
  4. A little wasteful of GPIO and code space perhaps, but could you not send the encoder's signals to two pins each and attach rising and falling interrupt handlers / functions to those pins separately?
  5. Won't work. The ULN is on one side of the breadboard, not spanning the gap in the breadboard, so pins 1/16, 2/15, 3/14 and so on are bridged.
  6. @@spirilis or @@energia are the ones most able to address the glitches.
  7. Like the OP code, your code's fadeValue and fadeValue2 do not have any value assigned before entering loop() and being accessed in constrain() functions so are undefined.
  8. @@Derekspeegle - maybe...: const int voltPin = P1_5; const int voltoutPin = P1_7; const int voltoutPin2 = P1_6; float voltage1; float voltage2; float voltage3; int fadeValue; int fadeValue2; // get voltages function void getVoltages() { //Obtain RAW voltage data voltage1 = analogRead(voltPin); voltage2 = (voltage1 / 1024) * 3.3; voltage3 = voltage2 * 5.65; } void setup() { // configure input and output pins as required: pinMode(voltPin, INPUT); pinMode(voltoutPin, OUTPUT); pinMode(voltoutPin2, OUTPUT); // configure analog/PWM output frequency: analogFrequency(10
  9. One thing I see is that during the first pass through loop(), "fadeValue" and "fadeValue2" are being accessed in constrain() functions without having any value assigned to them prior to first use.
  10. Somewhere around 2000 LED's? Anyhow.... What about something looking like a pendulum, hanging either below the ring, or in the center, housing logic and power, with a few LED's simulating the pendulum swing?
  11. Hadn't considered that, but it does state "decoupling capacitance", which the electrolytic isn't part of, no? Even if it were, then a 10uF electrolytic on the USB side should fare well, and that wouldn't affect the electrolytic on the device side...? *edit- Ok, I sort of get it... I think. Too much bulk capacitance on the USB side could increase the current drawn through the USB port in order to charge the capacitors which could cause the USB port to shut down... I think.
  12. What I meant is a single cap on the input side, and another single cap on the output side, both close to the regulator. Like, on the USB side it goes USB > electrolytic > regulator > electrolytic > load, and instead should be USB > electrolytic > ceramic > regulator > ceramic > electrolytic > load. I also, in retrospect, think I was wrong with the value of the caps being 0.1uF and probably should've said 0.01uF for them. A 0.1uF on either or both sides could be used in addition to things though, if needed: USB > electrolytic > 0.1uF ceramic > 0.01uF
  13. Shouldn't there also be a 0.1uF ceramic on both LDO input and output, close to the LDO? ... and a 1nF or so on the !RST to ground?
  14. Welcome! First thing you should do is learn to use the code tag for wrapping code into a more readable block of text. The code tag can e accessed by clicking the button above marked "<>", then paste your code in.... like: #include <Servo.h> //Setup the variables for the HC-SR04 const int trigPin = 3; const int echoPin = 4; // create servo object to control a servo // a maximum of eight servo objects can be created Servo myservo; // variable to store the servo position int pos = 0; void setup() { // initialize serial communication: Serial.begin(9600); // attaches the
  15. @@bluehash - Seems to be working now.
  16. @@bluehash - "Mentions" don't seem to be working now. I was mentioned in another thread and didn't receive notification of it.
  17. @@Marija With an analog input, you likely wouldn't want to set a pull-up or pull-down state. However, with digital inputs, and without setting the input as INPUT_PULLUP or INPUT_PULLDOWN in the sketch or using an external pull-up or pull-down resistor, the input pin will float, as in won't have a default state, and this can cause issues like false or missed triggers. So, if the switch connects to ground when pushed, either set internal pull-up in the sketch or provide an external resistor (10K should work) pull-up to VCC. If the switch connects to VCC when pushed, either set internal
  18. @@Shiv - Okay, I can confirm this behavior on a 432. When "HIGH", the read does in fact take the pin LOW. However, the reverse is not true: when the pin is LOW, the pin it does not go HIGH. The following code was used: int state = 0; void setup() { Serial.begin(115200); pinMode(RED_LED, OUTPUT); } void loop() { digitalWrite(RED_LED, HIGH); state = digitalRead(RED_LED); Serial.print(state); delay(500); digitalWrite(RED_LED, LOW); state = digitalRead(RED_LED); Serial.println(state); delay(500); }I've submitted a bug report to Energia devs: https://github.com/ener
  19. On MSP430G2553 LP, I tried the code below and execution was as expected. RED_LED is set HIGH and its state is read, then the GREEN_LED is set to the inverse. If reading the state of RED_LED flipped it, both red and green LED's should both be either on or off at the same. However, this is not the case, and they are opposite each other. int state = 0; void setup() { pinMode(RED_LED, OUTPUT); pinMode(GREEN_LED, OUTPUT); } void loop() { digitalWrite(RED_LED, HIGH); state = digitalRead(RED_LED); digitalWrite(GREEN_LED, !state); delay(500); digitalWrite(RED_LED, LOW); st
  20. Interesting read. I have a FR6989 launchpad running the default program in temp mode, powered by a 3.6V NiCD cordless phone pack that was charged to about 2.6V. It was connected to the 3v3/GND pins at the lower right of the LP for a few days, then removed for a day so the V would settle, and the jumpers from the ICDI were removed so it didn't power those when running. It has been running continuously since 8am Feb 18, so that's about 8 days / 192 hours on the pack as of 8am this morning, or about 200 hours as of this moment. No doubt a few, cheap solar panels would extend the run tim
  21. Well this was wasted: void setup() { for (int ledPin = 1; ledPin <= 20; ledPin++) { // set all GPIO pins to OUTPUT; pins 1, 16, 17 and 20 cannot do GPIO if ((ledPin != 1) && (ledPin != 16) && (ledPin != 17) && (ledPin != 20)) pinMode(ledPin, OUTPUT); } } void loop() { for (int ledPin = 1; ledPin <= 20; ledPin++) { // toggle each GPIO pin if ((ledPin != 1) && (ledPin != 16) && (ledPin != 17) && (ledPin != 20)) { // pins 1, 16, 17 and 20 cannot do GPIO digitalWrite(ledPin, HIGH); delay(10);
  22. @@Derekspeegle Maybe this will do what you want: byte PWM1_PIN = P1_5; byte PWM2_PIN = P1_4; byte PWM3_PIN = P1_3; byte ROUT = P1_7; byte GOUT = P1_6; byte BOUT = P8_3; void setup() { analogFrequency(10000); // moved from loop() to setup() pinMode(PWM1_PIN, INPUT); pinMode(PWM2_PIN, INPUT); pinMode(PWM3_PIN, INPUT); pinMode(ROUT, OUTPUT); pinMode(GOUT, OUTPUT); pinMode(BOUT, OUTPUT); } void loop() { analogWrite(ROUT, map(pulseIn(PWM1_PIN, HIGH), 0, 1636, 0, 255)); analogWrite(GOUT, map(pulseIn(PWM2_PIN, HIGH), 0, 1636, 0, 255)); analogWrite(BOUT, map(pulseIn(PWM3_
  23. Oh, you mean "Devices and Printers" in "Control Panel", not in "Device Manager". So this is something like you'd see: (note the icon at the bottom left) I guess I need to figure some things out in order to help you but just a few days ago, I re-installed Win10 and got the system drivers loaded, then installed CCS and Energia and haven't had any problems. The XDS thing is the debug interface and it also produces two entries for the MSP432 in Device Manager, one of which is "Application/User UART" and the other is "Auxiliary Data Port". The "Application/User UART" is the COM: por
  24. Running Win10 here and no such problems as you suggest. And now you mention MSP432? I thought your issue was G2553? And no "Devices and Printers" in Win10 Device Manager: Notice the two "MSP430 Application UART"? One is a G2 Launchpad and the other is the access point for TI Chronos watch. Docking in my MSP432 gives me: Notice the "XDS110 Class" additions, one of which is "Application/User UART"? Those are the MSP432 things. *edit- you might have to click on the images to get them to "blow up" so you can read them.
  • Create New...