Notebook (Toshiba) zarna. 600 myanga

Toshiba (2006 oniih):

Intel Centrino Core Duo mit 1,66 Ghz (T 2300)
Grafikkarte Mobile ATI Radeon mit 256 MB
Speicher Arbeitsspeicher 1024 MB RAM
Festplatte 100 GB (5400 RPM)
15,4" WXGA Trubite TFT Screen HD togo
DVD Super Multi Drive
56k Modem
LAN 10/100 Mbit
Wireless LAN 802.11 a/g

Hariltsah hayag: erdenekhorloos@yahoo.com

Notebook (Fujitsu Siemens) zarna. 1 saya

Fujitsu Siemens (2008 oniih):

Intel Pentium Dual Core T4300 2x 2.1 GHz
4096 MB DDR2 RAM
Intel® GMA 4500M
320 GB Festplatte
DVD-SuperMulti Brenner
Cardreader
3xUSB 2.0
WLAN bg
15.4"WXGA Display
Windows Vista

mouse 2 Gb iin usb dagalduulna

hariltsah hayag: erdenekhorloos@yahoo.com

genext2fs: too big filesystem

Эмбэддэд линуксыг хөрвүүлж, NFS дээр байрлах үндсэн файлын системийг үүсгэх үед

genext2fs: too big filesystem

алдаа өгөх тохиолдол гардаг.

Looking up port of RPC 100003/2 on "ip_addr"

Хэрэв эмбэддэд линукс цөм ачааллаад, үндсэн файлын системийг NFS-р дамжуулан суурилуулж чадахгүй дараахь симптомыг үзүүлээд байвал

Looking up port of RPC 100003/2 on "ip_addr"
Looking up port of RPC 100005/1 on "ip_addr"

name server, firewall-н тохиргоог дараахь файлуудад шалгаарай:

- /etc/resolv.conf (name server)
- /etc/sysconfig/iptables (firewall)

Name server-н хувьд:

nameserver "ip_addr"

firewall-н хувьд:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 4000:4003 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 4000:4003 -j ACCEPT

гэсэн тохиргоо байх ёстой.

Temporary failure in name resolution

When Fedora (10) yum returns "[Errno 4] IOError: Trying other mirror." and prevent to install any rpm package, configure /etc/resolv.conf by specifying nameserver IP address, such as

nameserver 192.168.0.1

Kernel panic: No init found. Try passing init= option to kernel.

Линукс-н цөмийг ачааллах үед гардаг энэ алдааг хэрхэн засах талаар.

1. rootpath is empty in IP-Config during kernel boot. -> Configured DHCP with

option root-path "192.168.0.98:/opt/rootfs.incaip2";

to the file /etc/dhcpd.conf. Did not helped.

2. Embed initrd to kernel. Solved.

Kernel panic: No init found. Try passing init= option to kernel.

Линукс-н цөмийг ачааллах үед гардаг энэ алдааг хэрхэн засах талаар

Setting up the Network File System (NFS) on Fedora 9

Here's a quick post on how to build and setup NFS server on Fedora 9. (Fedora 9 болон түүнээс дээшхи хувилбарын үйлдлийн систем дээр хэрхэн Network File System суулгаж, холбогдох тохируулгыг хийх тухай товч заавар. Зөвхөн өгөгдсөн командуудыг дууриагаад хийхэд хангалттай гэж найдаж байна)

NFS server installation and configuration

Do following as root.

1. Download and install NFS rmp by using yum:

yum -y install nfs-utils rpcbind

2. Configure the server by specifing the shared directories, the IP address(es) of the hosts that have access to the shared directories and their rights (read-only, read+write etc) in the /etc/exports file. For example, /opt/rootfs.incaip2 is NFS share and a host with the IP address 192.168.0.97 can access to this share:

/opt/rootfs.incaip2 *(rw,async,no_root_squash)

or

/opt/rootfs.incaip2 192.168.0.0/24(rw,async,no_root_squash)

or

/opt/rootfs.incaip2 192.168.0.97(rw,async,no_root_squash)

To make this change in effect, invoke:

exportfs -rv

3. Copy files to your NFS share. For example, copy unpacked root file system, /tmp//build/root_filesystem, to the /opt/rootfs.incaip2 directory.
4. In order to prevent hosts from other networks from connecting any of the NFS-related daemons, edit /etc/hosts.deny file as follows:

lockd:ALL
mountd:ALL
rpcbind:ALL
rquotad:ALL
statd:ALL

5. In order to allow only the host with IP address of 192.168.0.97 to connect, add following lines to the /etc/hosts.allow file:

lockd:127.0.0.1,192.168.0.97
mountd:127.0.0.1,192.168.0.97
rpcbind:127.0.0.1,192.168.0.97
rquotad:127.0.0.1,192.168.0.97
statd:127.0.0.1,192.168.0.97

6. Specify fixed IP ports in use of NFS by adding following lines to the /etc/sysconfig/nfs file:

