ARM *simulators*
in [Embedded]
|
From: D Yuniskis on 20 Mar 2010 15:38 Hi, [Trying not to hijack the "Best dev kits for ARM Cortex" thread] I'd appreciate comments re: vendor offerings for ARM *simulators* (i.e., forget the "device/vendor-specific I/O's) and their (presumably) code generating counterparts. I do most of my development and testing *without* target hardware so appreciate tools that let me exercise my code without being tethered to a physical device. Thanks! --don
From: Leon on 20 Mar 2010 17:04 On 20 Mar, 19:38, D Yuniskis <not.going.to...(a)seen.com> wrote: > Hi, > > [Trying not to hijack the "Best dev kits for ARM Cortex" thread] > > I'd appreciate comments re: vendor offerings for ARM *simulators* > (i.e., forget the "device/vendor-specific I/O's) and their > (presumably) code generating counterparts. > > I do most of my development and testing *without* target > hardware so appreciate tools that let me exercise my code > without being tethered to a physical device. > > Thanks! > --don The Rowley CrossWorks simulator is very good. Leon
From: Marcus Harnisch on 22 Mar 2010 07:43 D Yuniskis <not.going.to.be(a)seen.com> writes: > I'd appreciate comments re: vendor offerings for ARM *simulators* > (i.e., forget the "device/vendor-specific I/O's) and their > (presumably) code generating counterparts. Which devices/cores do you need to have support for? That'll limit your options. Many of the popular MCU toolchains come with simulators. Often you get (restricted) free-as-in-free-beer eval versions. If, however you are targeting higher-end cores, you might have to consider getting ARM's RVISS (formerly Armulator), ISSM or RTSM. The decision also depends on what kind of performance you need. ARM's RTSM are built using their FastModels which generate JIT compiled code on the host machine. Impressive. -- Marcus Harnisch http://www.doulos.com/arm/
From: Chris H on 23 Mar 2010 11:04 In message <ho3819$krp$1(a)speranza.aioe.org>, D Yuniskis <not.going.to.be(a)seen.com> writes >Hi, > >[Trying not to hijack the "Best dev kits for ARM Cortex" thread] > >I'd appreciate comments re: vendor offerings for ARM *simulators* >(i.e., forget the "device/vendor-specific I/O's) and their >(presumably) code generating counterparts. > >I do most of my development and testing *without* target >hardware so appreciate tools that let me exercise my code >without being tethered to a physical device. One of the best is the Keil Simulator for many reasons. I have used Keil system for 100% unit testing on a critical project. It works. Also it is the only system where I have seen silicon vendors say they will guarantee that if it ran on the simulator it would run in the silicon. This was for a system that was one time programmable and we could not have a second byte at the cherry. Not all systems use flash. eg ASICS, Smart cards etc. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
From: D Yuniskis on 23 Mar 2010 13:15 Hi Chris, Chris H wrote: > In message <ho3819$krp$1(a)speranza.aioe.org>, D Yuniskis > <not.going.to.be(a)seen.com> writes >> Hi, >> >> [Trying not to hijack the "Best dev kits for ARM Cortex" thread] >> >> I'd appreciate comments re: vendor offerings for ARM *simulators* >> (i.e., forget the "device/vendor-specific I/O's) and their >> (presumably) code generating counterparts. >> >> I do most of my development and testing *without* target >> hardware so appreciate tools that let me exercise my code >> without being tethered to a physical device. > > One of the best is the Keil Simulator for many reasons. > > I have used Keil system for 100% unit testing on a critical project. It > works. Also it is the only system where I have seen silicon vendors say > they will guarantee that if it ran on the simulator it would run in the > silicon. This was for a system that was one time programmable and we > could not have a second byte at the cherry. > > Not all systems use flash. eg ASICS, Smart cards etc. Does the simulator also give *timings* (admittedly, this requires details of the particular device being used)? E.g., could I use it to fully characterize my RTOS? (Thanks to the other respondents, as well! My news feed is expiring articles so I can't individually reply :-/ )
|
Next
|
Last
Pages: 1 2 Prev: ZigBee CC2500 interface with AT89C2051 Code Next: FX2LP I/O port issue... need help |