-2
\$\begingroup\$

Does anyone know of a free simulator software for C for ARM11 and PIC16. I have KEIL for compiling embedded C.B ut, I don't have any simulator to run the code. Any idea about this?

\$\endgroup\$
  • 1
    \$\begingroup\$ Simulators are always processor specific, so you'll need to specify the type of processor you're targetting. \$\endgroup\$ – PeterJ Aug 2 '13 at 9:52
  • \$\begingroup\$ For ARM and PIC @PeterJ \$\endgroup\$ – karthi Aug 2 '13 at 9:55
  • 4
    \$\begingroup\$ Both ARM and PIC are wide ranges of architectures, spanning lots and lots of chips. So again, for which specific chip (type number)? \$\endgroup\$ – Wouter van Ooijen Aug 2 '13 at 10:52
  • \$\begingroup\$ @WoutervanOoijen PIC16 and ARM11 \$\endgroup\$ – karthi Aug 2 '13 at 11:01
  • 1
    \$\begingroup\$ You can Simulate in Keil for ARM. No issue in that! And I guess, MPLAB also supports simulation! \$\endgroup\$ – Swanand Aug 2 '13 at 11:33
1
\$\begingroup\$

Here's what I do:

  1. Make the I/O accesses inline routines, and initially have these routines read and write from files or stdin/stdout.
  2. Test under Linux (usually Ubuntu). Even ISRs can be tested this way, using console inputs. Plus you have the advantage of catching things like seg faults, which isn't usually available to you in bare metal processing, and being able to add print routines to help with debugging.
  3. Then port to the target hardware and run.

You can build suprisingly sophisticated emulation tools with just a bit of code...

\$\endgroup\$
  • 1
    \$\begingroup\$ Yes, to a degree, but you won't validate that the code appropriately handles the details of the target architecture. So this is mostly useful for algorithmic, user interface, etc work. \$\endgroup\$ – Chris Stratton Aug 2 '13 at 13:03
  • \$\begingroup\$ @ChrisStratton: It's certainly possible to write code which will work in "simulation" but not on actual hardware, but if one is careful one can write code which works on both. \$\endgroup\$ – supercat Aug 2 '13 at 15:30
  • \$\begingroup\$ Rather than having routines use console input/output, I've found it helpful to have the program which will run the target system's code establish a TCP connection to a test-bed program, which can then simulate the hardware. I generally have the target-system code run until it attempts an I/O operation, whereupon it will send a message to the test bed and wait for a response, then continue running target code until the next I/O operation, etc. In some cases I/O operations may be I/O port sets/clears; in other cases, I abstract larger chunks like flash-block writes. \$\endgroup\$ – supercat Aug 2 '13 at 20:30
  • \$\begingroup\$ One advantage of using a two-program approach is that one can have a debugger single-step through the embedded-system code while the user interface for the test-bed remains "live". For some applications, I'd like to be able to have multiple instances of the embedded system run within the same app, but I haven't figured out a good way to do that in C. \$\endgroup\$ – supercat Aug 2 '13 at 20:31
  • \$\begingroup\$ @brooks can you please explain little more about your suggestion? \$\endgroup\$ – karthi Aug 7 '13 at 4:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.