STATD_PORT=4000
LOCKD_TCPPORT=4001
LOCKD_UDPPORT=4001
MOUNTD_PORT=4002
RQUOTAD_PORT=4003

These are suggested ports to be used in NFS-related daemons.

Firewall configuration

7. Configure firewall to allow above selected TCP and UDP ports. To do so edit the /etc/sysconfig/iptables file, so that it contains following settings:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 4000:4003 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 4000:4003 -j ACCEPT

Make sure that these lines must be before COMMIT, otherwise they have no effect.
8. Once the changes are made to the firewall, restart it:

service iptables restart

Starting and verifying NFS services

9. With all of the changes made, the NFS daemons can be started up:

service rpcbind restart
service nfs restart
service nfslock restart

10. To make sure that everything is working properly, the RPC information can be checked by invoking:

rpcinfo -p

The similar information should be displayed as below:

program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 4000 status
100024 1 tcp 4000 status
100011 1 udp 4003 rquotad
100011 2 udp 4003 rquotad
100011 1 tcp 4003 rquotad
100011 2 tcp 4003 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 4001 nlockmgr
100021 3 udp 4001 nlockmgr
100021 4 udp 4001 nlockmgr
100021 1 tcp 4001 nlockmgr
100021 3 tcp 4001 nlockmgr
100021 4 tcp 4001 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100005 1 udp 4002 mountd
100005 1 tcp 4002 mountd
100005 2 udp 4002 mountd
100005 2 tcp 4002 mountd
100005 3 udp 4002 mountd
100005 3 tcp 4002 mountd

11. Verify that the selected directories are exported:

showmount -e

12. In order to verify that the selected TCP and UDP ports are being listened, invoke:

netstat -tauap

13. If everything is OK, make NFS services startable at boot time with following commands:

chkconfig portmap off
chkconfig nfs off
chkconfig nfslock off
chkconfig --level 345 portmap on
chkconfig --level 345 nfs on
chkconfig --level 345 nfslock on

Sources:
1. Setting up a Fedora NFS server
2. Fedora9: Quick NFS Server Howto setup NFS server fedora
3. F9 Network File System (NFS)

Uploading a file to TFTP server from local host

In this case, we are uploading a text file from the Windows host to the TFTP server running on Fedora guest. (VirtualBox!)

1. The command given in Windows host is depicted below.


2. The "Permission denied" response from the server is due to the SElinux policy.


3. Серверт файл хадгалах шаардлага одоогоор шаардлагагүй тул шийдлийг нь хийсэнгүй. Шийдэх арга замыг эндээс үз.

Starting up TFTP server

1. switch to superuser

su

2. invoke following commands

/sbin/chkconfig tftp on
/sbin/chkconfig xinetd on
/sbin/service xinetd start

Downloading a file to the embedded target using TFTP

1. Power on the embedded target board (EASY 21653)
2. During boot press "Enter" to stop automatic boot
3. The shell prompt will appear and type following to load a file named "test" to location at 0x80a00000 in the RAM

tftp 0x80a00000 test

4. The result is depicted below figure.

Setting up "Serial ports" in VirtualBox for Fedora guest

1. Run VirtualBox and select the desired VM
2. Select "Serial ports" from the right panel
3. Choose "Port 1" tab
4. Set Port 1 as follows:

Port Number: COM1
Port Mode: Host Device
Port Path: COM1

With this setting you cannot use the serial port COM1 simulataneously from host (Windows) and guest (Fedora).

Setting up "Bridged networking" in VirtualBox for Fedora guest

1. Run VirtualBox
2. Create a new VM
3. On the right panel select "Network"
4. In the "Network" dialog box, after selecting "Adapter 1" tab, set as follows

Enable Network Adapter: checked
Adapter Type: IntelPRO/1000 MT Desktop (82540EM)
Attached to: Bridged Adapter
Name: Intel (R) PRO/1000 MT Network Connection

5. And start the VM

Installing TFTP on Virtualbox/Fedora (guest)

Virtualbox-н зочин Fedora дээр TFTP суулгах, суугаад ажиллаж байгаа эсэхийг шалгах.

1. Дараахь командаар TFTP серверийн багцыг Fedora дээр суулгана

yum install tftp-server

2. Харин TFTP клиентийг суулгахдаа

yum install tftp

гэсэн командыг өгнө.

3. TFTP серверийн тохируулгыг

/etc/xinetd.d/tftp

файлд хийх ба

disable = yes

мөрийг

disable = no

болгож солино. Энэ нь TFTP серверийн ажиллагааг "зөвшөөрөөгүй" байсан анхны (default) тохиргоог "зөвшөөрсөн" болгож солино.

Энэ файл дахь

server_args

хувьсагч нь TFTP серверийн файлын санг заасан мэдээллийг агуулна. Сан нь анхны байдлаар

/tftpboot

гэж байх боловч хэрэглэгч үүнийг өөрийн дураар өөрчилж болно.

Мөн сангийн эзэмшигч нь анхны байдлаар (default)

root

гэж өгөгдөх боловч түүнийг

