Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Peabody

  1. I found this code for a rotary encoder providing fine and coarse adjusment: https://forum.43oh.com/topic/9306-energia-library-rotary-encoder-with-coarse-fine-adustment/?tab=comments#comment-70635 Included in the .ino file on Github is the following: ---------------------------------------------------------- void setup() { Serial.begin (115200); pinMode(buttonPin, INPUT_PULLUP); pinMode(encoderPin1, INPUT_PULLUP); pinMode(encoderPin2, INPUT_PULLUP); attachInterrupt(encoderPin1, ISR_Encoder1, CHANGE); // interrupt for encoderPin1 attachInterrupt(encoderPin2, ISR_Encoder2, CHANGE); // interrupt for encoderPin2 attachInterrupt(buttonPin, ISR_Button, FALLING); // interrupt for encoder button ------------------------------------ And I'm having trouble understanding the "CHANGE" interrupts. My understanding is that MSP430 I/O pins don't have a "change" interrrupt. What am I missing here?
  2. I'm working on a reflow controller with a G2553 driving a solid state relay to control power. It also includes a rotary encoder with push button and two 7-segment displays to adjust and display the duty cycle. I've written it in assembler, and all of the activity takes place within the interrupt service routine triggered every 2ms by the watchdog timer in interval timer mode. Between interrupts, the processor sleeps. In assembler, the service routine does its magic in about 0.1ms, or 1/20th of the total time, so there's no danger of an overrun into the next trigger. There are no pin interrupts because the encoder and push button are serviced by polling. I'm thinking about converting the software to Energia to make it more accessible to others, and possibly also to Arduino for the same reason. But I'm having trouble finding Energia or Arduino examples of setting up timer-based interrupts other than fiddling directly with the registers. If anyone can point me to information on any higher-level commands that implement timer interrupts, I would appreciate it. One other general question I have concerns pin interrupts. My understanding is that MSP430 parts can do rising or falling edge interrupts, but I've seen examples of people using "change" interrupts as are available on Atmel parts. Can someone explain how an on-change interrupt is actually implemented for MSP430 parts? Thanks very much.
  3. I don't know if this has any application for Energia, but might be of use to someone at some point. I've been working on a way to embed a generic USB-to-UART adapter like the CP2102, FT232 or CH340 in an MSP340 project so firmware can be updated without having to buy a Launchpad. The newer MSP430 parts presented a problem because BSL-Scripter, TI's software for BSL flashing for those parts, doesn't transmit the special invoke pattern on /Reset and Test. Instead, it just brings both lines low, which messes things up. I gave up on trying to recompile Scripter, but I've written a Windows program that generates the pattern, and developed methods to disconnect DTR from /Reset after the pattern has invoked BSL, but before BSL-Scripter is run, which allows flashing to proceed with /Reset high. A full explanation, source code, executable, and schematic are in my Github repo. It all seems to work, at least with an FR2311 under Windows 7. https://github.com/gbhug5a/CP2102-with-BSL-Scripter-for-MSP430
  4. Thanks. That's a really great repo. 🙂 But it's all BSLDEMO , and I need to do the same thing with BSL Scripter.
  5. I'm on a mission from God to permit updating firmware on F5xx, F6xx, FRxx, etc. using TI's BSL-Scripter software and a generic USB-to-Serial adapter like the CP2102, which could be embedded in a project. As things stand, Scripter requires either a "Rocket" programming device or an MSP-FET because it is those devices which actually generate the pattern on /Reset and TEST that invokes BSL on the target device. I've written a short program that produces the special pattern on DTR and RTS of a CP2102, but when I run Scripter immediately thereafter, it brings both of those lines low and keeps them there. Of course that puts the target device into /Reset, so not much is gonna get flashed that way. I need to modify Scripter to add a MODE line or command line option called "INVOKE", which if present would cause Scripter to generate the required pattern on DTR and RTS itself, and leave them in the correct state. before doing whatever else it's going to do. The source code is available, but it's way over my head. It requires the Microsoft 2013 Visual C++ complier, and a bunch of third party stuff, including something called Boost. I have none of that, and don't know how I would modify the code. I did it for BSLDEMO, but that was plain C, with no third party stuff. So I wondered if anyone here had ever gotten Scripter to compile from the TI source, and if so, if he would like to compile a version for me (assuming I can figure out what to change). The only code I can find that deals with DTR and RTS in the source is in TestReset.h, but I don't understand it.
  6. I've added a second PDF file describing an efficient polling routine for servicing multiple momentary push-button switches.
  7. I worked on a new servicing routine for my kit oscilloscope's quadrature rotary encoder, and decided to write it all up and post it on Github. Included are routines for periodic polling and for pin-interrupt servicing. Hardware switch debouncing is not needed. The routines are for general use, but I wrote testing code for the MSP430G2231 installed on the Launchpad. The scope guys have used the "lookup table" state transition routine that most people use today, but it doesn't work very well on the scope, and I haven't found it to work very well generally. My routines are designed to avoid all effects of switch bouncing, and seem to work very well and efficiently. Everything is explained in the PDF file in the repo. All the testing code is also included, both source code and executable hex files, and I'm afraid it's all in assembler. But I hope it wouldn't be too difficult to create Energia versions if anyone is interested. I've provided hex files for both types of encoders - those with the same number of pulses as detents per revolution, and those with half as many pulses as detents. The code produces one "tick" per detent in both cases. https://github.com/gbhug5a/Rotary-Encoder-Servicing-Routines
  8. Can I ask a related question? Recently I posted here about an alternate G2553 BSL entry mechanism that I had developed and posted on Github. This involves a very short code segment buried in INFOA in between the calibration data blocks. There are two requirements for it to work. The first is that the Reset vector at 0xFFFE must point to 0x10C0, which is where the boot entry code resides at the beginning of INFOA. The second is that the firmware which will be running on the chip after flashing must begin at 0xC000, which is the beginning of MAIN memory. The code in INFOA tests whether USB is connected, and if not it BRanches to 0xC000. So the application must begin there, and it must be an instruction, not .dw stuff. This is easy in assembler, but it has occurred to me that the two requirements might not be easy, or even possible, to satisfy in plain C or in Energia, about which I know very little. What do you think?
  9. I originally posted about this in October, but wanted to report that I've updated the G2553 special BSL entry code to fix a bug. Everything is included in my Github repository: https://github.com/gbhug5a/MSP430-BSL To review, this project deals with the MSP430G Value Line processors, and was prompted by the idea of embedding a CP2102 USB-to-Serial adapter in a project's circuit rather than hooking one up through a pin header, or using the Launchpad for JTAG flashing. So all you would need to flash new firmware is a USB cable and the right software. A detailed description of what's involved is in the long-winded PDF file. The PDF deals with the much-despised BSL password in the G2553 ROM-based BSL, and offers a couple ways around it, including special boot code that fits entirely in the INFOA segment along with the existing calibration data, and lets you run BSL with INFOA protected from erasure, which means you can flash new firmware without knowing the password, and without erasing the calibration data. There's also a complete custom BSL system for the lowly G2231, which has no built-in BSL. Included are installers for the chip and the PC software to drive the process. And there's a discussion of circuit design for using embedded adapters or modules containing them. The installers for the chips use the Naken assembler, and the PC software uses the LCC compiler. But the repo includes both the source code and the executables for everything, so assembler-phobes can just flash the hex files. There are two small bonuses - a VBScript for Windows that converts an IntelHex file to TI-TXT format, and as part of the BSL installation for the G2231, the calibration values for 8, 12 and 16 MHz are derived from the existing 1 MHz calibration value, with no crystal required, and saved in the usual places in INFOA (based on original work by Steve Gibson). I did the original work on this for a project, and decided I might as well write it up in case it might be useful to others at some point. The Value Line processors are kinda old school now, but are still available in DIP, and are still pretty popular. And the circuit design portion may be more generally useful. Of course I'd like to know about any bugs or errors anyone may find. Hope this will be useful.
  10. Last summer I worked on the idea of embedding a USB-to-Serial adapter in Value Line projects so firmware revisions could be done with only a USB cable and the right software, without needing a Launchpad. The adapter chips and modules containing them are now so inexpensive that this makes sense. On the chance that it might be useful to someone, I've written it all up and posted it to Github: https://github.com/gbhug5a/MSP430-BSL The project is summarized in the README, and explained in detail, with needed software and hardware, in the PDF.
  11. Greeeg, I think that chip has a BSL built in. I'm curious whether you considered using that. Of course the built in BSL would need a PC master (the Scripter program?) to drive it, and I understand your bootloader only needs an SD card plugged in. But the built in version has the big advantage of having everything already done for you. Anyway, your version looks very interesting.
  12. I finally figured it out. The special signalling pattern didn't work because DTR is inverted coming out of BSLDEMO2. So that was never going to work. But entering BSL cold start from an application gave errors because I used the +u switch in the command line. It looked like that was the correct thing to do since I was indeed bypassing the signalling pattern, but for reasons I don't understand, when you use that switch the program doesn't send the password on all commands, in particular the ones I was trying to test with (read and verify). But of course the G2553 was expecting a password for these commands, so I got an error. I've recompiled BSLDEMO2.exe from the source code provided by TI, but with the polarity of DTR reversed. So it should all work now. I've asked TI to publish a new version of BSLDEMO2 with DTR polarity the right way for use with the USB-to-serial adapters, but I doubt they will do that. This is all "deprecated", so I doubt they will be willing to spend any effort or money fixing it.
  13. I have a G2553 set up on a breadboard, and am using a USB-to-UART adapter for BSL flashing. TI provides BSLDEMO2.exe on the Windows side to do the flashing, but I've been unable to get it to work. If I use the special signalling pattern on /RST and Test, I get a "synchromization failed" error, and if I boot directly into the cold start vector of BSL, I get a "communications error". So I just wondered if anyone here has actually done this successfully? The two ends talk to each other, but it always errors out.
  14. Hmmm. Your reply seemed much longer when I first read it. I'm just a participant in the project. It was designed and built by someone else. But despite its shortcomings, the 2231 is more than adequate for what needs to be done. It is also extremely low power. I can't really go into the details of the project because it's not mine. As for writing in assembler, the project builder made that choice, but that was fine with me because I never really got comfortable with C, and was already very familiar with assembler for 6502, x86, and even a little ARM. So instead of hundred of megabytes of CCS or IAR, I just use the Naken assembler, which is very small, and compiles instantaneously.
  15. Yes, thanks very much. As I replied to you there, it appears from one of the links you provided that there already exists software that can be used to flash firmware using a USB-to-UART board like the one I have. It appears to be called MSPFET.EXE, but so far I haven't found a good link to it. Still working on that. It appears it would be necessary to change to a 2553 though since the 2231 has no BSL. But that's ok.
  16. I'm new here, and haven't been able to go through all of this thread, but just wanted to report that it's possible to generate the 8 MHz settings for a G2231 without installing a crystal. Steve Gibson did this for a project a while back, and he incorporates the calibration code into the firmware. On powerup he checks to see if the 8 MHz values are there, and if not he does the calibration and writes the result to INFO memory. It takes about 20 seconds to do this, but only on the first powerup. It's basically the same as using a crystal, but instead he uses the low-frequency oscillator in the chip. Of course it's not accurate like a crystal would be, but apparently is very stable. So basically, you set the clock to the calibrated 1 MHz, and using TimerA you count count up for a few low-frequency cycles, then set the clock to trial 8 MHz settings, set the TimerA divisor to 8, and see if you get the same result as before. If not, you adjust the trial settings until you get "very close". This produces an 8 Mhz clock that's as accurate as the 1 MHz calibration is - no better, no worse - which is normally good enough. And I was encouraged to find that if you run this code multiple times on the same chip, you get the same answer each time. I haven't tried it, but I assume with a little tweaking it would be possible to do 12 MHz and 16 MHz as well. I apologize if this has been covered before. I just didn't see anything that didn't require a crystal.
  17. I'm new here, so hello everyone. I'm participating with a number of other people in a project that uses the G2231, and it's necessary to flash new firmware periodically. So, everybody had to buy a Launchpad. But last week I built a cheap oscilloscope kit that uses an STM microcontroller, and was reminded that for such controllers the only hardware you need to flash firmware is one of those little USB-to-UART boards that use the CP2102 chip or something similar. The one I ordered for my scope kit is 3/4 inch by 5/8 inch, comes with the right-angle male header, and the whole thing, micro-USB connector and all, cost $1.62 delivered from China. For future versions of the current project, and for just in general, I'd like to find a way to incorporate one of those interface boards into the project itself instead of every participant having to buy a Launchpad. So the user would just connect the device directly to his computer via USB, and flash new firmware. This would be used only for flashing, not debugging or anything else. I've read through all the relevant threads in this section, and while there was one early thread talking about doing exactly what I want to do, I didn't find any reports of anyone actually doing it successfully. So I'd like to find out whether it's even possible, and if so, what it would take to implement. So first off, while the G2553 datasheet discusses the BSL, the G2231 datasheet does not. So I'm assuming it doesn't have BSL. That would mean only 2-wire JTAG could be used to flash the G2231, which I just assume is completely incompatible with regular serial. I had hoped it would be possible to use the TI command line flasher, but with the CP2102 USB driver, to flash, but that doesn't look feasible. (Although - the interface board I ordered does also have a DTR output that perhaps could be manipulated to provide a clock.) Anyway, while I would much prefer to find something that works with the 2231, it would certainly be feasible to switch to the 2553 if BSL is the only way to make this work. I should also say that if new Windows software is required in place of the command line flasher, that would not be an insurmountable obstacle. I'm not a trained EE, really just a hobbyist. I program the MSP430s in assembler using Mike Kohn's Naken Assembler, and flash with the command line flasher. So all pretty much basic entry-level stuff. But I assume there are lots of real experts here, and would appreciate hearing any thoughts anyone has about how this idea might be implemented. I think it would be a very neat thing to have available for everyone. Thanks very much.
  • Create New...