tag:blogger.com,1999:blog-42747946158166900622024-03-10T04:45:52.499+02:00risc-a-dayPicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.comBlogger31125tag:blogger.com,1999:blog-4274794615816690062.post-24338585873736536882018-12-15T23:08:00.001+02:002020-09-24T18:04:58.025+03:00Configuring CAN interface during bootThis is an easy way to configure a CAN bus interface during boot. Just create a new config file:<br />
<br />
<pre>$ sudo nano /etc/network/interfaces.d/can0</pre><br />
...and add the following:<br />
<pre>allow-hotplug can0
iface can0 can static
bitrate 125000</pre><br />
Supported bitrates are 125000, 250000, 500000, 1000000 for standard CAN (non-FD).PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-3125876292985440992015-10-25T03:35:00.001+03:002015-10-25T03:38:47.765+03:00Creating local mirror for Buildroot package sourcesWhen you need to frequently and quickly rebuild Buildroot for a variety of reasons, there's a neat feature in Buildroot that allows you to use a local source mirror, so you can avoid wasting bandwidth and unnecessary waiting for downloads.<br />
<br />
Here's a list of the BR variables, which configure the mirroring behavior:<br />
<br />
<pre>BR2_PRIMARY_SITE
BR2_PRIMARY_SITE_ONLY
BR2_BACKUP_SITE
BR2_KERNEL_MIRROR
BR2_GNU_MIRROR
BR2_LUAROCKS_MIRROR
BR2_CPAN_MIRROR</pre><br />
The variables usage should be pretty obvious, but as always don't hesitate to take a look at the Config.in, where the variables are documented (or use menuconfig and go to "Build options", "Mirrors and Download locations").<br />
<br />
Basically you have 2 ways to change these variables - either edit them in Config.in file, or assign them in your boards's configuration file (configs/boardname_defconfig). The difference is that boardname_defconfig affects only your board, and Config.in affects all boards' builds. <br />
<br />
Here's a very simple example of making a local mirror for all sources, just add this to your boardname_defconfig:<br />
<br />
<pre># Use local source mirror
BR2_PRIMARY_SITE="http://www.myserver.org/mirrors/buildroot"</pre><br />
Of course the best place to put your server is inside your LAN, which will guarantee sub-second downloads during the build process.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com3tag:blogger.com,1999:blog-4274794615816690062.post-72747741140839038222015-08-12T18:21:00.002+03:002015-08-12T18:22:54.327+03:00A closer look at GStreamer pipelinesOne common issue people have with GStreamer is to understand what is the actual dynamic pipeline built via gst-launch command-line tool. There's a neat mechanism to extract the information from the pipeline, including the full media graph and all plugins/pads parameters. Here's how.<br />
<br />
GStreamer can dump media graphs in Graphviz .dot format, in a location pointed by GST_DEBUG_DUMP_DOT_DIR env-var:<br />
<br />
<pre>$ export GST_DEBUG_DUMP_DOT_DIR=/tmp</pre><br />
Now run gst-launch in the console, it will automatically create .dot files in /tmp, one per state transition:<br />
<br />
<pre>$ gst-launch playbin2 uri=file:///test.mp4
^C</pre><br />
Now we we can convert the .dot files to to PNG images:<br />
<br />
<pre>$ cd /tmp
$ for i in *.dot; do dot -Tpng -O $i; done</pre><br />
There's a ton of useful info in the media graphs, make sure to check them out!<br />
<br />
All credits go to GStreamer team's online docs: <a href="http://docs.gstreamer.com/display/GstSDK/Basic+tutorial+11%3A+Debugging+tools">http://docs.gstreamer.com/display/GstSDK/Basic+tutorial+11%3A+Debugging+tools</a>PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-51290888052825339252015-05-04T12:56:00.001+03:002015-05-04T12:57:04.678+03:00Building Yocto 1.8 "Fido" for i.MX6 Quick guide how to download and build Yocto 1.8 "Fido" for i.MX6 (same as my previous post about "dizzy"):<br />
<br />
<pre>mkdir ~/bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
PATH=$PATH:~/bin
mkdir yocto-fido-sabresd && cd yocto-fido-sabresd
repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b fido && repo sync
source ./setup-environment build
bitbake core-image-minimal</pre><br />
The default target machine is "imx6qsabresd", but you can change it in your conf/local.conf file.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com2tag:blogger.com,1999:blog-4274794615816690062.post-88414714986799150172015-05-01T02:33:00.000+03:002015-05-01T02:33:49.493+03:00Poor man's paddle (CW key)I was impressed by <a href="http://members.ziggo.nl/cmulder/paddle.htm">PA0CMU's web site</a>, and decided to do myself a homebrew CW key. My preferences were to have single lever key (called "paddle"). Why exactly I wanted such type of morse key - don't know, it just looked more convenient to me.<br />
<br />
My requirements for the project materials were:<br />
- to use only cheap and easily accessible materials;<br />
- to be manufactured easily without needing special instruments and machines.<br />
<br />
In addition, I wanted to extend PA0CMU's idea by:<br />
- prevent flexing the copper-clad board pieces by adding triangle pieces in the corners;<br />
- using contacts from a off-the-shelf automotive relay, instead of screw and copper surface contact (it will oxidize sooner or later, as it's not protected);<br />
- mounting a wooden handle, which is much pleasant for touching/using than the copper clad board.<br />
<br />
So, here are my materials:<br />
- double-sided copper clad (PCB). I just had that handy, and took advantage of soldering both sides for better mechanical strength.<br />
- 2x low-cost automotive relays (Sun Hold SG4-1220A), used for their contacts (but probably any automotive power/high-current relay will do the job);<br />
- 2x icecream sticks (for the key handle);<br />
- cable + 3.5mm connector cut from old damaged headphones.<br />
<br />
Here's a photo of my good old Icom IC-706 MKII and my hand-made key:<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDdifPfE2BRcyeLr-A02eC3vDkzp6AFH_3bxOMozL0opVMxfJemnMEZvGqYH8CwomTtoPuSrHNe5R3905OgTFJQhDrZNGrJ4vHmyBkP6gcgwGvnDDDA_uQhaX0v2IRFIbttYtaqAqpbq4/s1600/cw_paddle_09.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDdifPfE2BRcyeLr-A02eC3vDkzp6AFH_3bxOMozL0opVMxfJemnMEZvGqYH8CwomTtoPuSrHNe5R3905OgTFJQhDrZNGrJ4vHmyBkP6gcgwGvnDDDA_uQhaX0v2IRFIbttYtaqAqpbq4/s640/cw_paddle_09.jpg" /></a></div><br />
I have to admit that I haven't used mechanical drawing diagram at all - I was just looking at PA0CMU's key and choosing materials/sizes which looked reasonable, and in the end I wanted to build this more key just for an hour or two. After I made the key I just rushed to connect it to my transceiver so I can try it and didn't bothered to properly fix the cable... but I'll have to do it anyway.<br />
<br />
Here are more detailed pictures of the key:<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgye9HPehVgmOdcn1zQKElqhd7IazKukQZy2fujqI1LkSn7EPdGjY9l0okb2nbxa-sG__TqhvByl-uD_mfF0jsdtilZYVeY2q-Y87WGbDS-LZea_uGIKNP1cqzVDkJlJJYYJs7izVdFFxY/s1600/cw_paddle_01.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgye9HPehVgmOdcn1zQKElqhd7IazKukQZy2fujqI1LkSn7EPdGjY9l0okb2nbxa-sG__TqhvByl-uD_mfF0jsdtilZYVeY2q-Y87WGbDS-LZea_uGIKNP1cqzVDkJlJJYYJs7izVdFFxY/s640/cw_paddle_01.jpg" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiUSfIbRtHobRcU3nHTl9CsBxgXOH6Dl7FWP0yKDFDKrSrEShKwUcz1bttyXrZPfq3YEQV_kF5Qf44JBPiLr8Rb7RcQDDmGou7QTSWfjwfwxeRsFdSxnFqRSN20ORLrk7TJeRxUmT8Y3tU/s1600/cw_paddle_02.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiUSfIbRtHobRcU3nHTl9CsBxgXOH6Dl7FWP0yKDFDKrSrEShKwUcz1bttyXrZPfq3YEQV_kF5Qf44JBPiLr8Rb7RcQDDmGou7QTSWfjwfwxeRsFdSxnFqRSN20ORLrk7TJeRxUmT8Y3tU/s640/cw_paddle_02.jpg" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhn3TwYEt650zD7J8fl5j7bOzLIaw8pgxnYYTJ_1MMbYDm9I3u3r-r4rfsC1cfrHtI-vzNoHB-5J8krUBQ6E-FQunbefL7_vSrORDemPX6Z1aR1YW4t15zCli2nP5-jkwk95anblT7BbDE/s1600/cw_paddle_03.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhn3TwYEt650zD7J8fl5j7bOzLIaw8pgxnYYTJ_1MMbYDm9I3u3r-r4rfsC1cfrHtI-vzNoHB-5J8krUBQ6E-FQunbefL7_vSrORDemPX6Z1aR1YW4t15zCli2nP5-jkwk95anblT7BbDE/s640/cw_paddle_03.jpg" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQ0KRjeHohtxTmLHcxlvRrdGZGLVA1p3jhXFACGcv4bui6dLZz-aSfyzG3uo_qG4JJt7QPJ97Xlvn7kISxTQtd-nz8Sp5rj24hT-195Bio-UfYKFuEfl3ZV_MwHTM_ApIGfwWWTX5K158/s1600/cw_paddle_04.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQ0KRjeHohtxTmLHcxlvRrdGZGLVA1p3jhXFACGcv4bui6dLZz-aSfyzG3uo_qG4JJt7QPJ97Xlvn7kISxTQtd-nz8Sp5rj24hT-195Bio-UfYKFuEfl3ZV_MwHTM_ApIGfwWWTX5K158/s640/cw_paddle_04.jpg" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAnDGCThy_6MifUkf7w1JCnQYk3k3OJfYQiwhEP4WZQBslkXtjAaqqu7DeaOmes9Ur1aEMjOP5IfjZcnl7QgT-CKxIt-xgEGSuIxYGN2QJZKdGF8gc2vmysifeaBdyB9mIrYLSeTmrWhA/s1600/cw_paddle_05.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAnDGCThy_6MifUkf7w1JCnQYk3k3OJfYQiwhEP4WZQBslkXtjAaqqu7DeaOmes9Ur1aEMjOP5IfjZcnl7QgT-CKxIt-xgEGSuIxYGN2QJZKdGF8gc2vmysifeaBdyB9mIrYLSeTmrWhA/s640/cw_paddle_05.jpg" /></a></div><br />
Note that the screws are used to adjust the distance of side motion and to center the lever. The actual electrical contact is done by the relay pieces.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9roA9zwOeIWwBSnqptEcgFWA-RTDZhIh1J2S3YFGQMsmbLs_fp3OdHt3mxQLxeIqdJjhI-y5pGL5gkq04IrmpCQ2ZsTdYORgPeN-zQfx7Sg3DI3Vhqmn5AgKRc16Nwlx-11QmYj4WTV4/s1600/cw_paddle_06.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9roA9zwOeIWwBSnqptEcgFWA-RTDZhIh1J2S3YFGQMsmbLs_fp3OdHt3mxQLxeIqdJjhI-y5pGL5gkq04IrmpCQ2ZsTdYORgPeN-zQfx7Sg3DI3Vhqmn5AgKRc16Nwlx-11QmYj4WTV4/s640/cw_paddle_06.jpg" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7x_5IvXIoyaPNu3rOTXWbnfaHQd7UsR0S9nVwXDWChFbPwCpbodWIqEsZAvF1PHUgSerjW47Vm46d2uFDZRWcE591opds0EP0YDqyE5MPL85JSnfC65w3RMJNJxYqE5Jn9qmMBopQMaU/s1600/cw_paddle_07.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7x_5IvXIoyaPNu3rOTXWbnfaHQd7UsR0S9nVwXDWChFbPwCpbodWIqEsZAvF1PHUgSerjW47Vm46d2uFDZRWcE591opds0EP0YDqyE5MPL85JSnfC65w3RMJNJxYqE5Jn9qmMBopQMaU/s640/cw_paddle_07.jpg" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBKC_jOzi_KoUgXbPiMhQlAMDyPy1sMONGk9ViwvYYkTb1E-seopvlwCgYJkW9XIqHLxyeXd4l56zUxDgVYUcOxidfx1gNDYEXkgxbL2iZdPRttvkcTV0HpuOS8Q3fIzM2y6dNsoXvUUo/s1600/cw_paddle_08.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBKC_jOzi_KoUgXbPiMhQlAMDyPy1sMONGk9ViwvYYkTb1E-seopvlwCgYJkW9XIqHLxyeXd4l56zUxDgVYUcOxidfx1gNDYEXkgxbL2iZdPRttvkcTV0HpuOS8Q3fIzM2y6dNsoXvUUo/s640/cw_paddle_08.jpg" /></a></div><br />
The original purpose of this hole was to make the material more flexible in this point. It turned out that it became too flexible, so it's up to you to decide how you like the lever stiffness.<br />
<br />
PS: This is an English translation of my original article written in Aug.2011.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-88936287098434348232015-04-29T23:10:00.000+03:002015-04-29T23:10:12.074+03:00FTP must die!Just stumbled upon <a href="http://mywiki.wooledge.org/FtpMustDie">this article</a>, mentioned in the <a href="https://kernel.org/hurr-durr-ima-sheep.html">"News" section on kernel.org</a>.<br />
Needless to say that I agree with the author. So let's help FTP die with honor, long live the SCP!PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-57753792126431440232015-04-03T09:01:00.001+03:002015-04-03T09:02:30.475+03:00Securing the SSH serverThis is my checklist of TODO things to make my SSH daemons more "Internet-ready":<br />
<br />
1. Copy my public key to the remote host:<br />
<pre>ssh-copy-id remote_host</pre><br />
2. Login on the remote host<br />
<br />
<pre>ssh remote_host</pre><br />
3. Edit the /etc/ssh/sshd_config file and change the following configuration options:<br />
<br />
<pre>ChallengeResponseAuthentication no
LoginGraceTime 30
MaxStartups 2:30:10
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
UsePAM no</pre><br />
4. Restart the SSH daemon, but don't disconnect the SSH session:<br />
<br />
<pre>sudo service ssh restart</pre><br />
5. Open another shell and verify that pubkey authentication now works:<br />
<br />
<pre>ssh -v remote_host</pre><br />
6. Observe that:<br />
- Now I logged without typing my password<br />
- The SSH client printed the following message:<br />
<br />
<pre>debug: Authentication succeeded (publickey)</pre><br />
That's it.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-48253557385233733742015-03-26T18:22:00.001+02:002015-03-26T18:24:56.203+02:00Mainline Buildroot for RIoTboardNow that we have a Buildroot support for our lovely RIoTboards, lets try it. Here's short guide how to compile and run it (copy/paste from the readme.txt):<br />
<br />
<pre>1. Compiling buildroot
----------------------
make riotboard_defconfig
make
2. Installing buildroot
-----------------------
Prepare an SD-card and plug it into your card reader. Write the bootloader to
your SD-card:
sudo dd if=output/images/u-boot.imx of=/dev/sdX bs=1k seek=1
Create 1 partition on the SD-card using your favourite tool. The partition
should be big enough to hold your rootfs, for example 128MiB. Here's how an
example of such partition layout:
Device Boot Start End Blocks Id System
/dev/sdX1 2048 264191 131072 83 Linux
Format the SD-card partition with your favourite filesystem:
sudo mkfs.ext2 /dev/sdX1
Deploy your rootfs to the SD-card:
sudo mkdir /mnt/sdcard/
sudo mount /dev/sdX1 /mnt/sdcard/
sudo tar xf rootfs.tar -C /mnt/sdcard/
sudo umount /dev/sdX1
3. Running buildroot
--------------------
Position the board so you can read the label "RIoTboard" on the right side of
SW1 DIP switches. Configure the SW1 swiches like this:
10100101 (1 means ON position, 0 means OFF position)
Now plug your prepared SD-card in slot J6. Connect a serial console (115200, 8,
N, 1) to header J18. Connect a 5V/1A power supply to the board and enjoy your
new toy.</pre><br />
Note: Buildroot automatically recognizes and takes advantage of multicore machines, so don't use "-j" flags for make.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com3tag:blogger.com,1999:blog-4274794615816690062.post-54828743824441202912015-02-21T19:33:00.002+02:002015-02-21T19:34:13.126+02:00Building Yocto 1.7 "Dizzy" for i.MX6Quick guide how to download and build Yocto 1.7 "Dizzy" for i.MX6 (almost the same as my previous post about "daisy"):<br />
<br />
<pre>mkdir ~/bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
PATH=$PATH:~/bin
mkdir fsl-community-bsp && cd fsl-community-bsp
repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b dizzy && repo sync
source ./setup-environment build
bitbake core-image-minimal</pre><br />
As usual, the default target machine is "imx6qsabresd", but you can change it in your conf/local.conf file.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-37673859635942477872015-01-28T18:38:00.001+02:002015-01-28T18:39:02.736+02:00Linux audio support for RIoTboardRIoTboard support was introduced with mainline Linux v3.17. Since when I got this board, I was interested in using the on-board audio codec (SGTL5000), but initially didn't managed to have the audio working properly. Later I managed to get it working, and this is a short report to remind and others what works so far:<br />
<br />
<pre>Kernel Status
====================
Linux 3.17.0 OK
Linux 3.17.1 OK
Linux 3.17.2 OK
Linux 3.17.3 OK
Linux 3.17.4 OK
Linux 3.17.5 OK
Linux 3.17.6 OK
Linux 3.17.7 OK
Linux 3.17.8 OK
Linux 3.18.0 OK
Linux 3.18.1 OK
Linux 3.18.2 OK
Linux 3.18.3 OK
Linux 3.18.4 OK</pre><br />
All the kernels have been compiled natively on the RIoTboard itself (running Debian Wheezy on external USB drive). Each build takes about 70m, so please be patient.<br />
<br />
PS: Just found out that the RIoTboard audio subsystem is somewhat screwed-up:<br />
1. HP_VGND is connected to analog ground, while the datasheets explicitly says that it shouldn't be connected anywhere else other than the headphones jack. This effectively shorts out the virtual ground amplifier and leads to #2.<br />
2. Headphones are connected via 2x 47uF ceramic capacitors. Electrolytic capacitor 100-220uF would be much better, and no capacitor would be best in terms of audio quality (but this needs proper connection to HP_VGND).<br />
3. Line-in inputs are... well, not connected. That's really bad, as it rules out a number of use cases where we need stereo line-in and/or better quality ADC, so we're left with Lo-Fi mono microphone input (say goodbay to the low-cost SDR). I feel crushed...PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-33442711996535451562015-01-12T18:55:00.002+02:002015-01-12T18:55:31.812+02:00Tracing DHCP packets with TsharkRecently I needed to debug a DHCP issue for my imx6 ARM board. The best tool which I know for such purpose is the "usual suspect" - Wireshark, and namely it's console variant, tshark. The tool is wonderful and makes such task a breeze:<br />
<br />
<pre>$ sudo tshark -i eth0 -f "udp port 67"
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
0.000000 0.0.0.0 -> 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x2233523a
0.000186 10.10.10.1 -> 10.10.10.8 DHCP 342 DHCP Offer - Transaction ID 0x2233523a
0.000422 0.0.0.0 -> 255.255.255.255 DHCP 342 DHCP Request - Transaction ID 0x2233523a
0.000601 10.10.10.1 -> 10.10.10.8 DHCP 342 DHCP ACK - Transaction ID 0x2233523a
^C4 packets captured</pre><br />
Here's how to save the capture to a file for later inspection and/or documentation purposes:<br />
<br />
<pre>$ sudo tshark -i eth0 -f "udp port 67" -w dhcp_capture.pcapng
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
4 ^C</pre><br />
Packets can now be easily viewed with the Wireshark GUI - you can use another (developer) machine for this task, and also don't need root privileges.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-79398648408401631242014-10-19T23:32:00.000+03:002014-10-20T21:11:32.797+03:00New voltage regulator for ZX Spectrum+I decided to make small reorganization in my Spectrum+. Removing the heatsink for the linear voltage regulator seemed to be a good idea, and this generally means that the linear vreg will also have to be removed (as usually it has to dissipate about 2.2W). So I had to put a replacement vreg that doesn't need a (big) heatsink. The usual rule of thumb is that small components/modules without heatsink can dissipate up to 600mW without serious concerns for their longevity. 2.2W will fry any regular electronic component, even TO-220 package, when not cooled down.<br />
<br />
Some months ago I purchased a handfull of <a href="http://www.seeedstudio.com/depot/Adjustable-StepDown-DCDC-Converter-10V-17V18A-p-1717.html">these switching regulators</a>. The expected current consumption of the Speccy is about 0.5A, so it was a good match for this regulator.<br />
<br />
Here's the old linear vreg before the change (heatsink is already removed):<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYibeZGn4lZWr5KST0QXQ7EVcyAwBmsQL7Gdjugj0LOByjwjZmrMXN6-ZEUEsFYGFRsLTDmKjHSSauXfx7X3BpifLPVIdVC7ukYxn9wSssVWXWCLADu0zAQYkvEbQtLQokutGFZRkXYSY/s1600/vreg_old.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYibeZGn4lZWr5KST0QXQ7EVcyAwBmsQL7Gdjugj0LOByjwjZmrMXN6-ZEUEsFYGFRsLTDmKjHSSauXfx7X3BpifLPVIdVC7ukYxn9wSssVWXWCLADu0zAQYkvEbQtLQokutGFZRkXYSY/s640/vreg_old.jpeg" /></a></div><br />
And here's how it looks after the replacement with DC-DC converter:<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdNzm4c_QbeSxOJyX5CLJ6aw1aq4duBm8q5RrvWmyFibwaaYv30U_VCpJgBEkVybxvFkIjUXEx-M9fWP7mlOfvYLkbsWaCxcW1lLwjA4TRgr3z2IVUjIQCzYbiWyg20FYayyYzTp6CSac/s1600/vreg_new.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdNzm4c_QbeSxOJyX5CLJ6aw1aq4duBm8q5RrvWmyFibwaaYv30U_VCpJgBEkVybxvFkIjUXEx-M9fWP7mlOfvYLkbsWaCxcW1lLwjA4TRgr3z2IVUjIQCzYbiWyg20FYayyYzTp6CSac/s640/vreg_new.jpeg" /></a></div><br />
The switching regulator has good enough efficiency (datasheet states it's up to 95%?), during normal operation of the Speccy it gets barely warm. As a result of the improved efficiency, the Speccy current consumption was reduced from 550mA to about 400mA (with 9V power supply), which is very nice.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-38987360125210020662014-10-19T22:04:00.001+03:002014-10-20T21:11:53.084+03:00debconf: warning: possible database corruptionI recently saw this error message on my ARMHF Debian board. Here's how it's solved:<br />
<br />
cd /var/cache/debconf<br />
rm *-old<br />
for i in *.dat; do cat /dev/null > $i; donePicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-71320840335932589542014-10-10T19:20:00.002+03:002014-10-20T21:12:21.550+03:00Mainline Linux for RIoTBoardYep, these days you can enjoy a good Linux mainline support for RIoTBoard, thanks to the hard work of lots of people. Here are my notes how to build latest Linux kernel for this cool board.<br />
<br />
mkdir ~/riotboard<br />
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.17.tar.xz<br />
tar xf linux-3.17.tar.xz && cd linux-3.17<br />
make distclean && make imx_v6_v7_defconfig && make LOADADDR=0x10008000 uImage -j4<br />
cp arch/arm/boot/uImage ~/riotboard/<br />
cp arch/arm/boot/dts/imx6dl-riotboard.dtb ~/riotboard/<br />
make modules_install INSTALL_MOD_PATH=~/riotboard<br />
<br />
Well, now ~/riotboard contains the fresh kernel, device tree and drivers, so you can copy them to your embedded target.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com4tag:blogger.com,1999:blog-4274794615816690062.post-78653327401383268552014-10-10T18:50:00.001+03:002014-10-20T21:12:49.013+03:00Mainline U-Boot for RIoTBoardWell, the days when there was no mainline U-Boot support for RIoTBoard are behind us. The official board support was added with v2014.07. Here are my notes for how to get the latest bootloader for your RIoTBoard, just make sure you have a working ARM cross-compiler.<br />
<br />
<pre>wget ftp://ftp.denx.de/pub/u-boot/u-boot-2014.10.tar.bz2
tar xf u-boot-2014.10.tar.bz2 && cd u-boot-2014.10
make distclean && make riotboard_defconfig && make u-boot.imx -j4</pre><br />
You can load u-boot.imx on the board either via USB OTG port (by using <a href="http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX6_SW">Freescale's MFGTool</a> or <a href="https://github.com/boundarydevices/imx_usb_loader/">Boundary Devices's imx_usb_boot</a>), just configure the on-board micro-switches for USB OTG boot, as described <a href="http://risc-a-day.blogspot.com/2014/10/introduction-to-riotboard.html">here</a>.<br />
<br />
Otherwise you can flash the new bootloader to your non-volatile boot memory (spi nor, sdcard, raw/managed nand, etc). I prefer to test new bootloaders via USB.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com10tag:blogger.com,1999:blog-4274794615816690062.post-5942521707539970512014-10-06T23:10:00.000+03:002015-02-15T15:51:17.166+02:00Introduction to RIoTboardI have this board for some months, finally decided to put some technical notes about the RIoTboard's peripherals and interfaces.<br />
<br />
Main components:<br />
- CPU: i.MX6 Solo @ 800 MHz, 512K L2 cache, 32K+32K I&D cache<br />
- RAM: 1 GiB DDR3 @ 400 MHz (800 MT/s), 32-bit, single rank<br />
<br />
Storage:<br />
- USDHC2: SD card (J6)<br />
- USDHC3: MicroSD card (J7)<br />
- USDHC4: 3.6 GiB eMMC NAND<br />
<br />
Interfaces:<br />
- UART1: Connected to OpenSDA debugger<br />
- UART2: 3.3V serial console (J18)<br />
- UART3: Expansion port (J13)<br />
- UART4: Expansion port (J13)<br />
- UART5: Expansion port (J13)<br />
- I2C1: PMIC, audio codec<br />
- I2C2: HDMI DDC<br />
- I2C3: LVDS DDC, Expansion port (J13)<br />
- I2C4: CSI, Parallel camera, Expansion port (J13)<br />
- SPI1: Connected to OpenSDA debugger<br />
- SPI2: Expansion port (J13)<br />
- SPI3: Expansion port (J13)<br />
- USB 2.0 OTG: OTG port (J11), the board can boot from this interface<br />
- USB 2.0 Host: uses internal USB-hub to provide 4x host ports with over-current protection<br />
- Ethernet: 10/100/1000 Gigabit ethernet (PHY address 0x04)<br />
- Audio: I2S integrated audio codec with MIC preamp and HP amp, supports sample-rates 8-96 KHz, supports master-slave clocking, full-duplex mode. Beware that the SGTL5000 doesn't respond at all to I2C communication if the master clock is not running.<br />
- HDMI: HDMI connector (J3) - the only port that has ESD-protection<br />
- LVDS0: LVDS connector (J2)<br />
- CSI: MIPI serial camera (J8)<br />
- Parallel camera: Not sure whether this is MIPI-compliant (J9)<br />
- JTAG: Debug interface with non-standard connector (J10), you can easily wire standard 20-pin ARM JTAG connector here<br />
<br />
Boot sources:<br />
They are selected by 8-way micro-switch SW1. Here's a list of some common boot configurations:<br />
<br />
[00 xxxxxx] - Boot from fuses (Note: fuses are not programmed by default!)<br />
[01 xxxxxx] - Boot from OTG (can be used with MFGtool for Windows or imx_boot for Linux)<br />
[10 xxxxxx] - Internal boot (boots according to BOOT_CFG pins)<br />
[11 xxxxxx] - Reserved<br />
<br />
Here are all usable combinations (imho) for the Internal Boot:<br />
[10 10X010] - MicroSD card (J7), normal boot, 1 delay cells, 1-bit, port = USDHC3<br />
[10 10X110] - MicroSD card (J7), normal boot, 1 delay cells, 4-bit, port = USDHC3<br />
[10 10X001] - SD card (J6), normal boot, 1 delay cells, 1-bit, port = USDHC2<br />
[10 10X101] - SD card (J6), normal boot, 1 delay cells, 4-bit, port = USDHC2<br />
[10 110011] - eMMC NAND, normal boot, 1-bit SDR, port = USDHC4<br />
[10 110111] - eMMC NAND, normal boot, 4-bit SDR, port = USDHC4<br />
<br />
Legend:<br />
Orient the PCB so that the imx6 is at the top side, and SW1 is bottom side. 0 means low switch position, 1 means high switch position.<br />
<br />
Pros:<br />
The board has a pretty modern and fast Cortex-A9 CPU (if you have used Cortex-A8 boards in the past, you'll feel the difference instantly), and also the CPU is probably the single best documented modern ARM Cortex-A9 in the commercial world. The board has also good amount of system memory, flexible on-board audio, lots of connectivity and display options, low power consumption. All this can be yours for a price which is definitely in range of home experimenters (it currently retails for 70.49E at Farnell, which is about 89$ USD). Btw, the board was designed and manufactured by Embest Technologies, and I think they've done a great job with this design. As of today, Embest is acquired by Farnell.<br />
<br />
Cons:<br />
All interfaces (except HDMI) are missing ESD protection (TVS diodes are not soldered, even if they're shown on the schematic). Taking into account that this board is intended to be attached to zillions of user devices, peripherals and what-not, for me this is a serious failure. Congratulations, you-re just about to fry 70 euro.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-4791593111501283902014-10-05T22:22:00.001+03:002014-10-05T22:24:00.400+03:00TDA1543 from ChinaRecently got a bunch of TDA1543's from China-based seller. I was wondering about how good these chips are, taking into account that they are not manufactured anymore, and there's a huge change to receive either completely borked chips, or chips discarded by factory testing.<br />
<br />
So, as I usually do for all my new ICs, I set up a testbench and checked what's up with these. I was kinda pleasantly surprised to find out that they actually work. Still puzzled, I decided to check all possible sample rates that my USB sound card allows (I'm using for the test Asus Xonar U7). It turned out that chips handled without issues samplerates in the range 44.1-96 KHz, but on 176.4 KHz instead of music I heard horrifying noise. I explicitly check one old original TDA1543 made by Phillips, and handled 176.4 KHz without any issues, exactly following the specification. Of course, the original Philips TDA1543 also couldn't play at 192 KHz.<br />
<br />
Intrigued by this finding, I tested all new chips from the batch (10x total) and found that:<br />
- 6 of them work up to 96 KHz<br />
- 3 of them work up to 176.4 KHz<br />
- 1 of them is sleeping with the fishes<br />
<br />
Well, that's not too bad. The intended usage for these DACs is for retro computing projects using samplerates below 96 KHz, and the can easily tolerate non-audiophile performance, so no big deal.<br />
<br />
So, this was my opinion on "TDA1543 from China". Hope this helps someone.<br />
Regards.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-7045184117665378882014-09-11T19:30:00.002+03:002015-02-21T19:33:49.449+02:00Building Yocto 1.6 "Daisy" for i.MX6Quick guide how to download and build Yocto 1.6 "Daisy" for i.MX6 platform:<br />
<br />
<pre>mkdir ~/bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
PATH=$PATH:~/bin
mkdir fsl-community-bsp && cd fsl-community-bsp
repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b daisy
repo sync
source ./setup-environment build
bitbake core-image-minimal</pre><br />
The default target machine is "imx6qsabresd", but you can change it from conf/local.conf file.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-34526694346065134782014-09-10T07:43:00.001+03:002015-09-20T12:49:10.277+03:00Getting my UPS to work with LinuxRecently I acquired an UPS to power my home file server. The model is "Eaton 5E 1100i USB", made by Eaton (obviously). Now, to tell you something straight - if you relate Eaton with the high-end PowerWare UPSs from the near past (we used them to power our server room back in the good old days), well... that's OK, but the 5E serier is something I'll never refer as "high-end". Let me explain.<br />
<br />
The UPS box came with the following things:<br />
- 1x UPS<br />
- 2x IEC power cords for attaching equipment<br />
...and nothing else. <b>No power cord to power the UPS itself from the grid, no USB cable, no CD/DVD with software</b>. Cool, huh?<br />
<br />
First thing I did when got the UPS was to connect it to the power grid so it can immediately start charging the batteries (sitting on the store shelves doesn't improve the battery health, you know). Then I connected the UPS via USB to my laptop and started looking for software, so I can test it on Windows (somehow assuming this will be the easiest way to test USB commnication). Eaton provides a software package called "Eaton UPS Companion", so I went to their site to download it. <b>Unfortunately, if you want to download their software, you'll have to provide them your email, and there's no way around it</b> (it's pretty funny, on the web form asking for your email they say "Hey, please enter your email, we maybe already have your details!" - how the hell is this possible I don't know). So you give them away your email address, and then you receive a download link in your email, where you click and get the software. The SW package was small (2-3MB) and downloads/installs quickly.<br />
<br />
<b>Again unfortunately, after installing their software on Windows 7, it just refused to work properly</b>. The SW was unable to connect to the UPS over USB, and in general it was totally non-responsive. What's even cooler is that the SW showed in the system tray and there was no way to stop/exit it. It didn't reacted on menu actions like (start / stop / show). I can admit that giving my email away on "someone out there" and installing arbitrary crap on my box was already enough to piss me off quite a bit, so I decided that half an hour wasted for Windows was enough and rebooted the machine under Debian.<br />
<br />
Initially I expected that the Linux UPS setup will be much harder than Windows. So, it turned out to be exactly the opposite. First, connect the UPS to an USB port, and check whether the USB device is "visible" to the OS:<br />
<br />
<pre>lsusb
...
Bus 008 Device 002: ID 0463:ffff MGE UPS Systems UPS
...</pre><br />
Next you need to install a software package called "nut" (comes from Network UPS Tools):<br />
<pre>sudo apt-get install nut</pre><br />
Now you need to configure your UPS, so nut can use it. You have to edit /etc/nut/nut.conf:<br />
<pre>sudo mcedit /etc/nut/nut.conf
...
MODE=standalone</pre><br />
Now edit /etc/nut/ups.conf and add section for the UPS device itself:<br />
<pre>...
[myups]
driver = usbhid-ups
port = auto
vendorid = 0463
pollfreq = 30</pre>You may need to adjust the vendorid to suit your case. The pollfreq setting show how period in seconds between consecutive USB commands to the UPS - you can reduce it, but some UPSs hang if it's too fast (mine works OK with pollfreq = 10). Again YMMV.<br />
<br />
Now we can start the driver:<br />
<pre>sudo upsdrvctl start</pre><br />
If the tool moans about some issues with starting the driver, you can reboot the machine (not scientific, but it works).<br />
<br />
And finally, you can check that your UPS is connected and alive - there are console and GUI tools to do this. The console tool is called "upsc", and you can use it as regular user:<br />
<pre>upsc myups</pre><br />
And here's the output for my UPS:<br />
<pre>battery.charge: 75
battery.runtime: 1737
battery.type: PbAc
device.mfr: EATON
device.model: 5E 1100i
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.vendorid: 0463
driver.version: 2.6.4
driver.version.data: MGE HID 1.31
driver.version.internal: 0.37
input.voltage: 229.0
outlet.1.status: on
outlet.desc: Main Outlet
outlet.id: 1
outlet.switchable: no
output.frequency: 49.9
output.frequency.nominal: 50
output.voltage: 233.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 01.04.0018
ups.load: 12
ups.mfr: EATON
ups.model: 5E 1100i
ups.power.nominal: 1100
ups.productid: ffff
ups.start.battery: yes
ups.status: OL CHRG
ups.timer.shutdown: -1
ups.vendorid: 0463</pre><br />
If battery.charge/battery.runtime fields are "0", you'll have to wait for several minutes until they're populated with actual values.<br />
<br />
There's a GUI tool called "NUT-Monitor" and is located in the "nut-monitor" Debian package:<br />
<pre>sudo apt-get install nut-monitor
NUT-Monitor</pre><br />
(TODO: Add configuration for handling power events)<br />
<br />
On the positive side, things are looking well with the USB communication. The UPS provides lots of details about it's state of charge, voltages/currents, attached loads, etc. It's just better than the good olf days when most of the UPSs (except the most expensive ones) had dumb serial interface with ON/OFF signals, and now even a low-cost UPS has similar features. Also, I'm still to test how this UPS handles power outages (but I think our power company will do this for me in the next evenings).<br />
<br />
<b>So, that's it - just 5min to make it work with free/libre software in your favorite OS</b>. It's also possibly to export the UPS status across the local network, so other machines can also use it (for power management or even for logging). Now you can enjoy your freshly power-backed system and don't forget to thank to the <a href="http://www.networkupstools.org">NUT Team</a>.<br />
<br />
Thanks for reading.<br />
<br />
PS: When the UPS is charging, the cooling fan is quite noisy, which freaked me out the first time. This is definitely "no go" if you want to use the UPS in silent environment. The good part is that during normal operation (aka waiting for power outage), the UPS is dead silent.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com10tag:blogger.com,1999:blog-4274794615816690062.post-22732815341565089352014-06-24T19:28:00.002+03:002014-09-11T08:06:58.923+03:00Simple optimizations for SSD on Windows 7Recently I dusted-off one SSD and decided to install it into my ThinkPad X201. It's a small 64GiB 2.5" Transcend drive, and wanted to see how much better is using the SSD compared to the conventional spinning disk drive. So here's my check-list:<br />
<br />
1. Install Windows 7 as usual.<br />
2. Disable scheduled disk defragmentation - right click on the drive, select "Tools" tab, click "Defragment now...", click "Configure schedule...", uncheck "Run on a schedule".<br />
3. Disable file indexing - right click on the drive, select "General" tab, uncheck "Allow files on this drive to have contents indexed in addition to file properties".<br />
4. Check the MSAHCI driver is using SATA mode - edit registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci\Start" to value "0".<br />
5. Reboot and check in your BIOS that the disk is in SATA (sometimes described as AHCI) mode, not Compatibility mode.<br />
6. Check for disk TRIM support, run this command in the console (run "cmd" as administrator): "fsutil behavior set disabledeletenotify 0".<br />
Note: SSD TRIM can actually slow-down your machine, by explicitly marking blocks for deletion. It's entirely possible to have TRIM disabled and to just over-provision your disk by leaving some non-partitioned spaceon the disk (between 7% and 25%). Feel free to experiment and choose what suits you best.<br />
7. Disable your system page file - Control Panel -> System, select "Advanced" tab, click on "Settings..." button in "Performance" area, select "Advanced" tab, click "Change...", uncheck "Automatically manage paging file size for all drives", select "No paging file" radio-button, click "Set", reboot (hey, GUIs are nicer than command-line, aren't they?).<br />
<br />
It's not very scientific, but it works.<br />
<br />
PS: This information was found on the "Internet", and was copied here solely for my own convenience. I didn't invented this tip, credit should go to others.<br />
PS2: Need to dig out my notes for similar checklist on Linux SSD setup.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-90001577655462688442014-06-23T03:32:00.000+03:002014-09-11T08:07:46.338+03:00Synchronizing Linux and Windows 7 system clocks on dual-boot machine<i>Offtopic: As I tend to forget I have to write things down, especially important ones. So I decided to start putting short post-it notes online, just not to forget countless little things that I have to remember.</i><br />
<br />
It became a habit of mine to always have at least 2 OSes installed on all of my machines - a favorite one (GNU/Linux) and a "expensive-and-buggy" one (Windows 7). It took me a while to notice that the system clock is always wrong in one of the OSes, and when you fix it in one of them, it breaks the other one. It turned out that Windows 7 prefers to use user's local time as system clock, while Linux uses UTC and calculates the offset to the local time. I decided to force Windows 7 to the "the right thing". You need to edit the following registry key value:<br />
<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal</pre><br />
...and change its value from "0" to "1". If this registry key value doesn't exist, just create a new one with value type "DWORD" and set it to "1". Now you can reboot and enjoy a synchronized clocks on both OSes.<br />
<br />
PS: This information was found on the "Internet", and was copied here solely for my own convenience. I didn't invented this tip, credit should go to others.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-54251151648395292882013-01-06T15:14:00.002+02:002013-01-07T23:15:24.882+02:00Bus Pirate - a handy tool for inventorsLast year I discovered an interesting hardware tool - the <a href="http://dangerousprototypes.com/docs/Bus_Pirate">Bus Pirate</a>. The thingie looked quite promising, so I couldn't resist and ordered it (I got it from <a href="http://www.seeedstudio.com/depot/bus-pirate-v3-assembled-p-609.html?cPath=61_68">Seeed Studio</a>, as they ship worldwide for a very low cost).<br />
<br />
When I received the Bus Pirate, I did the usual quick checks - plugged into the nearest machine, installed drivers and played for a minute with the integrated shell, but nothing more. The Pirate collected dust on my shelf for a couple of months. Then it came the moment when I run out of USB-serial converters (I typically use <a href="http://uk.farnell.com/ftdi/um232h/module-dev-um232h-ft232h/dp/1870926">UM232H</a> as they are not too expensive and works well with both Linux & Windows). As you can guess, it's impossible to order new hardware during the holidays, so I had to dig deep in my drawers to check what's there to save my day. I found one <a href="http://uk.farnell.com/ftdi/ft2232hq-mini-module/module-usb-2-port-ft2232h-based/dp/1697465">FT2232H</a> (dual channel USB-to-anything on steroids!) and the Bus Pirate. I've knew that the FT2232H will work for me, and I was more curious to put the Bus Pirate in action, so I plugged it in.<br />
<br />
What I needed was very simple - a USB-serial board. The Bus Pirate can be configured to work like a USB-serial "bridge" (that's how they call it in the docs). It's not a rocket science to do this, actually quite the opposite. Connect the Bus Pirate to your box, install the device drivers if needed and open your favorite terminal emulator (puTTY, screen), select the proper serial port and do the actual configuration. Press "?" to print the integrated shell help:<br />
<pre>HiZ>?
General Protocol interaction
---------------------------------------------------------------------------
? This help (0) List current macros
=X/|X Converts X/reverse X (x) Macro x
~ Selftest [ Start
# Reset ] Stop
$ Jump to bootloader { Start with read
&/% Delay 1 us/ms } Stop
a/A/@ AUXPIN (low/HI/READ) "abc" Send string
b Set baudrate 123
c/C AUX assignment (aux/CS) 0x123
d/D Measure ADC (once/CONT.) 0b110 Send value
f Measure frequency r Read
g/S Generate PWM/Servo / CLK hi
h Commandhistory \ CLK lo
i Versioninfo/statusinfo ^ CLK tick
l/L Bitorder (msb/LSB) - DAT hi
m Change mode _ DAT lo
o Set output type . DAT read
p/P Pullup resistors (off/ON) ! Bit read
s Script engine : Repeat e.g. r:10
v Show volts/states . Bits to read/write e.g. 0x55.2
w/W PSU (off/ON) <x>/<x= >/<0> Usermacro x/assign x/list all</pre><br />
Press "m" to select the Bus Pirate mode of operation and select "3" for UART mode:<br />
<pre>HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)
(1)>3</pre><br />
Select your sample rate (I used 115200):<br />
<pre>Set serial port speed: (bps)
1. 300
2. 1200
3. 2400
4. 4800
5. 9600
6. 19200
7. 38400
8. 57600
9. 115200
10. BRG raw value
(1)>9</pre><br />
Select your data bits/parity settings, I usually just hit ENTER as defaults are OK for my case (8N1):<br />
<pre>Data bits and parity:
1. 8, NONE *default
2. 8, EVEN
3. 8, ODD
4. 9, NONE
(1)></pre><br />
...same here:<br />
<pre>Stop bits:
1. 1 *default
2. 2
(1)></pre><br />
...and here:<br />
<pre>Receive polarity:
1. Idle 1 *default
2. Idle 0
(1)></pre><br />
Select your UART output type - usually you'll need "normal", but YMMV:<br />
<pre>Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)
(1)>2
Ready</pre><br />
You need 2 more steps - list currently available UART macros (optional) and activate the "UART bridge" macro (needed):<br />
<pre>UART>(0)
0.Macro menu
1.Transparent bridge
2. Live monitor
3.Bridge with flow control
UART>(1)
UART bridge
Reset to exit
Are you sure? y</pre><br />
From this moment on, the Bus Pirate will act move data across the the line as if it was regular USB-serial convertor (and it's about the same price as the FTDI modules). Keep in your mind that the only way to get out the Bus Pirate of this mode is to power-cycle the device (unplug/plug the USB connector), as there's no RESET button on the PCB.<br />
<br />
Enjoy playing with this toy!<br />
<br />
P.S.: I knew that FTDI made various USB-to-something chips and I even had some of them, but the reason why exactly the UM232H came to my attention is that one of my colleagues asked me for a favor to debug his ATmega <-> USB JTAG setup, and it was based on this chip. The JTAG worked very well in the end and I was pleasantly surprised. Thanks Hristo for the idea!<br />
<br />
P.S.2: With Linux the FTDI chip can work in 2 different configurations - using ftdi_sio to act as regular usb-serial port, and with <a href="http://www.intra2net.com/en/developer/libftdi/">libftdi</a> to act as multi-purpose USB interface (I2C/SPI/bit-bang/etc). Also I usually use <a href="http://code.google.com/p/libmpsse/">MPSSE</a> for lazy SPI access. Something cool to share - libftdi & libmpsse compile and work fine with embedded ARM Linux.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-36719372344537149202012-12-31T21:56:00.000+02:002013-01-01T20:43:15.106+02:00Year at a glanceLet's prepare to say "Goodbye!" to year 2012. We lived through dynamic times, so let's summarize what happened this year (random stuff, in random order):<br />
<br />
- Microsemi acquired Actel.<br />
- Speaking of Actel, in 2012 QVL released a security analysis of Actel FPGAs which described a non-documented factory test interface to the chips (of course, Actel/Microsemi first denied this, just the usual theater). Cool, now we can sleep happy when using "the most secured & tamper-resistant FPGAs in the world". Doh...<br />
- Imagination Technologies acquired MIPS. Rest in peace, Stanford MIPS! Now Microchip is the only vendor of cheap "MIPS for the masses" (I don't count Broadcom, as they don't deserve it). We'll have to unfortunately line-up the MIPS architecture in the museum next to DEC's Alpha, HP-PA, Sun's SPARC/UltraSPARC (UltraSPARC is dead, just ask Oracle).<br />
- Samsung released first mass produced Cortex-A15 chips (dual-core Exynos 5), TI made OMAP5 demos. In general, things are now looking promising, as there's at least one non-x86 architecture that's accessible (mass produced & low cost) and has acceptable performance for everyday computing (e.g. more than it takes to blink a LED).<br />
- Elecraft finally released the KX3 radio!<br />
<br />
And also there are some hobby things to relate with this ending year:<br />
- Got my first Spartan-6 devkit (Atlys from Digilent).<br />
- Got my Elecraft K2 radio, made my first trans-ocean HF contact with US (still can't believe this happened with 10W and cheap homebrew 20m dipole).<br />
- Got my hands on a long-standing dream, USRP B100 software-defined radio (thanks Ettus Research for treating me like a criminal because my credit card was European).<br />
- Wrote userspace driver in Python for ENC624J600 and also a Python-based network stack for one of my projects.<br />
- Wrote userspace driver and Layer3 P2P tiny stack in Python for MRF24J40, for a wireless project (I can't express my happiness for avoiding the work with proprietary Zigbee specs).<br />
<br />
And one stupid joke - year 2012 should be remembered as the year, where millions of people almost died from disappointment that the world didn't end up :D<br />
<br />
Happy new year 2013!PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-21016701084375972732012-12-31T19:57:00.000+02:002013-01-01T20:43:47.163+02:00Looking for alternatives of Microchip PICsI've been using <a href="http://www.microchip.com/">Microchip</a> PICs for about 12 years. In those dark ages when I started my first steps, we had only UV-erasable EPROM parts, and each erase/reprogram cycle forced you to wait patiently for 30min of UV-lamp erasure. The standard chips for production were OTP, One-Time-Programmable (yep, no way to fix bugs after releasing the product other than replacing the whole chip). Later EEPROM parts became available (anyone remember the famous PIC16C84?), and then the FLASH parts (each time I reprogram a modern PIC I remind myself with a smile that 10s reprogram time is much less than 30min).<br />
<br />
I've done lots of PIC projects in the past, mostly related with industrial automation, sometimes to handle custom/proprietary protocols, and also for small fun projects.<br />
<br />
It's been 12 years of mostly an Assembly programming (I've actually done 1 project in C for the company of friend of mine, but that's mostly an exception). For all this time I was telling myself that the architecture is just not so bad, I just have to learn it better, and better... but after so many years, I must admit that I'm already tired of using this weird beast. I think it's finally the time to seek a new platform for my embedded projects, so let's see what features the new platform should have in order to be usable for my purposes.<br />
<br />
Here's a short list of ideas in my head:<br />
<br />
1. CPU core requirements:<br />
1.1. ALU should be 16-bits or more. I'm tired of carrying/borrowing bits for even simple operations! The tasks solved these days with embedded CPUs are a little bit more complex than they were before 20 years and will fit much better in 16-bits than in 8-bits.<br />
1.2. ALU should use registers instead of carry/borrow bits. After some e-mail exchanges with <a href="http://news.yasep.org/">Yann Guidon</a> (and a a good amount of re-reading parts of one of my favorite books <a href="http://www.amazon.com/Morgan-Kaufmann-Computer-Architecture-Design/dp/1558604103/ref=sr_1_1?s=books&ie=UTF8&qid=1357065033&sr=1-1&keywords=1558604103">"See MIPS Run"</a>) I'm now finally convinced that having/handling STATUS bits around causes more trouble that in solves.<br />
1.3. CPU should have a real register file, not just 1 fraking (here I mean "working") register. I'm not too greedy for 32+ registers, because it will increase the cost for full context save/restore, but anything between 4 and 16 general purpose registers will be fine.<br />
1.4. CPU should have a real stack in RAM, capable of storing not only return addresses, but also data (sets of registers for context switches, local variables).<br />
1.5. CPU should support big enough address space in order to linearly address the the whole internal SRAM/FLASH memories without using page switching (I need to repeat this several times specially for the Microchip designers).<br />
1.6 Interrupts handling<br />
1.6.1 Interrupts should be handled with low enough latency: low cost context switching will even allow me to have deferred interrupt handling for low priority tasks.<br />
1.6.2 Interrupts should support vectored handling, thus further reducing the time for handling the interrupt.<br />
2. Peripherals requirements:<br />
2.1 At least 2x Timers/counters, the more, the better. If there are multiple timers, I now prefer all of them to be with the same capabilities.<br />
2.2. Timers should allow selection of internally/external clock.<br />
2.3. Timers should support one-time or automatic reloading, both should be able to emit interrupt to the CPU core.<br />
2.4. The hardware must provide atomic capture of the timer/counter value.<br />
2.5. As one of the timers is typically used for the task scheduling, it should have enough bits to cover even the longest time periods needed. I now prefer to avoid having a pre-scaler, just having a wide enough counter will do the job. For a practical example, if we have 80MHz clock, a 24-bit timer will provide ~4.77 interrupts/sec (~210ms). But maybe 32-bit timer will just cover all the current/future use cases.<br />
2.6. 1x Watchdog, preferably with separate oscillator (I don't mind RC oscillators, as long as they function at all in the whole temperature range).<br />
2.7. 1x UART, 2x would be perfect. Supporting rx/tx FIFO, 115200 is a must, and also rx/tx interrupts.<br />
2.8. 1x I2C, 2x would be perfect. Supporting master/slave modes is a must, and also rx/tx interrupts.<br />
2.9. 1x SPI, 2x would be perfect. Supporting master/slave modes is a must, and also rx/tx interrupts.<br />
2.10. 2x PWM, more is better. Resolution should be 10+ bits, it's also preferable to have support for different output types - single/half-/full-bridge. The new PWM value should be latched and applied on the next PWM cycle to avoid output glitches. Having a common "latch" signal for all the PWM channels would be a nice addition, but is not required.<br />
<br />
The platforms that I'm currently looking at are <a href="http://www.atmel.com/products/microcontrollers/avr/megaavr.aspx">AVR-based ATmega</a>, <a href="http://www.ti.com/lsds/ti/microcontroller/16-bit_msp430/overview.page?DCMP=MCU_other&HQS=msp430">MSP430</a>, <a href="http://www.arm.com/products/processors/classic/arm7/index.php">ARM7</a>, <a href="http://www.arm.com/products/processors/cortex-m/index.php">Cortex M0-M3</a>. All of them are supported by a standard C compiler (like <a href="http://gcc.gnu.org/">GCC</a>) and would allow me to have much faster and productive C-based development. One also possible solution is to have a soft-core compatible with one of the fore-mentioned architectures implemented inside a modern <a href="http://en.wikipedia.org/wiki/Field-programmable_gate_array">FPGA</a> (with the idea to use a standard toolchain). And as a final solution it's possible to use a soft-core implementing a different, new, more modern <a href="http://en.wikipedia.org/wiki/Instruction_set_architecture">ISA</a> (like <a href="http://yasep.org/">Yann Guidon's YASEP</a>).<br />
<br />
That's all for today (enough ranting :D).<br />
<br />
Update (1.Jan.2012): Added links to all mentioned sites.PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com0tag:blogger.com,1999:blog-4274794615816690062.post-28777659010220858962011-12-28T18:10:00.007+02:002011-12-29T04:28:20.478+02:00FPGA JTAG Debug<div align="justify">Hey, I'm still alive. Even if I'm not writing every day (hmm, once per year?). Anyway...</div><div align="justify">With my resurrected interest in programmable logic, I wanted to find a better way to debug my FPGA designs. I know that design verification with the simulator helps, but there's no better test than the real device working on your bench (and sometimes it's even preferable, compared to working with Xilinx's ISE WebPack). The major event that pushed me into the direction of searching for my own solution was the fact that Xilinx provide ChipScope Pro in the WebPack distribution, but during the design compilation ChipScope Pro just moaned about my license (it's a free WebPack license) and the design build failed. I won't lie that I had some thoughts about just finding a key-generator for the ISE and to start working with the full version, but... This won't help me in the long-run, and neither will help to the general public. A second and still important factor is that I'm quite curious about what FPGA companies are actually offering these days as free downloadable design software - is it a big piece of crap or it's really usable thing than can actually attract people to this engineering field? My current observation is that things are really improving, there's still a lot of space for improvement. Can you guess why? These companies are selling HARDWARE, not software, so why are they artificially limiting the popularity of their devices by limiting the access to their design tools? For example Microchip maybe is not the best engineering company in the world, maybe their products are not the best products, but the software has always been available for free (except C-language toolchain). So, to summarize - gents, if you sell hardware don't skimp software.</div><div align="justify">Back to the problem - I wanted to debug my design without usign ChipScope Pro. I found out that ChipScope uses 2 commands for the JTAG TAP (Test Access Port) controller to access 2 user-defined (or design-defined) registers - USER1 & USER2. The JTAG TAP is available in your design as a macro called BSCAN_SPARTAN3 (actually this is only valid for Spartan-3 and Spartan-3E devices, which I'm interested in). Here is how this macro is declared (OK, at least this is my estimation):</div><br />
<pre>module BSCAN_SPARTAN3 (
output reg TDI,
output reg RESET,
output reg SHIFT,
output reg CAPTURE,
output reg UPDATE,
output reg DRCK1,
output reg SEL1,
input wire TDO1,
output reg DRCK2,
output reg SEL2,
input wire TDO2
);</pre><br />
What's not obvious is how this module is used actually.<br />
TODO - add Verilog code to show BSCAN module usage.<br />
TODO - add scope captured waveforms to show how this design works.<br />
<br />
Next thing I wanted to do was to connect the FPGA to the PC with JTAG interface. Generally I wanted to use OpenOCD, because it's (relatively) easy to play with this JTAG tool. I check around how to compile it for Win32 but it turned out that OpenOCD authors rely mostly on Cygwin - a compromise I'm not ready to make (did I mentioned that I hate Cygwin?). My only choice was to build it for Linux - my test box is a small 600MHz VIA EPIA miniITX, running Debian Lenny (kernel 2.6.26-2-486, gcc-4.3.2). Please note that in order to have useful OpenOCD tool, you have to choose what JTAG interfaces have to be supported. I have currently Amontec USB JTAGkey-Tiny (it's partially broken - nTRST buffer is blown but I'm still too lazy to fix it), and also I have Digilent Parallel Port JTAG cable (I think it's compatible with Xilinx JTAG Cable 3). In order to add support for JTAGkey-Tiny, I had to download and compile the latest <a href="http://www.intra2net.com/en/developer/libftdi/download.php" target="_blank">libftdi-0.19 library</a> (the Debian-provided package was just too old). Next I had to download and compile <a href="http://sourceforge.net/projects/openocd/" target="_blank">OpenOCD-0.5.0</a> JTAG tool:<br />
<br />
<pre>$ ./configure --enable-parport --enable-ft2232_libftdi && make</pre><br />
Please pay attention to configure's output - there's a possibility that the script can't find the header/library for libftdi (you'll have to fix this). Now you can build OpenOCD. After it's compiled, you can move the binary in your favourite working directory (it's available in src directory). You can also remove the unneeded fat from the ELF application, if you want:<br />
<br />
<pre>$ strip --strip-unneded openocd</pre><br />
This reduced the size of the binary from 4.3MB to 1.2MB.<br />
Now's the time to connect your JTAGkey to the Linux box. It's useful to observe the connection process just to be sure everything goes as expected (you'll have to perform this command as root or any user, member of the adm group):<br />
<br />
<pre># tail -f /var/log/syslog</pre><br />
And here's the output:<br />
<br />
<pre>Dec 28 16:22:50 epia kernel: [ 6802.200057] usb 1-1: new full speed USB device using uhci_hcd and address 2
Dec 28 16:22:50 epia kernel: [ 6802.404726] usb 1-1: configuration #1 chosen from 1 choice
Dec 28 16:22:50 epia kernel: [ 6802.419605] usb 1-1: New USB device found, idVendor=0403, idProduct=cff8
Dec 28 16:22:50 epia kernel: [ 6802.419627] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 28 16:22:50 epia kernel: [ 6802.419643] usb 1-1: Product: Amontec JTAGkey
Dec 28 16:22:50 epia kernel: [ 6802.419655] usb 1-1: Manufacturer: Amontec
Dec 28 16:22:50 epia kernel: [ 6802.419668] usb 1-1: SerialNumber: XXXXXXXX</pre><br />
In order to use this USB JTAG interface, you'll have to instruct OpenOCD what's the interface, what are the attached devices, etc... This is done via a OpenOCD configuration file. Here's my initial file for playing with Digilent Spartan-3 Starter Kit board:<br />
<br />
<pre># spartan3.cfg
# OpenOCD commands
telnet_port 4444
gdb_port 3333
interface ft2232
ft2232_device_desc "Amontec JTAGkey Tiny"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8
adapter_khz 6000
# JTAG TAPs
# TODO</pre><br />
Please note that initially I didn't have any clue about how to define the devices in the boundary scan chain. I just remembered that the Digilent ExPort & Xilinx Impact programs are detecting 2 devices in the scan chain - Spartan-3 1000 and XCF04S platform flash. For some unknown reason the device order in the vendor-provided software is the opposite to the way OpenOCD shows these devices. And just for the curios - here's what I saw initially on the console, while trying to understand how to configure my scan chain:<br />
<br />
<pre>$ ./openocd -f spartan3.cfg
Open On-Chip Debugger 0.5.0 (2011-12-28-00:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'6000 kHz
Info : clock speed 6000 kHz
Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x05046093 ..."
Warn : AUTO auto1.tap - use "jtag newtap auto1 tap -expected-id 0x11428093 ..."
Warn : AUTO auto0.tap - use "... -irlen 8"
Warn : AUTO auto1.tap - use "... -irlen 2"
Error: IR capture error at bit 10, saw 0x03FFFFFFFFFFFFFFFFFFFFFFFFFFF501 not 0x...3
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined
</pre><br />
It's generally hard to automatically recognize "who's who" on the boundary scan chain, thanks to standard deviations and mis-interpretations. So here we're seeing that at least OpenOCD sees "something" on the scan chain. If we add "newtap" lines to define the length of JTAG TAP instruction registers for these 2 devices:<br />
<br />
<pre># JTAG TAPs
jtag newtap unknown0 tap -irlen 8jtag newtap unknown1 tap -irlen 6</pre><br />
...things are starting to get a better shape:<br />
<br />
<pre>$ ./openocd -f spartan3.cfg
...
Info : JTAG tap: unknown0.tap tap/device found: 0x05046093 (mfg: 0x049, part: 0x5046, ver: 0x0)
Warn : JTAG tap: unknown0.tap UNEXPECTED: 0x05046093 (mfg: 0x049, part: 0x5046, ver: 0x0)
Info : JTAG tap: unknown1.tap tap/device found: 0x11428093 (mfg: 0x049, part: 0x1428, ver: 0x1)
Warn : JTAG tap: unknown1.tap UNEXPECTED: 0x11428093 (mfg: 0x049, part: 0x1428, ver: 0x1)
Error: Trying to use configured scan chain anyway...</pre><br />
You can ask me how I found out the IR length? Please check <a href="http://bsdl.info/" target="_blank">here</a>. On this site you can also get the DEVICE_ID codes for these chips, so we can complete our scan chain configuration:<br />
<br />
<pre># JTAG TAPs
jtag newtap xcf04s tap -expected-id 0x05046093 -irlen 8jtag newtap xc3s1000 tap -expected-id 0x11428093 -irlen 6</pre><br />
Now OpenOCD is much happier (so am I):<br />
<br />
<pre>$ ./openocd -f spartan3.cfg
...
Info : JTAG tap: xcf04s.tap tap/device found: 0x05046093 (mfg: 0x049, part: 0x5046, ver: 0x0)
Info : JTAG tap: xc3s1000.tap tap/device found: 0x11428093 (mfg: 0x049, part: 0x1428, ver: 0x1)</pre><br />
One unpleasant point is that is that in order to use BSCAN component, the device must be already configured. This complicates the things a lot, because I'll have to program and debug the FPGA design via the same interface (which CAN be complicated, because I'm still searching for an acceptable triplet of JTAG interface/application/OS that works for all my needs), or I'll have to live-swap JTAG interfaces after programming (ugly but possible, just keep the ground wire first connected/last disconnected).<br />
I tried to program SVF file with Linux/OpenOCD/JTAGkey-tiny with this telnet command (it uses a .svf file in the same working directory as OpenOCD binary)<br />
<br />
<pre>$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.Escape character is '^]'.
Open On-Chip Debugger
> scan_chain
TapName Enabled IdCode Expected IrLen IrCap IrMask
------------------- -------- ---------- ---------- ----- ----- ------
0 xcf04s.tap Y 0x05046093 0x05046093 8 0x01 0x03
1 xc3s1000.tap Y 0x11428093 0x11428093 6 0x01 0x03
> svf -tap xc3s1000.tap tralala.svf
svf processing file: "tralala.svf"...</pre><br />
...but at some poing OpenOCD quits with this error:<br />
<pre>Error: ftdi_write_data: usb bulk write failed
Error: couldn't write MPSSE commands to FT2232</pre><br />
I didn't wanted to debug libftdi, so I used my other JTAG device, Digilent parport cable. Please note you'll have to change your OpenOCD config file for the new interface, and you'll have to ensure that your /dev/parport0 device is available (mine was not, but "modprobe ppdev" solved the problem, and also I have to add my user to the "lp" group for proper permissions). Here's the new OpenOCD config :<br />
<br />
<pre># spartan3.cfg
# OpenOCD commands
telnet_port 4444
gdb_port 3333
interface parport
parport_port 0
parport_cable dlc5
adapter_khz 100
# JTAG TAPs
jtag newtap xcf04s tap -expected-id 0x05046093 -irlen 8
jtag newtap xc3s1000 tap -expected-id 0x11428093 -irlen 6</pre><br />
This time the communication was slower but it didn't failed. Nevertheless I was still unable to program the board (it failed with some error at the end of programming). I supposed that there's a problem with OpenOCD SVF parser, but my next attempt with XSVF file was even more unsuccessful. I'll post an update if there's any progress with the programming.<br />
<br />
Note: Here are some links to other people's work on the subject:<br />
<br />
<a href="http://www.holmea.demon.co.uk/Frac3/Main.htm">http://www.holmea.demon.co.uk/Frac3/Main.htm</a><br />
<a href="http://www.fpgarelated.com/usenet/fpga/show/85173-1.php">http://www.fpgarelated.com/usenet/fpga/show/85173-1.php</a><br />
<a href="http://www.xilinx.com/support/answers/10703.htm">http://www.xilinx.com/support/answers/10703.htm</a><br />
<a href="http://www.eng.auburn.edu/~strouce/class/elec4200/lab7.pdf">http://www.eng.auburn.edu/~strouce/class/elec4200/lab7.pdf</a><br />
<a href="http://labserver.uv.es/svn_FPGA/trunk/source/urjtag/extra/fjmem/README">http://labserver.uv.es/svn_FPGA/trunk/source/urjtag/extra/fjmem/README</a><br />
<a href="http://www.eng.auburn.edu/~strouce/class/elec4200/spart_configJTAG.pdf">http://www.eng.auburn.edu/~strouce/class/elec4200/spart_configJTAG.pdf</a><br />
<br />
P.S.: I haven't blogged for a while, but Blogspot web-based editor is still the same shit - it just breaks over and over hours of my efforts to create some beautiful formatted text. Damn!PicMasterhttp://www.blogger.com/profile/13300377990065511523noreply@blogger.com7