chown nobody:nobody /tftpboot

гэсэн командаар nobody хэрэглэгчийн мэдэлд шилжүүлж болно.

Түүнчлэн TFTP сервер луу файл хадгалдаг болгохын туд server_args хувьсагчид -c аргументийг нэмж өгч болно. Ж/нь

server_args = -c -s /tftpboot

Лог системд xinetd сервисийн логийг бүртгүүлэх бол нэг буюу хэд хэдэн -v аргументийг server_args хувьсагчид олгоно. Ж/нь:

server_args = -c -s -v -v -v /tftpboot

4. Ингээд серверийг ачааллахдаа

/sbin/chkconfig tftp on
/sbin/chkconfig xinetd on
/sbin/service xinetd start

эсвэл

chkconfig tftp on
chkconfig xinetd on
service xinetd start

командуудыг өгнө.

Хэрэв сервер ажиллах явцын дунд түүний тохиргуулгын файлд (/etc/xinetd.d/tftp) ямар нэгэн өөрчлөлт хийсэн бол

/etc/rc.d/init.d/xinetd reload

гэсэн командаар идэвхжүүлнэ.

5. Сервер ажиллаж байгаа эсэхийг шалгахдаа, /tftpboot санд дурын файл байрлуулж байгаад түүнийг татан авч шалгаж болно. Ж/нь:

touch /tftpboot/test.txt

гэсэн командаар /tftpboot санд test.txt файлыг үүсгэе.

Дараа нь локал хост дээрээ TFTP клиентээ ачааллан сервертэйгээ холбогдоно.

tftp

server_ip_addr нь тухайн сервер ажиллаж байгаа хостын IP хаяг юм. Ж/нь: 192.168.0.100

TFTP клиент дээрээс дараахь командаар файлаа татна, хэрэв амжилттай бол quit командаар гараарай.

tftp> get test.txt
tftp> quit

6. Хэрэв үл мэдэгдэх шалтгааны улмаас TFTP серверээс файл татаж болохгүй байвал дараахь аргуудаар сервер ачаалагдан ажиллаж байгаа эсэхийг шалгаж болно.

6.1. netstat ашиглах

netstat -a | grep tftp

командыг өгөхөд хариуд нь

udp 0 0 *:tftp *:*

гэсэн мөр буцаж байвал сервер ажиллаж байна гэсэн үг.

6.2. chkconfig ашиглах
chkconfig --list | grep xinetd
командыг өгөхөд

xinetd based services:

хэсэгт

tftp: on

гэж байвал сервер хэвийн ажиллаж байгааг заана.

7. Нэмэлт, firewall-г хаах, буцааж идэвхжүүлэх
Хаахдаа:

/etc/init.d/iptables save
/etc/init.d/iptables stop

командуудыг өгнө.
Буцааж идэвхжүүлэхдээ:

/etc/init.d/iptables start

гэсэн командыг өгнө.

Эх сурвалж:
1. Installing TFTP on Fedora
2. Check TFTP server
3. Quick HOWTO: Ch16: Telnet, TFTP, and xinetd
4. Setting up DHCP and TFTP servers
5. How to disable the iptables firewall in Linux

Linux terminal programs (гадны төхөөрөмжийг сериал портоор дебагдахад ашиглах линуксын терминал программууд)

Minicom: similar to HyperTerminal on Windows, but without GUI. It's usually included in linux distros.
One has to configure it before really use, by typing:

minicom -s

Add your user account to the uucp group (that owns /dev/ttySx devices) by adding the user account to this group in the /etc/group file.


C-Kermit: compared to minicom more powerful. Need to install it.
Here are short instructions how to install it:
- create a new folder in /opt (i.e., /opt/kermit)
- download and save compressed source from ftp://www.columbia.edu/kermit/archives/cku211.tar.gz in gunzip format
- decompress it, by typing

gunzip < file.tar.gz | tar xvf -

- make install for linux, by typing

make linux

and it produces an executable called

wermit

.
- try it out to make sure it works, by typing

./wermit

- copy it to public folder (i.e., /usr/bin) by renaming as

kermit

and give appropriate permission

Setting up direct null-modem connection over a serial port (i.e., COM1 or /dev/ttyS0) by using C-Kermit:
- start C-Kermit by typing

kermit

- from the kermit command line give following commands:

set modem type none

indicating null-modem connection

set line /dev/ttyS0

over the first serial port (COM1)

set speed 115200

with 115200 bps

set flow none

without flow control

set parity none

without parity check

connect

and finally start connection

Tools and programs I use in my work (ашигладаг програм хэрэгсэл, багаж төхөөрөмж)

1. Systems/Үйлдлийн систем:

1.1. Windows XP
1.2. Fedora core 10 (running as a guest on Windows XP/VirtualBox 2.2.2)

2. Software development tools/Програм боловсруулахад:

