Tuesday, December 18, 2012
Your Face is a Python
I was asked to find a way to programmatically analyze some log files - those files are a tab delimited format with something like 6 fields of data. This sort of thing I might have done in Perl at one time. However, having been some very long time since I did anything in Perl, and, I don't know, just not finding Perl very intuitive right now for some reason. With my recent discovery of the Trac software project management system, all written in Python, I decided it was time to jump right into some Python programming.
I have to say that it was pretty easy to knock together a simple text file parser... Python seems to be very clean and to the point. Maybe one day I'll stop using shell scripts and sed for everything (when all you have is a hammer, yada yada )..
Wednesday, December 12, 2012
Trac Setup
Trying to setup a Ubuntu Virtual Box to evaluate Trac (issue tracking system for software development projects).
There were a lot of installation steps, since it requires setting up Subversion in Apache in addtion to the Trac server itself. There is plenty of documentation how to do this, but I found a handy guide by David Winter that gets right to the point.
One small change I made is using SVNParentPath, with multiple repos under /var/lib/svn, e.g.
DAV svn
SVNParentPath /var/lib/svn
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/dav_svn.passwd
Require valid-user
I installed Trac (version 0.12.2-1build1) using apt-get.
Evaluation of some software peer review plugins for Trac:
PeerReviewPlugin: installed from the downloaded source zip file and followed the standard Trac plugin install instructions. When I attempted to open a new review I got the error "'NoneType' object has no attribute 'youngest_rev'". There was already a ticket - 7034 - for this issue and the multiple-repo.patch seems to address the problem. But when creating a new code review ... how to easily add the files based on a diff or a changeset? like the line by line comments though.
I want to see the files committed in conjunction with the ticket ... TicketModifiedFilesPlugin ...
but only worked on some tickets references?
Try CommitTicketUpdater and follow the instructions to enable the component.
Appears to setup correctly, but no information is added to tickets.
Tried some advice from the webs (maybe wasn't necessary after all?):
However, the updater requires the changeset author to have TICKET_MODIFY
permission to close tickets. If your commit username is different from
your Trac username, you will not have the required permission. So you
should disable that check by setting the "[ticket]
commit_ticket_update_check_
... because stupid me not properly "wikifying" my tag ... brackets dummy ... [re #4]
And then all is working after one more edit to the post-commit script:
# The Python egg cache directory is currently set to:
# /var/www/.python-eggs
export PYTHON_EGG_CACHE="/var/lib/trac"
CodeReviewerPlugin: ok .. simple ... no line by line comments. But get an error when try to submit the code review.
AttributeError: 'NoneType' object has no attribute 'get_changeset'
There were a lot of installation steps, since it requires setting up Subversion in Apache in addtion to the Trac server itself. There is plenty of documentation how to do this, but I found a handy guide by David Winter that gets right to the point.
One small change I made is using SVNParentPath, with multiple repos under /var/lib/svn, e.g.
DAV svn
SVNParentPath /var/lib/svn
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/dav_svn.passwd
Require valid-user
I installed Trac (version 0.12.2-1build1) using apt-get.
Evaluation of some software peer review plugins for Trac:
PeerReviewPlugin: installed from the downloaded source zip file and followed the standard Trac plugin install instructions. When I attempted to open a new review I got the error "'NoneType' object has no attribute 'youngest_rev'". There was already a ticket - 7034 - for this issue and the multiple-repo.patch seems to address the problem. But when creating a new code review ... how to easily add the files based on a diff or a changeset? like the line by line comments though.
I want to see the files committed in conjunction with the ticket ... TicketModifiedFilesPlugin ...
but only worked on some tickets references?
Try CommitTicketUpdater and follow the instructions to enable the component.
Appears to setup correctly, but no information is added to tickets.
Tried some advice from the webs (maybe wasn't necessary after all?):
However, the updater requires the changeset author to have TICKET_MODIFY
permission to close tickets. If your commit username is different from
your Trac username, you will not have the required permission. So you
should disable that check by setting the "[ticket]
commit_ticket_update_check_
... because stupid me not properly "wikifying" my tag ... brackets dummy ... [re #4]
And then all is working after one more edit to the post-commit script:
# The Python egg cache directory is currently set to:
# /var/www/.python-eggs
export PYTHON_EGG_CACHE="/var/lib/trac"
CodeReviewerPlugin: ok .. simple ... no line by line comments. But get an error when try to submit the code review.
AttributeError: 'NoneType' object has no attribute 'get_changeset'
Friday, September 21, 2012
NetBeans+gdb Breakpoints Fix/Workaround
NetBeans and gdb apparently don't always work well together. If you find that the debugger won't stop on breakpoints, there is an easy fix. (I believe this applies to NB + MinGW, not NB + Cygwin).
In Windows XP, I added the additional command arguments, i.e. "-J-Dgdb.breakpoints.shortpaths=true", in the shortcut by appending to the "Target" string, after the program name. Yes it is true, we are still using XP at my work!
This fix seems to get breakpoints completely functional... run to cursor (F4) still doesn't work but I guess that is just a slight nuisance.
Wait... there's more! I am surprised to find that I can't directly edit memory locations while debugging in NB. The workaround is to go directly to the console available in NB, but the console is not enabled by default in order to protect the innocent. There is an additional command line parameter which will enable the gdb console:
-J-Dgdb.console.window=true
Unfortunately, due to limitation of the gdb remote protocol, NB is not immediately notified of changes made to memory inside the gdb console... this requires closing and then reopening the memory window in order to force NB to synchronize with gdb.
In Windows XP, I added the additional command arguments, i.e. "-J-Dgdb.breakpoints.shortpaths=true", in the shortcut by appending to the "Target" string, after the program name. Yes it is true, we are still using XP at my work!
This fix seems to get breakpoints completely functional... run to cursor (F4) still doesn't work but I guess that is just a slight nuisance.
Wait... there's more! I am surprised to find that I can't directly edit memory locations while debugging in NB. The workaround is to go directly to the console available in NB, but the console is not enabled by default in order to protect the innocent. There is an additional command line parameter which will enable the gdb console:
-J-Dgdb.console.window=true
Unfortunately, due to limitation of the gdb remote protocol, NB is not immediately notified of changes made to memory inside the gdb console... this requires closing and then reopening the memory window in order to force NB to synchronize with gdb.
Thursday, August 9, 2012
Galaga Z80 Disassembly Uploaded
I've been pretty sidetracked lately but I finally got around to uploading the code for the Galaga Disassembly Project.
In order to rebuild the code and generate the ROM images for the program, you need to have a build environment with the asz80 assembler and sdcc compiler tools installed.
I've been working on and off on this project since 2001 (mostly off!). In 2001 I disassembled most of the code, primarily using MAME to analyze the code in the emulator and dump it to dis-assembly files. At the time I was building the resulting assembly code with a Z80 assembler that I had modified to support some of the undocumented opcodes. After a few months I moved on to other projects, and the project was not touched for some time.
In 2010 I got interested again after learning about the sdcc compiler. SDCC is interesting in that it targets the C language to many 8-bit micros. It is based on the asz80, which is a very advanced assembler and fairly unique in that it incorporates a linker. With this kind of compiler capability, I entertained the idea of porting the Galaga code to C on the original hardware Z80 architecture, but dropped that plan when I got interested in building C programs in gcc-m68k on the Genesis. I did a little work re-writing the Galaga code on the Genesis, but I doubt that will ever get completed. I've been looking a bit at SDL lately so maybe that's the direction I'll go.
The Galaga code is pretty fascinating in my opinion. Ideally I would have it translated to C, while preserving the structure and data organization as much as possible. We'll see what happens!
In order to rebuild the code and generate the ROM images for the program, you need to have a build environment with the asz80 assembler and sdcc compiler tools installed.
I've been working on and off on this project since 2001 (mostly off!). In 2001 I disassembled most of the code, primarily using MAME to analyze the code in the emulator and dump it to dis-assembly files. At the time I was building the resulting assembly code with a Z80 assembler that I had modified to support some of the undocumented opcodes. After a few months I moved on to other projects, and the project was not touched for some time.
In 2010 I got interested again after learning about the sdcc compiler. SDCC is interesting in that it targets the C language to many 8-bit micros. It is based on the asz80, which is a very advanced assembler and fairly unique in that it incorporates a linker. With this kind of compiler capability, I entertained the idea of porting the Galaga code to C on the original hardware Z80 architecture, but dropped that plan when I got interested in building C programs in gcc-m68k on the Genesis. I did a little work re-writing the Galaga code on the Genesis, but I doubt that will ever get completed. I've been looking a bit at SDL lately so maybe that's the direction I'll go.
The Galaga code is pretty fascinating in my opinion. Ideally I would have it translated to C, while preserving the structure and data organization as much as possible. We'll see what happens!
Wednesday, July 25, 2012
Spice It Up
I do not go around trying to pass myself off as a EE, but embedded software development does require a fair amount of knowledge in electronics and I thought it was high time to brush up on my circuit analysis skills ...a professional improvement activity! We have a PSpice license at my work, but it is usually needed by our EE for working on the board layout. I went looking for an alternative and discovered LTspice. Sadly this is only available for Windows, but it is free, and seems to provide fairly complete SPICE functionality in a GUI environment. I thought I'd make a few notes from my learning activities.
The following circuit is extracted from the fueling controller for which I write software in my job as a Control Systems Engineer. I thought I understood the function of the circuit, but it caused me considerable grief and wasted time trying to demonstrate the expected behavior in LTSpice.
In the circuit, Vout is connected to the gate of an N-channel MOSFET and the gate voltage is controlled by the 5V signal at Vctl. The non-inverting input of the LM2903 is connected to a voltage reference of approximately 500mV established by the potential divider at the junction of R3 and R4. The inverting input of the 2903 would be connected to the signal Voc, such that the comparator is turned on by the presence of a voltage on Voc in excess of 500mV. The intent is that Voc would be connected to some other diagnostic or protection circuitry, and used to detect when the gate drive to the MOSFET (connected at Vout, not shown) should be disabled because of some kind of fault condition. My understanding is that it is the open-collector characteristic of the LM2903 output that enables this to work as intended. Although the comparator can't drive it's output high (allowing Vout to be 5V when Vctl pulse is high), the 2903 is nonetheless able to pull Vout low when the inverting input voltage exceeds the .5V threshold. In the example circuit, Voc is connected to ground, in order to force the comparator ON for the demonstration.
The output of the circuit is shown in the waveform trace. I believe the open-collector characteristic of the 2903 is not being correctly modeled, preventing Vout from being pulled to 0V when the Vctl pulse goes low. The LM2903 model was downloaded from the ON website.
The following circuit, when simulated, provides the desired behavior. Vout is pulled low by Vctl even though the 2903 output state is high. It uses an LM2903 model downloaded from the Texas Instruments website.
The following circuit is extracted from the fueling controller for which I write software in my job as a Control Systems Engineer. I thought I understood the function of the circuit, but it caused me considerable grief and wasted time trying to demonstrate the expected behavior in LTSpice.
In the circuit, Vout is connected to the gate of an N-channel MOSFET and the gate voltage is controlled by the 5V signal at Vctl. The non-inverting input of the LM2903 is connected to a voltage reference of approximately 500mV established by the potential divider at the junction of R3 and R4. The inverting input of the 2903 would be connected to the signal Voc, such that the comparator is turned on by the presence of a voltage on Voc in excess of 500mV. The intent is that Voc would be connected to some other diagnostic or protection circuitry, and used to detect when the gate drive to the MOSFET (connected at Vout, not shown) should be disabled because of some kind of fault condition. My understanding is that it is the open-collector characteristic of the LM2903 output that enables this to work as intended. Although the comparator can't drive it's output high (allowing Vout to be 5V when Vctl pulse is high), the 2903 is nonetheless able to pull Vout low when the inverting input voltage exceeds the .5V threshold. In the example circuit, Voc is connected to ground, in order to force the comparator ON for the demonstration.
The output of the circuit is shown in the waveform trace. I believe the open-collector characteristic of the 2903 is not being correctly modeled, preventing Vout from being pulled to 0V when the Vctl pulse goes low. The LM2903 model was downloaded from the ON website.
The following circuit, when simulated, provides the desired behavior. Vout is pulled low by Vctl even though the 2903 output state is high. It uses an LM2903 model downloaded from the Texas Instruments website.
Apparently it is "buyer beware" when using 3rd party models in SPICE!
Sunday, June 17, 2012
Definitive Galaga Disassembly Project Created
Finally got around to importing some files to an svn repository on Google Code. I could not get the authentication to go through using svn command line (in Cygwin). Eventually I got it to work in Tortoise SVN ... the winning recipe is copied here for my convenience:
Comment by nbutterworth1953@gmail.com, Jan 10, 2009
Here's how to import your project using TortoiseSVN, the most popular Windows SVN client.
I assume you have created your Google Code (GC) project and it is called PROJECT and that the local source you want import is in a directory tree rooted at SOURCE.
a) Go to your GC home page and select the "Profile" menu - this will give you your UID and then click the "Settings" tab to find your PASSWORD - this is not the same as your gmail password.
b) In Windows explorer, right click n your SOURCE directory to get the Tortoise context menu and choose "Import..." This will pop up a dialog asking for the repository url. Enter the following:
https://PROJECT.googlecode.com/svn/trunk
c) You will be prompted for a userid & password - enter UID and PASSWORD described above.
Your project should now be uploaded to the GC repository. From now on you can use the Tortoise repo-browser and other tools to access it via the url above.
We'll see if it generates any interest....
Comment by nbutterworth1953@gmail.com, Jan 10, 2009
Here's how to import your project using TortoiseSVN, the most popular Windows SVN client.
I assume you have created your Google Code (GC) project and it is called PROJECT and that the local source you want import is in a directory tree rooted at SOURCE.
a) Go to your GC home page and select the "Profile" menu - this will give you your UID and then click the "Settings" tab to find your PASSWORD - this is not the same as your gmail password.
b) In Windows explorer, right click n your SOURCE directory to get the Tortoise context menu and choose "Import..." This will pop up a dialog asking for the repository url. Enter the following:
https://PROJECT.googlecode.com/svn/trunk
c) You will be prompted for a userid & password - enter UID and PASSWORD described above.
Your project should now be uploaded to the GC repository. From now on you can use the Tortoise repo-browser and other tools to access it via the url above.
Thursday, May 3, 2012
PICOS18 on dsPIC
Porting application code to a new processor, the dsPIC33EP64. The present code base is from the dsPIC30, and we have a brand new board design.
Working from Code Example CE443, a simple demonstration of the Timer 1 interrupt, I could verify the operation of the board with the scope. Adding some extra test leads to the board is very necessary, as the chip pins are much too fine for probing! Any new PIC requires some time fiddling about with the configuration "fuses" to get the basic chip configuration straightened out. In this case, a matter of setting up for an external crystal with PLL, and also setting the specific pins for the ICD debugger.
I am actually running the dsPIC version of "PICOS18" and have now verified that all the basic OS timing.
Having now got the board alive and working, I now need to get the ECAN device driver setup, and then the board will begin to resemble something with slightly higher function than a mere brick!
Working from Code Example CE443, a simple demonstration of the Timer 1 interrupt, I could verify the operation of the board with the scope. Adding some extra test leads to the board is very necessary, as the chip pins are much too fine for probing! Any new PIC requires some time fiddling about with the configuration "fuses" to get the basic chip configuration straightened out. In this case, a matter of setting up for an external crystal with PLL, and also setting the specific pins for the ICD debugger.
I am actually running the dsPIC version of "PICOS18" and have now verified that all the basic OS timing.
Having now got the board alive and working, I now need to get the ECAN device driver setup, and then the board will begin to resemble something with slightly higher function than a mere brick!
Subscribe to:
Posts (Atom)