Hi,
I've just started with SXSim1.55 - it looks great, but...
My code all provokes a
"RESET directive not found" on loading the .lst file. Even super-simple sample code forces this, when there's almost nothing _but_ a reset directive [noparse]:)[/noparse]
You must start your code with the following lines:
device···SX28,oschs1,turbo,stackx,optionx
irc_cal···IRC_SLOW
id···'justanid'
reset···reset_entry
freq···20_000_000
fill in the required types and values for your program.
The reset label (reset_entry above)
'must' (I think)·be a label somewhere in codepage 0.
And you should end your program with the directive end.
It was indeed obvious. Too old a version of SX-key, so I didn't have the symbols at the end of the listing.
SX-Key/Blitz Development System Manual 2.0 · Parallax, Inc. · Page 73 seems to have an error - it claims that
"When SASM successfully assembles a source code file, it creates the following files, located in the same
folder where the source code file resides:
· List file (.LST)
· Map File (.MAP)
· Object file (.OBJ)"
when in fact, they're in the SASM Output directory...
However, good progress, and my code is now simulating happily away. (The combination of SX-key3 and SXSim does seem to be an excellent environmnet to get things done in - thanks, guys!)
Steve, I'm happy that I have found a new SxSim fan, and Peter, thanks for your fast support response while I was busy posting the reply to another thread in the forum.
SxSim is - by no means - yet completed. Today, I got another bug report via eMail which makes SxSim go crazy when you try to simulate an application created for an SX 48/52. Unfortunately, for now, SxSim does not support these devices at all but it should report this incompatibility instead of crashing. I have fixed this in the meantime - it will be contained in the next update. I think time has come for a new major version with SX 48/52 support but this will be a bunch of work when support of the two timer/counters is included.
The manual is just not complete enough in the area you read. Actually, you can go into the configuration dialog and uncheck the "SASM file to 'SASM Output' dir" and then the files will go into the same directory as the source files. However, the default was set up so that it used the output directory instead, because it seemed that cluttering up the source directory with all the assembler's files was not the best approach.
Page 29 of the manual explains it all, but the same info wasn't carried over to the section on page 73. In addition, the manual is a bit out of date since it was written before the version 3.0 software, hence it shows (among other things) the old configuration dialog.
Hi,
thanks for the comments. I certainly didn't intend to knock the manuals - I was only nitpicking because it's all so damn good [noparse]:)[/noparse]
Working with the SX again is an absolute joy after being bogged down with much bigger CPUs and FPGAs for the last couple of years. To return, and find that the tools have moved on so far, with such fine support, just makes me very happy. It's good to be back [noparse]:)[/noparse]
I didn't think you were nitpicking, but rather pointing out an area of the manual that could use a little more refinement when the next version comes out.
I'm glad to hear you think the tools have come a long way. It's been a ton of work to get them there.
For the RTCC and W registers, I have defined byte variables just like in the "real" SX.
The "Laufzeitfehler/Run-Time Error" 6 (overflow) occurs with your sample code when SxSim tries to execute a RETIW instruction. When debugging the SxSim code, I found out that at this place, RTCC contained 216 = 0xD8, and W contained 82 = 0x52. SxSim then tries to store RTCC + W into RTCC which yields in 298 with these numbers, i.e. the result is above 255, and this is why the overflow run-time error is fired.
In the meantime, I have modified the SxSim code to handle this overflow situation, i.e. RTCC does receive (RTCC+W) mod 256 now, so RTCC no longer overflows but "wraps" around - but this is just one side of the coin.
In a "real live" application, it should not happen that the RETIW overflows the RTCC because this means that the ISR execution took too many clock cycles.
I think SxSim should not only be a "stupid" SX emulator but it also should be an analyzing tool. Therefore, I tend to trap this RTCC overflow situation on RETIW instructions by reporting an error.
What do you think?
Besides this, let me test the step/step back feature when entering/leaving an interrupt - maybe, I've got to do some more work in this area.
....
Can you issue a warning the moment RTCC overruns while inside
the ISR and not wait until reti or retiw is executed? This would make the
error much clearer.
regards peter
Peter, I think this is a good idea - I'll handle it this way. I think I should also add another checkbox to turn the RTCC overflow checking within ISRs on and off.
Hi Guenther
Thanks for making such a terrific tool·in your sx simulator. I'm using·it to learn·the assembler language and it really is usefull to see everything 'opened out' on the screen. Reminds me of the old minicomputer days when everything was there in bright red octal digits, sigh
Anyway,·I was using your simulator to get to grips with the ·IREAD instruction when I found what may be a small 'feature'.· If you use the Bck button to go back before the IREAD it doesn't seem to restore the M value. Not a big hill of beans in the grand scheme of things but I know you like to get things right.
I'm using version 1.56 and enclosed the src for the file I was using.
thanks to Alan's report, I could fix two bugs in the undo function - as usual, please find the latest version (1.07) attached to the first "sticky" post in this thread.
In order to avoid that this first post becomes longer an longer, I have decided to only maintain the two most recent entries of the software history in this post. You can always find the complete history attached ro the end of the documentation from now on.
First of all i must say that this is a great tool! Last night it saved me a few good hours of troubleshooting. In that case it was a "add PC, w" that was not on the low page half nor page 0. I'm really coding in·C with the·C2C compiler with snippets of inline asm, and then it is really easy to do misstakes like this. But with a clear error message like "bad jump...." i learned a good lesson.
I have a question also. Would it be possible have statistics regarding the code depth in·the ISR routine? I find myself constanly checking·manually (since i code in c and most changes are in the isr) the number of instructions in the·interrupt routine to make sure there·are enough cycles.·What i'm looking for something like this:
With the "average" figure it would be easier to see how much "power" there is left to execute tasks outside the isr routine.
I have thought about developing a script that would a least do the "max" calculations statically on a file, but there are a couple of obvious problems with that. So my question is it possible in SxSim? The statistics would of course only be based on the actual executed lines.
the current version of SXSim already keeps track of the maximum IRS cycles. They are displayed in the field titled "ISR Cycles" at the bottom of the main window. While running a simulation, you will notice that the value displayed in that field eventually increases. This is the case for ISRs with variable execution times (or cycles).
It would be quite easy to save a min value as well, and optionally display this, and also count the number of ISR calls in order to calculate and then display the average. I'll put this on my current TODO list, and make it available in the next version.
BTW, yesterday, I found a bug in the recent version: When the list file currently being simulated is changed by an external program, SXSim asks if that file shall be re-loaded. When any brealpoints are set, it also asks if the breakpoints shall be restored. When you select "No" in this case, the breakpoint markers in the list display become un-checked but internally, the breakpoints still remain active. I have fixed that in the meantime. As a work-around, simply click "CLR BPs" to actually clear all breakpoints for now.
I'm glad that SXSim is useful for you, and - you are right - you have found another bug! To be honest, I have simply ignored the setting of the CARRYX fuse bit so far because I have never used it in one of my "real" SX applications. Nevertheless, it should be correctly emulated in SXSim, and I'll fix it (does not seem to be too complicated).
I'll also check the "File not found" error you have reported.
As I always like to learn about additonal SXSim features from the users, I have read your suggestions with great interest. Passing the simulated output states to the "real world", and reading in the real input states back to SXSim would be a "super feature".
As a matter of fact, I have developed an SX-based application called "µControl" which is kind of a PLC using a very simple programming language. I have written an IDE that runs under Windows on a PC, allowing the user to edit, compile, simulate, remote-simulate, and to transfer the compiled application into an EEPROM on the µControl Board for stand-alone execution (similar to the BS). The "remote-simulate" mode does exactly what you are asking for here. As I used external port-extenders, I could easily implement this with an SX 28 because enough I/O pins were available for the serial communication, and the I²C link to the external EEPROM.
I agree with you, to extend this to a "real" SX 28, some kind of an in circuit emulator based on an SX 48/52 would be required in order to support all 20 I/O pins of the SX 28.
When we assume that such a device were available, you should keep in mind there is still a drawback when testing a system with SXSim: The lack of real-time speed. SXSim's "Run" mode is much, much slower than an SX clocked at 50 MHz, even on the fastest PC available. I think if I would write the simulator part of SXSim in 80x86 Assembly (might be a real challenge to go back to the roots, as I did a lot of 80x86 Assembly a loooong time ago), it might come close to the SX but the PC's COM port for getting the I/O information in and out would be the bottleneck. Nevertheless, if speed is not a concern, I think it can be done.
Your second idea can be implemented quite easily from the SXSim-side. I will only have to add a command-line option, telling SXSim which LST file it may open at start-up (I will implement this in the next version). I'll check with Parallax about an option in the SX-Key IDE to launch external applications (not just SXSim, but maybe others as well).
boan said...
... I have a question also. Would it be possible have statistics regarding the code depth in the ISR routine? I find myself constanly checking manually (since i code in c and most changes are in the isr) the number of instructions in the interrupt routine to make sure there are enough cycles. What i'm looking for something like this:
minNofCycles = 10
maxNofCycles = 245
avergeNofCycles = 100
With the "average" figure it would be easier to see how much "power" there is left to execute tasks outside the isr routine..../boan
boan,
in the meantime, I have implemented the statistics you have suggested, and after testing them, I agree with you that the "average" function is quite valuable. I have simulated one of my "real-life" applications, where the minISR value was pretty low compared to the maxISR value - but the avgISR value was close to the minISR value which means that most of the time, the ISR "eats up" only a couple of cycles from the main routine, and only occasionaly requires more cycles. BTW, I calculate the avgISR cycles by adding up all ISR cycles executed so far, divided by the number of ISR calls - this is much more realistic than simply calculating the average between the max and min values.
I'm working on some other modifications but I'm pretty sure to post a new version of SXSim soon which will include the enhancements you had suggested.
SXSim sends a command byte, followed by one data byte, except when reading port bits. In this case, SXSim sends the command byte, and the ICE returns one byte.
Command Byte Structure
ppoooooo
pp = Port-Id:
00 = RA
01 = RB
10 = RC
11 = reset port configurations to power-on states
oooooo = Operation:
000000 = set TRIS register
000001 = set LVL register
000010 = set PLP register
000011 = set ST register
000100 = set WKEN_B register
000101 = set WKED_B register
000110 = set CMP_B register
000111 = set OPTION register (in order to configure the RTCC pin
When the port B wakeup/interrupt features are used, or RTCC increments on RTCC pin transitions are active, the ICE should send two bytes, indicating these events:
11111110 rrrrrrrr = RTCC overflow (rrrrrrrr = current RTCC contents)
11111111 bbbbbbbb = port B changed (bbbbbbbb = new port B status)
When the slave SX in the ICE handles the port B changes, and the RTCC overflow, and the ICE automatically notifies SXSim of such events, as described above, it is not necessary for SXSim to periodically poll the states of port B and the RTCC. As in this slave SX, the RTCC is used to count external RTCC pin events, it cannot make use of interrupts triggered by an internally clocked RTCC. This means, communication between the two SXes can't be handled by an ISR in the slave. Communications between master and slave might be handled via I²C, where, at least, in the slave, the I²C code would be executed in the main program loop.
What do you think?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
Post Edited (Guenther Daubach) : 1/26/2005 5:50:18 PM GMT
It strikes me that timing issues are likely to come up more often than not in this sort of a system. With the SXKey, reprogramming the SX takes so little time that I just don't see the advantage. What am I missing here?
It WOULD however, be wonderful to have a device that would inject signals into all the pins on the SX being debugged by the SxKey. That device could be an SX52 and some external RAM. It could be clocked from the SXKey and so would stay in sync, and could be loaded via serial port, etc... from the PC. The RAM would allow very large stim files at full SX speed. The 52 could clock the RAM (INC RC) at top speed for 256 states at a time or at lower speeds for much larger sets and could simulate more complex devices such as terminals, I2C chips, Analog voltages (needs RC?) and other things that are more interactive.
For maxium flexibilty, lower speed devices could be simulated by a command language that would allow people to develop "virtual test hardware" to be loaded into the SX52. e.g. you could program the SX52 to assert one pin some number of ms after it saw a signal from the target SX thereby simulating an RC network. Or any number of other interactions.
Now, this sort of thing would make initial development on SxSim really nice. No need for any hardware, develop on the road (plane, train, etc...) and then use the signal files from the SxSim simulated devices to inject into a real SX while debugging via the SXKey. Finally, when you have it all working and the timing issues nailed, you build the actual hardware with a better chance of it working the first time.
The clock speed does not register on the SXSim screen - "Not defined"...
Tony,
before addressing the ICE topic (and James' ideas) in more detail, I'd like to explain this one.
For now, SXSim does not build up its own symbol table from where it could figure out that ClockSpeed is a Symbol with an assigned value of "50_000_000". Instead, SXSim simply scans the list file for a line containing the FREQ keyword, and expects that it is followed by a numeric value (eventually with dashes in between) to find out the clock frequency. This is why SXSim flags "Not defined" with your code.
Since a while, I'm thinking of building "my own" symbol table while SYSim is reading a list file. I think - similar to an assembler - I would have to do two passes through that file. Pass 1 for collecting the symbols, and pass 2 to load the list file replacing the symbols with the information gathered during the first path.
Looks as if SXSim is coming close to a full-time job for me but I still need some time for my "income-generating" jobs as I still have to feed some mouths here
Personally, I would try and avoid having to replicate any of the functionality of SASM. At one point, before adding SASM to the IDE, I was working on adding "include" file ability to the original Parallax assembler. For various reasons, it was easier for me to do this as a pre-pass on the source code and then invoke the Parallax assembler. It looked pretty straightforward until I starting thinking about things like "ifdef" and "if". The problem was that I could potentially have code that was included or not (code which might have an "include" line it in) because of an "if" or "ifdef", but the only way to know would be to build up my own symbol table. This meant also having to add an expression evaluator into the mix because I might stumble across code like:
if ThisVar + ThatVar > 1
include "a file.src"
It was also technically possible to have an include inside a macro, so a macro evaluator would also have to be written. Suddenly, I found myself looking at writing most of an assembler just to have the ability to build up a symbol table.
In this case, it's far simpler to just parse the existing symbol table at the end of the list file and look for "__SX_FREQ". This is the clock frequency as determined by SASM. I believe you are already parsing the table, so it's not a problem for you to find this extra symbol. Is there additional information you need in the symbol table that would help you with SxSim?
you are right - I did not want to replicate parts of the functionality of SASM. My idea was to collect the symbols from the list file, i.e. SASM has already done a lot of work for me, like expanding macros, including files etc.
On the other hand, I don't know why I have ignored so far the __SX_FREQ and also the __SX_RESET symbols - they give me exactly the information I need. Yes, I already parse the symbol table for VAR and ADDR Types in order to display symbolic names in the "Next Instruction" field. Thank you for this important tip - this saves me a lot of work.
I have already changed SXSim to read those two symbols, that is, Tony's
no problem concerning the delay. As a matter of fact, a looong time ago, I did a lot of Z80 programming in assembler. One of my projects was writing a cross-assembler and a simulator for the 6800 for training purposes. It was really funny to see a 6800 assembler program run on a TRS-80. Another really challenging project was the development of a Z80-controlled rhythm and accompaniment unit for an electronic organ. To my knowledge, this one was the first microprocessor controlled unit available.
Well, concerning the combination of two SXes, I have the following ideas:
The slave SX more or less replaces the SX normally sitting in the hardware under test, i.e. its RA, RB, RTCC, and MCLR pins are connected to the hardware, where the RC pins are used to communicate with the master. I think both SXes could be clocked from the same source at 50 MHz, indepentently of the clock provided by the hardware under test.
The master's RC pins are connected to the hardware, two RA pins could be used to handle the communication with SXSim (RxD/TxD).
The communication between master and slave could be done via I²C which only requires two I/O pins on both SXes. Another (faster) possibility would be some kind of parallel data exchange via the eight free RC pins on the slave and the eight free RB pins on the master. As pins will be used for some kind of handshake, data could be exchanged nibble-wise via four I/O pins, for example.
I think it is important to have the slave's RB pins connected to the hardware in order to allow for interrupts by signal transitions on the RB pins, i.e. when pins are configured to cause an interrupt, the slave's IRS is actualy executed, causing a signal passed via the master to SXSim. The same is true for RTCC overflow interrupts when the RTCC is
clocked externally via the RTCC pin.
To emulate the sleep/wake-up mode would be a bit difficult becase we can't really put the slave into sleep mode, as it then would no longer reply to requests from SXSim. Maybe, SXSum could simulate the sleep mode, i.e. when it comes across a sleep instruction, it pauses further program execution until the slave reports an interrupt caused by an RB pin, which is a wake-up in this case.
On the other hand, it sould be possible to detect a hardware reset because in this case, the slave executes the code beginning at the main enty, and this code could send a reset message to SXSim which then performs a simulated reset.
So I have added a new value to my suggested list of events reported by the ICE:
11111101 xxxxxxxx = Device reset (x = don't care)
Yes, I agree, the input panel should be functioning when open. As SXSim will have to be set into a special "ICE mode" anyway, it would be easy to de-activate the input buttons in the panel but still change their colors depending on the input states, or even hide the buttons, and show green "LEDs" instead.
BTW, here is another limitation, the SXSim-ICE will have. Imagine what happens when an input is pulsed by the hardware at a variable rate where the "normally" running SX shall measure the time between two subsequent positive edges. For a real SX (up to a certain pulse frequency) this is no problem at all but the much slower executing simulator will not be able to catch up.
Yes, I think the GUI needs to be enhanced by a configuration dialog for the COM port to be used. It is not necessary to configure the baud rate as I would prefer to run the communication between SXSim and the ICE as fast as possible. I found that an SX28 @ 50 MHz can handle 115,2 kBaud safely. At lower baud rates, the COM port would be the "bottleneck".
Fine that you like my book. Yes, the I²C routines shown there are an "overkill" for this ICE application. I do have stripped-down code here, that I use to "talk" with EEPROMs. The problem I see is that in a typical I²C master-slave configuration, the master always controls the communication, i.e. the slave never starts sending data by itself but only when requested by the master. In the ICE configuration, it would be nice if the slave could become active when it detects an interrupt or a reset without beeing polled by the master. "In I²C", this would be a multi-master configuration with all the additional stuff to handle bus arbitration.
Instead of a multi-master system, we could could use one more free port pins on both SXes, allowing the slave to alert the master about a special event (like interrupt or reset), and the master would - in this case - poll the slave immediately.
Maybe, we should also consider the parallel communication as an alternative, and it would even be faster.
Well, James ideas are highly interesting. While we discuss emulating an SX, connected to existing hardware, his idea is to simulate the hardware with "simulated stimulation".
Yes, that would be a great enhancement. A very rudimental one is the I/O panel but this only allows for inputs under "human control". I think it would not be too complicated to enhance the SXSim code in order to allow for "plug-ins", e.g. DLLs having a relatively simple SXSim interface. Via this interface, the current status of all I/O pins need to be exchanged, and SXSim would call this DLL once for each simulated clock cycle. This would open SXSim for external modules, hopefully supplied by many SXSim users.
Let's continue this very interesting discussion and brainstorming. Besides this, I think it becomes more and more necessary that SXSim can simulate the SX48/52 devices. I'm currently trying to figure out what has to be done. Maybe, in a first version, I will not yet simulate the two multi-purpose timer/counters but only the larger program and RAM memory, and the RAM addressing modes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
Post Edited (Guenther Daubach) : 1/29/2005 3:04:40 PM GMT
Comments
I've just started with SXSim1.55 - it looks great, but...
My code all provokes a
"RESET directive not found" on loading the .lst file. Even super-simple sample code forces this, when there's almost nothing _but_ a reset directive [noparse]:)[/noparse]
device SX28L,OSCXT5,TURBO
freq 50_000_000
7FF- A00 reset start
000- 2A8 start inc 8
001- 0E9 dec 9
002- 26A not 10
003- A00 jmp start
Any hints, or samples that do work, would be gratefully received. It's going o be obvious, but not just yet....
Cheers,
Steve
device···SX28,oschs1,turbo,stackx,optionx
irc_cal···IRC_SLOW
id···'justanid'
reset···reset_entry
freq···20_000_000
fill in the required types and values for your program.
The reset label (reset_entry above)
'must' (I think)·be a label somewhere in codepage 0.
And you should end your program with the directive end.
regards peter
·
SX-Key/Blitz Development System Manual 2.0 · Parallax, Inc. · Page 73 seems to have an error - it claims that
"When SASM successfully assembles a source code file, it creates the following files, located in the same
folder where the source code file resides:
· List file (.LST)
· Map File (.MAP)
· Object file (.OBJ)"
when in fact, they're in the SASM Output directory...
However, good progress, and my code is now simulating happily away. (The combination of SX-key3 and SXSim does seem to be an excellent environmnet to get things done in - thanks, guys!)
Steve
Steve, I'm happy that I have found a new SxSim fan, and Peter, thanks for your fast support response while I was busy posting the reply to another thread in the forum.
SxSim is - by no means - yet completed. Today, I got another bug report via eMail which makes SxSim go crazy when you try to simulate an application created for an SX 48/52. Unfortunately, for now, SxSim does not support these devices at all but it should report this incompatibility instead of crashing. I have fixed this in the meantime - it will be contained in the next update. I think time has come for a new major version with SX 48/52 support but this will be a bunch of work when support of the two timer/counters is included.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
The manual is just not complete enough in the area you read. Actually, you can go into the configuration dialog and uncheck the "SASM file to 'SASM Output' dir" and then the files will go into the same directory as the source files. However, the default was set up so that it used the output directory instead, because it seemed that cluttering up the source directory with all the assembler's files was not the best approach.
Page 29 of the manual explains it all, but the same info wasn't carried over to the section on page 73. In addition, the manual is a bit out of date since it was written before the version 3.0 software, hence it shows (among other things) the old configuration dialog.
Thanks, PeterM
thanks for the comments. I certainly didn't intend to knock the manuals - I was only nitpicking because it's all so damn good [noparse]:)[/noparse]
Working with the SX again is an absolute joy after being bogged down with much bigger CPUs and FPGAs for the last couple of years. To return, and find that the tools have moved on so far, with such fine support, just makes me very happy. It's good to be back [noparse]:)[/noparse]
Steve
I didn't think you were nitpicking, but rather pointing out an area of the manual that could use a little more refinement when the next version comes out.
I'm glad to hear you think the tools have come a long way. It's been a ton of work to get them there.
Thanks, PeterM
I get a laufzeitfehler '6' error with the attached list file.
I set a breakpoint at line 1388 and then just let it walk.
What is runtime error 6?
regards peter
apparently the laufzeitfehler 6 occurs after executing retiw
as the final instruction inside the ISR.
I suspect that the ISR timing is PC generated (I get an interrrupt, but
when I do step back, and then step again I get no interrupt), whereas
·it should be ticks generated (with every executed word the RTCC should increment) or is this already the case?
I figured it out. It is an error signaling the RTCC has overrun while in the ISR,
but the message does not come when RTCC overruns but when retiw
(and· reti too I expect) is executed. I see the RTCC counting once the
option register is set.
When I click ok on that error message , sxsim is terminated immediately.
regards peter
Post Edited (Peter Verkaik) : 1/14/2005 2:43:04 PM GMT
I have just downloaded your test16.lst file, and will figure out what the problem is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
this is a tricky one...
For the RTCC and W registers, I have defined byte variables just like in the "real" SX.
The "Laufzeitfehler/Run-Time Error" 6 (overflow) occurs with your sample code when SxSim tries to execute a RETIW instruction. When debugging the SxSim code, I found out that at this place, RTCC contained 216 = 0xD8, and W contained 82 = 0x52. SxSim then tries to store RTCC + W into RTCC which yields in 298 with these numbers, i.e. the result is above 255, and this is why the overflow run-time error is fired.
In the meantime, I have modified the SxSim code to handle this overflow situation, i.e. RTCC does receive (RTCC+W) mod 256 now, so RTCC no longer overflows but "wraps" around - but this is just one side of the coin.
In a "real live" application, it should not happen that the RETIW overflows the RTCC because this means that the ISR execution took too many clock cycles.
I think SxSim should not only be a "stupid" SX emulator but it also should be an analyzing tool. Therefore, I tend to trap this RTCC overflow situation on RETIW instructions by reporting an error.
What do you think?
Besides this, let me test the step/step back feature when entering/leaving an interrupt - maybe, I've got to do some more work in this area.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I think the real RTCC also wraps around, then simply counts until
zero is reached again and then just enters a new ISR. Even though
the RTCC should not overrun while in the ISR, I can imagine that
if you just want to do some non-time-critical routines, independant from
the main code, it wouldn't matter. Better of course to set the prescaler
so RTCC does not overrun.
Can you issue a warning the moment RTCC overruns while inside
the ISR and not wait until reti or retiw is executed? This would make the
error much clearer.
regards peter
Peter, I think this is a good idea - I'll handle it this way. I think I should also add another checkbox to turn the RTCC overflow checking within ISRs on and off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I have posted a new SXSim version (see the "sticky" post for more details).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Thanks for making such a terrific tool·in your sx simulator. I'm using·it to learn·the assembler language and it really is usefull to see everything 'opened out' on the screen. Reminds me of the old minicomputer days when everything was there in bright red octal digits, sigh
Anyway,·I was using your simulator to get to grips with the ·IREAD instruction when I found what may be a small 'feature'.· If you use the Bck button to go back before the IREAD it doesn't seem to restore the M value. Not a big hill of beans in the grand scheme of things but I know you like to get things right.
I'm using version 1.56 and enclosed the src for the file I was using.
Regards
Alan
I'm glad to hear that you like SXSim, and that it is useful for you.
Well, the Undo feature was a major change, and I almost expected that there was hiding a bug somewhere.
Thanks for submitting the sample code - I'll use it to kill that bug.
Please stay tuned for a fixed version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
thanks to Alan's report, I could fix two bugs in the undo function - as usual, please find the latest version (1.07) attached to the first "sticky" post in this thread.
In order to avoid that this first post becomes longer an longer, I have decided to only maintain the two most recent entries of the software history in this post. You can always find the complete history attached ro the end of the documentation from now on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I have a question also. Would it be possible have statistics regarding the code depth in·the ISR routine? I find myself constanly checking·manually (since i code in c and most changes are in the isr) the number of instructions in the·interrupt routine to make sure there·are enough cycles.·What i'm looking for something like this:
minNofCycles····· = 10
maxNofCycles···· = 245
avergeNofCycles·= 100
With the "average" figure it would be easier to see how much "power" there is left to execute tasks outside the isr routine.
I have thought about developing a script that would a least do the "max" calculations statically on a file, but there are a couple of obvious problems with that. So my question is it possible in SxSim? The statistics would of course only be based on the actual executed lines.
Cheers
/boan
·
the current version of SXSim already keeps track of the maximum IRS cycles. They are displayed in the field titled "ISR Cycles" at the bottom of the main window. While running a simulation, you will notice that the value displayed in that field eventually increases. This is the case for ISRs with variable execution times (or cycles).
It would be quite easy to save a min value as well, and optionally display this, and also count the number of ISR calls in order to calculate and then display the average. I'll put this on my current TODO list, and make it available in the next version.
BTW, yesterday, I found a bug in the recent version: When the list file currently being simulated is changed by an external program, SXSim asks if that file shall be re-loaded. When any brealpoints are set, it also asks if the breakpoints shall be restored. When you select "No" in this case, the breakpoint markers in the list display become un-checked but internally, the breakpoints still remain active. I have fixed that in the meantime. As a work-around, simply click "CLR BPs" to actually clear all breakpoints for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I'm glad that SXSim is useful for you, and - you are right - you have found another bug! To be honest, I have simply ignored the setting of the CARRYX fuse bit so far because I have never used it in one of my "real" SX applications. Nevertheless, it should be correctly emulated in SXSim, and I'll fix it (does not seem to be too complicated).
I'll also check the "File not found" error you have reported.
As I always like to learn about additonal SXSim features from the users, I have read your suggestions with great interest. Passing the simulated output states to the "real world", and reading in the real input states back to SXSim would be a "super feature".
As a matter of fact, I have developed an SX-based application called "µControl" which is kind of a PLC using a very simple programming language. I have written an IDE that runs under Windows on a PC, allowing the user to edit, compile, simulate, remote-simulate, and to transfer the compiled application into an EEPROM on the µControl Board for stand-alone execution (similar to the BS). The "remote-simulate" mode does exactly what you are asking for here. As I used external port-extenders, I could easily implement this with an SX 28 because enough I/O pins were available for the serial communication, and the I²C link to the external EEPROM.
I agree with you, to extend this to a "real" SX 28, some kind of an in circuit emulator based on an SX 48/52 would be required in order to support all 20 I/O pins of the SX 28.
When we assume that such a device were available, you should keep in mind there is still a drawback when testing a system with SXSim: The lack of real-time speed. SXSim's "Run" mode is much, much slower than an SX clocked at 50 MHz, even on the fastest PC available. I think if I would write the simulator part of SXSim in 80x86 Assembly (might be a real challenge to go back to the roots, as I did a lot of 80x86 Assembly a loooong time ago), it might come close to the SX but the PC's COM port for getting the I/O information in and out would be the bottleneck. Nevertheless, if speed is not a concern, I think it can be done.
Your second idea can be implemented quite easily from the SXSim-side. I will only have to add a command-line option, telling SXSim which LST file it may open at start-up (I will implement this in the next version). I'll check with Parallax about an option in the SX-Key IDE to launch external applications (not just SXSim, but maybe others as well).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
boan,
in the meantime, I have implemented the statistics you have suggested, and after testing them, I agree with you that the "average" function is quite valuable. I have simulated one of my "real-life" applications, where the minISR value was pretty low compared to the maxISR value - but the avgISR value was close to the minISR value which means that most of the time, the ISR "eats up" only a couple of cycles from the main routine, and only occasionaly requires more cycles. BTW, I calculate the avgISR cycles by adding up all ISR cycles executed so far, divided by the number of ISR calls - this is much more realistic than simply calculating the average between the max and min values.
I'm working on some other modifications but I'm pretty sure to post a new version of SXSim soon which will include the enhancements you had suggested.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
here are my thoughts on the serial protocol:
SXSim sends a command byte, followed by one data byte, except when reading port bits. In this case, SXSim sends the command byte, and the ICE returns one byte.
Command Byte Structure
ppoooooo
pp = Port-Id:
00 = RA
01 = RB
10 = RC
11 = reset port configurations to power-on states
oooooo = Operation:
000000 = set TRIS register
000001 = set LVL register
000010 = set PLP register
000011 = set ST register
000100 = set WKEN_B register
000101 = set WKED_B register
000110 = set CMP_B register
000111 = set OPTION register (in order to configure the RTCC pin
100000 = read port bits
100001 = read WKPND_B register
100010 = read RTCC register
When the port B wakeup/interrupt features are used, or RTCC increments on RTCC pin transitions are active, the ICE should send two bytes, indicating these events:
11111110 rrrrrrrr = RTCC overflow (rrrrrrrr = current RTCC contents)
11111111 bbbbbbbb = port B changed (bbbbbbbb = new port B status)
When the slave SX in the ICE handles the port B changes, and the RTCC overflow, and the ICE automatically notifies SXSim of such events, as described above, it is not necessary for SXSim to periodically poll the states of port B and the RTCC. As in this slave SX, the RTCC is used to count external RTCC pin events, it cannot make use of interrupts triggered by an internally clocked RTCC. This means, communication between the two SXes can't be handled by an ISR in the slave. Communications between master and slave might be handled via I²C, where, at least, in the slave, the I²C code would be executed in the main program loop.
What do you think?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
Post Edited (Guenther Daubach) : 1/26/2005 5:50:18 PM GMT
It WOULD however, be wonderful to have a device that would inject signals into all the pins on the SX being debugged by the SxKey. That device could be an SX52 and some external RAM. It could be clocked from the SXKey and so would stay in sync, and could be loaded via serial port, etc... from the PC. The RAM would allow very large stim files at full SX speed. The 52 could clock the RAM (INC RC) at top speed for 256 states at a time or at lower speeds for much larger sets and could simulate more complex devices such as terminals, I2C chips, Analog voltages (needs RC?) and other things that are more interactive.
For maxium flexibilty, lower speed devices could be simulated by a command language that would allow people to develop "virtual test hardware" to be loaded into the SX52. e.g. you could program the SX52 to assert one pin some number of ms after it saw a signal from the target SX thereby simulating an RC network. Or any number of other interactions.
And it would be even more wonderfull for SxSim to simulate injected signals or, even more orgasmic, to simulate devices. For example, there is a really cool Java simulator for the PIC called MiSim
http://www.feertech.com/misim/homepage.html
that can simulated a ton of external devices including a TV. You can actually play PIC PONG or PIC TETRIS on the web using the demo version right in your browser.
http://www.feertech.com/misim/online/index.html
There are all sorts of devices that can be simulated, including LED matrix's, keypads, switches, stepper motors, LCDs, 7seg, etc...
http://www.feertech.com/misim/plugins.html
http://www.feertech.com/misim/plugins.html
Now, this sort of thing would make initial development on SxSim really nice. No need for any hardware, develop on the road (plane, train, etc...) and then use the signal files from the SxSim simulated devices to inject into a real SX while debugging via the SXKey. Finally, when you have it all working and the timing issues nailed, you build the actual hardware with a better chance of it working the first time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
Tony,
before addressing the ICE topic (and James' ideas) in more detail, I'd like to explain this one.
For now, SXSim does not build up its own symbol table from where it could figure out that ClockSpeed is a Symbol with an assigned value of "50_000_000". Instead, SXSim simply scans the list file for a line containing the FREQ keyword, and expects that it is followed by a numeric value (eventually with dashes in between) to find out the clock frequency. This is why SXSim flags "Not defined" with your code.
Since a while, I'm thinking of building "my own" symbol table while SYSim is reading a list file. I think - similar to an assembler - I would have to do two passes through that file. Pass 1 for collecting the symbols, and pass 2 to load the list file replacing the symbols with the information gathered during the first path.
Looks as if SXSim is coming close to a full-time job for me but I still need some time for my "income-generating" jobs as I still have to feed some mouths here
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Personally, I would try and avoid having to replicate any of the functionality of SASM. At one point, before adding SASM to the IDE, I was working on adding "include" file ability to the original Parallax assembler. For various reasons, it was easier for me to do this as a pre-pass on the source code and then invoke the Parallax assembler. It looked pretty straightforward until I starting thinking about things like "ifdef" and "if". The problem was that I could potentially have code that was included or not (code which might have an "include" line it in) because of an "if" or "ifdef", but the only way to know would be to build up my own symbol table. This meant also having to add an expression evaluator into the mix because I might stumble across code like:
if ThisVar + ThatVar > 1
include "a file.src"
It was also technically possible to have an include inside a macro, so a macro evaluator would also have to be written. Suddenly, I found myself looking at writing most of an assembler just to have the ability to build up a symbol table.
In this case, it's far simpler to just parse the existing symbol table at the end of the list file and look for "__SX_FREQ". This is the clock frequency as determined by SASM. I believe you are already parsing the table, so it's not a problem for you to find this extra symbol. Is there additional information you need in the symbol table that would help you with SxSim?
Thanks, PeterM
Post Edited (PJMonty) : 1/29/2005 1:30:06 AM GMT
you are right - I did not want to replicate parts of the functionality of SASM. My idea was to collect the symbols from the list file, i.e. SASM has already done a lot of work for me, like expanding macros, including files etc.
On the other hand, I don't know why I have ignored so far the __SX_FREQ and also the __SX_RESET symbols - they give me exactly the information I need. Yes, I already parse the symbol table for VAR and ADDR Types in order to display symbolic names in the "Next Instruction" field. Thank you for this important tip - this saves me a lot of work.
I have already changed SXSim to read those two symbols, that is, Tony's
ClockSpeed EQU 50_000_000
FREQ ClockSpeed
problem will be gone in the next version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
no problem concerning the delay. As a matter of fact, a looong time ago, I did a lot of Z80 programming in assembler. One of my projects was writing a cross-assembler and a simulator for the 6800 for training purposes. It was really funny to see a 6800 assembler program run on a TRS-80. Another really challenging project was the development of a Z80-controlled rhythm and accompaniment unit for an electronic organ. To my knowledge, this one was the first microprocessor controlled unit available.
Well, concerning the combination of two SXes, I have the following ideas:
The slave SX more or less replaces the SX normally sitting in the hardware under test, i.e. its RA, RB, RTCC, and MCLR pins are connected to the hardware, where the RC pins are used to communicate with the master. I think both SXes could be clocked from the same source at 50 MHz, indepentently of the clock provided by the hardware under test.
The master's RC pins are connected to the hardware, two RA pins could be used to handle the communication with SXSim (RxD/TxD).
The communication between master and slave could be done via I²C which only requires two I/O pins on both SXes. Another (faster) possibility would be some kind of parallel data exchange via the eight free RC pins on the slave and the eight free RB pins on the master. As pins will be used for some kind of handshake, data could be exchanged nibble-wise via four I/O pins, for example.
I think it is important to have the slave's RB pins connected to the hardware in order to allow for interrupts by signal transitions on the RB pins, i.e. when pins are configured to cause an interrupt, the slave's IRS is actualy executed, causing a signal passed via the master to SXSim. The same is true for RTCC overflow interrupts when the RTCC is
clocked externally via the RTCC pin.
To emulate the sleep/wake-up mode would be a bit difficult becase we can't really put the slave into sleep mode, as it then would no longer reply to requests from SXSim. Maybe, SXSum could simulate the sleep mode, i.e. when it comes across a sleep instruction, it pauses further program execution until the slave reports an interrupt caused by an RB pin, which is a wake-up in this case.
On the other hand, it sould be possible to detect a hardware reset because in this case, the slave executes the code beginning at the main enty, and this code could send a reset message to SXSim which then performs a simulated reset.
So I have added a new value to my suggested list of events reported by the ICE:
11111101 xxxxxxxx = Device reset (x = don't care)
Yes, I agree, the input panel should be functioning when open. As SXSim will have to be set into a special "ICE mode" anyway, it would be easy to de-activate the input buttons in the panel but still change their colors depending on the input states, or even hide the buttons, and show green "LEDs" instead.
BTW, here is another limitation, the SXSim-ICE will have. Imagine what happens when an input is pulsed by the hardware at a variable rate where the "normally" running SX shall measure the time between two subsequent positive edges. For a real SX (up to a certain pulse frequency) this is no problem at all but the much slower executing simulator will not be able to catch up.
Yes, I think the GUI needs to be enhanced by a configuration dialog for the COM port to be used. It is not necessary to configure the baud rate as I would prefer to run the communication between SXSim and the ICE as fast as possible. I found that an SX28 @ 50 MHz can handle 115,2 kBaud safely. At lower baud rates, the COM port would be the "bottleneck".
Fine that you like my book. Yes, the I²C routines shown there are an "overkill" for this ICE application. I do have stripped-down code here, that I use to "talk" with EEPROMs. The problem I see is that in a typical I²C master-slave configuration, the master always controls the communication, i.e. the slave never starts sending data by itself but only when requested by the master. In the ICE configuration, it would be nice if the slave could become active when it detects an interrupt or a reset without beeing polled by the master. "In I²C", this would be a multi-master configuration with all the additional stuff to handle bus arbitration.
Instead of a multi-master system, we could could use one more free port pins on both SXes, allowing the slave to alert the master about a special event (like interrupt or reset), and the master would - in this case - poll the slave immediately.
Maybe, we should also consider the parallel communication as an alternative, and it would even be faster.
Well, James ideas are highly interesting. While we discuss emulating an SX, connected to existing hardware, his idea is to simulate the hardware with "simulated stimulation".
Yes, that would be a great enhancement. A very rudimental one is the I/O panel but this only allows for inputs under "human control". I think it would not be too complicated to enhance the SXSim code in order to allow for "plug-ins", e.g. DLLs having a relatively simple SXSim interface. Via this interface, the current status of all I/O pins need to be exchanged, and SXSim would call this DLL once for each simulated clock cycle. This would open SXSim for external modules, hopefully supplied by many SXSim users.
Let's continue this very interesting discussion and brainstorming. Besides this, I think it becomes more and more necessary that SXSim can simulate the SX48/52 devices. I'm currently trying to figure out what has to be done. Maybe, in a first version, I will not yet simulate the two multi-purpose timer/counters but only the larger program and RAM memory, and the RAM addressing modes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
Post Edited (Guenther Daubach) : 1/29/2005 3:04:40 PM GMT