2.1. IAR Embedded Workbench IDE 5.2.1 (Windows)
-- used to write C programs for V850; and includes:
- IAR C/C++ compiler for V850 3.50A
- IAR Assembler for V850 3.50A
- IAR CSpyBat debugger 5.2.1
- IAR Library Builder 1.030
- IAR XLIB 4.61C/386 (library editor)
- IAR XLINX 4.61C (linker)

2.2. GNU Compiler Collection 3.4.4. (Linux)
-- used to compile, build C programs
- GNU C/C++ compiler 3.4.4

2.3. Eclipse IDE 3.3.2
-- used to edit C source codes
- Eclipse C/C++ Development Tools (CDT) 4.0.3

2.4. NEC MiniCube2 (Windows)
-- used to debug and install software to V850 microprocessors
- NEC QB Programmer 3.00
- NEC QB Mini 2 on-chip debug emulator & flash programmer

2.5. Doxygen 1.5.8
-- used to manage documentation for source files (.c, .vhd)

2.6. Rhapsody Modeler 7.4
-- used to create UML diagrams

2.7. CVS
-- used to archive source files (.c, .vhd)

3. Hardware logic design tools/Логик дизайнд:

3.1. Xilinx ISE Design Suite 11 (Windows)
-- used to configure and install logic design in Xilinx CPLDs; and includes:
- ISE Project Navigator 11
- iMPACT 11.1 (for installing bit/configuration files to CPLD/FPGAs)
- PACE (for pin configuration)

3.2. ModelSim XE III/Starter 6.0A (Windows)
-- used to simulate logic designs described in VHDL

3.3. Protel Design System 3.5.1 (Windows)
-- used to make schematic diagramms, and PCB layouts; and includes:
- EDA/Client 3.5

4. Other instruments/Багаж хэрэгслүүд:

4.1. Digital real-time oscilloscope
-- used to measure signal properties
- Tektronix TDS 210 (2 channel, 60 MHz, 1GS/s, 5V-2mV, 5s-5ns)

4.2. Laboratory power supply
-- used to supply operating voltage
- Voltcraft (0-30 VDC, 2.5A)

4.3. Digital multimeter
-- used to measure voltage and conducting lines
- Monacor DMT-2560 (0.2-1000VDC, 0.2-700VAC, 0.2m-20A DC/AC, 200-20MOhm, diode, transistor check)

Шинээр ажилд оруулж байгаа хавтан

Энэ хавтанг шинээр ажилд оруулж байгаа. NEC 32-битийн микропроцессор, TI тоон сигналын процессор, 2 ширхэг програмчлагддаг логик, VoIP кодек бүхий хэлхээ. Одоогоор:
- микропроцессор <-> LED дэлгэц
- микропроцессор <-> RAM
- микропроцессор <-> UART
гэсэн интерфейсүүдийг туршин ажиллуулаад байгаа.

Электроник, мэдээллийн технологийн чиглэлээр суралцагчдад

Электроник, мэдээллийн технологийн чиглэлээр суралцаж байгаа, доорхи шаардлагуудыг хангасан, идэвхтэй, найдвартай оюутныг системийн загварчлал, симуляцийн чиглэлийн ажилд хамтран ажиллуулна. Уг ажлын талаархи товч мэдээллийг "Mapping of application model to architecture model" бичлэгт өгсөн байгаа. Энэ ажлыг сурахын хажуугаар хийх боломжтой, заавар зөвлөмж, харилцаа онлайн хэлбэрээр хийгдэх бөгөөд 2 долоо хоног тутамд ажлын тайланг авч байна. Эхлээд тодорхой асуудлыг шийдэх даалгавар өгч, гүйцэтгэлээс нь хамааруулан сонгон авна. Ажлын үргэлжлэх хугацаа доод тал нь 6 сар, сарын суурь хөлс 50 евро + шагнал.

Тавигдах үндсэн шаардлага:
- электроник, мэдээллийн технологийн чиглэлээр суралцаж байгаа
- англи хэл дээрх мэргэжлийн материалыг төвөггүй уншиж ойлгодог байх (ажлаа тайлагнаж, дүгнэж бичих чадвартай байвал бүр сайн)
- жава хэл дээр програм бичих дадлага, туршлагатай байх
- линукс үйлдлийн систем дээр ажиллаж байсан (гэхдээ шээл болон пэрл скрипт бичдэг бол бүр сайн)

Мөн дараахь дадлага, туршлагатай байвал бүр сайн:
- матлаб/симулинк дээр загварчилж байсан
- ЮМЛ диаграм ашиглан дээр загварчилж байсан
- микропроцессор бүхий жижиг электрон схем зохион бүтээж, туршиж байсан

Хэрэв эдгээр шаардлагыг хангаж байгаа гэж үзвэл, өөрийнхөө товч танилцуулгыг (CV ч юм уу) yahuumeel эт yahoo цэг com хаягаар илгээж, блогт давхар коммент үлдээнэ үү. Ямар ч тохиолдолд хариуг буцаан илгээх болно.

АНХААР! Зөвхөн коммент үлдээсэн тохиолдолд л имэйлээ шалгах болно.

