I need to learn to program MSP430, but don't have the actual chip yet. All configurations that I've tried at Code Composer Studio (except Snapshot, but it does not count, right?) require something on my USB. How do I learn to program the chip without the chip?
And what is an emulator that requires a USB?
Online emulator (used chrome): http://www.msp430emulator.com
This MSP430 Emulator is open source, and can be used directly online without downloading anything. Still under construction but has a good debug interface. Unfortunately no integration with CCS.
It is on the TI Open source page: TI Open Source Project Page
"The MSP430 Online Emulator provides a complete software model of the MSP430 16-bit instruction set. It is an interactive debugger for advanced development and in depth firmware/hardware analysis. Peripherals include UART, GPIO Ports, BCM+, Timer_A, and more! Open source, and absolutely free - access to the TI MSP430 Launchpad allows you to effectively build and debug firmware. No hardware setup, emulate anytime anywhere!"
open source on github:
https://github.com/RudolfGeosits/MSP430-Emulator
If you need something implemented you can add to the code yourself and run a local emulation server for real time applications.
This emulator is pretty awesome, once you can get it running. Note that it does claim GDB support, which likely means you can get a pure eclipse CDT C project & CDT-GDB-HW-Debugging session up and running against it (making sure to compile with the msp430's tool chain, of course).
http://opencores.org/project,openmsp430
As far as a simulator, the answer is truly 'no'. I would like to be wrong on that... But consider for a moment the number of variants of the msp430, the peripherals, and so on. Not sure if any company can justify that kind of cost!
Especially when launchpad/etc are so cheap and fast.
If you can afford £10 then the launchpad is the way to go just to teach yourself about the MSP430. You can use either IAR Embedded Workbench or Code Composer Studio, both which come in code size limited version which will be plenty big enough to learn with. I don't like either, but of the two the IAR one is, IMHO, the better bet as it's not Eclipse based. If you don't mind Java and Eclipse, then CCS is a viable option for you. One huge advantage with CCS is it runs on Linux, but really, it's still not a patch on Rowley Crossworks which runs on Linux. The latter has a cheap educational licence.
As far as the emulator and USB question is concerned, it's maybe being slightly pedantic, but it's not an emulator, it's a debug interface. There is a debugger built into the chip that enables you to load the code into the chip, set breakpoints, single step through code.
This kit is a great way to start because the debugger interface is built into the kit, you can access pins on the processor, see LEDs come on and all that good stuff that gives you the warm feeling you're programming a chip properly. For the sake of £10 you'd be mad not to!
Related
I really like live smalltalk environment (though I only experimented a bit with Pharo), but there is one thing why I can't really use it for everyday development. It seems that it is not possible to create a native standalone executable from smalltalk system. The native standalone executable means to create a single executable file (PE on windows, ELF on linux, Mach-O on macosx), that a user could run by double clicking it without the need to install any additional execution environments. Am I missing something and it is in fact possible to create native standalone executable with smalltalk?
If we talk about Pharo specifically. I know that Pharo's environment includes efficient just in time compiler (that generates true native code from Pharo's VM bytecode), I know that the VM image can be stripped down by cutting of the code that my application won't ever need. So basically we already have almost everything (except the linker I guess) to be able to create native standalone executables. Cross-compilation shouldn't be a problem too, if we put all code generation stuff (for all target processors) in the image.
I know that in smalltalk world it is considered to be a good thing to deliver the whole VM image separately from the runtime environment, so the user can hack on software he/she is using. However I don't see any good reasons why it shouldn't be possible to deliver your smalltalk software as fully compiled native standalone executable. Could you please explain me why it is not a common thing to do in smalltalk world? Is there any good smalltalk implementation that allow to do it?
To sum all this. I dream of a live smalltalk environment, where I could develop and test my software, but then (when the software is actually ready for delivery) cross-compile it to native executables for windows, linux and macosx from my single development machine. That would be really awesome.
ironically enough there is one thing that an exe needs to be preloaded. Your OS. See the thing is that C/C++ can be so light because already your OS acts pretty much as the image acts with a ton of preloaded libraries. You need to waste several GBs of memory just get a simple calculator starting. Your OS is a collection of C/C++ libraries.
Things are not any prettier with other languages like python, java etc , even if the app is smaller, they still depend on this libs and they come will quite big libraries that would need installation whether your app use them or not.
Pharo and Smalltalk in general is diffirent case because they aspire to be a virtual OS by itself. The diffirence with a real OS , the smalltalk image is made to be hacked the easy way by a user .
Saying that you can rename the pharo executable, change its icon, disable to IDE tools inside Pharo so your user sees only the GUI of your App. Applications like Dr. Geo and Phratch already do this.
Compiling a Pharo project to a native executable will not make much difference, because a) Pharo is already compiled to a native executable b) you dont need to do that since Pharo is already standalone does not need to even be installed.
My advice is stop worrying about things that do not really matter and enjoy learning how powerful and fun Pharo can be.
Not Pharo, but native, compiled (through ANSI C or its own JIT) smalltalk [applications] (with ability to load pre-compiled DLLs or [JIT-]compile code on demand):
Smalltalk/X
http://www.exept.de/en/products/smalltalk-x.html
or (unofficial enhanced development version):
Smalltalk/X JV branch - https://swing.fit.cvut.cz/projects/stx-jv/
Nearly completely open-source. Everything except librun (core runtime - memory management, JIT, etc.) and stc (smalltalk-to-c) compiler is already open-source. Claus Gittinger / Exept also promised/confirmed they would release remaining sources were they to stop further development (AFAIK, those parts are closed only because of concerns of existing clients).
I highly recommend everyone to check it out, it is a wonder such a great implementation is so little known.
You might also check out Dolphin from Object Arts.
It is windows only, but the very best IDE, bar none.
If you do anything in Smalltalk, you should buy a copy.
(They also have a free non-commercial version, but you will
want to support the kind of craftsmanship behind it by buying
the Pro version. An absolutely kick-ass product, IMHO).
It will produce a standalone exe, if that's what you want.
I made an exe of a medium-featured wiki with it - the exe was
less than 1 MB. That is not a typo.
-Jim
The problem is that Pharo, in that case, cannot be compared to any native compiler like C, C++ or others, but more like java, python, ruby and other languages with a Virtual Machine around.
In these languages, you produce jars, eggs or gems to distribute your project.
In Pharo, you produce a "production image" following technics you already mentioned. But nothing prevents you to deliver an artefact including also the PharoVM (it is 2m large, after all), and you can prepare your apps to detect and open your production image (without having to ask for it).
It is about as practical with Smalltalk as with other languages: not very much. As soon as you create a somewhat larger application, you start depending on other libraries/applications being installed. If you compile them statically with the application, you have now created a much larger application that takes longer to download, and needs to be updated at least as soon as a security problem is found in one of the dependencies. If not, your application is no longer double-click startable.
There are two directions for solutions: web applications, and installers and package managers.
Squeak still maintains its one-click installer, allowing the same set of files to work on windows, mac and linux. Pharo used to have that too, but moved to having separate builds. The need hasn't been so large that the one-click build has been reinstated. It is mostly seen as useful to be able to carry around a cross-platform environment on an usb-stick. With the move to the 64-bit spur vm the dependency problems will lessen as more of the needed libraries will come pre-installed on those platforms.
Dolphin Smalltalk can produce a standalone .exe for Windows.
This is a key feature of the Pro version.
Your dream has been around since the mid-80's and it is called Smalltalk/X.
I'm looking for a verilog simulator for windows. All I see is the source code for veriwell, with makefiles for Linux. Anybody have any suggestion on where I can find the binaries for veriwell or other Verilog simulator.
Veriwell is an excellent simulator, but unfortunately only supports vlog-95, which makes it unusable for realistic designs. Icarus is the way to go - I'm pretty sure you can download Windows binaries, very reliable and stable, active support, good language compliance, very low level of bugs (much better than at least one widely-used commercial simulator, for example).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I have purchased a Tiva C series LaunchPad TM4C123G Evaluation Kit from Texas Instruments. This kit contains a small PCB with an ARM Cortex M4F microcontroller. Now I want to start writing software for this microcontroller. I am used to program AVR 8-bit microcontrollers using AVR Studio on Windows. I heard that it shoud be easy to program ARM-based microcontrollers on Linux, and since Linux is my main platform, I would like a simple IDE that will work more or less like I am used to from AVR.
For several days I have been searching for a good IDE and tools that will do the job. To my surprise, only a few will run on Linux, and none is open source or freeware. Can this really be true? I do not want to spend several hundred dollars just to try out some programming for the Cortex M4F. Nor do I want to learn one IDE now and then another later when I found out it is not good enough or too expensive. I am used to Linux and the open source way of doing things and I am very shocked that nobody seem to be doing any serious embedded ARM programming with open source tools on Linux. Please correct me if I am wrong.
I have no plans running Linux on the Cortex M4F - I just want to program it like a normal microcontroller.
Texas Instruments recommends one of the following tool chains on the back cover of the evaluation kit:
Code Composer Studio IDE: full functional board locked
Keil: 32KB address limited
IAR: 32KB address limited
Mentor Embedded Sourcery CodeBench: 30-day full functional
I have also been recommended Red Studio from code_red.
Neither is open source or free and all have limitations. It seems to me that only Code Composer Studio and Red Studio is Linux compatible.
I stumbled upon yet another product, Rowley CrossWorks, which is also Linux compatible but still very commercial and expensive.
Is it really true that there is no open source alternative? Most of the products seem to use Eclipse and GCC, which one should be able to do without these commercial packages, right? I just can't find any tutorial or guide explaining how to do set this up for embedded ARM programming. Also I need to know how to program the device after compiling.
I really want to get started soon. Any advice and ideas are very appreciated :-)
It's always the same, no matter which eval board you have: STM32 discovery, LPCXpresso, TI Launchpads. They are very cheap, but the recommended IDEs are limited: Their code size is limited, Windows only, or they are bound to a specific Linux distribution.
In my experience the choice depends on your long-term goals:
Do you want to share code with AVR 8-bit (or PIC32, Renesas RX 32, ...)?
Is it a mid-term/long-term goal to have a build system based on make?
Do you need tab-completion and/or an integrated debugger?
Do you want to try other eval boards in the future (without being forced to install yet another IDE)?
or do you just want to get this one up and running quickly. In that case I would use one of the recommended IDEs to get an impression.
On the other hand, all 32-bit microcontrollers I have used (Cortex-M0/3/4, PIC32, Renesas RX) can be programmed with gcc. As far as I know Code Red, Mentor, and MPLABX use gcc (or a modified gcc).
So there is always the possibility to use Eclipse with a Makefile project, and gcc.
I have tried it twice, but it did not work well for me, because I share libraries between the different targets, and I found it difficult to pass around the defines in Eclipse.
So my IDE is Makefile, Emacs, and gcc, and I have switched completely to using C++: This might be another advantage of using gcc.
Both possibilities (Eclipse with Makefile project or just editor with make) are not "off the shelf": They require time, patience, and your favourite Internet search engine.
Update
I am not aware of a complete tutorial on how to setup a GCC + make based environment, so I simply describe the basic steps I did it some years ago (with some changes).
Get a binary distribution of GCC for ARM from https://launchpad.net/gcc-arm-embedded
The following steps are STM32 specific:
Get one of the discovery boards, for example the STM32 value line Discovery.
Get a flash utility: I am using stlink (git clone https://github.com/texane/stlink.git). This includes a GDB backend as well.
There are various examples available, search for "stm32vl discovery blink" (I cannot recommend one here, the one I used has vanished)
As an alternative (or follow-up): Get the Peripheral firmware examples
You will find a GNU ld compatible linker script in Project/Examples/GPIOToggle/TrueSTUDIO/stm32_flash.ld
You will find a GNU as compatible startup in Libraries/CMSIS/CM3/DeviceSupport/ST/STM32F10x/startup/TrueSTUDIO/startup_stm32f10x_ld_vl.s
You will find all other required library include files and sources in the .zip archive as well
Look at the GPIOToggle project (Project/Examples/GPIOToggle)
Write a Makefile to compile, link, and flash
To build your own development environment you could use the following combination:
Eclipse CDT
Get the toolchain to be used (official GCC version or some third-party customized for your platform)
Integrate the toolchain into Eclipse environment either through the internal Eclipse build system (CDT builder) or through some external builder (i.e. make)
In order to have JTAG debugging support, there is a GDB Hardware Debugging Eclipse plug-in you will need to setup
I've managed to complete my own setup in such a way for LPC1769 (Cortex-M3 CPU) and it worked :)
I am quite new to the embedded linux programming and did not really understand this concept very well.
Can anyone explain the essence of the "host-target" relation? Is this model only specific to the "cross-compilation"? Is it used just because "executable code will be run on another enviroment"? and what matters with the linux kernel on the target? E.g., the "building the embedded linux system" book mentioned this, but did not explain its motivation or goal of this type of development.
Thanks a lot.
The 'motivation' for this model is that seldom is an embedded target a suitable platform for development. It may be resource constrained, have no operating system, have no compiler that will run on the target, have no filesystem for source files, have no keyboard or display, no networking, and may be relatively slow or anything else you might need to develop effectively.
If your embedded system is suited to running Linux, it is possible that not all of the above limitations apply, but almost certainly enough of them to make you want to avoid developng directly on the target. If this were not so, they it hardly qualifies as an embedded system perhaps.
http://www.landley.net/writing/docs/cross-compiling.html
Seems pretty clear. What specific questions do you have?
Linux since its very origin was written in very portable way. It runs on a whole range of machines with very different CPUs, and it is considered the Good Thing to write in a portable way, so that, for example, package maintainer can easily port your program to some embedded ARM or Cygwin, or Amiga, or...
So, yes, the model is "only" specific to cross-compilation, but actually about every compilation on Linux is a (variant of) cross-compilation, just that by default build, host and target are automatically set to the same value, the same as the machine you run on.
Still, even then, you can take a Linux-i386 compiled compiler, sources for it, and "cross-compile" it for Linux-amd64. And the resulting binary will run much faster on a 64bit CPU.
It IS quite essential in embedded programming though. Mostly because you write programs for weak CPUs that are not capable of running a compiler or would run it at a snail pace. So you take a cross-compiler on a fast CPU (say, some multi-core Intel) and cross-compile for the embedded CPU (say, some low-end ARM).
"In different environment" is putting things very mildly. What you're doing when cross-compiling for embedded is working with entirely different instruction set, different memory access modes, different resource access methods and so on and so on. A machine of entirely different construction than the build host. Your build host may be a Windows PC running Cygwin. Your target may be a chip inside a smartphone. The binary will look nothing like the Cygwin .exe files.
As a direct consequence, -everything- must be compiled for the target from scratch. The kernel, the system utilities, the system libraries, all the tools the target must be running. Thing is, if the target is a ticket selling booth, there is really no sense cross-compiling Eclipse, GCC and Gnome for it, then developing in "local" environment, typing your code on a ticket booth keyboard. Instead, you just cross-compile the essentials of the OS, and your specific applications. You keep the development environment on the build machine, and cross-compile everything you need on the embedded device.
[in practice, you get a Linux distro for the target, and just compile whatever you need modified].
Does iPhone SDK 3.0 or 3.1 support Power PC machines having Leopard 10.5 or above? If not then what's the solution for the same results, I have a Mac with Power PC and Panther. I will upgrade to Leopard and install iPhone SDK.
Okay. The answers so far are NOT correct. For some reason, the iPhone SDK has been shipping as a Universal Binary for ages. So, yes, you CAN use a Power PC mac for iPhone development. I've done it and it's verrry dirty.
It's involved and a serious pain. It doesn't work all of the time and there are numerous bugs. It works well enough if you're ABSOLUTELY dedicated and ABSOLUTELY cannot afford a new computer.
Basically, you need to hack up the install XML properties in the installation package. Get rid of the "Intel" check javascript-ish code and/or make it always return true. This will enable the "iPhone SDK" checkbox in the installer.
Once you install it, you can use the SDK and cross-compile to ARM (iPhone processor). The simulator even works, but your milage may vary. My experience was so awful that I simply purchased an Intel Power Mac.
You'll need to hack up the install script for every update. This will involve converting the DMG to read/write beforehand. Editing some Javascript embedded in the XML installation package. Then, hacking up your build properties to get rid of "Native System" selections. It's actually very very painful.
You can Google "how" to do it in more detail. I do not suggest EVER releasing to the Apple store with this method. If you just want to play and get accustomed to the platform, then it might work for you.
Again, I MUST stress, this is very very unstable and totally unsupported. Please know what you are doing before you even consider attempting it.
Yes, it's possible. No, it's not fun.
The iPhone SDK only works on Macs with Intel processors. If you want to save money, you might be able to get the iPhone SDK working on a Hackintosh, but building a Hackintosh may be illegal and applying software updates will be annoying.
I suggest looking for a cheap second-hand Intel-based Mac Mini.
As noted by Will, since the SDK only supports the Intel processors, you are limited to a newer Mac unless you build a Hackintosh which may or may not be legal. However, you also don't need the latest and greatest machine to write software with, although better hardware does help! So you have a couple of options if you are looking to save money in that you could get a refurbished Mac from Apple or check around on eBay or Craigslist to see if you could get one.