I'm just getting started with the Attiny84 on AVR Studio 5 (based off of Visual Studio). However, I cant find the C programmers manual for it so I can figure out how to write ISR's, address GPIO pins, etc... Any ideas where I could find the manual for it?
Just looking at the AVR Studio 5 web page, it looks as though it can use the GCC compiler--not sure what other compilers it might be able to use.
The GCC compiler is an open-source compiler used for many platforms, so documentation is available for that from many places on the Internet.
The other thing I could suggest is taking a different approach: start by looking at some publicly available code for the AVR. AVR Studio 5 is in beta, but I expect it wouldn't be hugely different from what has already been in use for several years (AVR Studio 4 etc). AVR Freaks is a good resource for looking at AVR code done by others, for a wide range of applications.
It takes a bit of hunting down, but according to this press release, the integrated compiler is GCC. The GCC documentation is at http://gcc.gnu.org/onlinedocs/ for all versions.
In the 4.6.0 release, AVR specific sections are:
3.17.2 AVR Options
6.37.8 AVR Variable Attributes
The Atmel AVR Studio 5 web page claims that it has several hundred example projects included, I am sure than many of them include interrupt handler examples.
So the official manual is located here (provided by Atmel Applications Engineer):
http://www.nongnu.org/avr-libc/user-manual/modules.html
It had all the information I needed to get up and running.
I too am just getting started with AVR Studio 5. When doing GPIO, interrupts etc, I think you will want to leverage the code already provided in the ASF (Atmel Software Framework). Under the Project menu use the "Select Drivers from ASF..." to select the pieces you need. Alternately you can load sample projects targeted for your processor. I found the AVR Studio screencasts on the Atmel site (they are also on YouTube) worth watching.
Related
What are the differences between the different Rebol 3 branches, especially with the new REN branch?
Is it the platforms they'll run on, the feature set, code organization, the C standard compliance?
This is an answer destined to become outdated, hence set to Community Wiki. This information is as of Sep-2015. So if updating this answer after some time has passed, please modify the date as well.
Binary download of Rebol3 from rebol.com
Last build was 5-Mar-2011 and pre-dates the open source release.
No GUI support, no HTTPS support, no serial port support, no UDP support, no smart console...
No 64-bit builds. Binaries are for Windows x86, OS/X (PPC or x86), Linux (x86 or PPC), FreeBSD x86.
While Rebol2 binaries are archived for many "esoteric" systems (BeOS, AIX, Windows DEC Alpha, QNX, Solaris...) similar binaries were not provided for Rebol3. The only "weird" build is for Amiga, and only an OS4 PowerPC Amiga. No successful builds of Rebol3 for Amiga emulators have been reported.
Open source release of Rebol3 on Github rebol/rebol
Open-sourcing was on 12-Dec-2012.
The rebol.com binary downloads were not rebuilt as part of this release. However, a community member (#earl here on SO) created a build farm at rebolsource.net that follows this GitHub master whenever it updates. Given that GitHub's rebol/rebol master hasn't been updated since March 2014, this dynamism is currently underused.
Building the source at time of release got an executable not distinguishable (?) in functionality from the builds on 5-Mar-2011. This suggests few changes to the source were made besides some cleanup and Apache-licensing edits to prepare for publication.
Minor patches and bugfixes were integrated sporadically, with most PRs sitting idle. Last PR accepted at time of writing was Mar 3, 2014, which is over a year ago.
The most noticeable "breaking" PR that did get approved was to repurpose the FUNCTION name. It was considered to be worth breaking the old arity 3 form to let the word be taken for the much more useful implementation as locals-gathering FUNCT. (This also brought Rebol in alignment with Red, whose FUNCTION is arity 2 and acts similarly.) FUNCT was kept around as-is for legacy code.
The most major non-breaking PR that was taken is probably not requiring blocks around IF, UNLESS, or EITHER bodies. This has been received well among those who know it's there, as fitting the freeform and non-boilerplate philosophy of the language. It allows some code constructs to get "prettier" and gives programmers more choice, while it doesn't seem to cause any more problems than anything else. It's certainly less of a speedbump than if [condition] [...], in fact it seems almost no one knows this feature got added, so it must not be biting anyone. (If anyone can bend ears over at Red to make sure it gets IF and IF/ONLY then that would be ideal.)
RETURN/REDO was removed. Rationale was that it permitted functions to effectively behave with variable arity, and that this was unnecessary and took terra firma away by no longer being able to predict a function's arity from its spec. Perhaps this stance warrants a second look...as Lisp users who are pressuring for the addition of Lisp-style macros seeming aren't worried about that very much. (Here in the StackExchange universe, this provoked a Programmers.SE question Would Rebol (or Red) benefit from Lisp-style Macros?, which hasn't gotten much in the way of answers yet.)
The fork by Saphirion: "Saphir"
Prior to the open-sourcing of Rebol, Saphirion AG had a special relationship with Rebol technologies. They had access to the source and were taking responsibility for most of the development work for Rebol3 GUI features. They also added several other things like HTTPS.
Saphir is available as a binary download from their website, but only provided for 32-bit Windows. There was at one time an experimental .APK for Android from Saphirion.
Some (but not all) of Saphir's source was released after the open-sourcing. Notable omissions were the android build and some Rebol3 code for encapping...a way of injecting compressed scripts and resources into binaries of the interpreter without needing to recompile it.
(Note: Under Apache2 license there is no requirement to release source code for one's derived work.)
"Community" Integration at Rebolsource on GitHub
With the GitHub rebol/rebol being held up on integrations, a fork at rebolsource/r3 was established to be a "community build" where work could be staged.
Rebolsource changes were conservative, seemingly aimed toward showing process for how GitHub's rebol/rebol might adopt changes "in the spirit in which Rebol was conceived" should that repository be delegated to the community. (For that spirit, see this.) Hence it integrated non-controversial bugfixes and tweaks, instead of large third-party cryptography libraries for implementing HTTPS. Also: no allowance for adding build dependencies besides a C compiler (no GNU autotools, for instance).
Binaries for the community build were produced on an as-needed basis for those requesting them who could not build it themselves.
Atronix Engineering's Rebol "3.0" at Github zsx/r3
Atronix is an industrial automation solutions provider that uses Rebol. How they do so is described in a video here by David den Haring, director of Engineering, and their ZOE software is built on their version of Rebol.
After the open sourcing, Atronix partnered with Saphirion to port the GUI to Linux. Atronix publishes their source publicly as it is developed, and David den Haring notes in the video above that they have only one proprietary component they developed (an industrial control driver). Other than that they are happy to share the source for all Rebol development they do.
Atronix integrated the 64-bit patches from Rebolsource, created a Windows 64-bit target, and offer up-to-date binaries of their development branch for Windows and Linux x86/x64, as well as Linux ARMv7.
Besides having the features of Saphir, the Atronix build added support for CALL with /INPUT, /OUTPUT, /ERROR. It also added a Foreign Function Interface, implementing LIBRARY!, ROUTINE! and STRUCT! for communicating with non-Rebol dynamic libraries. It brings in encapping support as well on Windows and Linux.
Rebol's "religion" was at times at odds with expedience, so the Rebol-based build process was replaced when needed by hand-edited makefiles and Visual Studio projects. The FFI library introduced a dependency on GNU autotools to build.
All Atronix builds include the GUI, so there is no "Core" build. And again, only Linux and Windows.
Ren-C
(Bias Note: This fork is the initiative #HostileFork started, knows the most about, and will speak most enthusiastically about.)
Ren-C started as an an extraction of a Core build out of Atronix's codebase. That gave it features like HTTPS, the enhanced CALL, and Foreign Function Interface to essentially all the platforms that Rebolsource was able to build for. Updates Jul/Sep-2015 Ren/C supports line continuations in the console, user infix functions, several bugfixes...
Ren-C makes large-scale changes and fixes fundamental issues in R3-Alpha, which are tracked on a Trello that provides more information. There is a new FAQ as a GitHub wiki. Critical issues like definitionally-scoped returns have been solved, with continuous work on other outstanding problems.
Though Atronix's R3/View required some additional dependencies, Ren/C pushed back to being able to be built with nothing besides a C compiler, and eliminated all handmade makefiles/projects.
Beyond Windows, Linux and Mac in both 32-bit and 64-bit variants, Ren/C has also been built for smaller players like HaikuOS and yes, even Syllable. This is interesting more for the demonstration of how broadly turnkey builds of the C89 code work (simply as make -f makefile.boot) as opposed to there being a particularly large userbase of those particular OSes!
From the point of view of language rigor, Ren/C is pushing on modern techniques. Although it can still build as C89, it can be built as C99 and C11 as well. It has also been verified to build as C++98 through C++14, and with some strategic modifications under #ifdef __cplusplus it can take advantage of modern C++ as a kind of static analysis tool over the C code. Warnings are raised, type errors all fixed up, and it's "const correct". The necessary changes were carefully considered to make Rebol's baseline C code not just more correct but cleaner and clearer source across the board.
From a point of view of C developers, Ren/C should be stable, organized, and commented enough for anyone who knows C to "modify with confidence" and try new features. That means being able to implement definitionally scoped returns (actually written, but not pushed), or try developing features like NewPath.
From a point of view of architecture, Ren/C is intended to not have an executable at all...but to be a library for embedding a Rebol interpreter into other programs. It is now the basis for Ren/C++, which was designed to anticipate working with Red as well.
From a point of view of testing, Ren/C intends to whip everything into shape for engineering rigor and zero bug tolerance. This means avoiding practices like zero-filling memory to obscure uninitialized memory accesses, using Address Sanitizer, Valgrind, and a test suite that can pass the highest settings on both.
While enabling all the extra functionality has made Ren/C's executable nearly twice the size of Rebolsource's, there's not yet been any audit to see how this can be brought down. It has been confirmed that there are duplicate copies of Zlib and PNG encoding/decoding--for instance (Saphirion included LodePNG, likely to work around a bug in the existing PNG because it was easier than fixing it...yet did not mothball the previous code). Also, being able to do a build which selectively integrates only the codecs you want to use is on the agenda.
Ren/C currently has the stakeholders from Atronix and Rebolsource participating in its development and direction, which strengthens the likelihood that it may evolve into "the" Rebol Core. It is now being linked in as the code backing Ren Garden, and using a similar approach it may be set up as the library used by Atronix's R3/View...then Rebolsource...and perhaps ultimately rebol/rebol itself.
The fork by Oldes
(Bias Note: this edit is added 28-Feb-2019 by Oldes himself)
Forked from the community branch. Main focus on keeping the code close to the original Carl's release without blindly taking everything from Atronix/Saphirion but still trying to pick-up the good things from these branches slowly.
Not like Ren-C, this version is not trying to introduce new syntax, but rather be closer to the original Rebol2 and new Red language
I was recently assigned a micro-controller programming task. I will need to program on MKL05Z32VFM4 device.
I was reading some programming tutorials on Microchip Technology's MPLAB IDE X, because that seems to have the most information, but looks like that IDE is only for Microchip products.
What development tools should I choose for MKL05Z32VFM4? Are there a generic IDE and simulator environment? Are there some tutorials for me to start to look at?
I apologize for a basic question. I am a decent general software developer, but I am very new to this area.
(this post will be partly useless if you plan to use some commercial toolchain like Keil, IAR or sth like that)
For ARM Cortex devices you have quite a lot of options available (; If you're in a mood for a bit of automatic translation you could check my website - I wrote a tutorial about (open source) toolchain for ARM - http://www.freddiechopin.info/pl/artykuly/35-arm/59-arm-toolchain-tutorial - unfortunately it's not translated to English, so you'll have to use google translate. There are also some other resources that you might find useful, especially my template/example projects for such toolchain (in Download). If you ever used Eclipse, Makefile and GCC this whole subject should be easy for you. Most of example projects will be close to what you need, but you should probably check example for STM32 (any) - which is a Cortex-M3, and the example for LPC1114 - which is a Cortex-M0.
As for the simulator, I personally think they're not worth the trouble, recent GCC toolchains disable it anyway, as it's only instruction simulator, you won't be able to easily simulate peripherals. If you want to simulate instructions just write your code for PC as it will work the same way (; If you need to check something on the real hardware you can use GDB and JTAG. As long as it's not some extremely expensive proprietary design (you can - again - check my website for other options) the tools are almost free - OpenOCD (GDB Server) is open-source, and you can buy a FTx232 based JTAG (the most popular kind for OpenOCD) starting at ~30$.
Big commercial toolchains sometimes have simulators with peripherals simulation, but these cost a few thousand € / year (;
Google around for "ARM Cortex" with keywords like: toolchain, gcc, openocd, debugging, jtag etc. to find some articles - there's a lot of it in the network.
Your question is really general, so pretty hard to answer, as we don't know what tools are you going to use, are you planing to use some external libraries, what type of work are you going to do with these devices etc.
From my experience contact with embedded world is often a huge shock for developers of PC software. It mostly works the same, but because resources are constrained you really should do things differently. You don't have "+infinity" of RAM, you should usually try to fit a lot of things in ROM and so on. And of course there's only C and C++, but in C++ you shouldn't use some of it's features (exceptions, RTTI, iostreams, parts of STL, ...), dynamic allocation of memory is not a good idea generally (with the chip you mentioned - 4kB of RAM - it's out of question in my opinion).
The chip you mentioned is really tiny, so it will probably be a bigger shock (;
Try to ask some specific question and give some more details about your project so we could give more detailed answers (;
That's a Cortex-M0 device. You can find lots of information online. You can start at arm.com. As far as toolchains go, gcc and clang are both free and support ARM and will work fine. You can get ARM's tools too, if that's what you're into. JTAG for debugging is going to cost you - most people use ARM's in-house RealView debugger or Trace32 from Lauterbach. I've also used the BDI3000 from Abatron.
It looks like a Freescale MCU. Freescale's IDE of choice is CodeWarrior.
A good place to start is the part manufacturer's site, generally they will have tools or links to recommended third parties as well as application notes and libraries. Start at the Freescale Kinetis KL0 series "Software & Tools" page.
Freescale's own CodeWarrior tool is Eclipse based.
I was willing to create an app for IntelAppUp store.I came across Cilk++.I was wondering how to use this C++ library in C # application while building a form based application?Any insight will be helpful
Cilk++ is unsupported. It has been replaced by Intel® Cilk™ Plus, which has been implemented by the Intel Composer XE C++ compiler (Composer XE 2011 or later), as well as in the "cilkplus" branch of GCC.
You'll need to be careful mixing Cilk Plus and C# forms. Cilk Plus provides an easy-to-use fork/join parallelism mechanism. Inside the parallel region, there's no way to predict which thread a piece of code will run on. You'll need to be aware of the limitations of C# forms and threaded applications. A good primer on the issues here is the article "Safe, Simple Multithreading in Windows Forms" available at http://msdn.microsoft.com/en-us/library/ms951089.aspx . You might also look at the QuickDemo example which shipped with Composer XE for Windows. Admittedly, QuickDemo is an MFC, not WinForms, based application, but it demonstrates many of the same issues.
- Barry Tannenbaum
Intel Cilk Plus Runtime Development
I'm learning embedded programming with the PIC24, and I'm looking for something "real-world" to dig into to help me learn. Are there any free software projects that might be targeting to the PIC? Anything that I could help port, or a niche I could try to fill?
Quite old (2005) but may help you to start:
http://www.gnupic.org/
For example, gpsim at http://www.dattalo.com/gnupic/gpsim.html
If you are looking for software projects, look up gputils - is the open source assembler and linker, and sdcc - an open source c/c++ compiler (lacks a PIC24 port).
If you are looking for embedded projects, there is nothing specific that comes to mind. However, do visit the piclist to pick up code snippets and learn from examples. Some of the best PIC coders contribute there.
If you are looking for hardware projects, there are verilog PIC16/18 cores on opencores but no PIC24 cores yet.
So, there's plenty to suit all tastes.
Are there any IDE's for developing HLSL code? The three key features I want are:
1) syntax highlighting
2) auto-complete
3) interaction debugging
Visual Studio doesn't do any of these things, and it doesn't seem that RenderMonkey or FX Composer do either.
Is there some IDE that I'm not aware of, or does one of these three IDE's actually support these features and I'm too clueless to figure out how to use them properly?
Have you actually tried ATI's RenderMoney or NVidia's FX Composer?
Both actually provide syntax highlighting. Futher more, NVidia's Cg toolkits actually allows you to enable syntaxhightling in Visual Studio with some custom setting.
As for auto-completion, I don't think it's much needed as compare to our normal programming. It's because you won't be writing a very long code for your shader programming. Shader is quite critical in that it is run on every frame generated, and every instruction require 1 to a few clock cycle to execute, thus there's always a physical limit to how long you can afford to write.
Interactive debugging is currently the limitation of GPU hardware. To actually do that, the GPU has to be emulated with our CPU, which is quite impossible considering that the REF (software rendering) device can never cop up with even obsolete GPU, what more to say about emulating shader.
Another new answer to an old question (actually 2 answers):
NShader is a Visual Studio plugin that provides syntax highlighting for HLSL / GLSL / CG. No intellisense or debugging though.
IntelliShade, mentioned already, is no longer available at the original site, but it has been mirrored here.
New answer to old question,
For debugging: NVidias Shader Debugger and it recently became free.
In the MSDev environment you can define key words and also specify 'hlsl' and 'fx' to be recognized and known files and get MSDev highlight the keywords you want.
As for the editing tools - you can use the FX composer by NVidia or RenderMonkey by ATI. If you need to debug and profile you can use their tools as well and give Pix a spin.
Take a look at Shazzam. It doesn't feature interactive debugging, but it's pretty easy to edit and refresh.
Now with Visual Studio 11 there is a "real hlsl ide and debugger". It was detailed at Game Debugging in Visual Studio 11 and is available at Visual Studio 11 Beta.