Mapping of application model to architecture model (wireless sensor system)

The proposed work will cover the definition and implementation of a mapping mechanism that constructs an executable system model for an application-specific sensor network simulation. The desired system model, which will be based on a wireless sensor network, shall be built by using appropriate submodels that separately represent system behavior (function model), its physical implementation (architecture model) and application-specific model (i.e., mobility).

Function model: it describes target system behavior by using logical sensor entities, which provide typical sensor network functionalities, like sensor processing, radio communication, and data management. A behavior of such a logical entity would be given in certain separate state diagrams (compatible with UML statecharts). The sensor processing diagram represents basic operations for accessing sensors and processing sensor data, i.e., data averaging or compression. The communication diagram represents basic communication protocol and is the main part of the function model. The data management diagram specifies local data storage handling (data is removed after successful transmission or due to memory overflow). The function models can be defined for the source and destination entities differently.

Architecture model: it contains potential physical parameters for physical sensor nodes, that can be obtained from technical descriptions of available hardware platforms or some prototype models: sensor type/delay, memory size, processor type, radio transmission range/rate.
Two types of hardware architecture models are chosen: COTS (Berkeley Mica series) and SoC (VHDL/FPGA) models and both support the TinyOS operating system.

Application-specific model: radio channel models, group/individual mobility model.

Mapper: According to a given application scenario, it constructs a system model that comprises of aforementioned three separate models: function, architecture and application-specific models.
It takes certain parameters from application requirements: a number of the target objects (i.e., animal under biological study), additional properties/restrictions of the target objets and base stations (i.e., mobile or stationary, possible communications), study area, intended positions for obtaining data from the targets (if destinations are stationary), candidate sensor node hardware architecture (one or more) etc.

The mapper creates the same number of the instances (a simple PTII actor that can contain required parameters for the function and mobility models) for the source nodes; the amount is equal to a number of target objects. The maximum possible number of the instances for destination nodes (or base stations) will be derived from the number of the base stations (or their positions). By default, all source nodes will be mobile and all destination nodes will be stationary and only existing communication is between the sources and destinations (restriction: no communication between sources).

The system is verified by simulation and evaluated with certain metrics, such as connectivity/delay (a function of the numbers of sensors, destination nodes, and positions, communication protocol, memory), and power consumption/network lifetime (a function of architecture, communication protocol, and the numbers of sensors). Because of complexity in estimating power consumption, only connectivity/delay will be considered at first.

When any of source nodes is in communication distance of any of destination nodes and the destination node is active they will exchange data until the communication terminates due to distance. During communication, physical delays will be introduced by a channel model and the architecture model.

Possible application scenarios:
- mobile sources and stationary destinations
- both sources and destinations are mobile
- communication is only between sources and destinations, but not between sources
- communication is possible between sources, and sources and destinations.
- above scenarios in case of 2-3 different communication protocols (protocol descriptions will be taken from the Zebra project)

A diagram below shows structure of components that will be defined and implemented within the work.



Comment:
- Implementation (in blue, PTII actors)
- Definition (in pink, UML compatible)
- Definition (in green, actor-oriented/PTII compatible, classes)

Design space exploration of a domain-specific wireless sensor networks

My research interest is in both hardware and software design challenges of wireless communication systems. In alignment with the research work that is being done at the Institute of Microelectronic Systems (MES) of TU Darmstadt, I integrated to a team of researchers who work on wireless sensor networks and reconfigurable hardware design.

Design space exploration is one of the major tasks in electronic system-level design. Same applies to the whole design process of application specific wireless sensor network design. Due to the complexity of such a system, automated development involves various levels of system abstraction. Consequently, a variety of different development tools including several different simulators are required. It was estimated that the work is best divided into four phases depending on the level of abstraction.

In the first phase, the objective is to create a sensor node library that includes a set of common components of a single sensor node. Here the lowest level of abstraction shall be dealt with, including the hardware and software platforms for a sensor node. A typical sensor node consists of smaller hardware modules such as a microcontroller (in certain case with an integrated special-purpose hardware unit), sensing and actuating modules, and a (medium/short range) radio transceiver as well as software modules such as a real-time operating system, (multihop) routing protocol, and other task-specific algorithm implementations.

The second phase involves domain-specific system modeling, the goal being the modeling of a target application environment. It is thus effectively the highest level of abstraction. Here the primary modeling methodology shall be based on an actor-oriented approach. By use of an existing actor-driven, distributed embedded system design framework a chosen specific application shall be modeled into a system model. Consequently, this system model describes the target system behaviour as a set of functions. A wildlife tracking and monitoring, which is considered as a one of the most complex wireless sensor network applications, is chosen as the target application.

The proposed domain-specific, model-based simulation approach to the design space exploration shall be prototyped in the third phase. Here, previously predefined system functions (from the second phase) shall be mapped to the sensor node platforms (from the first phase) and these mapping techniques will be evaluated. While this phase ends with the development of the prototype on the basis of homogeneous sensor nodes, the fourth phase will extend the prototype by supporting heterogeneity and reconfigurability of sensor nodes.

