[Simulavr-devel] Re: simulavr, again

[Theodore A. Roth]

On Sat, 12 Oct 2002, Joerg Wunsch wrote:

:)Hi Ted,
:)
:)writing up all that stdio stuff based on Alexander's sample
:)implementation makes quite some progress.  Find the output from one of
:)my first tests below...
:)
:)In the course of testing all this, of course i started using the
:)simulator again.  Well, i would start hacking some more virtual
:)devices for it, but still most of the innards are somewhat puzzling to
:)me...  One of the first things that would be needed for the ATmega128
:)emulation is a working RAMPZ, i. e. updating IO port 0x3b (or memory
:)location 0x5b) should set the RAMPZ in the device core.  Currently,
:)while RAMPZ is evaluated during the elpm instructions, except for the
:)Z+ case, it's never set at all.  This also leaves random garbage in
:)RAMPZ which will cause the simulator to abort with an invalid address
:)complaint during startup since the startup code copies the .data
:)variables from the end of the flash into the SRAM using elpm.

The attached patch implements rampz simulation. Bang on it and if it works, 
I'll commit it. The patch stops me from getting this from the simulator 
(from the startup code for mega128):

WARNING: file ../../src/memory.c: line 168: **** Attempt to write invalid addr: 
0x005b
0x000052 (0x0000a4) : 0xbf0b : OUT

:)
:)Then, i might perhaps try to find some simple emulation for a UART
:)that uses a pty to provide some communications channel to the
:)environment.

If you are interested, I've got another patch someone submitted that 
implements some UART stuff, but I've never tried it since I didn't take the 
time (have the time?? ;-) to write a test app to exercise it.

:)
:)While the uninitialized RAMPZ caused one surprise, there was another
:)one waiting...  When all worked in the simulator, moving the test to
:)the real device made it reset immediately.  It took me quite some time
:)until i found out that it was just the garbage in RAM after turning
:)the device on that had caused this.  The simulator neatly initializes
:)the RAM to 0 which is obviously somewhat unreal. ;-)  It's perhaps
:)better to use random() to fill it.

That makes some sense. I'd be more inclined to preload the sram with some 
known background data though which still raises some errors so you can track 
things down.

I guess the best solution would be to make it a command line option. Maybe 
"-R, --random-fill-sram". Wouldn't be that much work to implement. The 
default would be zero, but for stress testing, users can randomize.

:)
:)Here's some result so far.  (Note that snprintf() doesn't seem to work
:)as expected, but i'll debug that later.)
:)
:)First 512 bytes of SRAM:
:) 100: 46 69 72 73 74 20 25 64 20 62 79 74 65 73 20 6f
:) 110: 66 20 53 52 41 4d 3a  a  0 25 30 34 78 3a 20  0
:) 120: 25 30 32 78  0 77 6f 72 6c 64  0 68 65 6c 6c 6f
:) 130:  0 54 68 69 73 20 77 69 6c 6c 20 62 65 63 6f 6d
:) 140: 65 20 76 65 72 79 20 6c 65 6e 67 74 68 79 2e  0
:) 150: 54 68 61 74 27 73 20 61 6c 6c 20 62 79 20 6e 6f
:) 160: 77 2e  a  0 20  0 85  1  0  0  3 ab  1  0  0  0
:) 170:  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
:) 180:  0  0  0 87  1 24  0  0  0  0  0  0  0  0  0  0
:) 190:  0  0  0  0  0  8  0  0  0 19  0 cf  0  0  0  0
:) 1a0:  0  8  0  0  0  0  0 cf  0  0  0 32 28 3e 3f ba
:) 1b0: d4 56 5a d1 fe a0  d 18 ca b6 a2 aa 3e 2b 8f 31
:) 1c0: 46 85 e7 1e 2c 3b 8f 65 16 37 73 4b a9 fb 37 84
:) 1d0: f8 bd 45 b9 16 4b b0 c0 de d8 20 48 24 45 a2 62
:) 1e0: d1 cf 32 a8 15 85 9e 28 d8 24 c1 5d ba 3b 1c 3a
:) 1f0: 43 7d eb 15 2c  b 9e e1 44 d5 2a 3b cf fa b5 40
:) 200:  4 ac b3 30 f5 99 78 5f d9 6a 5a f0 1b 72 7b a2
:) 210: f5 e2 51 b4  9 b9  7 e3 97 db 42 99 21 e2 cf db
:) 220: 17 5a d0 81 5f 24 a2 de fa 55 c0 12 af 61 ad 41
:) 230: fb 7a 98 6a 50 b3 b3 a0 59 f7 3d 50 bb f2 1b 1b
:) 240: 5d 90 cf  5 9c 91 6f bd 5f d2 6b d1 b2 bf 4f ca
:) 250: aa 67 c4 b1 62 58  3 24 8d 1d e9 d7 92 92 f5 ce
:) 260: f0 e8 f0 e0 99 13 7f 3d 5a ae d6 f5 4b 83 52 95
:) 270: ad 25 11 80 53 76 84 e1 b5 f6 8b da fe 3e 46 9c
:) 280: 3c ee 23 48 fa 7e bf ad 5e d3 9a 9a 97 db 73 96
:) 290: 8d 5f fe 10 9d b1 e0 e9 a1 48 a9 bf 37 97 e1 a4
:) 2a0: 4e e2 29 41 13  2 2f 17 3d 17 c3 82  c 73 6a ed
:) 2b0: 15 82 71 95 3b b2  6 92  f 23 13 47 be 70 56 b7
:) 2c0: 35 91 86 ac 9b  2 6e 24 29  a ad 26 83 53 41 7b
:) 2d0: d9 45  5 8d 57 e6 9f cb 20 c7 e5 be e2 53 14 4d
:) 2e0: 68 fd  5 81 b8 97 2f c6 73 6f  7 41 75 df 67  0
:) 2f0: e3 ea 55 74 9e 3f 79 bb 75 bc 13 a8  3 91 7d 64
:)
:)String alignment tests:
:)hello                         
:)                         world
:)Number formatting:
:)%+15d:            +243
:)overflowing snprintf(), len 30, result This will become ver`$
:)My clock frequency (long int): 14745600
:)That's all by now.

You lost me there. It just looks like a bunch of random numbers to me. ;-)

Ted Roth

sim-rampz.diff
Description: Text document