On 23 February 2016 at 01:32, Markus Hitter wrote:
> Am 23.02.2016 um 01:16 schrieb Petr Hluzín:
>> IMO the reason of algorithm testing and examples for learning are fantasy.
>
> D'oh. So we're doing fantasy:
>
> http://reprap.org/wiki/Teacup_Firmware#Teacup_in_Sim
Simulavr does not implement a device that would use the three-level
stack. The code ThreeLevelStack in src\hwstack.h is not reachable, it
is dead, therefore there cannot be a discussion about dropping the
feature.
The parts are difficult to get and it is likely to get worse.
People have provided
Hello folks
I am sorry to arrive this late at the party. Thankfully my two cents
do not change much.
IMHO simulators are more useful to detect and report possibly buggy
situations. Simulators can provide a way to override the default
behavior. In fact the error message might indicate to user how
On 6 February 2016 at 00:12, Albrecht Frenzel wrote:
>> (I don't think simulavr has a notion of a BOOTRST fuse, so it always
>> starts from $pc = 0.)
>
> Sometimes it starts on the correct bootloader start address. Since simulavr
> terminates on , that means that "sometimes" the fuses are chec
This looks like GDB does not have debugging symbols for any of the libraries.
There is nothing we (i.e. the other guys :} ) could do without
function names, source lines and states of local variables.
On 11 February 2016 at 23:35, Christian Taedcke wrote:
> Hello list,
>
> i committed some chang
I suggest to change all "reserved" registers that are actually not
implemented yet to print "not implemented yet" or something similar.
We seem to have NotSimulatedRegister class just for that.
Otherwise more people will came asking whether their program is buggy
or simulavr does not do implement
On 10 February 2016 at 17:50, Klaus Rudolph wrote:
> The problem with the thread I can't explain. I never looked in that code and
> I have no idea what the tread is good for while accessing registers. Maybe
> this stuff can also be removed...
>
> Maybe someone else can give some hints especiall
On 22 November 2013 18:58, wrote:
> "
> systemclock.cpp: In instantiation of 'void MinHeap::Insert(Key,
> Value) [with Key = long long int; Value = SimulationMember*]':
> systemclock.cpp:135:40: required from here
> systemclock.cpp:70:23: error: 'resize' was not declared in this scope, and
> no
>
> I'd say make them all static instances.
> 'Twould eliminate some unneeded indirection.
> I'm pretty sure they can all be initialized in the pre-body
> portions of the constructors of the classes that use them.
>
I think you mean to make them member variables. Like this:
HWPortpo
On 14 November 2013 00:47, Markus Hitter wrote:
> Am 13.11.2013 23:27, schrieb Petr Hluzín:
>
>> Does your firmware use timer interrupts at 40 kHz and calculate
>> whether to produce new steps in the ISR?
>>
>> I think that grbl firmware does that. I was wondering i
On 13 November 2013 22:05, Markus Hitter wrote:
>
> While I filed a bug already, I'm new to this list, so:
>
> Hello everybody!
>
>
> The last two days I searched the net up and down to find out how I can
> fit SimulAVR into my task. I found quite some stuff about installation
> (http://www.nongnu
Ok, conclusions so far (if I understood the participants correctly):
Klaus Rudolph and Joerg Wunsch say that: if interrupts were are enabled or
just became enabled (because of SEI, RETI, OUT) and an interrupt was
pending or just became pending, then one more instruction will be executed
and then th
On 24 January 2013 19:26, Klaus Rudolph wrote:
> Hi all,
>
> yesterday I did one real apllication example on simulavr and it runs
> totally instable on it but works on a real device.
>
> After a few hours I found out that the irq handling is broken.
>
> What I expect:
>
> If a irq comes up the co
On 26 July 2012 20:56, Ytai Ben-tsvi wrote:
> Hi!
> I've built simulavr from source on Ubuntu / 64-bit.
>
> I'm getting:
> $ simulavr -d at90can128 --gdbserver
> simulavr: irqsystem.cpp:289: void
> HWIrqSystem::DebugVerifyInterruptVector(unsigned int, const Hardware*):
> Assertion `existing == sou
On 18 April 2012 23:39, Lars Immisch wrote:
>> The support for new avr-libc looks good (#108026: ).
>
>> I am not able to
>> review patch for building on OS X (#108027), I am not know autotools
>> and I do not have access to an OS X. Any volunteers?
>
> Well, the build was plain broken on OS X. I
On 15 April 2012 21:41, Lars Immisch wrote:
> Hi,
>
> On Apr 15, 2012, at 16:29 , Petr Hluzín wrote:
>> On 13 April 2012 11:35, Lars Immisch wrote:
>>> Hi,
>>>
>>> I have tried (and succeeded) to compile simulavr on OS X.
>>>
>>> The s
On 13 April 2012 11:35, Lars Immisch wrote:
> Hi,
>
> I have tried (and succeeded) to compile simulavr on OS X.
>
> The simulavr examples are working, python support also works (Tcl does not
> work yet).
>
> The result are two patches for simulavr.
>
> One adds support for the current avr-libc (t
Fixed in
http://git.savannah.gnu.org/cgit/simulavr.git/commit/?id=37a008adcc81fe97ec649133605f9e8ff6b5ff41
On 1 March 2012 09:39, Petr Hluzín wrote:
> Hi Mathias
>
> You are right,it is in Czech language. It is not an error message, its
> actually a debugging trace. It is useles
On 19 March 2012 18:50, Michael Hennebry wrote:
> Neither the original nor the proposed code works as advertised.
> ms is supposed to be tenths of milliseconds, so I renamed it.
>
> // Delay in 1/10's of a millisecond
> // won't work with -O0, use -O1 for debugging
> void msleep(INT16U ms10) { for
Hi Mathias
You are right,it is in Czech language. It is not an error message, its
actually a debugging trace. It is useless for almost anyone, I should
have removed it. Please ignore the message.
Petr
On 29 February 2012 23:48, Mathias Kussinger
wrote:
> Hi,
>
> i have encountered an error mess
On 6 February 2012 20:45, ThomasK wrote:
> Hi @all,
>
> the first release is the hardest ... ;-)
There has been multiple releases before. Users do not know the code
base is different.
>
> Now I've pushed a first version of manual for upcoming release 1.0 to
> savannah: http://download.savannah.g
On 31 January 2012 21:53, Joerg Wunsch wrote:
> Ahoj Petre,
>
>> I guess ATmega1281 will be similar to ATmega128.
>
> Well, let's say "mostly upwards compatible".
>
>> AVR097 says: "ATmega128 and ATmega1281/2561 are designed to be a pin
>> and functionality compatible sub family.".
>
> Yes, compat
On 31 January 2012 11:21, Marius Monton wrote:
> Hi,
>
> I'm adding ATmega1281 to simulavr. Currently I've mapped I/O pins and
> instantiate some of the perihperals, but I have some doubts about Timers
> and how to connect them. There's some documentation available about that?
> I'm open to send t
On 30 January 2012 19:23, ThomasK wrote:
> Hi Petr,
>
>
>> * attackers on network are able to abuse the poor simulavr
>
>
> I think, this is really a security problem. It's an open port for somebody,
> which is able to connect to it and nobody can be sure, that there is no
> possiblity to abuse it
On 29 January 2012 21:01, David Madden wrote:
> On 1/29/2012 11:54, Petr Hluzín wrote:
>>
>> all communication-capable classes would put
>> event objects (Windows) or file descriptors (Unixes) to a central
>> location which would do WaitForMultipleObjects() or select()
Hi folks
Currently if user wants to use GDB, then he has to use command like
"target remote:1234" and "simulavr --gdbserver -p 1234". This some
disadvantages:
* personal firewalls will complain about the listening port
* attackers on network are able to abuse the poor simulavr
* automated scripts
o the signatures are searchable when no device is created
yet.
The discussion is at
http://lists.nongnu.org/archive/html/simulavr-devel/2010-06/msg0.html
> Am 22.01.2012 19:43, schrieb Petr Hluzín:
>
>> Hi folks
>>
>> User may include `#include' in source code, this
&g
Hi folks
User may include `#include ' in source code, this
will create a new ELF section. We can use that to detect which device
was user's program compiled for when the ELF file is loaded via --file
on command line or `load' via GDB [1], or by a script.
The implementation will touch many files,
On 13 January 2012 01:39, Petr Hluzín wrote:
> On 12 January 2012 11:39, Stan Behrens
> wrote:
>> If interrupts are globally disabled and a condition occurs where an ISR
>> would be executed, they will be delayed until interrupts are enabled
>> again (SEI or RET
On 12 January 2012 11:39, Stan Behrens
wrote:
> If interrupts are globally disabled and a condition occurs where an ISR
> would be executed, they will be delayed until interrupts are enabled
> again (SEI or RETI).
> On a real MCU the interrupt's condition is saved in hardware through the
> wiring
On 11 January 2012 21:51, Stan Behrens
wrote:
> TODO: Check if execution is continuable on a real MCU.
> ---
> src/avrdevice.cpp | 6 ++
> src/decoder.cpp | 9 +
> src/decoder.h | 19 +++
> src/decoder_trace.cpp | 6 ++
> 4 files change
On 5 January 2012 22:52, Stan Behrens
wrote:
> Hi Petr,
>
> On 05/01/12 21:39, Petr Hluzín wrote:
>> Why does your patch add instructionBREAKJustExecuted to AvrDevice and
>> then have the if() condition in AvrDevice::Step()?
>> It would be easier to do the tracin
On 7 January 2012 10:49, ThomasK wrote:
> Hi Petr,
>
> just to answer, not to make the "next battle in the war": :-)
>
>
>> Readability and parsing were not affected. There are other, more
>> important reasons for tabs.
>
>
> Readability IS affected if somebody looks to a source with tab space 4 (
On 5 January 2012 17:50, ThomasK wrote:
> Hi Petr,
>
>> Are you aware that spaces-vs-tabs issue is a holy war which has been
>> going on for decades and remains unsolved?
>> It is unlikely that anyone finds a solution people would like. Maybe
>> if the solution was implemented in an editor.
>
>
>
On 4 January 2012 16:09, Stan Behrens
wrote:
> TODO: Check if execution is continuable on a real MCU.
> ---
> src/avrdevice.cpp | 11 ++-
> src/avrdevice.h | 1 +
> src/decoder.cpp | 10 ++
> src/decoder.h | 20
> src/decoder_t
On 4 January 2012 16:39, Stan Behrens
wrote:
>
> Back to topic: I could not find any code that implements handling of
> FUSEs, so that I had to change my patch. Simulavr treats the BREAK
> instruction as NOP now when no gdb session was established.
What do you use the instruction for?
If you use
On 30 December 2011 12:21, Klaus Rudolph wrote:
> Hi,
>
> I can't see a reason to add a pseudo break instruction. Breakpoints handled
> in simulavr with a address table which works together with gdb.
Breakpoints are usually planted at places that are interesting to a
programmer. Usually a progra
On 4 January 2012 16:46, ThomasK wrote:
> Hi,
>
> after some questions about building a released version of simulavr and after
> many months of development, :-) (sure, last time it was only Petr, which has
> commited some work) it's time to create a first release. I'll start this in
> the beginnin
On 4 January 2012 16:34, ThomasK wrote:
> Hi,
>
> I've commited now a script to count all tab spaces from source files in
> simulavr workspace. Goal is to reduce step by step tab spaces from source
> files.
Are you aware that spaces-vs-tabs issue is a holy war which has been
going on for decades
(This patch fixes bug https://savannah.nongnu.org/bugs/?35195)
Patch applied. Thanks.
http://git.savannah.gnu.org/cgit/simulavr.git/commit/?id=ae8b9a718b07514acda7fe6368b1e08302eaaf52
On 30 December 2011 10:43, Stan Behrens
wrote:
> ---
> src/decoder.cpp | 2 +-
> 1 files changed, 1 insertio
On 21 December 2011 07:50, D. Laszlo Sitzer wrote:
> Hi Petr,
>
> thanks for your fix. I have tried to build once again but it still
> fails with a (smaller) error message related to systemclock.cpp
Oh great. Committed a second attempt. The last commit should fix that.
--
Petr Hluzin
_
On 14 December 2011 17:11, Klaus Rudolph wrote:
>
> The problem with mi is not really clear to me but could be fixed by
> removing auto with the correct data type from the iterator needed. I can
> send a patch tomorrow. I actually could not access my other pc :-)
The "auto" is a feature added in
On 12 December 2011 15:12, D. Laszlo Sitzer wrote:
...
> I'm using the following software/versions:
>
> kernel 2.6.35-31-generic x86_64
> gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
> autoconf (GNU Autoconf) 2.67
> automake (GNU automake) 1.11.1
> GNU Make 3.81
> GNU bash, version 4.1.5(1)-release (
On 4 December 2011 09:07, Joerg Wunsch wrote:
> As Brandon Mason wrote:
>
>> Can I get one of the devs to produce a tar for the most recent version? I
>> need support for atmega328, which appears to not be supported in the most
>> recent tar (simulavr-0.1.2.7).
>
> simulavr 0.1 is a completely di
On 6 November 2011 22:49, Marek Pietrzak wrote:
> Hi,
>
> Recently I added a call to eeprom_read_byte from avrlibc to my project
> but it results in AvrDevice::Step returning -1. This is wrong I believe.
> I turned on trace output which resulted in the following:
>
> ../Debug/lcmeter.elf 0x12fc: _
On 23 October 2011 14:04, Sebastià Vila-Marta wrote:
> Hi,
>
> I detected a bug when tracing branch instructions: the labels associated to
> the target address are wrong.
> The problem is a consequence of a confusion between the real PC value and
> byte-measured PC value . I've sent a patch
> that
On 26 September 2011 21:42, Marek Pietrzak wrote:
> Petr,
>
> You added printfs ThreadList::OnCall(). Are they on purpose or were for
> debug only? My call stack has grown and I started getting strange
> messages.
Oops, they are debug-only. The particular code is not finished, though
you are safe
2011/9/14 Marek Pietrzak :
> On Wed, 2011-09-14 at 01:38 +0200, Petr Hluzín wrote:
>> 2011/9/13 Сергей Смирнов <5sergey55...@mail.ru>:
>> > Hi,
>> > is it possible to build pysimulavr under Visual Studio?
>>
>> The project files do not take SWI
2011/9/13 Сергей Смирнов <5sergey55...@mail.ru>:
> Hi,
> is it possible to build pysimulavr under Visual Studio?
The project files do not take SWIG in account. Therefore it is not
possible right now.
However I am anxious to try Python too, so if you are willing to wait
a week or two I hope I
On 17 August 2011 23:49, Marek Pietrzak wrote:
> I'm afraid Petr is right and current design doesn't support multiple gdb
> servers, or I do something wrong, anyway multiple instances for me lock
> one other.
GdbServer::Step() has a loop iterating over other servers (variable
GdbServer::allGdbSer
st never
considered the scenario.
> Am Montag, den 15.08.2011, 22:34 +0200 schrieb Petr Hluzín:
>> You cannot simulate multiple AVR chips with GDB because our GDB
>> processing code does not support multiple processes and we cannot
>> pretend multiple GDB servers now.
--
Petr Hluzin
On 15 August 2011 22:29, Marek Pietrzak wrote:
> I don't see the GdbServer class being exported to Python in SWIG file,
> so the answer is most likely no. Perhaps because it's kind of weird
> using gdb when you can get all about the internal state of the device
> with Python alone. Why do you want
On 15 August 2011 21:55, Sebastian
wrote:
> Hi,
> is it possible to connect with gdb to a core of a python simulation?
>
> Something like
> device = pysimulavr.AvrFactory.instance().makeDevice(mcu)
> device.Load(program)
> device.SetClockFreq(clock_setting)
> sim.Add(de
(This is a reply to
http://lists.nongnu.org/archive/html/simulavr-devel/2011-07/msg6.html.
Savannah's no-name mailinglist browser does not handle references
across month boundary.)
> On my System
>
>avr-objdump --all-headers --disassemble --source --debugging
> --syms >
On 1 August 2011 18:53, langure wrote:
> Hi.
> I work with atmega8 and I need for simulation interrupt and timer0,1,2,
> because
> I changed/wrote code for timer1, mask for tifr,timsk register (use
> irq_vtable for bit mask)
> add description for register timers (TCNT1L H,TCCR1A B,TIMSK,TIFR ...)
Hello
How did you build the ELF file?
What are the versions of gcc, binutils and gdb? WinAR?
I tried this:
avr-gcc -mmcu=atmega8 -Wa,--gdwarf2 experiment.S -o experiment.elf
avr-objdump --all-headers --disassemble --source --debugging --syms
experiment.elf > experiment.listing
$ avr-gcc --versio
2011/7/6 Сергей Смирнов <5sergey55...@mail.ru>:
> Are there any ready Python unit-tests for simulavr except for those 5 in the
> 'examples' location? Is there some kind of simulavr unit test database? How
> do you test simulavr when adding new models of microcontrollers?
There are no other t
On 29 May 2011 19:40, Joerg Wunsch wrote:
> As Onno Kortmann wrote:
>
>> > How to get the current version?
>> > Where is your repository?
Albrecht: The info is on the the main page on savannah. The info is up to date.
>> The most up-to-date source code can be fetched from git:
>>
>> git clone gi
Hi Raphaël
2011/5/13 Raphaël Martin :
>
> Hello,
> I'm gonna switch soon from ATmega32 to ATmega64, and I noticed that it
> is not yes supported by simulavr.
> I'm going to try to add it by myself but I wanted to ask before if
> anyone already wrote that patch ?
Nobody is working on new device su
Hello Sebastian
On 7 May 2011 18:26, Sebastian wrote:
> Hi,
> When compiling simulavr with gcc 4.6, I get some errors.
>
> The first one (NULL undefined) was easy to fix.
> #include
> in pin.h
You are right.
Personally, I would like it added in some kind of
include-the-boring-stuff.h hea
On 2 May 2011 20:48, ThomasK wrote:
>> Why do you think nightly build service is not usable for us?
>> Is it difficult to setup? If yes, isn't that a bug?
>
> Not really difficult if you don't want to test special cases. But the
> main point is, that in my opinion, you'll find only services, which
Hi folks
On 1 May 2011 17:26, ThomasK wrote:
> Hi list,
>
> I'm back after a long time ... ;-) (hopefully) It's a question of free time,
> of course.
>
> About nightly build service:
>
> At all, it's a good idea. In my work I see many such solutions. Some build
> quick and dirty - just for this p
2011/4/15 Сергей Смирнов <5sergey55...@mail.ru>:
>> What version of GDB are you using?
>> Does have "set remotetimeout 1" any effect?
>
> I'm using gdb 6.8
> Command "set remotetimeout 1" doesn't have any effect.
In file gdb_remotelogfile.txt:
w $qSupported#37
r +$PacketSize=800;qXfer:
On 14 April 2011 15:23, Tim Barrass wrote:
> ...
> Error: SWIG version >= 1.3.18 is required. You have 2.0.2. You should look
> at http://www.swig.org
Wow, the message look really weirdly incorrect. Seems like a bug in
the feature test macro.
We happen to be a patch for that [1]. Its early ver
2011/4/10 Сергей Смирнов <5sergey55...@mail.ru>:
>> Good. I recommend to not use Eclipse when we troubleshoot the bug.
>>
>> > But when I'm connecting avr-gdb to simulavr, Connect() function stops to
>> execute and ReadByte() begins to execute (5-10 times per second)
>>
>> Does ReadByte() retur
2011/3/22 Сергей Смирнов <5sergey55...@mail.ru>:
>
>> Your situation is strange due GDB sending data to simulavr but
>> simulavr behaves as the connection has not been opened yet.
>>
>> Try starting simulavr with --debug-gdb. (This will not fix the problem
>> but will print some diagnostic.)
>>
2011/3/16 Сергей Смирнов <5sergey55...@mail.ru>:
>> This means that simulavr is not responding to gdb at all. The message
>> 'warning: unrecognized item "timeout" in "qSupported" response' is
>> probably printed by Eclipse trying to parse error messages coming from
>> GDB. This indicates a bug
2011/3/16 Сергей Смирнов <5sergey55...@mail.ru>:
> Hello, I have some problems compiling simulavr (last version from
> 2011-03-06, Petr Hluzin branch) under MS Visual Studio 2008. The problem is
> that it can't find config.h and on that strings
>
> #include "config.h"
>
> I have
>
> fatal er
2011/3/11 Сергей Смирнов <5sergey55...@mail.ru>:
> Sorry me now )) I haven't caught your idea. You are right, I managed to set
> commands before connection in .gdbinit file and have got remotelogfile.txt:
>
> w $qSupported#37
> r
> w $qSupported#37
> r
> w $qSupported#37
> r
> w $qSupported
2011/3/9 Сергей Смирнов <5sergey55...@mail.ru>:
>> Simulavr (C++) does not send send word "timeout" in response to
>> "qSupported". In fact it does not use the string at all anywhere, so
>> it could not be due some mix of output streams or something.
>>
>> Set Eclipse to execute this command in
2011/3/8 Сергей Смирнов <5sergey55...@mail.ru>:
> Hello. Does anybody have any experience of working with simulavr and
> avr-gdb under eclipse?
> I'm using Eclipse with AVREclipsePlugin and it works fine with official
> C versions of simulavr
> (such as 0.1.2.6) with using avr-gdb
Hi folks
GDB can launch and connect to a simulator or other remote target by
typing "target remote | SIM". GDB will launch the program 'SIM',
attach its standard input and output internally and send remote
protocol packets to it. [1]
This has some advantages:
* user can have multiple simulation s
Hi folks
I just commited support for ATmega164A/164PA/324A/324PA/644A/644PA/1284/1284P.
(This is experimental. Please verify each peripheral using code which
is known to work on real silicon.)
ATmega644A is just like ATmega644, except it has additional USART.
Less coherent notes about porting fo
On 27 February 2011 00:25, Michael Hennebry
wrote:
> How thorough is the simulation of atmega168s and their siblings?
> For example, some of the code I would like to test depends on
> an assignment to SPDR changing MISO even when SCK isn't changing.
AVR151: Setup And Use of The SPI:
"When the SPI
Hi Onno
(This is my rant about Git/TortoiseGit. Others may want to skip reading it.)
On 21 December 2010 07:15, Onno Kortmann wrote:
> Hi Petr,
>> It seems my GIT client recently committed [1] John McCullough's patch
>> [2] which adds support for CAN devices.
>> It was an accident. By looking in
Hello
I tried to build the newest simulavr (from Git) and the build failed:
$ make
...
libtool: link: g++ -I/usr/include -g -O2 -Icmd -Iui -Ihwtimer -o
.libs/simulavr.exe main.o dumpargs.o .libs/adcpin.o
.libs/application.o .libs/at4433.o .libs/at8515.o
.libs/atmega668base.o .libs/atmega128.o .li
Hello
2011/2/17 Олег Большаков :
> ...
> I can also see many TODOs for atmega8 device in the last simulavr
> release 0.1.2.6.
>
> The question:
> Is the development of simulavr is still maintained?
>
> We are intersted in using some AVR-simulator. Is it reasonably to
> maintain simulavr in your op
On 17 February 2011 17:23, David Madden wrote:
> On 02/17/2011 07:57 AM, Petr Hluzín wrote:
>
>> Actually this is a bug in simulavr. In file src/cmd/gdbserver.cpp in
>> function GdbServer::gdb_read_memory(const char *pkt) change these
>> lines:
>
> Thanks, Petr. (I
On 17 February 2011 05:25, David Madden wrote:
> On 02/16/2011 08:14 PM, David Madden wrote:
>>
>> Hi, I'm a new user, hoping to use Simulavr to figure out how to run
>> FreeRTOS on an ATmega328.
>
> Uh oh, after more poking around, it's possible that it's a GDB
> communications (or pure GDB) issu
Hello folks!
This patch is a first try on implementing support for compiling with
MS Visual Studio.
The MinGW and native Linux builds should not be affected.
The patch may require some changes that are not commited to Savannah
repository. (They are in my local git working copy and I do not know
w
Ho Onno
On 16 January 2011 21:37, Onno Kortmann wrote:
> Hi Petr,
>> Adding getopt() implementation.
>> Disabling compilation of vpi.h (it uses some strange types and depends
>> on Verilog or something).
>> Changed some #includes.
>> Altered socket interface.
>> Crippled AvrDevice::Load() since i
Hi folks
Should we add support for building in Visual Studio?
I did that about a year ago and I think it involved only few changes.
Adding getopt() implementation.
Disabling compilation of vpi.h (it uses some strange types and depends
on Verilog or something).
Changed some #includes.
Altered sock
Hi folks
It seems my GIT client recently committed [1] John McCullough's patch
[2] which adds support for CAN devices.
It was an accident. By looking in the repository I do not even know
the meaning of what I just did.
I do understand the theory how git works (heck, I even read the
algebraic theo
Helo
On 11 December 2010 10:15, Onno Kortmann wrote:
> Hi,
>> mela, thank you for answering the the report!
>>
>> However users compiling a source code should not need to search on how to
>> do such simple task.
> I agree, but only for a release. Remember that this is compiling from
> repository.
Hi people
On 17 October 2010 21:35, Petr Hluzín wrote:
> Hi Thomas
>
> On 17 October 2010 19:09, Thomas Klepp wrote:
>> Hi Ivica,
>>
>>> I think the atmega16_32 interrupt vectors for EEPROM Ready are not
>>
>> Not only this interrupt, also some oth
Hello
On 19 October 2010 01:49, henne...@cableone.net wrote:
> On Mon Oct 18 18:02 , 'Petr Hluzín' sent:
>>Simulavr is running on desktop. Users can afford waste few KB if it
>>makes their or our lives easier. Such optimization does not make a
>>sense.
>>
Hi Thomas
On 17 October 2010 19:09, Thomas Klepp wrote:
> Hi Ivica,
>
>> I think the atmega16_32 interrupt vectors for EEPROM Ready are not
>
> Not only this interrupt, also some other around ... My mistake, I've
> compared mostly register set but not interrupt vector table too.
By looking at th
Hello
On 15 October 2010 21:30, Petr Hluzín wrote:
> I will commit the fix and review your new files tomorrow (in Europe),
> unless an other commiter is faster.
Fix committed [1]. I think there were some problems [2], verify if my
fix is correct.
The Atmega8 code leaves some registers
Hello
On 15 October 2010 20:27, Ivca Safranko wrote:
> Hallo,
>
> Simulavr is a great idea and I'd like to contribute to its development.
Great!
> I think the atmega16_32 interrupt vectors for EEPROM Ready are not
> equal:
>
> atmega16_32.cpp
>
> eeprom = new HWEeprom(this, irqSystem, ee_bytes,
t; Cheers,
> Knut
>
> Am 11.07.2010 22:33, schrieb Petr Hluzín:
> > There is a The AVR Eclipse Plugin which does that. More or less.
> > http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin
The AVR Eclipse Plugin kinda makes it easier to use the simulavr (but
no
Hi Sebastian and list
On 11 July 2010 22:15, Sebastian wrote:
> Maybe I'll try to implement TWI. But I've no plans yet, when to start -
> so don't expect results too soon (or at all).
This is my style of contributing, too.
> Has anyone thought about implementing TWI, yet? Any hints where to
> s
A month ago I accidentally send my reply privately to Thomas - instead
of to the list. Sorry, here it is.
-- Forwarded message --
From: Petr Hluzín
Date: 19 June 2010 12:47
Subject: Re: [Simulavr-devel] Eclipse project settings
To: ThomasK
Hello folks
On 19 June 2010 10:33
On 23 March 2010 22:36, Onno Kortmann wrote:
> It is not possible out-of-the-box, but you can implement new devices in
> simulavrxx quite easily.
"Easily". That is the thing Michael Hennebry was talking about [1].
Preparing a package for programing (for first time) is not trivial and
neither is g
Hello
On 24 March 2010 00:05, henne...@cableone.net wrote:
> On Tue Mar 23 14:20 , Onno Kortmann sent:
>
>>Hi Michael,
>>As soon as the git is setup, just mail me off-list with your potential
>>problems of getting the code. As it will not include any of the fancy
>>git-cvsimport stuff, doing a c
Hello
On 23 March 2010 12:26, ThomasK wrote:
> - in our fork we have marked TCL interface deprecated! In the current state
> it looks awful (hi Petr, I agree with you for gitk and this is the same, I
> think ;-) ) and we have nobody to maintain it! If anybody out there, which
> wants to maintain
Hello
On 22 March 2010 06:18, Joerg Wunsch wrote:
> As Onno Kortmann wrote:
>> - simulavr moves to git.
>
> You have to convince Michael and maybe Petr about that, not Eric or
> me. ;-)
Since all interrested parties are going to have commit access the
distributed nature of git will have no use.
Hello
(Replying to 3 mails at once to not increase the heat by excessive traffic.)
On 19 March 2010 23:25, Joerg Wunsch wrote:
> I'm an administrator
> here, yes, but that doesn't mean I would be patching a CVS tree that
> is not even used by the developers at all.
Well, someone has to. No one
Hello
(Replying to 3 mails at once to not increase the heat by excessive traffic.)
On 19 March 2010 23:25, Joerg Wunsch wrote:
> I'm an administrator
> here, yes, but that doesn't mean I would be patching a CVS tree that
> is not even used by the developers at all.
Well, someone has to. No one
Hello
On 17 March 2010 19:06, ThomasK wrote:
>
> My opinion: our GIT repo is in fact a fork now, nothing else. So, we (Onno
> and me) have decided, to make this official now. In the moment, we grow up a
> sourceforge project (avrs) with that fork. I think, it's the best way to
> handle it. We lea
Hi
(Second try, accidentally not replied to the list earlier.)
On 17 February 2010 21:51, Onno Kortmann wrote:
> Hi,
>> (Remaining changes are not user-visible.)
>>
>> These were found while adjusting the code for different handling of memory
>> access: reading/writing (after this patch) goes th
1 - 100 of 108 matches
Mail list logo