Электрон хэлхээг (прототип) ажилд оруулах

Микроконтроллерийн удирдлага бүхий дэд хэсэг, дууны аналог дэд хэсэг, гадны бусад төхөөрөмжтэй холбогдох интерфейсийн дэд хэсэг бүхий цахилгаан хэлхээтэй хавтанг хэрхэн ажилд бэлтгэх буюу утааны тест (smoke test) хийх талаар SZ-н хавтан дээр хийсэн ажилдаа тулгуурлан тайлбарлав.

SZ хавтан нь ойролцоогоор 40 гаран том жижиг ИС (микропроцессор, тоон сигналын процессор, санах ой, програмчлагдах логик, кодек, цуурай дарагч, аналог мултиплексор, хаяг/өгөгдлийн буфер, шугамын драйвер, хүчдэл тохируулагч), 20 гаран транзистор, 10 гаран шулуутгах болон тогтворжуулах диод, 260-д эсэргүүцэл, 200-д конденсатор, цөөн тооны ороомгоос тогтох дуудлага, холбооны гэрлэн системийн удирдлагын төхөөрөмж юм.

Энэхүү төхөөрөмжийн хавтанг ажилд бэлтгэхдээ хэлхээний хэвийн байдалд үндсэн 2 шалгалтыг хийв.

1. Механикийн шалгалт (үүнийг голчлон гагнуурын төлөвлөгөөний зураглал буюу beschtueckungsplan-ны тусламжтайгаар хийнэ)
- ИС, элементүүд хавтан дээр бүгд бүрэн гагнагдсан эсэхийг гагнуурын төлөвлөгөөтэй тулгаж, нүдээр шалгана. (зарим эсэргүүцэл, конденсатор гагнагдаагүй орхигдсон байв)
- ИС, элементүүд зөв байрласан эсэхийг гагнуурын төлөвлөгөөтэй тулгаж, нүдээр шалгана. (санах ойн ИС буруу байрласан байв)
- ИС, элементүүд бүрэн гагнагдсан эсэхийг нүдээр шалгана. (кодекийн зарим хөл гагнагдаагүй байв)

2. Цахилгааны шалгалт (үүнийг бүх схем зураглал, техникийн тодорхойлолт дээр тулгуурлан програм хэрэгсэл, хэмжүүрийн болон бусад багаж хэрэгслийн тусламжтайгаар гүйцэтгэнэ, механик шалгалт ч мөн давхар хийгдэж болно)
- ИС-н оролт гаралт, свитч түлхүүрийн байрлал зөв тохируулагдсан эсэхийг шалгана.
- Тэжээлийн шугамууд бүгд зөв холбогдсон эсэхийг програм хэрэгсэл ашиглан зарчмын схемийг байрлал холболтын схемтэй тулгах замаар шалгана. (+24, +5, +3, +2, -5, +22-н бүх шугамуудыг PCB файл дээр нь мөрдөж шалгасан)
- Хэрэв хэлхээ дотроо тэжээлийн дэд хэсэгтэй бол түүний ерөнхий хүчдэлтэй ойролцоо хүчдэл бүхий үүсгүүрийг тэжээлийн дэд хэсэгт гаднаас холбож, хэлхээний гүйдлийн хэмжээг шалгана. Шаардлагатай тохиолдолд тэжээлийн дэд хэсгийн элементийг бүхлээр нь болон хэсэгчлэн хэлхээнээс салгаж, тусгаарлаж байгаад шалгана. (тэжээлийн дэд хэсэг дэх гаралтын хэлхээний ороомгийг салгах замаар тэжээлийн дэд хэсгийг хэлхээнээс тусгаарлаж, +5-н шугамд гаднаас тэжээл өгсөн. +5 өгөхөд гүйдэл 3А-с дээш байсан нь хэлхээ алдаатай, эсвэл согогтой гэдгийг харуулж байв)
- Хэлхээний тэжээлийн шугам бүрийг нэг бүрчлэн тусад нь шалгана. (+5, +3, +2, -5, +22-н шугамыг шалгасан. +5, +3-н шугамнаас тэжээл авдаг элемент, хэсгүүдэд алдаа байсныг олсон)
- Гадны тэжээлд холбоход хэлхээнийн гүйдэл хэт өндөр байх (+3A-с дээш байв), эсвэл өөр ямар нэгэн сэжиг илэрсэн үед эхлээд зарчмын схем зураглал дээрх ИС-н тэмдэг тэмдэглэгээ техникийн өгөгдөл, тодорхойлолттойгоо (datasheet) таарч байгаа эсэхийг шалгана. (кодекийн 3 хөлний тэмдэглэгээ тодорхойлолтоос зөрж байсныг илрүүлсэн)
- Мөн сэжигтэй тохиолдолд заавал хийх шалгалт нь зарчмын схем зураглал нь байрлал холболтын схем зураглалтай (layout) таарч байгааг програм, багаж хэрэгсэл ашиглан шалгах юм. (шугамын драйверийн ИС-н холболт буруу байсныг мултиметрийн хэмжилтээр олсон. Үүний дараа PCB файл дээр бусад бүх холболтуудыг мөрдөж шалгасан)

