Jump to content

xpg

Members
  • Content Count

    425
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by xpg

  1. Hi, I'm not quite sure. It haven't used the plugin myself for a long time myself. It has generally been far too long since I've had time to do anything with an MSP430 chip (which is also why I haven't really been active in here). But if you try it out please let me know how it goes.
  2. Thanks for the updates. That sounds somewhat annoying. I'll try to allocate some time to rebuild the tools so that you can give Eclipse and the MSP430 plugin a try. (I'm just really busy these days, but I'll get around doing it :-)) Cheers, Paul
  3. Hi Jim, This is caused by an old version of mspdebug bundled with the msp430-toolchain. I will try to get some time to rebuild the pre-build toolchain to include a newer version of mspdebug. Cheers, Paul
  4. Basically, we just need a proper way to extract the possible -mmcu values. When I created the plugin I didn't find any way to do that, so I ended up extracting the information from the ldscripts, which happened to match the -mmcu values. But it was a hack. It is fairly easy to replace the current mechanism with something else, given that there is a good way to extract the support devices. Unfortunately, I don't have time to look into this myself at this point. However, if someone comes up with a way to get the mcu list from gcc I'll implement it :-)
  5. Sure, I'll have a look at it as soon as I have some time on my hands. Actually I had plans to get the code merged into BMP, but I got sidetracked by other projects. Maybe it is time to restart that work :-) I can't give you a timeline, but it's on my todo list :-)
  6. Uhh. I am very happy to hear that. Although I have no clue what was wrong... oh well, let's just hope that it keeps working :-) Cheers, Paul
  7. I have not yet tried out the Red Hat toolchain. But I'm not surprised that the device list will not populate: The way I extract the list from the toolchain is quite ugly and very dependent on the way the mspgcc toolchain works. How is the Red Hat toolchain compared to the old mspgcc one? Is it ready for prime time yet? I'll put it on my todo list to check it out. Cheers, Paul
  8. The idea is that the msp430-toolchain-linux-amd64-3.0 folder is the tool-package directory. It should contain a file named "tool.info". So, if you have extracted the zip file to $HOME/msp430-toolchain-linux-amd64-3.0, then simply choose that directory when adding the toolchain in the toolchain manager.
  9. So, first off, the video is somewhat obsolete. I should probably replace it with a new one. Toolchains are no longer installed through eclipse. You are supposed to extract the toolchain somewhere and tell eclipse about it: From the menu in Eclipse select MSP430->Tool Manager. Click the "Add..."-button, and browse to the tool-package directory. Select the tool-chain and press the "Activate"-button in order to tell Eclipse to use it. Let me know if that works for you. Cheers, Paul
  10. :-) I wouldn't expect this to be causing any trouble. However, I cannot see what should be causing trouble at all, so it must be something that I find unlikely :-) Yes, the plugin is available at gitorious: https://www.gitorious.org/msp430eclipse/msp430eclipse It's not the prettiest code around, so feel free to ask questions about it. The list of supported MCUs is extraced from the linker scripts from GCC. The code can be found here. It's not a particular elegant way of doing it, but it -- usually -- works.
  11. Just tried the plugin with Siduction and Eclipse Kepler and it works here. However, I can see that there might be something wrong with the dependencies of the msp430-plugin as there are some complaints to the console, if I download the standard Eclipse distribution (rather than the C/C++ edition). So, maybe if you could try to download "Eclipse Kepler for C/C++ developers" and see if it still causes trouble? Furthermore, try using a new workspace when trying it out. If it continues to cause issues, could you send me the entire Eclipse workspace you used that caused issues? (just create a new one, with only the failing MSP430 project in it). Cheers, Paul
  12. Very strange. Please let me know if you run into trouble again.
  13. A happy new year to you too. Unfortunately, I don't have access to an OS X machine, so I can't try it out myself, but I will see if I can come up with something that might help you.
  14. Somewhat. I really can't explain what is happening yet, but I'm going to try and reproduce it.
  15. Somehow I completely missed that piece of news. I have to try that out as soon as possible. It's really cool that they are working on supporting the GCC tools in CCS. I'm not sure that I'm ready to jump away from the fairly minimalistic clean Eclipse approach, but I have to try CCS and see how I like it.
  16. Let me know if it solves the problem for you. Cheers, Paul
  17. First of all, sorry for my long response time! So, have you installed the MSP430 toolchain from the package from xpg.dk-website or from somewhere else? The only advantage of the package is that you don't have to setup the path to each individual tool manually or have them in your $PATH. If you know where the binaries are on your system, but they are not in your $PATH, you can go to the menu-bar and select "Window->Preferences". In the "MSP430" configuration you will be able to select the location of each tool. Hope this helps. Cheers, Paul
  18. Congrats -- to all of us. And thank you 43oh team, you have done a very good job! This is really the most friendly and helpful forum I have ever had the pleasure to participate in. Now, if I just could get some more spare time in the coming year to actually be active in here...
  19. "shortly" turned out to be 7 months, and I haven't made any of the planned "cleanups". However, the code is now available at github. Stellaris code is at https://github.com/xpgdk/networked-led-matrix-controller, while the LPC code is at https://github.com/xpgdk/lpc-led-matrix-controller Questions and comments regarding the code are welcome. I still have plans to do quite a bit of cleanup, but I just don't have the time for it currently. Thanks to @@hongphuc6789 for reminding me of releasing the code.
  20. Submission works... Editing as well Sendt fra min GT-I9100 med Tapatalk 4
  21. I'm very tempted by this...
  22. Unfortunately, I didn't get around to check the source code today, but I'll do it as soon as possible. You should check the source code for the exact configuration. The code at https://github.com/xpgdk/stellaris-enc28j60-booster uses PE4 as as ENC28J60 Interrupt pin. The code should perform a soft-reset of the ENC28J60, so it shouldn't matter that you do a reset of the Launchpad. However, you could try to remove the power connection from the ENC28J0 while holding the reset-button of the Launchpad and put the power back connection back before releasing the reset-button. This would allow you to see the output from a "hard-reset". The ENC28J60 should be powered from 3.3V. The activity LED blinking indicates that the ENC28J60 is properly initialized, and receiving and/or transmitting data. This doesn't tell us much more, than it is most likely a problem with the interrupt line. You could try to modify the code such that the interrupt signal is not used, such that it just keeps polling the ENC28J60 all the time. For the code in https://github.com/xpgdk/stellaris-enc28j60-booster you can do so by replacing line 206 "MAP_SysCtlSleep();" with "enc_action();" . Hope this helps you, /Paul
×
×
  • Create New...