If you're prepared to forego the arduino libs and use the native Atmel SDK, you can use AVR Studio 5 which includes a simulator/debugger and is built on VS2010 shell (doesn't require VS2010 license). You have to use avrdude yourself to squirt the compiled results to the arduino, but it works a charm. Just get a copy of the relevant datasheet and you're off...
Comments
piersh
-
-
couldn't you just make sure everything's installed below a single directory and use junction points to switch the currently installed version?
-
beware: shared_ptr uses Interlocked* to enforce thread safety on its refcounts. if you're false-sharing in the same cache line you can absolutely kill your app's performance.
speaking of machine models, anyone care to explain pointers to members of classes with mutiple virtual bases? or what happens when an exception is thrown?
-
great talk.
are there any plans to make MemoryStream.BeginRead synchronous like it was in .NET 1.1 ?
-
please, next time Matt asks for a 2-hour slot for his talk, GIVE IT TO HIM!
-
not related to >2s hangs, but wrt performance, can you guys take a look at the following debugger windows:
- callstack
- locals
- watch
having any one of these open when stopped at a breakpoint brings the IDE to a crawl (see the visible lag when resizing the IDE.)interestingly enough, the autos window doesn't exhibit this behavior. -
@Charles: errr, i don't think herb's comment there answers any of my questions.
-
@Daniel Moth: I think you missed the point of my question.
in the future, suppose:
- you have a C++AMP compiler that targets direct3d v12 which has more capabilities that v11.
- you want to write code that targets the version of direct3d that's available on the user's machine, but you want to take advantage of the new d3dv12 features if available.
it would seem to me that there's definitely a need for versioning there, both at compile time AND at runtime.
will "restrict(direct3d)" always mean v11, if so how will we restrict to v12? if not, won't that break existing code when switching compilers?
-
ok, i love the fact that I can write 'portable' C++ code in my pixel shaders. but the problem is that as soon as I write "recstrict(direct3d)", my code is, by definition, non-portable. how are you guys going to address portability between 'restrictions' implemented by different compilers? wouldn't it have been better to use non-platform-specific restriction identifiers?
who writes/distributes the AMP runtime components? are they a standard OS component (.so/.dll), or are they a .lib baked in at compile-time? how will these be serviced (apropos GDI+ nightmare)?
will non-Microsoft, direct3d-targeting compilers use Microsoft-supplied direct3d runtimes, or will they have to write their own?