Жишээ нь SZ хавтан дээр илэрсэн алдаанууд:
- эхлээд +24-н хэлхээнд +5-г гаднаас өгөхөд тэжээлийн блокийн гүйдэл 3А-с дээш зааж байв. Энэ нь хэлхээнд алдаа, согог байгаа гэдгийг харуулж байна. Уг нь 260mA-с хэтрэх ёсгүй.
- Тиймээс тэжээлийн ороомгийг салгаж байгаад +5-н шугамд гаднаас +5-г өгөв. Гүйдлийн хэмжээ өндөр хэвээр.
- Тэгэхээр нь +3-н хэлхээнд гаднаас +3-г өгөв. Учир нь +3, +2, -5 нь +5-р үүсгэгдэж байгаа. Гүйдэл мөн өндөр хэвээр.
- +3 ямар ИС, элементэд холбогдсоныг зарчмын схемийн дагуу мөрдөж, тэдгээр холбоотой ИС, элементүүд хавтан дээр зарчмын схемийн дагуу холбогдсоныг мултиметрээр шалгах явцад шугамын драйверийн хэлхээнд буруу холболт хийгдсэнийг олов.
- Алдааг засаад дахин +3-г гаднаас өгөхөд гүйдэл өндөр хэвээр байв. Өөрөөр хэлбэл өөр алдаа байна гэсэн үг.
- Бүх холболтыг PCB файл дээр шалгаж, зөв гэдгийг тогтоосны дараа ИС-н тэмдэглэгээг datasheet-тэй нь тулгаж шалгав. Энэ шалгалтаар кодекийн 3 хөл зарчмын схем дээр буруу тэмдэглэгдсэн болохыг олов. Өөрөөр хэлбэл зарчмын схем дэх симбол буруу тодорхойлогдсоноос алдаа гарч, ИС-н хөлнүүд буруу сигналд холбогдсон байв. Энэ буруу холбогдсон хөлнүүдийг хавтангаас хөндийрүүлсний дараа +3-г холбоход гүйдэл багасч ойролцоогоор 400mA болсон байв. Үүнийг +3-н хэлхээ алдаагүй болсон гэж үзэв.
- +5-н шугамд гаднаас +5-г өгөхөд гүйдэл дахин өндөр хэвээр байв. Гэхдээ 2,5А орчим байв.
- +5-н шугамд PCB файл дээр шалгалт хийх явцад санах ойн ИС буруу байрласныг олов.
- Уг ИС-г хэлхээнээс салгаж байгаад дахин +5-г өгөхөд гүйдэл багасаад 400mA орчим зааж байв. Ингээд +5 шугамд гүйдэл бага байгаа тул +3, +2 шугамууд хэвийн гэж үзэв.
- Нэгэнт дотоод тэжээлийн гаралтын хэлхээ хэвийн болсон тул тэжээлийн оролтонд +5-с +24 хүртэл хүчдлийг аажмаар өгөв. Гүйдэл бүр багасч 200mA-с багыг зааж байв.
- Үлдсэн -5, +22 шугамын хүчдэлийг шалгахад -5 хэвийн, харин +22-н оронд +16 зааж байв. +16-н хэлхээний ҮӨ-н гаралт 0В орчимд байсан тул үүнийг хэвийн гэж үзэв.
- Шалгалтын явцад бусад жижиг алдаануудыг мөн илрүүлэв: зарим эсэргүүцэл, конденсатор холбогдоогүй, зарчмын схемийн хэд хэдэн алдаа г.м.

const char*

C код дотор const char* гэсэн мөр нэлээд тааралдах нь бий. Тухайлбал хувьсагч, функцын аргумэнтийн төрлийг ингэж тодорхойлсон байдаг.

Жишээ нь:

struct MyStruct
{
const char* name;
int return;
};

эсвэл

void MyFunction(const char* file, int line, const char* message);

Энэхүү const char* төрөл яагаад const char * гэж бичигдээгүй нь анхаарал татлаа. Дээрх жишээн дэх name, file, message гэсэн хувьсагч, аргумэнтууд нь бүгд утгыг нь өөрчилж болдоггүй тэмдэгт мөрийг (string constant, string literal) заах заагчид юм. Хэрэв эдгээр нь заагч юм бол од (*) уг нь хувьсагчийн нэрэнд зүүлттэй баймаар юм.

const char *name, const char *file

г.м.-ээр.

Яагаад заавал одыг (*) char дээр зоогоод байгаагийн учрыг мэдмээр байна.

BENNING Duspol analog plus - Шугамын хүчдэл шалгагч

Товч тайлбар

Хувьсах болох тогтмол хүчдэл хэмжинэ, шугамын фазын чиглэлийг тогтооно. Хэмжилтийн утгыг гэрлийн диод (LED) болон шилжих заагуур* бүхий хуваариар үзүүлнэ.

