• Content count

  • Joined

  • Last visited

  • Days Won


terjeio last won the day on July 15

terjeio had the most liked content!

About terjeio

  • Rank
    Level 1

Profile Information

  • Gender
  • Location
  • Interests
    Electronic design, motion control, programming
  • Github

Recent Profile Visitors

314 profile views
  1. https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf Changing the code from SPI to parallel comms for an existing library could be the easiest way to get it working. Maybe there are libraries available utilizing parallel comms for diifferent MCUs that can be adapted without too much effort.
  2. Sorry for beeing a bit terse again, OR'ing NVIC_APINT_VECTKEY with the bits you want to set is the trick to make it work since NVIC_APINT_VECTKEY is the "password" or "guard" bits to allow the other bits to be changed. My point was that some other registers are similarily protected so it is something to be generally aware of. Read the documentation carefully is my motto - and do not expect details like this to be found in the context where you might think it should be mentioned.
  3. Some registers are "password" protected. From page 164, APINT-register description: VECTKEY: "This field is used to guard against accidental writes to this register. 0x05FA must be written to this field in order to change the bits in this register. On a read, 0xFA05 is returned." So if register writes does not work as expected this is something to keep in mind.
  4. I2C interface for 4x4 keyboard with partial support for 2-key rollover and autorepeat. Based on a Texas Instruments MSP430G2553 processor, uses a GPIO pin for signalling keypress events to host. Example PCB is a KiCad project for the 20-pin DIP version MSP430G2553. https://github.com/terjeio/I2C-interface-for-4x4-keyboard I am using this to test jogging in my GRBL-port embedded in the CO2-laser controller firmware (for Tiva C) I am working on. I have left some code (#defined out) to show how 2-key rollover and autorepeat can be enabled for some keys. The hardware abstracted ARM GRBL-port and an example driver for the Tiva C LauncPad is also available on GitHub.
  5. I have not switched to CCS 7 yet, in CCS 6 you can find examples via View > Getting Started > Browse Examples - same in CCS 7? Since many MSP430 processors have limited resources I prefer to implement the interfaces myself, reusing snippets of code from earlier projects.
  6. Does port 6 support interrupts? - check the documentation for your processor. I know this is not always so for the processors I have used.
  7. What is the requirement which is not met? Bouncing issues? Button matrix scanning? You need to use NMI?
  8. "On the edge" - I finally got around to port the latest GRBL version (1.1f) to ARM, in the process HALifying and making a library out of it. I then integrated it into my Tiva C based CO2-laser controller card codebase - next step is to hook it up to the laser proper to verify everything is working outside the test setup. I have to spend some time to learn git - currently I use Subversion for source control, running on my local server. I will not swich to git, Subversion works great for me, but for making code available to the community git is the way forward? Implementing a HAL-driver should be relatively straightforward, the core GRBL code in my port is nearly 100% hardware agnostic and all hardware related code can reside in one file (the HAL - Hardware Abstraction Layer). A preliminary version of my port can be found in the tread "Portability Experiments (ARM M4)" over at https://github.com/gnea/grbl/issues Test rig, from the edge... Terje
  9. A Google search - and I found this: https://github.com/fmilburn3/RTClib I find solutions for most of the questions I have by searching - if that fails then the manuals are great. This processor even has driverlib support it seems.
  10. Maybe wrong processor selected? Will it work if you remove #include <driverlib/rom.h>?, I believe that will force the linker to link the complete library functions into your program - IIRC when using the ROM version only a dispatch table and some stubs are added. If this does not help you may copy the GPIOIntRegister implementation into your code...
  11. You have to register your interrupt handler with GPIOIntRegister.
  12. @@NurseBob Sure have to do that, from table 8.2 in the user guide: "Port Select P2SEL 02Eh Read/write 0C0h with PUC" 0Ch means pins 6 and 7 are configured for primary peripheral module function on power up, not i/o.
  13. Printing a holder for a aiming laser for my CO2 laser on my new homemade 3D printer. The printer controller contains a Raspberry Pi running OctoPrint, an Arduino with a Ramps shield and an "intelligent power switch" based on a MSP430G2553 circuit of my design for booting/shutting down the Pi. I am using FreeCad & Slic3r for the 3D workflow - a lot of new stuff to learn...
  14. Ok, here we go - @@Fmilburn it is not my code, I have just "translated" it from assembly to C - I have to admit I did not understand much when I started coding for MCUs... In my application the processor is running at 1MHz, timing parametes (BIT_50 and BIT_75) must be adjusted different. The header file: // // Philips RC-5 IR protocol decoder library for MSP340G2553 // #include <msp430.h> #include <stdint.h> #include <stdbool.h> // The following bit timings are for a 1MHz clock #define BIT_50 890 // 890 #define BIT_75 1348 // 1348 #define IRDATA BIT2 // IR receiver input (P1) void initRC (void); void startRC (void); uint8_t getAddress (void); uint8_t getCommand (void); bool getToggle (void); Functions: // // Philips RC-5 IR protocol decoder library for MSP340G2553 // // Adapted from assembly code published in Texas Instruments Application Report SLAA134 // http://www.ti.com/litv/pdf/slaa134 // // by Terje Io // #include "rc5recv.h" static volatile uint8_t count; static volatile uint16_t data; // returns device address (5 bits) uint8_t getAddress (void) { return count == 0 ? (data >> 6) & 0x1F : 0; } // returns device command (6 bits) uint8_t getCommand (void) { return data & 0x3F; } // returns toggle status - changes when a new remote key is pressed or a key is pressed, released and pressed again bool getToggle (void) { return (data & 0x800) != 0; } // Init input pin and Timer 0 void initRC (void) { P1DIR &= ~IRDATA; P1SEL |= IRDATA; TA0CTL = TASSEL_2|MC1|TACLR|TAIE; } // Start receiving data - call must be followed by LPM0 in main code (to wait for command) void startRC (void) { data = 0; count = 14; TA0CCTL1 = CM1|SCS|CAP|CCIE; } #pragma vector = TIMER0_A1_VECTOR; void __interrupt TimerA0 (void) { switch(__even_in_range(TAIV, 14)) { case 0: break; // No interrupt case 2: // CCR1 not used #ifdef DEBUG P1OUT ^= DEBUG_PIN; #endif if(TA0CCTL1 & CAP) { TA0CCTL2 = 0; TA0CCTL1 = CCIE; TA0CCR1 += BIT_75; } else if(--count == 0) { TA0CCTL1 = 0; if(data & 0x1000) { // second startbit ok? data &= 0xFFF; LPM0_EXIT; } else startRC(); } else { data = data << 1; data |= (TA0CCTL1 & SCCI) >> 10; TA0CCTL1 = CM1|CM0|SCS|CAP|CCIE; TA0CCR2 = TA0CCR1 + BIT_50; TA0CCTL2 = CCIE; } #ifdef DEBUG P1OUT ^= DEBUG_PIN; #endif break; case 4: // Handle overruns by resetting TA0CCTL2 = 0; startRC(); break; default: break; } } Snippet from my application showing usage: startRC(); // set up IR receiver for next message while(1) { LPM0; toggled = toggle != getToggle(); toggle = getToggle(); if((address = getAddress()) == 16) { switch(getCommand()) { case 0: selectBtn(PHONO); if(isMuted()) // If muted then selectBtn(MUTE); // demute break; ... case 12: if(toggled) selectBtn(STDBY); break; case 13: if(toggled) selectBtn(MUTE); break; ... } } if(address != 0) // if IR receiver command processed startRC(); // set it up for next message } } I have code (and schematics) for a RC5 transmitter based on MSP430G2312 as well, again based on someone elses work but cannot remember where I found it. I run it off a CR2025 cell so it has limited range (4-5m), still battery life is 1 year+ with my (daily) use.
  15. SLAA134 may also be of interest: http://www.ti.com/litv/pdf/slaa134 I have recoded the RC5 receiver algoritm in C (for CCS) - I like it because it does not use much RAM. I can post the code but I need to make it postable first - it is part of one of my very first MCU projects. Terje