Re: Will simulavr support the Windows platform?
Hi, Am 31.10.20 um 15:59 schrieb Helge Kruse: This sounds good. As Thomas K writes a re-integrate of Windows support is possible. I will look at your branch and probably we get a strategy how to merge everything. Honestly my attemps are currently work-in-progress and without a clear strategy. I will setup a fork repo on github so that we can see how it can be sync'd. Perfect! I also took a look on some other clones we see on the net. Maybe we can integrate them also. What version of Visual Studio do you use? I have VS2013 and VS2019 Community Edition available. This should be obscured by CMake, but I would get a good feeling if we could share easier ideas. I have no windows installation, so I can't check anything against windows compilation. * the console tracer is now working. The console tracer was dropped a very long time ago and I have no idea why. I reenabled printing register content, memory content, register names, timestamp, irq vector name and a lot more. I just needed the register content during a simulation and have just added this part. Sounds like you did much more. Yes, I enabled all features from the past. So you also have IO register names, stack pointer and XYZ register "virtual" content back. And you get the names of memory areas which access is going to or from. Also reduced the number of printed symbols if there are multiple names pointing to the same location. * open drain simulation is working again Honestly I don't know what's the topic. It allows to connect to a simulated wire with OpenDrain functionality. This can also be done much better with verilog, but I implemented that long before verlog interface was added. As older simulations need that feature, I bring it back. I have a problem on the desk: I want to simulate the UART RX ISR. I currently don't have any idea how I can prepare the UART registers and trigger an interrupt at a give CPU cylce (or cycle range). - Does your branch supports this in any way? - Did I miss this feature in the main branch? Getting interrupt handler called by receiving a byte on rx is working, even if the complete interrupt timing and interrupt priority is broken as I mentioned. But we can use the old implementation which was not "simplified" and it will work as on the target hardware. This is on my todo list. But for non accurate timing and cycle ordering it works. You simply have to connect you UART rx pin to another UART tx or use the tcl uart support. By doing this you get a GUI with a editor window where you can type from you pc keyboard and all characters will be send to your uart. This should work from scratch. Take a look on the examples section! There is an LCD example, which also works now, ( LCD support was fully broken by last versions ). There is also a simulated UART transfer. Even if the avr code did not use irq, you have a wroking environment for uart and can modify you avr code to use interrupts. As we loose so many features and functionality in the past: Please take care, run unit tests and for new features: write new ones :-) In hope to get the functionality back and make simulavr fully working again! Regards Klaus
Re: Will simulavr support the Windows platform?
This sounds good. As Thomas K writes a re-integrate of Windows support is possible. I will look at your branch and probably we get a strategy how to merge everything. Honestly my attemps are currently work-in-progress and without a clear strategy. I will setup a fork repo on github so that we can see how it can be sync'd. What version of Visual Studio do you use? I have VS2013 and VS2019 Community Edition available. This should be obscured by CMake, but I would get a good feeling if we could share easier ideas. > * the console tracer is now working. The console tracer was dropped a very long time ago and I have no idea why. I reenabled printing register content, memory content, register names, timestamp, irq vector name and a lot more. I just needed the register content during a simulation and have just added this part. Sounds like you did much more. > * open drain simulation is working again Honestly I don't know what's the topic. I have a problem on the desk: I want to simulate the UART RX ISR. I currently don't have any idea how I can prepare the UART registers and trigger an interrupt at a give CPU cylce (or cycle range). - Does your branch supports this in any way? - Did I miss this feature in the main branch? Regards, Helge Am 28.10.2020 um 13:20 schrieb Klaus Rudolph: > I am currently not able to use the master branch of simulavr nor > simulavr 1.1 because all these versions have lost too many features in > the past. I started to reintegrate a lot of the old features and also > fix a long list of bugs. There are still a long list of known bugs, e.g. > broken irq handling, spi, some unit tests and a lot of dropped features. > > So I decided to create a new branch which you can find on the repo named > "krud_private_reenable_old_features". The meaning of "private" is, that > I will not again see commits on this branch which will again remove > features :-) > > The current state of "my" branch is: > * lcd support is now back from the old simulator and works as expected. > In addition 8 bit mode interface added. > > * the console tracer is now working. The console tracer was dropped a > very long time ago and I have no idea why. I reenabled printing register > content, memory content, register names, timestamp, irq vector name and > a lot more. > > * open drain simulation is working again > > * building of libs for python and tcl is now working again > > * unit tests are reenabled, some minor bugs have fixed there > > * python is adapted to python 3 > > I did not remove any windows stuff on "my" branch, so there is a chance > that it works out of the box but I have no windows installation and > can't test it. > > Feel free to use the new branch, it has a lot of reenabled features and > a lot of bugs fixed. > > I have no idea what we will see in the future on the project. I did not > know if the master branch will take over my changes or not. But as the > master removes so many features, I was simply not able to compile nor to > use it anymore. The cmake stuff on master did not work on my fedora > installation so I wrote my own Makefile for the master branch, but still > it has dropped so many features that it is useless for me. Especially > that the console tracer is only tracing the instructions and nothing > more is useless for me. > > I have planned, but without any timeline, also to fix irq handling ( > using simply the old working code before it was "simplified" to get > correct irq handler selection and timing. > > Also planned to monitor and analyze nested irqs in the irq statistic. > That has started but is not finished. > > Also using the verilog interface for tracing registers, irq level and > memory content will be prepared ( after irq level info is available ). > > Again: Feel free to use it, maybe some of the changes may help you, > maybe the non removed windows support is a startpoint. > > Regards > Klaus
Re: Will simulavr support the Windows platform?
I am currently not able to use the master branch of simulavr nor simulavr 1.1 because all these versions have lost too many features in the past. I started to reintegrate a lot of the old features and also fix a long list of bugs. There are still a long list of known bugs, e.g. broken irq handling, spi, some unit tests and a lot of dropped features. So I decided to create a new branch which you can find on the repo named "krud_private_reenable_old_features". The meaning of "private" is, that I will not again see commits on this branch which will again remove features :-) The current state of "my" branch is: * lcd support is now back from the old simulator and works as expected. In addition 8 bit mode interface added. * the console tracer is now working. The console tracer was dropped a very long time ago and I have no idea why. I reenabled printing register content, memory content, register names, timestamp, irq vector name and a lot more. * open drain simulation is working again * building of libs for python and tcl is now working again * unit tests are reenabled, some minor bugs have fixed there * python is adapted to python 3 I did not remove any windows stuff on "my" branch, so there is a chance that it works out of the box but I have no windows installation and can't test it. Feel free to use the new branch, it has a lot of reenabled features and a lot of bugs fixed. I have no idea what we will see in the future on the project. I did not know if the master branch will take over my changes or not. But as the master removes so many features, I was simply not able to compile nor to use it anymore. The cmake stuff on master did not work on my fedora installation so I wrote my own Makefile for the master branch, but still it has dropped so many features that it is useless for me. Especially that the console tracer is only tracing the instructions and nothing more is useless for me. I have planned, but without any timeline, also to fix irq handling ( using simply the old working code before it was "simplified" to get correct irq handler selection and timing. Also planned to monitor and analyze nested irqs in the irq statistic. That has started but is not finished. Also using the verilog interface for tracing registers, irq level and memory content will be prepared ( after irq level info is available ). Again: Feel free to use it, maybe some of the changes may help you, maybe the non removed windows support is a startpoint. Regards Klaus Am 25.10.20 um 14:23 schrieb Helge Kruse: Hello, The support for Windows has been dropped with simulavr 1.1. But I would like to use the simulator on the Windows platform. I have compiled the current version with VS2017 Community Edition. This required some changes of the CMake output as well as at the source files. Here are the necessary changes: The Windows socket layer requires some changes: - different set of include files. - call to WSAStartup/WSACleanup - call to _read() or recv() instead of read(), same applies to write() The getopt module is not part of th Windows run time library and had to be added from source. The static constructors caused by the AVR_REGISTER macro invocation doesn't work with the Microsoft linker. The reason is, that the linker only uses object modules that resolve undefined symbols. As a workaround, the simulavr currently links againts the static library sim_static.lib and all object modules are forced to be included with /WHOLEARCHIVE:sim_static.lib. These changes require a change of the source code. Some "#ifdef WIN32" can be used to make the adaption to the winsock subsystem. The getopt module must be added or referenced by the simulavr project. Probably the remaining changes can be done with a Windows specific CMakefile.txt. Since CMake requires only one CMakefile.txt in a directory, the Linux and the Windows build should get their own directories. So, that's my idea of regaining the support for Windows of simulvar 1.x. What do you think about it? Is it still desired to maintain a cross-platform program? In that case I could try to add my changes and (honestly current) hacks to a Git repository after improving the code quality (remove hacks, etc.). Best regards, Helge
Re: Will simulavr support the Windows platform?
Hi Helge, it's right, that (at least in the moment :-) ) simulavr 1.1 does only build with linux. Problem was, that I use only linux and it's possible to use simulavr with docker, even on windows. But why not re-integrate windows support. The main problem is, that we need somebody, who can support an test changes and new versions on windows! If you like, youre most welcome. :-) My question is: do you use only simulavr as application for debugging with gdb? Or do you use also python or tcl extension? For getopt you could have a look into old directory, there is the getopt from version 1.0. Also the needed parts for windows in gdbserver.cpp - you could have a look in older versions. To create a separated version of CMakefile.txt explicit for windows is, in my opinion, not a good idea. I would recommend to start with a dev branch, where you change all, what's needed, to get it running native on windows. After that we can start to compare and what's possible to merge together. One step after another. I'm not sure if the problem with the AVR_REGISTER macro is a linker problem. This could become a hard nut. Binding again static lib could be a problem, if you want to use python or tcl extension. But we'll see ... What's really needed is, to get a documentation, what's needed for build simulavr on windows and how to do that. Maybe you could have a look into doc/sphinx directory. And feel free to ask. Maybe I will not answer quickly ... it's a question of spare time ... but I'll try to answer. cu, Thomas Am 25.10.20 um 14:23 schrieb Helge Kruse: Hello, The support for Windows has been dropped with simulavr 1.1. But I would like to use the simulator on the Windows platform. I have compiled the current version with VS2017 Community Edition. This required some changes of the CMake output as well as at the source files. Here are the necessary changes: The Windows socket layer requires some changes: - different set of include files. - call to WSAStartup/WSACleanup - call to _read() or recv() instead of read(), same applies to write() The getopt module is not part of th Windows run time library and had to be added from source. The static constructors caused by the AVR_REGISTER macro invocation doesn't work with the Microsoft linker. The reason is, that the linker only uses object modules that resolve undefined symbols. As a workaround, the simulavr currently links againts the static library sim_static.lib and all object modules are forced to be included with /WHOLEARCHIVE:sim_static.lib. These changes require a change of the source code. Some "#ifdef WIN32" can be used to make the adaption to the winsock subsystem. The getopt module must be added or referenced by the simulavr project. Probably the remaining changes can be done with a Windows specific CMakefile.txt. Since CMake requires only one CMakefile.txt in a directory, the Linux and the Windows build should get their own directories. So, that's my idea of regaining the support for Windows of simulvar 1.x. What do you think about it? Is it still desired to maintain a cross-platform program? In that case I could try to add my changes and (honestly current) hacks to a Git repository after improving the code quality (remove hacks, etc.). Best regards, Helge