Техникийн үзүүлэлт

Хэмжүүрийн хязгаар: 12 - 690 Вольт (хувьсах хүчдэл, LED), 750 Вольт (тогтмол, шилжих заагуур)
Хувьсах орон, фазын чиглэл тодорхойлно: R (цагийн зүүний дагуу) гэсэн тэмдэглэгээгээр харуулна.
Хүчдэлийн туйлыг тодорхойлно: +/- туйлыг LED дээр харуулна.
Чичиргээт дохиололтой: энэ нь хүчдэлийг найдвартай, үнэн зөв мэдрэх үүрэгтэй.
Ачаалал залгаж турших боломжтой: даралтат товчлуураар шалгана. Is=250мА, 750В (тогтмол)
Батерей хэрэглэхгүй ажиллана.
Хамгаалалтын төвшин: IP64, тоос, усны үсрэлтээс хамгаалагдсан.
Хэт хүчдэлийн категори: CAT IV 500Вольт, CAT III 690Вольт.

* Шилжих заагуур гэдэг нь тогтоосон хуваарь дээгүүр шилжин хөдөлж, хэмжиж байгаа хэмжигдхүүний тоон утгыг харуулдаг механизм. Өөрөөр хэлбэл аналог тестерийн зүүтэй адил.

BENNING - халаасны тоон мултиметер

Товчхон тайлбар

Энэ халаасны тоон мултиметер (тестер ч гэж нэрлэж болно) нь 5 төрлийн хэмжилтийг (тогтмол болон хувьсах хүчдэл, эсэргүүцэл, давтамж, конденсаторын багтаамж) тоон хэлбэрээр гүйцэтгэнэ. Хэмжилтийн үр дүнг HOLD товчлуураар өөртөө хадгалах боломжтой. Ашиглахгүй удсан үед өөрөө автоматаар унтарч, батерей хэмнэх горимтой. Мөн хагас дамжуулагч диодны гарцыг хэмжихээс гадна шугамын холболтыг хэмжиж, дуут сигнал өгнө.

Техникийн үзүүлэлт

Тогтмол хүчдэлийг (Vdc) хэмжих хязгаар: 0,1мB - 600B, +/-0,6%
Хувьсах хүчдэлийг (Vac) хэмжих хязгаар: 0,1мB - 600B, +/-0,9%
Эсэргүүцэлийг (R) хэмжих хязгаар: 0,1Oм - 40МОм, +/-0,9%
Давтамжийг (f) хэмжих хязгаар: 1МГц - 5 МГц, +/-0,3%
Багтаамжийг (C) хэмжих хязгаар: 10пФ - 100мкФ, +/-2,9%

Хэмжилтийн утга: дундаж квадрат (RMS)
Хэмжүүрийн категори: CAT III, 300Вольт
Хэрэглэгдэх батерей: LR44 төрлийн 2 ширхэг 1,5В (2x1,5В LR44)
Овор, хэмжээ: 132x86x19мм, 130гр

Дагалдах зүйлс: хэмжүүрийн хошуу, арьсан гэр, батерей (2xLR44)

ATmega8 микроконтроллерийн туршилтын хавтан

Энэ хавтан нь Atmel ATmega8 микроконтроллерт тулгуурлан янз бүрийн зориулалттай жижиг электрон төхөөрөмжийн зохион бүтээлтэнд зориулагдсан.
Хавтан нь микроконтроллер, тэжээлийн хэсэг, гэрлэн диодууд, товчлуур, баззер (дуун дохио үүсгэнэ), өргөтгөх интерфэйс, программчлах интерфэйс гэсэн үндсэн хэсгүүдээс тогтоно. Сериал эсвэл USB портоор компьютерт холбогдон программчлагдах боломжтой. Мөн LCD дэлгэц, Ethernet интерфэйс, температурын сенсор гэх мэт нэмэлт төхөөрөмжөөр тоноглох боломжтой.
Хэрэв та энэ хавтанг ATmega8 микроконтроллерийн удирдлагатай жижиг электроник хийж туршихдаа ашиглах сонирхолтой байвал хүсэлтээ блогт тайлбар хэлбэрээр үлдээгээрэй.

Asuro robot

Asuro robot - developed in the German Airspace Centre.

Асуро нь Германы Агаарын болон Сансрын Нислэгийн Төвд зохион бүтээгдсэн хөдөлгөөнт робот бөгөөд электроник сонирхогч болон сургалтанд зориулагдсан.
Роботыг хэрхэн яаж угсрах талаар доорх видео бичлэгт үзүүлсэн байгаа (энд дарж бичлэгийг үз.) Үүнээс гадна зарим блогуудад ч угсралтын талаар дурдсан байгаа. Жишээ нь энэ блогийг уншиж болно.
Хэрэв ийм робот дээр элдэв туршилт хиймээр байвал хүсэлтээ блогт тайлбар болгон үлдээгээрэй.