You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(21) |
Sep
(22) |
Oct
(16) |
Nov
(18) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(103) |
Feb
(33) |
Mar
(20) |
Apr
(14) |
May
|
Jun
(14) |
Jul
(5) |
Aug
(11) |
Sep
(4) |
Oct
(1) |
Nov
(3) |
Dec
(17) |
2007 |
Jan
(8) |
Feb
(6) |
Mar
(6) |
Apr
(73) |
May
(19) |
Jun
(57) |
Jul
(18) |
Aug
(3) |
Sep
(22) |
Oct
(18) |
Nov
(45) |
Dec
(5) |
2008 |
Jan
|
Feb
(7) |
Mar
(2) |
Apr
(2) |
May
(61) |
Jun
(18) |
Jul
(20) |
Aug
(16) |
Sep
(41) |
Oct
(3) |
Nov
(75) |
Dec
(39) |
2009 |
Jan
(33) |
Feb
(131) |
Mar
(27) |
Apr
(47) |
May
(65) |
Jun
(37) |
Jul
(41) |
Aug
(27) |
Sep
(80) |
Oct
(106) |
Nov
(119) |
Dec
(35) |
2010 |
Jan
(42) |
Feb
(15) |
Mar
(17) |
Apr
(19) |
May
|
Jun
(2) |
Jul
(23) |
Aug
(12) |
Sep
(13) |
Oct
(13) |
Nov
(16) |
Dec
(1) |
2011 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
(6) |
May
(20) |
Jun
(14) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
|
Nov
(14) |
Dec
(2) |
2012 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
(4) |
May
(3) |
Jun
(1) |
Jul
(8) |
Aug
(7) |
Sep
(3) |
Oct
(3) |
Nov
|
Dec
(1) |
2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(6) |
Oct
(5) |
Nov
|
Dec
(1) |
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(6) |
Jul
(15) |
Aug
(1) |
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
2016 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(4) |
Jun
(1) |
Jul
|
Aug
(7) |
Sep
(3) |
Oct
(12) |
Nov
(7) |
Dec
(7) |
2017 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(2) |
May
|
Jun
(6) |
Jul
(1) |
Aug
(1) |
Sep
(8) |
Oct
|
Nov
(6) |
Dec
(2) |
2018 |
Jan
|
Feb
(1) |
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
(16) |
Nov
(2) |
Dec
(9) |
2019 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(2) |
Aug
|
Sep
(8) |
Oct
|
Nov
(1) |
Dec
(1) |
2021 |
Jan
(6) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
(1) |
Sep
(15) |
Oct
(3) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Jochen G. <joc...@ya...> - 2006-03-13 15:39:09
|
Hello,=20 while trying to set the capacity of a capacitor to=20 10 * 0.000 001 Farad ktechlab crashes. This is reproducible. while trying to set the resistance of a resostor to=20 10 * 0.000 001 Ohm ktechlab crashes. This is reproducible. Beste Gr=FC=DFe Jochen ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de |
From: Bryn D. <cu...@pr...> - 2006-03-12 12:56:16
|
This seems to have recently (?) manifested, only noticed it when I've been fiddling with some design stuff for my new game genie. Crashes when trying to place a DPST or alter the number of inputs on a rotary switch ( which isn't connected to anything ) after I already have, e.g. a 5v fixed source and a logic input down on the sheet. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000067 0x00120f40 in Switch::calculateCurrent () (gdb) bt #0 0x00120f40 in Switch::calculateCurrent () #1 0x0006e8e8 in CircuitDocument::calculateConnectorCurrents () #2 0x0006d8d4 in CircuitDocument::update () #3 0x00062ba0 in Canvas::update () ... Hopefully I can rebuild this tomorrow and get a line number for you, but was thinking you might like the heads up. B. -- cu...@pr... | Assistant Language Teacher http://progsoc.org/~curious/ | Kasukabe Board of Education http://livejournal.com/users/curious_jp | Saitama Prefecture, Japan |
From: Jochen G. <joc...@ya...> - 2006-03-11 09:30:25
|
Hello, first: ktechlab is cool! Thanks for your work! second: I did not find a buglist, so I hope this is the right place. third: Maybe that is a bug: I have made a simple series connexion with one batterie and four signal lam= ps. When I change the voltage, the demonstration of the curcuit is wrong. =46or example: Two lamps are yellow, Two are white. If i close and reopen the file, the demonstration is OK. Beste Gr=FC=DFe Jochen ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de |
From: Mike S. <pag...@gm...> - 2006-03-08 15:15:48
|
I opened ktechlab and selected circuit. As I was looking to build a circuit= . Switched windows to cruise the web. Found what I was looking for and switched back to ktechlab. upon placing the first capacitor. ktechlab crashed. Here is the backtrace: Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1234999072 (LWP 8721)] [KCrash handler] #5 0xb732592e in vtable for QGPlugin () from /usr/lib/libqt-mt.so.3 #6 0xb77c5f52 in KXMLGUI::ActionList::unplug () from /usr/lib/libkdeui.so.= 4 #7 0xb784e3cb in KXMLGUI::ContainerNode::unplugActionList () from /usr/lib/libkdeui.so.4 #8 0xb784e506 in KXMLGUI::ContainerNode::unplugActionList () from /usr/lib/libkdeui.so.4 #9 0xb784e545 in KXMLGUI::ContainerNode::unplugActionList () from /usr/lib/libkdeui.so.4 #10 0xb78d55e1 in KXMLGUIFactory::unplugActionList () from /usr/lib/libkdeui.so.4 #11 0xb78d5929 in KXMLGUIClient::unplugActionList () from /usr/lib/libkdeui.so.4 #12 0x080ebc3d in ItemDocument::canvasRightClick () #13 0x080b3a83 in CMRightClick::mousePressedInitial () #14 0x080bac86 in CMManager::mousePressEvent () #15 0x080e42f9 in ItemView::contentsMousePressEvent () #16 0xb6f914d7 in QScrollView::viewportMousePressEvent () from /usr/lib/libqt-mt.so.3 #17 0xb6f94187 in QScrollView::eventFilter () from /usr/lib/libqt-mt.so.3 #18 0xb6e57b52 in QObject::activate_filters () from /usr/lib/libqt-mt.so.3 #19 0xb6e57bdb in QObject::event () from /usr/lib/libqt-mt.so.3 #20 0xb6e95dcd in QWidget::event () from /usr/lib/libqt-mt.so.3 #21 0xb6df0698 in QApplication::internalNotify () from /usr/lib/libqt- mt.so.3 #22 0xb6df0c6b in QApplication::notify () from /usr/lib/libqt-mt.so.3 #23 0xb7595d4e in KApplication::notify () from /usr/lib/libkdecore.so.4 #24 0xb6d80653 in QApplication::sendSpontaneousEvent () from /usr/lib/libqt-mt.so.3 #25 0xb6d7bae4 in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3 #26 0xb6d79dbe in QApplication::x11ProcessEvent () from /usr/lib/libqt- mt.so.3 #27 0xb6d938c0 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #28 0xb6e08da2 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #29 0xb6e08ccb in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #30 0xb6def225 in QApplication::exec () from /usr/lib/libqt-mt.so.3 #31 0x08269bc9 in main () Mike -- Sometimes "The Majority" is nothing more that all the fools on the same side. |
From: Gary F. <ga...@si...> - 2006-03-06 17:47:36
|
excellent, that did it (I should have greped for the object names) thanks -- Scanned by: ClamAV 0.88/1235/Sun Jan 8 13:13:01 2006 On: Mon Mar 6 12:47:27 EST 2006 |
From: David S. <da...@bl...> - 2006-03-05 22:38:55
|
On Saturday 04 March 2006 22:48, Gary French wrote: > assuming I've gotten my code correct, is there an additional bit of voodoo > to get the new bits to show up? Add an appropriate "addLibraryItem()" piece of code to itemlibrary.cpp. |
From: Bryn D. <cu...@pr...> - 2006-03-05 15:17:57
|
On 03/03/2006, at 11:58 PM, David Saxton wrote: > Fixed that issue, via use of the header file qglobal.h. Could you > test it out > to make sure that it's detecting darwin ok? :) Went to give it a go, but svn up to revision 840 doesn't seem to have it quiiite right. Great thinking though, I didn't even know qglobal.h existed. On my system, qglobal.h defines __DARWIN_X11__, which then sets Q_OS_DARWIN. I'm not sure I like the way qglobal.h does Q_OS_MACX separately, but hey, it's not the end of the world. So, just change #if defined(_OS_DARWIN) || defined(Q_OS_MACX) to #if defined(Q_OS_DARWIN) || defined(Q_OS_MACX) and it works a charm - wonder if we shouldn't go with the Q_OS defines though instead of our own DARWIN. Going to try and find out what's bogging the microbe compiler on my program tomorrow - wish me luck. B. -- cu...@pr... | Assistant Language Teacher http://progsoc.org/~curious/ | Kasukabe Board of Education http://livejournal.com/users/curious_jp | Saitama Prefecture, Japan |
From: Bryn D. <cu...@pr...> - 2006-03-05 05:34:52
|
On 03/03/2006, at 11:58 PM, David Saxton wrote: > "ProcessorConstructorList * ProcessorConstructor::processor_list = 0;" Whoops! You are, of course, correct. Sorry about that. > Fixed that issue, via use of the header file qglobal.h. Could you > test it out > to make sure that it's detecting darwin ok? :) Sure can! I'll do this later on this afternoon. I actually have another minor patch to chuck past you, this one's for Microbe - I think it's a leftover from a time when "Type" was a string instead of an enum - --8<--8<-- Index: microbe/pic14.cpp =================================================================== --- microbe/pic14.cpp (revision 840) +++ microbe/pic14.cpp (working copy) @@ -277,7 +277,7 @@ bool PIC14::isValidInterrupt( const QString & interruptName ) const { - if(m_type == "P16F84" || m_type =="P16C84") + if( m_type == P16F84 || m_type == P16C84 ) { return ( interruptName == "change" || interruptName == "timer" || --8<--8<-- Also, while the code describes the interrupt here as "change", the docbook entry describes it as "changed". Having fixed that though, my Microbe compile seems to be stuck in a loop somewhere - it's been chugging away at 80%+ processor utilisation for the last 20 minutes. Oh well, you live, you learn. ;-) B. -- cu...@pr... | Assistant Language Teacher http://progsoc.org/~curious/ | Kasukabe Board of Education http://livejournal.com/users/curious_jp | Saitama Prefecture, Japan |
From: Gary F. <ga...@si...> - 2006-03-04 22:45:50
|
I'm attempting to add devices to the svn (as of 2006-03-02) version of ktechlab (specifically a 14 and 16 segment display and a line driver) I've added (for each new component): svg files to icons/pics/SVG associated targets in Makefile.am source and header file to src/electronics/components associated targets in Makefile.am additional strings in po/ktechlab.pot it builds, and the objects are showing up in .src/electronics/components/.libs/libcomponents.a, but are not available in the final executable. assuming I've gotten my code correct, is there an additional bit of voodoo to get the new bits to show up? running Slackware 10.2 with qt-3.3.5, building in a parallel dir (i.e. "../ktechlab.working/configure" style ) -- Scanned by: ClamAV 0.88/1235/Sun Jan 8 13:13:01 2006 On: Sat Mar 4 17:33:06 EST 2006 |
From: David S. <da...@bl...> - 2006-03-03 14:58:19
|
On Friday 03 March 2006 07:48, Bryn Davies wrote: > Seems to have an issue with not recognising any supported chips - > this leads to a variety of odd errors in kTechLab along the lines of > "problem with cod file". Mikey Sklar ( <sklarm@electric- > clothing.com> ) has a patch that seems to fix this behavior, at least > in my case, bundled with his fink builds of gpsim 0.21.11: > > --8<-cut here-8<-- > > --- gpsim-0.21.11/src/processor.cc 2005-10-01 17:12:55.000000000 > -0400 > +++ gpsim-0.21.11-cvs/src/processor.cc 2005-10-08 08:17:04.000000000 > -0400 > @@ -1970,7 +1970,7 @@ > return cpu_constructor(); > } > -ProcessorConstructorList * ProcessorConstructor::processor_list = > new ProcessorConstructorList(); > +ProcessorConstructorList * ProcessorConstructor::processor_list; > ProcessorConstructorList * ProcessorConstructor::GetList() { > if(processor_list == NULL) { > > --8<-cut here-8<-- > > If non-mac people try this out and it doesn't cause problems for > other people, perhaps it could be folded into the patch on the > ktechlab web page? "ProcessorConstructorList * ProcessorConstructor::processor_list;" This the new line looks a bit dodgy. As far as I know, the processor_list pointer will only be null if the computer memory was previously zero before being used by gpsim. So it might work occasionally, but only by luck... A better line would be "ProcessorConstructorList * ProcessorConstructor::processor_list = 0;" > Also, very happy to see my patch find it's way into SVN, but it > would be nice if I could figure out a way to make configure set - > DDARWIN automatically. Sadly, I don't know much about configure. :-( Fixed that issue, via use of the header file qglobal.h. Could you test it out to make sure that it's detecting darwin ok? :) David |
From: Bryn D. <cu...@pr...> - 2006-03-03 07:49:00
|
Seems to have an issue with not recognising any supported chips - this leads to a variety of odd errors in kTechLab along the lines of "problem with cod file". Mikey Sklar ( <sklarm@electric- clothing.com> ) has a patch that seems to fix this behavior, at least in my case, bundled with his fink builds of gpsim 0.21.11: --8<-cut here-8<-- --- gpsim-0.21.11/src/processor.cc 2005-10-01 17:12:55.000000000 -0400 +++ gpsim-0.21.11-cvs/src/processor.cc 2005-10-08 08:17:04.000000000 -0400 @@ -1970,7 +1970,7 @@ return cpu_constructor(); } -ProcessorConstructorList * ProcessorConstructor::processor_list = new ProcessorConstructorList(); +ProcessorConstructorList * ProcessorConstructor::processor_list; ProcessorConstructorList * ProcessorConstructor::GetList() { if(processor_list == NULL) { --8<-cut here-8<-- If non-mac people try this out and it doesn't cause problems for other people, perhaps it could be folded into the patch on the ktechlab web page? Also, very happy to see my patch find it's way into SVN, but it would be nice if I could figure out a way to make configure set - DDARWIN automatically. Sadly, I don't know much about configure. :-( Cheers, B. -- cu...@pr... | Assistant Language Teacher http://progsoc.org/~curious/ | Kasukabe Board of Education http://livejournal.com/users/curious_jp | Saitama Prefecture, Japan |
From: Bryn D. <cu...@pr...> - 2006-03-02 14:51:47
|
Is there a central repository for simulation bugs or suspected bugs? Or do we just send them to the mailing list? Is there a preferred format for dumping them in, or do we just send the circuit file and a screenshot illustrating the problem? Thanks. :-) I hope the problem is not my electronics, but I have a whole bunch of seemingly phantom emf arriving from nowhere and powering up circuits that shouldn't be alive. B. -- cu...@pr... | Assistant Language Teacher http://progsoc.org/~curious/ | Kasukabe Board of Education http://livejournal.com/users/curious_jp | Saitama Prefecture, Japan |
From: David S. <da...@bl...> - 2006-03-02 00:48:13
|
Another person has been has been looking into AVR implementation (although AFAIK he is not subscribed to the list, so I am forwarding this email to him). I've updated the wiki to reflect this :) David On Wednesday 01 March 2006 17:11, Byrom Dorsey wrote: > Hi KTechLab developers, > > First, thanks very much for providing this tool. Excellent. > > I, like many people, immediately wanted AVR support. I saw > David's note about AVR support here: > > http://wiki.ktechlab.org/tiki-index.php?page=General%20Features > > and I was wondering what sort of effort it would really take. > So, I wrote to Klaus Rudolph, the author and supporter for > simulavrxx, to ask what he thought of the idea. Here's part > of what Klaus said: > > "It should be a simple thing to include the simuavrxx to any > other gui/frontend, because I support already libraries for > python and tcl/tk and c/c++. So there is no reason why we should > not able to connect my 'pins' to your simulation...." > > I'm sure "simple" is relative and depends on many things, as we > all know. > > And Klaus asks: > > "Is there an interface description which 'my' simlator must fit > in? If so, send it to me and I will have a look inside the things." > > Is this layed out somewhere? If not, then maybe I can dig it out > of ktechlab and gpsim for Klaus. > > What do you guys think? |
From: David S. <da...@bl...> - 2006-03-02 00:41:39
|
On Sunday 26 February 2006 16:48, de...@on... wrote: > Hi David. > Have you pregressed with the bug I submited days ago? I haven't had a chance to (been very busy of the past week). I'll spend more time on the bug when I get some free time. > It was that about the oscilloscope and the PIC signals. > If I can help in any way, just ask. > > I don't know if it is related, but I noticed that my CPU is at 100% when > I run a simulation. This is true even with the window minimized. In fact > I noticed a great increase of CPU usage since 0.2. Some parts of the simulation have had their accuracy increased at the cost of CPU usage. But (assuming the high CPU usage you're referring to isn't an unknown bug...) it should go dramatically down before 0.4. > And I still find new ways to crash KTechLab (see attached bt). It's > strange. Seems that I have the curious ability to find the most bizarre > bugs in your program. Looks like another facet of a bug which should have been fixed...I'll look into it. > BTW, great program. I wish you'd put a Paypal donate button in the KTechLab > home page. Then there would be a problem of how to distribute the money to all those who have helped out with ktechlab. Just keep on sending me bug reports, and I'll (at least) be happy :) David |
From: David S. <da...@bl...> - 2006-03-02 00:35:33
|
Have a look at the instructions at the bottom of http://ktechlab.org/download/subversion.php These will ensure that you are using the latest sources (where the bug might have been fixed), and also give the configure option for enabling debugging "./configure --enable-debug=full"). Then, if it still crashes, then send the crash backlog (when Dr Konqui the crash handler) pops up. On Wednesday 01 March 2006 17:18, Furkan Duman wrote: > When i try to run KTechLab, i give segmentation fault error. I > compiled and build both gpsim v0.21.11 with KTechlab patch and > ktechlab v0.3 . > > How can i solve this problem and how can i send to you debug messages? |
From: Furkan D. <cod...@gm...> - 2006-03-01 17:18:56
|
V2hlbiBpIHRyeSB0byBydW4gS1RlY2hMYWIsIGkgZ2l2ZSBzZWdtZW50YXRpb24gZmF1bHQgZXJy b3IuIEkKY29tcGlsZWQgYW5kIGJ1aWxkIGJvdGggZ3BzaW0gdjAuMjEuMTEgd2l0aCBLVGVjaGxh YiBwYXRjaCBhbmQKa3RlY2hsYWIgdjAuMyAuCgpIb3cgY2FuIGkgc29sdmUgdGhpcyBwcm9ibGVt IGFuZCBob3cgY2FuIGkgc2VuZCB0byB5b3UgZGVidWcgbWVzc2FnZXM/Cg== |
From: Byrom D. <by...@co...> - 2006-03-01 17:11:23
|
Hi KTechLab developers, First, thanks very much for providing this tool. Excellent. I, like many people, immediately wanted AVR support. I saw David's note about AVR support here: http://wiki.ktechlab.org/tiki-index.php?page=General%20Features and I was wondering what sort of effort it would really take. So, I wrote to Klaus Rudolph, the author and supporter for simulavrxx, to ask what he thought of the idea. Here's part of what Klaus said: "It should be a simple thing to include the simuavrxx to any other gui/frontend, because I support already libraries for python and tcl/tk and c/c++. So there is no reason why we should not able to connect my 'pins' to your simulation...." I'm sure "simple" is relative and depends on many things, as we all know. And Klaus asks: "Is there an interface description which 'my' simlator must fit in? If so, send it to me and I will have a look inside the things." Is this layed out somewhere? If not, then maybe I can dig it out of ktechlab and gpsim for Klaus. What do you guys think? Byrom |
From: nathan s. <nat...@ne...> - 2006-02-28 17:09:50
|
great program, any way that i can add a relay short and sweet -- Regards Nathan Silveston Sheerness Lifeboat Crew /ILB Mechanic M3ILB |
From: Bryn D. <cu...@pr...> - 2006-02-28 14:37:31
|
Hi, all. I hope this is the right place for this, and I hope somebody else hasn't already done this. It works pretty well, but the parallel port node is effectively disabled in the process, because of a lack of a unified API for parallel devices in Darwin. First, you'll need the kde & qt libraries. The quickest way to do this is probably to just install KDE out of fink. Install gpsim and gputils to taste, and then... Perform the checkout in a directory with no spaces in it, or ar will barf everywhere. Do the make -f Makefile.cvs to generate the configure script. Apply the following patches: Index: src/icndocument.cpp =================================================================== --- src/icndocument.cpp (revision 837) +++ src/icndocument.cpp (working copy) @@ -77,7 +77,7 @@ m_nodeGroupList.clear(); const GuardedNodeGroupList::iterator nglEnd = ngToDelete.end(); for ( GuardedNodeGroupList::iterator it = ngToDelete.begin(); it != nglEnd; ++it ) - delete *it; + delete (NodeGroup *)(*it); delete m_cells; m_cells = 0l; Index: src/electronics/port.cpp =================================================================== --- src/electronics/port.cpp (revision 837) +++ src/electronics/port.cpp (working copy) @@ -14,7 +14,9 @@ #include <errno.h> #include <fcntl.h> -#include <linux/ppdev.h> +#ifndef DARWIN + #include <linux/ppdev.h> +#endif #include <sys/ioctl.h> #include <unistd.h> @@ -31,7 +33,11 @@ QStringList Port::ports( unsigned probeResult ) { +#ifndef DARWIN return SerialPort::ports(probeResult) + ParallelPort::ports (probeResult); +#else + return SerialPort::ports(probeResult); +#endif } //END class Port @@ -238,12 +244,30 @@ //END class SerialPort - //BEGIN class ParallelPort +// I wasn't able to find any documentation on programming the parallel port +// in Darwin, so I've just functionally neutered this section. Apparently +// parallel output is handled on a case by case basis (???) by the +// manufacturer of whatever USB dongle is, unless they build it as a +// Comms class device, in which case it is treated as a serial device. +// ( Info from Garth Cummings, Apple Developer Technical Support ) + const int IRQ_MODE_BIT = 1 << 20; // Controls if pin 10 (Ack) causes interrupts const int INPUT_MODE_BIT = 1 << 21; // Controls if the data pins are input or output const int ALWAYS_INPUT_PINS = ParallelPort::STATUS_PINS; +// No code using these values will be reached on Darwin, this is just to +// keep the preprocessor happy. +#ifdef DARWIN + #define PPRDATA 0xFACADE + #define PPRCONTROL 0xC001D00D + #define PPWDATA 0xC0EDBABE + #define PPWCONTROL 0xFEEDFACE + #define PPRSTATUS 0xBAADF00D + #define PPCLAIM 0xDEADBEEF + #define PPRELEASE 0xCAFE +#endif + const int IOCTL_REG_READ[3] = { PPRDATA, PPRSTATUS, @@ -349,6 +373,9 @@ //BEGIN Register-oriented operations uchar ParallelPort::readFromRegister( Register reg ) { +#ifdef DARWIN + return 0; +#endif if ( m_file == -1 ) return 0; @@ -364,6 +391,9 @@ void ParallelPort::writeToRegister( Register reg, uchar value ) { +#ifdef DARWIN + return; +#endif if ( m_file == -1 ) return; @@ -431,6 +461,9 @@ Port::ProbeResult ParallelPort::probe( const QString & port ) { +#ifdef DARWIN + return Port::DoesntExist; +#endif int file = open( port.ascii(), O_RDWR ); if ( file == -1 ) return Port::DoesntExist; @@ -450,6 +483,9 @@ QStringList ParallelPort::ports( unsigned probeResult ) { QStringList list; +#ifdef DARWIN + return list; +#endif for ( unsigned i = 0; i < 8; ++i ) { @@ -471,6 +507,10 @@ bool ParallelPort::openPort( const QString & port ) { +#ifdef DARWIN + kdWarning() << k_funcinfo << "Parallel ports disabled on Darwin" << endl; + return false; +#endif if ( m_file != -1 ) { kdWarning() << k_funcinfo << "Port already open" << endl; @@ -499,6 +539,9 @@ void ParallelPort::closePort() { +#ifdef DARWIN + return; +#endif if ( m_file == -1 ) return; @@ -511,4 +554,3 @@ m_file = -1; } //END class ParallelPort - Index: src/electronics/pin.cpp =================================================================== --- src/electronics/pin.cpp (revision 837) +++ src/electronics/pin.cpp (working copy) @@ -29,11 +29,11 @@ { WireList::iterator end = m_inputWireList.end(); for ( WireList::iterator it = m_inputWireList.begin(); it != end; + +it ) - delete *it; + delete (Wire *)(*it); end = m_outputWireList.end(); for ( WireList::iterator it = m_outputWireList.begin(); it != end; + +it ) - delete *it; + delete (Wire *)(*it); } ( Patches end. ) Because qt out of fink is compiled with gcc-3.3, as opposed to Apple's shipping 4.0, you'll need to build ktechlab with 3.3 as well: CC=gcc-3.3; CXX=g++-3.3; CPPFLAGS="-I/sw/include -L/sw/lib - DDARWIN"; WANT_AUTOCONF_2_5=1; ./configure --with-qt-includes=/sw/ include/qt --with-qt-libraries=/sw/lib && make After this, you can do a make install and enjoy! Thanks for the great software, guys! Anything that minimises my time working with a real soldering iron is always greatly appreciated! Otsukaresama deshita, Bryn. -- cu...@pr... | Assistant Language Teacher http://progsoc.org/~curious/ | Kasukabe Board of Education http://livejournal.com/users/curious_jp | Saitama Prefecture, Japan |
From: <de...@on...> - 2006-02-26 16:49:06
|
Hi David. Have you pregressed with the bug I submited days ago? It was that about the oscilloscope and the PIC signals. If I can help in any way, just ask. I don't know if it is related, but I noticed that my CPU is at 100% when I run a simulation. This is true even with the window minimized. In fact I noticed a great increase of CPU usage since 0.2. And I still find new ways to crash KTechLab (see attached bt). It's stran= ge. Seems that I have the curious ability to find the most bizarre bugs in yo= ur program. BTW, great program. I wish you'd put a Paypal donate button in the KTechL= ab home page. |
From: asraniel <asr...@fr...> - 2006-02-21 14:25:53
|
It would be nice if there was a possibility to export the picture in the oscilloscope as a picture, tank you :-) Beat Wolf |
From: <de...@on...> - 2006-02-19 20:10:10
|
I think this bug is not completely fixed. I compiled svn revision 828 today, and found the following results. This program produces a perfect square wave on pin 1, as it should. loop: BSF PORTA, 1 NOP NOP NOP BCF PORTA,1 NOP GOTO loop This other doesn't (low value stays for twice the time of the high). Note= that it's almost the same of the first example. See attached image (examp= le2). loop: BSF PORTA, 1 NOP NOP ;NOP BCF PORTA,1 ;NOP GOTO loop This other is strange. The wave goes like that: 1 time high, 2 times low,= 2 times high, 2 times low and repeat. It's irregular. See attached image (example3). loop: BSF PORTA, 1 NOP NOP ;NOP BCF PORTA,1 NOP GOTO loop This one is also irregular. It's the inverse wave of the later. loop: BSF PORTA, 1 NOP NOP NOP BCF PORTA,1 ;NOP GOTO loop This is always on low. loop: BSF PORTA, 1 ;NOP ;NOP ;NOP BCF PORTA,1 ;NOP ; 0 or more NOP here GOTO loop Also I attached 2 more backtraces. If you want more information just ask. I'm happy to help. |
From: David S. <da...@bl...> - 2006-02-18 19:33:54
|
Thanks for the backtraces. ktechlab-bt1.txt: Fixed. It was crashing when a component was deleted too quickly after being created (such as when quickly dragging a component onto and then off the work area). ktechlab-bt2.txt: This doesn't look related to ktechlab, but to the kate editor. On Thursday 16 February 2006 23:59, de...@on... wrote: > Two backtraces are attached. The second one is a bit strange. I don't know > if it is related to KTechLab. Before the crash the following output was > sent to the console: > > *** glibc detected *** malloc(): memory corruption (fast): 0x099ee409 *** AFAIK, that message occurs when the program tries to do strange things (which often indicate buffer overflows, etc). It's a safety check mechanism. > KCrash: Application 'ktechlab' crashing... |
From: David S. <da...@bl...> - 2006-02-18 14:02:20
|
Fixed. Thanks for the report :) On Friday 17 February 2006 14:28, de...@on... wrote: > Recently I was experimenting with little programs and KTechLab, but > sometimes strange things happen. > For example, why is this program producing a perfect square wave in RA4 > output? > > loop: > BSF PORTA, 4 > BCF PORTA,4 > GOTO loop > > According to the pic specification, GOTO should take 2 cycles and B?F > should take only 1 cycle. > > To correct this, we must add two NOP's after BSF, is this correct? > With this little program we should have a perfect square wave on the RA4 > pin. > > loop: > BSF PORTA, 4 > NOP > NOP > BCF PORTA,4 > GOTO loop > |
From: David S. <da...@bl...> - 2006-02-18 11:40:40
|
On Saturday 18 February 2006 10:29, David Saxton wrote: > There was a bug in the oscilloscope which meant it didn't show anything > when zoomed in. > > After fixing that though, I tested your example programs, and they behave > as they should (see oscilloscope outputs program1.png, program2.png for the > first and second programs respectively). Sorry, ignore that. There is indeed a bug in toggling PORTA,4 (which doesn't apply to any other pins). RA4 state is only getting changed after e.g. the BCF instruction executes twice, so that what happens is looking like this: BSF // goes high BCF // stays high BSF // stays high BCF // goes low BSF // stays low BCF // stays low (and back to the top). I'll try and fix it. |