Flameman/proof

From eLinux.org
< Flameman
Revision as of 13:37, 3 August 2011 by Flameman (talk | contribs)
Jump to: navigation, search

For more interesting projects done by Flameman, be sure to checkout his project index

coldfire emulator

http://www.slicer.ca/coldfire/ (it has a bug, it does not work on bigendian host)


gentoo wiki

[1]

electronic

encoder

  • HP Agilent HEDS-5500 C11 Optical Encoder


walnut/NFS&C

i' am on a ppc machine (*walnut), equipped with IBM-405GP (~ppc603/4 core) the firmware (uboot) make me able to tftpboot only <6Mb of kernel+ramrootfs

i'd like to prepare a ~ NAS (network attached storage), i mean i'd like to have a remote "embedded machine" with software raid 1 in/from where mount a remote filesystem

now, suppose that you want to mount a filesystem on a remote computer sitting somewhere on the internet. There are two standard ways to do this

  • NFS (Network FileSystem) - the standard UN*X way
  • Samba (SMB/CIFS/Microsoft Windows Networking)



NFS is nice: it's fast, it's standard, it roxs Unfortunately, there are drawbacks to NFS, at least as far as I can tell:

1) You will need FULL access to both systems in order to configure them to use NFS - this means that you will need to be root on both systems

2) Both systems need to be able to talk to each other directly without being impeded by firewalls, gateways

3) I have experienced machine crashing when one side of the link goes down. In other words, if one machine is expecting the other machine to be there, and it isn't... BOOM... good luck regaining control. Note that this happens to me whether I use so-called "hard" or "soft" mount options.

4) Neither NFS nor Samba is particulary secure. I would never dare set up a share without being behind a firewall. Even then I'm a bit scared.


about The alternative ? sshFS, a filesystem client based on the SSH File Transfer Protocol.

OK, it a user space fs, but since most SSH servers already support this protocol it is very easy to set up:

  • on the server side there's nothing to do.
  • on the client side mounting the filesystem is as easy as logging into the server with ssh


on the server side, NFS is depending of portmap, which is issuing "segmentation fault" on uclibc-profile

other bad things happen trying to compile with uclibc

[net-fs/nfs-utils] issues not compiling cause net-fs/nfs-utils-1.1.6/

  • utils/statd/stat.c: #include "myglibc-missing-functions.c"
  • utils/mountd/cache.c: #include "myglibc-missing-functions.c"

that happens cause in the uc-pofile the glibc has been replaced by uclibc which is missing of

  • getgrouplist()
  • getrpcent_r()
  • int getrpcbyname_r()
  • int getrpcbynumber_r()

bugged binaries (cause of the missing functions of uclibc):

  • utils/mountd/mountd
  • utils/statd/sm-notify
  • utils/statd/statd


[sys-fs/sshfs-fuse] is claiming, too !

  • No package 'glib-2.0' found
  • No package 'gthread-2.0' found


but you do not use it on the server side ! what you only need is /usr/sbin/sshd !!!


NFS

sshFS

LAN chip CS8900A from Cirrus logic, IP Dragon II

The IP Dragon II is our second generation ethernet interface module based on the popular ethernet controller CS8900A from Cirrus logic.

The IP Dragon II is fully equiped to give any 8 or 16-bit system full ethernet capability. It features a selectable 8-bit or 16-bit databus interface, chip select and read/write signals. The board has two rows (2 x 15) of pins making it very easy to mount in an experiment system or a production system. The RJ-45 connector integrates both the inductor and two LED's that shows the link activity.

With this module your are ready to start implementing ethernet and internet communication on your embedded system in no time. Drivers for various TCP/IP stacks can be found on our download page.

General Information:

The IP Dragon is equiped with the Cirrus Logic embedded ethernet controller CS8900A. This ethernet controller is a flexible and powerful controller that can be used for embedded applications. Many other controllers on the market is targeted to the PCI bus and PC's making them very complex if not impossible to adapt to a low cost embedded system.

The module should connect to an MCU or CPU as a standard memory with the 8 or 16 -bit databus, IOR, IOW and CS signal. The module also supports interrupts in 16-bit mode.

A small serial EEPROM connected to the controller can be used to store the ethernet address and other controller related data. The EEPROM is only supported in 16-bit mode.

  • 8 or 16 -bit databus is easily selected by moving a jumper.
  • Measurements: 34mm x 50mm
  • Supply Voltage (IET8905E): 5V
  • Supply Voltage (IET8903E): 3.3V

opernWRT board

sony psx3

source released

AR7 DSL-G604T

The DSL-G604T looks like DLS-504T and also provides an 802.11g/802.11b WiFi connectivity.

  • CPU: Texas Instrument TNETD7300GDU AR7W MIPS 4KEc based SoC with built-in ADSL and Ethernet interfaces
  • SDRAM Memory: 16Mb Hynix HY57V281620HCT
  • Flash Memory: 4Mb SquashFS file system. Atmel AT49BV322A
  • DSP-based ADSL
  • WiFi: TI ACX-111 AirPlusG+ card (VLYNQ)
  • Ethernet: IP175A 5-port Ethernet hub (1 internal, 4 external)


net chip IP175A

IP175A is a low cost 10/100 Ethernet single chip switch. It integrates a 5-port switch controller, SSRAM, and 5 10/100 Ethernet transceivers. Each of the transceivers complies with the IEEE802.3, IEEE802.3u, and IEEE802.3x specifications. The transceivers are designed in DSP approach with 0.25um technology; they have high noise immunity and robust performance.

IP175A operates in store and forward mode. It supports flow control, auto MDI/MDI-X, CoS, port base VLAN, and LED functions, etc. Each port can be configured to auto-negotiation or forced 10M/100M, full/half duplex, and it is also able to configure to 100BaseFX transmission mode. Using an EEPROM or pull up/down resistors on specified pins can configure the desired options. IP175A does not support "forced 10M half mode".

IP175A supports two MII ports for router application, which supports 4 LAN ports and one WAN port. MII0 is for LAN traffic and MII1 is for WAN traffic and no external PHY is needed. Both MII can work in PHY mode and interface to the external MAC in this application. The external MAC can monitor or configure IP175A by accessing MII registers through SMI.

MII0 also can be configured to be MAC mode. It is used to interface an external PHY to work as a 4+1 switch.

Feature :

  • 5 port 10/100 Ethernet switch with built in transceivers and memory
  • Build in SSRAM for frame buffer
  • Built in storage of 1K MAC address
  • Support flow control
  • Support IEEE802.3x for flow control for full duplex mode operation
  • Support backpressure for flow control for half duplex mode operation
  • 5 port switching fabric
  • Support two-level hashing algorithm to solve MAC address collision
  • Support MAC address aging
  • Store and forward mode
  • Broadcast storm protection
  • Full line speed capability of 148800 (14880) packets/sec for 100M (10M)
  • Support 1536 byte data transfer for VLAN packet traffic
  • Port base VLAN
  • Port base CoS configuration
  • Integrate 5 ports transceiver
  • Each port can be auto negotiable or forced 10M/100M, full/half duplex
  • Each port can be configured as 100BaseFX
  • Automatic MDI/MDI-X configuration
  • Support tow MII, one SMI and extended MII registers for router application
  • Built in regulator for 3.3v to 2.15v
  • LED status of Link, activity, full/half duplex, speed, and power on diagnostic function
  • Initial parameter setting by pin or EEPROM (24LC01) configuration
  • Utilize single clock source (25Mhz)
  • 0.25u technology
  • Support Lead Free package (Please refer to the Order Information)


Firmware

ADAM2

uart

5-pin connector, attached to UART_A

1 RX 
2 GND 
3 +3.3V 
4 GND 
5 TX 

jtag

MIPS EJTAG, EJTAG 2.6 header
pin numbering is wrong, need to be verified

1 TRST
2 TDI
3 TDO
4 TMS
5 TCK
6 RST
7 DINIT

8 +3v (VIO)
9 -
10 GND
11 GND
12 GND
13 GND
14 GND
DSP JTAG (JP3)
pin numbering is wrong, need to be verified

1 - TMS
2 - TDI
3 - VCC (3.3V)
4 - TDO
5 - TCK
6 - TCK_RET
7 - EMU0

8 - TRST
9 - GND
10 - -key
11 - GND
12 - GND
13 - GND
14 - EMU1

core 405 vs core 440

PowerPC 405 core

Overview: The IBM PowerPC 405 core is a 32-bit RISC CPU core providing up to 400 MHz and 608 DMIPS performance as implemented in IBM's advanced 90-nm copper CMOS technology. The 405 core employs the scalable and flexible Power Architecture technology, optimized for embedded applications.

The licensable embedded core integrates a scalar five-stage pipeline, separate instruction and data caches, a JTAG port, trace FIFO, multiple timers and a memory management unit (MMU), with 1.52 DMIPS/MHz performance.

The PowerPC 405 core's performance, low power specifications and design attributes make it an ideal solution for emerging consumer, storage and wired or wireless communications applications.


when

The PowerPC 405 was released in 1998 and was designed for price or performance sensitive low-end embedded system-on-a-chip (SoC) designs. It has a five-stage pipeline, separate 16 KB instruction and data L1 caches, a CoreConnect bus, an Auxiliary Processing Unit (APU) interface for expandability and supports clock rates exceeding 400 MHz. The 405 core adheres to the current Power ISA v.2.03 using the Book III-E specification. Both AMCC and IBM are developing and marketing processors using 405 cores. IBM and Synopsys also offers a fully synthesizable core. IBM has announced plans to make the specifications of the PowerPC 405 core freely available to the academic and research community.[1]

where is it used

PowerPC 405 based applications includes digital cameras, modems, set-top boxes (IBM's STB04xxx processors[2]), cellphones, GPS-devices, printers, fax machines, network cards, storage devices and service processors for servers. Up to two 405 cores are used in Xilinx Virtex-II Pro and Virtex-4 FPGAs. In 2004 Hifn bought IBM's PowerNP network processors that uses 405 cores.[3]


doc

  • PPC405-S Embedded Processor Core User’s Manual
  • Halfhill, Tom R. (12 July 1999). "PowerPC 405GP Has CoreConnect Bus". Microprocessor Report.
  • Halfhill, Tom R. (11 November 2002). "IBM PowerPC 405EP Expands Family". Microprocessor Report.

PowerPC 440 core

Overview: The IBM PowerPC 440 core is a 32-bit RISC CPU core providing up to 667 MHz and 1334 DMIPS (worst-case) performance implemented in IBM's advanced 90-nm copper CMOS technology. The 440 core employs the scalable and flexible Book E enhanced Power Architecture optimized for embedded applications.

The licensable embedded core integrates a superscalar seven-stage pipeline, with support for two instructions per clock, separate instruction and data caches, a JTAG port, trace FIFO, multiple timers and a memory management unit (MMU), with 2.0 DMIPS/MHz performance.

PowerPC 405: IBM STB04500 in a Dilog DT 550. A set top box powered by a 252 MHz PowerPC 405 based SoC.


when

PowerPC 440: Introduced in 1999, the PowerPC 440 was the first PowerPC core from IBM to include the Book E extension to the PowerPC specification. It also included the CoreConnect bus technology designed to be the interface between the parts inside a PowerPC based system-on-a-chip (SoC) device.

how pretty

It is a high performance core with separate 32 kB instruction and data L1 caches, a seven-stage pipeline, supporting speeds up to 800 MHz and L2 cache up to 256 kB. The core lacks a floating point unit (FPU) but it has an associated four-stage FPU that can be included using the APU (Auxiliary Processing Unit) interface. The 440 core adheres to the current Power ISA v.2.03 using the Book III-E specification.

who is using it

Xilinx currently incorporates one or two cores (depending on the member of the family) into the Virtex5FXT FPGA.

Both AMCC and IBM are developing and marketing stand alone processors using 440 cores. IBM and Synopsys also offers a fully synthesized cores. [edit] QCDOC

QCDOC is a custom supercomputer built to solve small but extremely computationally demanding problems in quantum physics. It uses custom 440-based ASICs to obtain a peak performance of approximately 10 TFLOPS. [edit] Blue Gene/L

Dual 440 cores are used in the processors powering IBM's Blue Gene/L supercomputer which until June 2008 ranked number one on the list of the top 500 supercomputers around the world, with a peak performance of nearly 500 teraFLOPS in 2008. [edit] SeaStar

The 440 core is also used in the Cray XT3, XT4 and XT5 supercomputers, where its SeaStar, SeaStar2 and SeaStar2+ communication processors closely couples HyperTransport memory interface with routing to other nodes in supercomputer clusters. The SeaStar device provides a 6.4 GB/s connection to the Opteron based processors across HyperTransport (together making a processing element, PE), as well as six 7.6 GB/s links to neighboring PEs. SeaStar2+ offers 9.6 GB/s intra-node bandwidth and error correcting functionality to intercept errors en-route between computing nodes.


PowerPC 4XX CPU Core FAQ

Related links: PowerPC 405 Embedded Cores, PowerPC 440 Embedded Core, PowerPC Cores, FAQ


Question #1: There is no read-modify-write instruction. How is an atomic access handled?

Question #2: Why is it necessary to assert the JTAG TRST/ pin in order to reset the CPU?

Question #3: Our desire is to take a little endian application and run it without any changes. Can this be achieved with PowerPC 440 and 405 CPUs?

Question #4: Is it possible to load the boot code sequence through the JTAG port?

Question #5: What are the trade-offs in running the CPU timer logic at CPU clock frequency vs. using a separate clock via the TimerClock input?

Question #6: How do you determine the maximum CPU clock frequency of a 4XX core?

Question #7: Can cache policy be set on a per memory page basis?

Question #8: If a DCR register is less than 32 bits wide, does it have to drive all 32 bits of the DCR data bus? Must it drive "0" on the unused bits?

Question #9: Why disable operand forwarding? Doesn’t that affect pipeline performance negatively?

Question #10: Does enabling of data cache parity checking affect operand forwarding?

Question #11: Does enabling of instruction cache parity checking affect operand forwarding?

Question #12: What is the performance of the MAC function (multiply-accumulate logic)?

Question #13: Can CPU clock to PLB clock frequency ratios be changed on the fly – as in during CPU to PLB transactions?

Question #14: Can a PLB attached DMA engine directly access the CPU caches?

Question #15: Can a PLB attached DMA engine directly access data-side OCM attached memory?

Question #16: Can new instructions (op-codes) be added to the instruction set?

Question #17: Does using extended mnemonics mean that you can create new instructions?

Question #18: If the CPU becomes "hung" from a software or system error, how does one detect and recover from that condition?

Question #19: During a system level reset, all three reset inputs to the CPU were asserted. The "system reset" and "chip reset" inputs were de-asserted followed by the "core reset" input a few cycles later. After the reset cycle was completed, the DBSR[MRR] register field recorded the most recent reset as a "core" reset – why?

Question #20: The documentation mentions three power states; active, standby and sleep. Nowhere in the documentation have I found any detail on how those states are managed and exactly what happens in the non-active states?


Answers Question #1: There is no read-modify-write instruction. How is an atomic access handled?

Answer: Please see the lwarx (load with reservation) and stwcx (store conditional) instruction descriptions. These instructions are used to emulate and atomic access.

Ref: PPC440, PPC405

up arrowBack to questions

Question #2: Why is it necessary to assert the JTAG TRST/ pin in order to reset the CPU?

Answer: A portion on the debug logic function is in the JTAG clock domain and must be reset to guarantee that the CPU can properly initialize and boot correctly. TRST/ must be asserted during the power-on reset interval several cycles.

Ref: PPC440, PPC405

up arrowBack to questions

Question #3: Our desire is to take a little endian application and run it without any changes. Can this be achieved with PowerPC 440 and 405 CPUs?

Answer: When a memory page has the "E" storage attribute set in the TLB, it is treated as (true) little endian. But, a little endian page means that even the instructions are fetched from that page as little endian. We are not aware of anyone who does this since most of the tools (compilers/debuggers) are most heavily used and thus tested using big endian code. We believe some compilers support little endian code generation but not all do. We always recommend compiling the code big endian and putting it in a big endian page.

Data can be mapped to little endian pages as long as you don't use unions of structures which overlay longs or shorts over bytes (etc.). Remember, if the compiler is generating big endian code, it expects big endian byte ordering in words. Another issue for data comes about if you use bit fields in your code and then expect that the bits will end up in certain positions in certain bytes. This is generally not portable from one compiler to another and there will certainly be impacts when going to a PowerPC compiler that is generating big endian code (even if the data ends up in a little endian page).

Key points to be aware of:

  1. Most well written code that has endian dependence calls predefined routines (like ntohl()) that are easily ported and changed in one place.
  2. Code that makes explicit endian assumptions (like pulling bytes out of words) will work in little endian pages as long as unions of structures and bit fields are not used.
  3. Little endian support works well for accessing conventionally little endian devices (e.g. PCI).

Ref: PPC440, PPC405

up arrowBack to questions

Question #4: Is it possible to load the boot code sequence through the JTAG port?

Answer: Yes, this is done via a debug probe attached to the JTAG port. The CPU is put into a “halt” state via the Debug Halt pin. The CPU is then reset. When reset is complete, the CPU is ready to fetch its boot vector, but is held off by the halt state. The debug probe then “stuffs” the boot sequence directly into the instruction pipeline for execution.

Ref: PPC440, PPC405

up arrowBack to questions

Question #5: What are the trade-offs in running the CPU timer logic at CPU clock frequency vs. using a separate clock via the TimerClock input?

Answer: Key points to be aware of:

  1. When using the CPU clock, the timer count rate changes with the CPU clock frequency.
  2. When using the TimerClock input, the time base count is independent of and asynchronous to the CPU clock. The single restriction is the TimerClock input must be operated at less than half the CPU clock frequency.

In summary, if the primary use of the CPU timer function is to measure cycle counts for code profiling and performance estimations, then it is more straightforward to use the CPU clock to run the time base. Instruction execution cycle counts will be directly measured regardless of the CPU operating frequency. If the goal is to create real-time intervals for OS time-slice functions or for interrupt timing, then it is more straightforward to use a fixed frequency supplied through the TimerClock input.

Ref: PPC440, PPC405

up arrowBack to questions

Question #6: How do you determine the maximum CPU clock frequency of a 4XX core?

Answer: To determine the maximum clock rate, you do the following:

  1. Load NDR's for the core into NilPlot and set worst case operating conditions.
  2. Check clock rise to clock rise minimum time for all clock inputs on cores. Don't forget to allow for PLL jitter in this calculation. You must increase the minimum clock period by the amount of the PLL jitter.
  3. In order to account for chip-top clock tree distribution skews, it is suggested that you decrease the resulting frequency by at least 5%. For various other reasons, it is almost never possible to actually achieve the absolute maximum. 

Ref: PPC440, PPC405

up arrowBack to questions

Question #7: Can cache policy be set on a per memory page basis?

Answer: Yes, the "cache inhibit" and "write-thru" fields are available for each MMU TLB entry.

Ref: PPC440, PPC405

up arrowBack to questions

Question #8: If a DCR register is less than 32 bits wide, does it have to drive all 32 bits of the DCR data bus? Must it drive "0" on the unused bits?

Answer: The CPU drives the DCR data out lines to "0". The DCR slave should just pass on these values if it does not implement the register across all of the bits.

Ref: PPC440, PPC405

up arrowBack to questions

Question #9: Why disable operand forwarding? Doesn’t that affect pipeline performance negatively?

Answer: PThis represents a trade-off in maximum CPU clock frequency vs. a cycle of latency in certain cases, most notably the load-use scenario. Having operand forwarding enabled reduces the latency of a load-use scenario by one cycle. The maximum frequency that the CPU may be operated at is reduced in this configuration. If this mode (operand forwarding enabled) is supported, on a chip implementation, it must be timed and specified during chip development and verification. Most (if not all) IBM SOC designs have set operand forwarding fixed to the disabled mode.

Ref: PPC405

up arrowBack to questions

Question #10: Does enabling of data cache parity checking affect operand forwarding?

Answer: Yes, even if operand forwarding is enabled via the TIE_DisOperandFwd input, enabling parity support on the data caches blocks operand forwarding.

Ref: PPC405F4Vx, PPC405F5Vx

up arrowBack to questions

Question #11: Does enabling of instruction cache parity checking affect operand forwarding?

Answer: No, operand forwarding has no relationship to the instruction fetch logic or instruction cache.

Ref: PPC405

up arrowBack to questions

Question #12: What is the performance of the MAC function (multiply-accumulate logic)?

Answer: For half-word multiplies and multiply-accumulate instructions, the latency is two cycles for an instruction and the throughput is one instruction per cycle.

Ref: PPC440, PPC405

up arrowBack to questions

Question #13: Can CPU clock to PLB clock frequency ratios be changed on the fly – as in during CPU to PLB transactions?

Answer: Yes, under certain conditions:

   * N to 1 mode setting is not changed
   * CPU and PLB clocks must be rising edge aligned
   * Frequency ration changes can only occur at the coincidence of aligned rising edges of PLB clocks and CPU clock 

No, in the following scenarios:

   * Changing between “N to 1” mode and “non N to 1” mode settings
   * PLB and CPU clock phase relationships can not be maintained 

Ref: PPC440, PPC405

up arrowBack to questions

Question #14: Can a PLB attached DMA engine directly access the CPU caches?

Answer: No, The CPU load / store unit, instruction fetch unit and the cache controller modules are the only functional units that can access the cache arrays.

Ref: PPC440, PPC405

up arrowBack to questions

Question #15: Can a PLB attached DMA engine directly access data-side OCM attached memory?

Answer: No, The CPU load / store unit and the data cache controller module are the only functional units that can access OCM attached memory arrays.

Ref: PPC405

up arrowBack to questions

Question #16: Can new instructions (op-codes) be added to the instruction set?

Answer: Yes, this requires one of two methods to implement:

  1. Trap the instruction and use software emulation.
  2. Attach an APU engine to the APU interface and perform new operation in hardware. 

Ref: PPC440, PPC405

up arrowBack to questions

Question #17: Does using extended mnemonics mean that you can create new instructions?

Answer: No, extended mnemonics are alternate name references to common op-codes.

Ref: PPC440, PPC405

up arrowBack to questions

Question #18: If the CPU becomes "hung" from a software or system error, how does one detect and recover from that condition?

Answer: The CPU contains a Watch-dog timer function that can be set to automatically generate a reset after a programmed interval if the timer is not serviced by the operating system at regular intervals prior to expiration of the counter. This capability is documented in an application note available on the IBM web site.

Ref: PPC440, PPC405

up arrowBack to questions

Question #19: During a system level reset, all three reset inputs to the CPU were asserted. The "system reset" and "chip reset" inputs were de-asserted followed by the "core reset" input a few cycles later. After the reset cycle was completed, the DBSR[MRR] register field recorded the most recent reset as a "core" reset – why?

Answer: The state of the reset inputs (all three of them) is sampled in the cycle when the “core reset” pin goes inactive. If the core reset assertion is extended past the other reset input assertions for even one cycle, then their “presence” will not be recorded in the DBSR[MRR] field. If this capability is considered important, then the chip-top logic will need to provide for the simultaneous de-assertion of all active reset inputs.

Ref: PPC440, PPC405

up arrowBack to questions

Question #20: The documentation mentions three power states; active, standby and sleep. Nowhere in the documentation have I found any detail on how those states are managed and exactly what happens in the non-active states.

Answer: PowerPC 4XX CPU cores have several features that help conserve power:

   * First, the circuit implementation of the CPU cores automatically does clock gating to registers and latches when they are not being selected.
   * The CPU cores provide for program accessible means of stopping most activity by halting the execution pipeline.
   * Chip-top logic can be used to inactivate the clock enable inputs to the CPU or turn off the clocks external to the CPU core.
   * Chip-top logic can also be used to reduce the frequency of the clocks so that the CPU can continue to operate at a reduced capacity 

The power states are defined as:

   * Active: the normal operating mode where the CPU is executing instructions
   * Standby: CPU clocks are active; the execution pipeline is stopped; an interrupt will start execution.
   * Sleep: CPU clocks are inactive or gated off; CPU can not be restarted via software mechanism or interrupt. This must be done by chip-top logic external to the CPU core 

Ref: PPC440, PPC405


support

  • AMCC 4xx VxWorks: 5.5.1 - Tornado Tools 2.2.1 Wind River Product AMCC 405GP Walnut Board walnut Technical Specifications
  • AMCC 4xx VxWorks: 5.5.1 - Tornado Tools 2.2.1 Wind River Product AMCC PPC 440GP Ebony ebony

mips by TI, the AR7

The Texas Instrument AR7 is the fully integrated single-chip ADSL CPE access router solution. The AR7 combines a MIPS32 processor, a DSP-based digital transceiver, and an ADSL analog front end.

Features:

  • Integrated high performance MIPS 4KEc 32-Bit RISC processor
  • ADSL PHY subsystem based on TI C62x DSP, with integrated transceiver, codec, line driver, and line receiver
  • Hardware accelerated ATM SAR
  • Integrated IEEE 802.3 PHY
  • Two IEEE 802.3 MACs with integrated Media Independent Interface (MII) and Quality of Service (QoS)
  • Integrated USB 1.1 compliant transceiver (slave only?)
  • Two VLYNQ interfaces for compatible high-speed expansion devices
  • Two 16c550 compatible UARTs
  • EJTAG, GPIO and FSER interfaces
  • 4Kb PROM (0xBFC00000) and 4Kb RAM (0x80000000) on the chip for boot purposes
  • 324 BGA with 1.0-mm ball pitch

Options:

  • AR7DB
  • AR7RD
  • AR7WRD (TNETD7300GDU) is an AR7 option with a interface for WiFi card.
  • AR7VWI : DSL + VoIP + Wireless
  • AR7VW
  • AR7WI
  • AR7V : DSL + VoIP

TI does not provide detailed technical documentation for this SoC. Some details are known from the GPL-ed Linux sources.

Another source is a TI OMAP and DaVinci documentation. It seems, AR7 SoC peripherials is very close to the OMAP16xx and OMAP730 application processors , but MIPS instead ARM9-based. Source Code

The "GPL source code" as provided by the various vendors of TI AR7 (with linux) devices is incomplete, since TI apparently refuses to publish the source code to some of their core kernel modifications, such as LZMA (de)compression of the zImage. The gpl-violations.org project is actively trying to resolve this issue.

If you go through the GPL releases for AR7 devices by different vendors, you can find all the sources for the AR7 board. Here's a list:

Network driver 	In almost every vendor GPL release 	
DSL driver 	Netgear DG834(G) V1.0.5 	Hidden in patch-knl file
Wifi driver 	Linksys WAG54G v2 1.00.19-UK 	src/router/ti_ap/AP-DK5.7.0.4.tar.gz
USB driver 	Netgear DG834(G) V1.0.5 	Hidden in patch-knl file
Unknown status 	Actiontec GPL source code 	http://opensource.actiontec.com/

IRC

There is a specifically targeted #ar7 irc channel on Freenode where those devoted to hacking ar7 based architecture go to hang out. Memory map

AR7 family deploys unusual memory map. The AR7 chip has a small memory banks on the chip : 4Kb PROM (@0xBFC00000) and 4Kb RAM (@0x80000000) and memory block for the DSP (@unknown). The rest of the external memory banks are selectable with CS0..4. The FLASH is located at 0x90000000 (CS0) and RAM is located at 0x94000000 (CS1). Linux should define a non-contiguous memory and install an IRQ trampolines at the MIPS interrupt vectors. C62x DSP

TI TMS320C62x is a fixed-point Digital Signal Processor core. C62x is based on the VelociTI VLIW architecture developed by TI. C62x is a member of the TI C6000 family.

  • Notes on Texas Instruments Processors
  • Open Source TMS320C6x Development Tools
  • Free DSP Compiler Available

VLYNQ

TI's VLYNQ is a low power, low pin-count serial communication interface that enables the extension of an internal bus segment to one or more external physical devices. The external devices are mapped into local, physical address space and appears as if they are on the internal bus. The external device must have a VLYNQ interface. The VLYNQ module serializes bus transactions in one device, transfers the serialized data via a VLYNQ port, and de-serializes the transaction in the external device. The VLYNQ interface is described in the following TI documents:

  • SPRU768 - OMAP5912 Multimedia processor VLYNQ Serial Communications Interface Reference Guide
  • SPRUE36 - TMS320DM644x DMSoC VLYNQ Port. User's guide.

Emulation

Qemu with additional patches supports emulation of AR7 and some of its most important devices (serial ports, ethernet). It also includes a flash emulation and can run firmware of typical AR7 based DSL routers.


technology, varia

ita.blog http://www.appuntidigitali.it/

68hc11, 68000, hw/sw, varia, blog

http://learn-mot.blogspot.com/

i2c spi

board

??? linux/macOSX only binary http://www.totalphase.com/products/

http://www.i2cchip.com/

$120 linux/macOSX sources http://www.nanorivertech.com/miniboard

CAN bus

doc

http://www.datajob.com/corso/can/Default.aspx

alcune codifiche numeriche

Manchester

Nelle telecomunicazioni la codifica Manchester è una forma di comunicazione dati nella quale ogni bit viene segnalato da una transizione. La codifica Manchester è considerata una codifica self-clocking, il che significa che permette un'accurata sincronizzazione del flusso dati. Ogni bit viene trasmesso in un intervallo di tempo di bit predefinito.

La codifica Manchester fornisce un modo semplice per codificare sequenze binarie arbitrarie senza mai aver lunghi periodi di tempo privi di transizioni di clock, il che permette di prevenire la perdita della sincronizzazione del clock, oppure errori di bit causati da derive in bassa frequenza su collegamenti analogici poco equalizzati (vedi ones-density). Se trasmesso come segnale AC assicura che la componente DC del segnale codificato sia zero, prevenendo derive del livello di base del segnale ripetuto, e rendendolo facile da rigenerare. Comunque oggi esistono molte codifiche più sofisticate che ottengono lo stesso risultato con minore sovraccarico di banda, e meno ambiguità di sincronizzazione nei casi patologici (vedi sotto).

Uno degli utilizzi più noti della codifica Manchester è sui segnali elettrici nelle reti locali Ethernet.

Codifica Manchester come caso di Phase Shift Keying Binaria (BPSK)

La codifica Manchester si può considerare come un caso speciale della Phase Shift Keying Binaria (BPSK), in cui il dato da trasmettere controlla la fase di un'onda quadra portante alla frequenza della velocità di trasmissione dati. Perciò è estremamente facile generare tale segnale in modo digitale.

Per controllare la quantità di banda consumata, si può impiegare un filtro per ridurre la banda fino ad 1 Hz per bit/secondo, senza perdere informazione durante la trasmissione. Comunque, per praticità (e per controllare al meglio la banda passante, specialmente su spettri radio affollati), la maggior parte dei modulatori BPSK scelgono una frequenza di portante molto superiore alla frequenza di trasmissione dati, ottenendo larghezze di banda più strette e facili da filtrare. La proprietà dell'1 Hz/bit/secondo è comunque mantenuta.

Convenzioni per la rappresentazione dei dati [modifica]

Ci sono due convenzioni opposte per la rappresentazione dei dati.

La prima fu inizialmente pubblicata da G. E. Thomas nel 1949 ed è seguita da numerosi autori (ad es. Tanenbaum). Specifica che per un bit 0 i livelli di segnale saranno Basso-Alto (assumendo una codifica dei dati con l'ampiezza) - con un livello basso nella prima parte del periodo di bit, ed un livello alto nella seconda parte. Per un bit 1 i livelli di segnale saranno Alto-Basso.

Anche la seconda convenzione è seguita da molti autori (ad es. Stallings) come pure dallo standard IEEE 802.4. Stabilisce che uno 0 logico sia rappresentato da una sequenza di segnale Alto-Basso ed un 1 logico da una sequenza di segnale Basso-Alto.

Una conseguenza della transizione per ciascun bit è che la necessità di larghezza di banda per segnali codificati Manchester è doppia in confronto ad una comunicazione asincrona, e che lo spettro del segnale è considerevolmente più ampio. Nonostante la codifica Manchester sia una forma di comunicazione altamente affidabile, il requisito della larghezza di banda è visto come uno svantaggio, e le comunicazioni più moderne avvengono con protocolli con codici più moderni che ottengono gli stessi risultati con una codifica più rapida ed una richiesta di larghezza di banda minore.

Una peculiarità della codifica Manchester è la sincronizzazione del ricevitore col trasmettitore. A prima vista potrebbe sembrare che un errore di mezzo periodo di bit porterebbe ad una decodifica invertita dal lato del ricevitore, ma considerazioni ulteriori evidenziano che con alcune sequenze di dati specifiche questo causerebbe la violazione della codifica. L'hardware può rilevare queste violazioni di codifica e di conseguenza sincronizzarsi accuratamente sulla corretta interpretazione dei dati.

Una tecnica correlata è la codifica Manchester differenziale.

Riassumendo:

  • i segnali dei dati e del clock sono combinati per formare un flusso di dati auto-sincronizzante
  • ogni bit codificato contiene una transizione a metà del periodo di bit
  • la direzione della transizione determina se il bit è uno "0" o un "1"
  • la prima metà è il valore vero del bit e la seconda metà è il complemento del valore vero del bit. In contrasto con non ritorno a zero.

tx-rx on uart

byte decode_data(byte encoded)
{
byte i, dec, enc, pattern;
enc=encoded;
if (end==0xf0)
   return 0xf0;
dec=0;
for (i=0;i<4;i++)
    {
    dec >>=1;
    pattern=enc &0b11;
    if (pattern==0b11) //1
       bit_set(dec,3);
    else 
       if (pattern==0b10)
          bit_clear(dec,3); //0
       else
          return 0xff; // illegal code
    enc >>=2;
    }
return dec;
}

void send_data(bytetxbyte)
{
int i,j,b,me;
b=txbyte;
for (i=0;i<2;i++)
    {
    me=0;
    for (j=0; j<4; j++)
        {
        me >>=2;
        if (bit_test(b,0))
           me |= 0b01000000; // 1->0
        else
           me |= 0b10000000; // 0->1
        b>>=1;
        }
    putc(me);
    }
}

La Codifica Manchester differenziale

La Codifica Manchester differenziale è un sistema di rappresentazione di dati, derivato dalla Codifica Manchester, utilizzato soprattutto negli scambi di informazioni tra alcune categorie di reti informatiche. Questo sistema di codifica di dati, come la Manchester, è progettata in modo da sincronizzarsi autonomamente col clock di sistema, in quanto ogni bit viene trasmesso all'interno di un intervallo predefinito. Inoltre durante questo intervallo vi è la presenza di almeno una transizione a metà intervallo, salvo i casi di segnali fuori codifica.

La caratteristica che distingue la codifica Manchester differenziale dalla sua progenitrice è la rappresentazione dei bit: infatti la Manchester differenziale è basata sulla verifica di transizioni all'inizio di un intervallo. La presenza di una di queste, sia essa di tipo alto-basso o basso-alto, identifica un valore, la mancanza di transizione invece (ovvero continuità del segnale) indica il valore opposto. I segnali prodotti sono compresi tra 3 e 4.5 v per il segnale alto e tra -4.5 e -3 v per quello basso.

Per convenzione normalmente il bit 1 viene rappresentato dalla mancanza di transizione all'inizio del suo intervallo, mentre lo 0 è indicato con un cambiamento di segnale nello stesso periodo. Segnali in violazione di questa convenzione sono utilizzabili per informazioni di servizio o per delimitare gruppi di bit. Questo sistema rende la codifica più resistente al rumore rispetto alla Manchester normale, ma in cambio si paga una maggiore complessità degli algoritmi di gestione oltre che dell'hardware.

uart

rs422 rs485, networking

-Hi,
-
-I understand that two devices can communicate over RS422 via two sets of twisted pair cables. 
-what about adding a third device? 
-Can the cable be split so that each of three separate devices can be connected to each other 
-via RS422?
-
-I'm a little unclear with the RS422 network topology description on the web site.

There is a maximum of ten receivers on an RS422 communication line
but only one sender can be connected. 
Therefore RS422 is only useful when one central master sends commands to multiple slaves
but where the slaves don't have to send information back. 
If you want two-way communication between more than two serial devices
you should switch to RS485
as the RS422 network topology is not appropriate for that situation.

rs232 sgi apple cable

minidin8 rs422 rs232 db9
1 HSKo DTR,RTS 4,7
2 HSki CTS 9
3 TX- TX 3
4 gnd,RX+ gnd 5
5 RX- RX 2
6 TX+
7 GPI DCD,DSR 1,6



    8 7 6
    5 4 3
     2 1
soldering view


idea: using minidin8.pin6 for vcc=5V

music

see how mad are jappi http://www.youtube.com/watch?v=eM6nUX57gCg&feature=channel

hex

16=2^4 00010hex
32=2^5 00020hex
64=2^6 00040hex
128=2^7 00080hex
256=2^8 00100hex
512=2^9 00200hex
1k=2^A 00400hex
2k=2^B 00800hex
4k=2^C 01000hex
8k=2^D 02000hex
16k=2^E 04000hex
32k=2^F 08000hex
64k=2^10 10000hex

unix

http://informatica.di.univaq.it/getres.php?resid=575

Hardware hackers in general and robot-makers in particular are pleased by using things in elegant and unusual ways. Hack a day pleases me.

uart

http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html

http://www.comptechdoc.org/os/linux/programming/c/linux_pgcserial.html

pic

• M. Predko, "Programming and customizing the PIC microcontroller", Tab Books

• Wilmshurts, "Designing Embedded Systems with PIC Microcontrollers", Newnes

• R. Stevens, "Serial Communications", SquareOne books

• Barnett & O'Cull, "Embedded C Programming and the Microchip PIC", Thomson Delmar

• Del Corso & Galizia, "PIC micro. Progettare con i microcontrollori PIC", Inware Edizioni

• G. Galletti, "PIC Book", Sandit


number

• Forman S. Acton, "Numerical methods that (usually) work", MAA

• Richard Hamming, "Numerical Methods for Scientists and Engineers", Cambridge

• J. Stoer, R. Burlisch, "Introduzione all'Analisi Numerica", Zanichelli

• V. Comincioli, "Analisi Numerica, metodi modelli applicazioni", McGraw-Hill

• V. Comincioli, "Analisi Numerica, complementi e problemi", McGraw-Hill

  • Cavanagh ???

electronics

http://inst.eecs.berkeley.edu/~ee100/fa08/lectures/lectures.html

algorithm

http://web.media.mit.edu/~wad/mas864/proposal.html

robot

http://oap.sourceforge.net/download.php

http://www.pololu.com/catalog/product/425/pictures

http://www.guiott.com/Rino/index.html

motor control http://www.pmdcorp.com/motion-products/

electronic instruments

http://www.almasistemi.net/

GPS

tangogps (gps logging)

gpsdrive (gps logging ?)

  • url ???

navit (navigation)

gps zuaurus/hw

chips

   --- GPIO Support                                                                                     x x
  x x                              [*]   /sys/class/gpio/... (sysfs interface)                                                          x x
  x x                                    *** Memory mapped GPIO expanders: ***                                                          x x
  x x                                    *** I2C GPIO expanders: ***                                                                    x x
  x x                              <*>   MAX7319, MAX7320-7327 I2C Port Expanders                                                       x x
  x x                              < >   PCA953x, PCA955x, TCA64xx, and MAX7310 I/O ports (NEW)                                         x x
  x x                              < >   PCF857x, PCA{85,96}7x, and MAX732[89] I2C GPIO expanders (NEW)                                 x x
  x x                                    *** PCI GPIO expanders: ***                                                                    x x
  x x                                    *** SPI GPIO expanders: ***                                                                    x x
  x x                              <*>   Maxim MAX7301 GPIO expander                                                                    x x
  x x                              <*>   Microchip MCP23S08 I/O expander    



   < > Dallas DS1682 Total Elapsed Time Recorder with Alarm (NEW)                                       x x
  x x                              < > Philips PCF8574 and PCF8574A (DEPRECATED) (NEW)                                                  x x
  x x                              < > Philips PCF8575 (DEPRECATED) (NEW)                                                               x x
  x x                              < > Philips PCA9539 16-bit I/O port (DEPRECATED) (NEW)                                               x x
  x x                              < > Philips PCF8591 (NEW)                                                                            x x
  x x                              < > Maxim MAX6875 Power supply supervisor (NEW)                                                      x x
  x x                              < > Taos TSL2550 ambient light sensor (NEW)   

sh3.4.5

HP Jornada 690

HP-Jornada-690.jpg

  • CPU: SH7729@ 133 MHz that is SuperHitachiRish-SH-3
  • RAM': 32MB
  • LCD: 6.5" CSTN passive matrix 16-bit (64K colors), 640 x 240 6.5" CSTN passive matrix
  • SIZE: 18.9 cm x 3.4 cm x 9.5 cm, 510 g
  • BUS:
    • PCMCIA slot
    • CF slot
  • MISC:
    • Built in Modem
    • IrDA
    • BATTERY: the average battery run time is about ~ 8 hours


cat /proc/cpuinfo
machine         : HP6xx
processor       : 0
cpu family      : sh3
cpu type        : SH7729
cpu flags       : none
cache type      : unified
cache size      : 16KiB (4-way)
bogomips        : 66.15
master_clk      : 22.11MHz
module_clk      : 22.11MHz
bus_clk         : 132.66MHz
cpu_clk         : 132.66MHz
tmu0_clk        : 5.52MHz

mips

http://en.wikipedia.org/wiki/MIPS_architecture

arm

corso uni http://www.dei.unipd.it/corsi/ae1/web/_index.htm

embedded

tiny http://www.friendlyarm.net/products

poky http://free-opensource.qvantel.net/mediawiki//index.php/LN2440_-_Single_Board_Computer

nice-board with fpga http://www.embeddedarm.com/products/board-detail.php?product=TS-7800#

1. http://code.google.com/p/mini2440/wiki/MiniBringup i used this to know how to connect to the serial console with picocom and i used this for various nand manipulations described in there

2. http://wiki.linuxmce.org/index.php/Mini2440 this site shows howto build u-boot.bin and how to upload it to the device, later on it shows the same to the kernel

3. http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml?part=1&chap=1 here i followed the steps to build a toolchain with the "arm-unknown-linux-gnu" as cross compiler

4. http://www.friendlyarm.de/downloads i used the kernel provided on this site

OMAP Processor families

Per the TI website, the OMAP families are broken into "High Performance", "Basic Multimedia", and "Modem and Applications".

"High performance"

OMAP1

    * OMAP1710 - 220 MHz ARM926TEJ + C55x DSP
    * OMAP1621 - 204 MHz ARM926 + C55x DSP + 2MB Internal SRAM
    * OMAP1612 - 204 MHz ARM926TEJ + C55x DSP
    * OMAP1611 - 204 MHz ARM926EJ-S + C55x DSP
    * OMAP1610 - 204 MHz ARM926EJ-S + C55x DSP
    * OMAP1510 - 168 MHz ARM925T (TI-enhanced) + C55x DSP
    * OMAP5910 - ARM9 + C55x DSP
    * OMAP5912 - ARM9 + C55x DSP

OMAP2

    * OMAP2431 - 330 MHz ARM1136 + 220 MHz C55x DSP
    * OMAP2430 - 330 MHz ARM1136 + 220 MHz C55x DSP + PowerVR MBX lite GPU
    * OMAP2420 - 330 MHz ARM11 + 220 MHz C55x DSP + PowerVR MBX GPU

OMAP3

The OMAP3 is broken into 3 distinct groups: the OMAP34x, the OMAP35x, and the OMAP36x. OMAP35x is a variant of OMAP34x intended for open source development, and the OMAP36x is a 45nm version of the 65nm OMAP34x with higher clock speed.[1]

    * OMAP3640 - 1 GHz ARM Cortex A8 + 430 MHz C64x+ DSP + PowerVR SGX530 GPU + ISP (Image Signal Processor)
    * OMAP3630 - 720 MHz ARM Cortex A8 + 430 MHz C64x+ DSP + PowerVR SGX530 GPU + ISP (Image Signal Processor)
    * OMAP3620 - 720 MHz ARM Cortex A8 + 430 MHz C64x+ DSP + PowerVR SGX530 GPU + ISP (Image Signal Processor)
    * OMAP3610 - 720 MHz ARM Cortex A8 + 430 MHz C64x+ DSP
    * OMAP3530 - 600 MHz ARM Cortex A8 + 430 MHz C64x+ DSP + PowerVR SGX530 GPU + ISP (Image Signal Processor)
    * OMAP3525 - 600 MHz ARM Cortex A8 + 430 MHz C64x+ DSP + ISP (Image Signal Processor)
    * OMAP3515 - 600 MHz ARM Cortex A8 + PowerVR SGX530 GPU + ISP (Image Signal Processor)
    * OMAP3503 - 600 MHz ARM Cortex A8
    * OMAP3440 - 800 MHz ARM Cortex A8 + PowerVR SGX 530 GPU + 430MHz C64x+ DSP + ISP (Image Signal Processor)
    * OMAP3430 - 600 MHz ARM Cortex A8 + PowerVR SGX 530 GPU + 430MHz C64x+ DSP + ISP (Image Signal Processor)
    * OMAP3420 - 600 MHz ARM Cortex A8 + PowerVR SGX 530 GPU + 430MHz C64x+ DSP + ISP (Image Signal Processor)
    * OMAP3410 - 600 MHz ARM Cortex A8 + 430MHz C64x+ DSP + ISP (Image Signal Processor)

OMAP4

    * OMAP4440 - 1+ GHz dual-core ARM Cortex-A9 MPCore + PowerVR SGX 540 GPU + C64x+ DSP + ISP     * OMAP4430 - 720 MHz dual-core ARM Cortex-A9 MPCore + PowerVR SGX 540 GPU + C64x+ DSP + ISP 
"Basic multimedia"

    * OMAP331 - ARM9
    * OMAP310 - ARM9
    * OMAP-DM270 - ARM7 + C54x DSP

"Modem and applications"

    * OMAPV1035 - single-chip EDGE
    * OMAPV1030 - EDGE digital baseband
    * OMAP850 - 200 MHz ARM926EJ-S + GSM/GPRS digital baseband + stacked EDGE co-processor
    * OMAP750 - 200 MHz ARM926EJ-S + GSM/GPRS digital baseband + DDR Memory support
    * OMAP733 - 200 MHz ARM926EJ-S + GSM/GPRS digital baseband + stacked SDRAM
    * OMAP730 - 200 MHz ARM926EJ-S + GSM/GPRS digital baseband + SDRAM Memory support
    * OMAP710 - 133 MHz ARM925 + GSM/GPRS digital baseband


zaurus

Specifications
416MHz PXA-270 XScale processor
64MB RAM
128MB internal flash memory
640x480 16bpp backlit LCD touchscreen display
Input methods: keyboard, stylus with handwriting recognition
Ports: IrDA, USB (host & slave), headphones & remote, Zaurus connector, SD memory card slot, CF slot

Unlike the C3000 and C3100 units, there is no internal hard drive. A microdrive can be installed in the CF slot. I chose the C1000 specifically because it did not have a hard drive, since I worry that a hard drive subjected to a lot of handheld use would be prone to failure, especially if dropped. 

http://images.google.it/imgres?imgurl=http://www.gelhaus.net/zaurus/PC130020.JPG&imgrefurl=http://www.gelhaus.net/cgi-bin/showpage.py%3Fzaurus/%2Breview_C1000.html&usg=__ZV9tNgX12Qz30p94Hdf9g-X76bo=&h=300&w=400&sz=87&hl=it&start=9&sig2=lhOnrvLp7sO5iWtrdsG3fQ&um=1&tbnid=tI_-a3eyDKMw9M:&tbnh=93&tbnw=124&ei=Jza1SdjoC4eW_gaYlLG6BA&prev=/images%3Fq%3Dopen%2Bzaurus%2Bc1000%26hl%3Dit%26sa%3DN%26um%3D1

touchbook

Touchbook.png

The specifications

  • SIZE 9.4" x 7" x 1.4" for 2 lbs (with keyboard)
  • ARM Texas Instruments OMAP3 chip
  • 1024x600 8.9 screen
  • Storage: 8GB micro SD card
  • Wifi 802.11b/g/n and Bluetooth
  • 3-dimensional accelerometer
  • Speakers, micro and headphone
  • 6 USB 2.0 (3 internal, 2 external, 1 mini)
  • 10h to 15 hours of battery life


https://www.alwaysinnovating.com/touchbook/

sheevaplug

Sheevaplug-mobo.png

http://www.marvell.com/products/embedded_processors/developer/kirkwood/sheevaplug.jsp

SheevaPlug from Marvell contains MV88F6281 cpu running at 1.2GHz with 512MB of DDR2/800 memory. Other nice things are:

  • CPU: MV88F6281 @ 1.2GHz, Marvell Sheeva ARM, that is armv5te compliant
  • cache: 16+16Kb L1, 256Kb L2
  • endian ness: little endian and big endian both supportd
  • elf format: ELF 32-bit LSB executable, ARMv1 (SYSV), statically linked, not stripped
  • 1GbE network controller
  • 512MB of NAND for storage
  • USB 2.0 controller (up to 480Mbps speed)
  • RS232 serial port
  • ARM JTAG
  • SDIO slot
  • U-boot as bootloader


  • Sub Total: $99.00
  • Shipping: (FedEx International Priority) $31.78
  • Tax: $0.00
  • Total: $130.78


processor features

  • GIGABIT ETHERNET PORTS
  • SATA II PORTS
  • TDM PORTS

iPAQ

Overview

Model RAM (MiB) ROM (MiB) Slots CPU MHz OS WiFi Bluetooth IrDA PN 173396-001 Special Feature
H3100 16 16 None ARM SA1110 206 PPC2000
H3630 32 16 None ARM SA1110 206 PPC2000
H3660 64 16 None ARM SA1110 206 PPC2000
H3760 64 32 None ARM SA1110 206 PPC2002
H3850 64 32 1SD ARM SA1110 206 PPC2002
H3870 64 32 1SD ARM SA1110 206 PPC2002 BT1.1 Yes Yes
H3950 64 32 1SD/IO PXA250 400 PPC2002 Yes NEVO TV Remote Software
H3970 64 48 1SD PXA250 400 PPC2002 BT1.1 Yes Yes NEVO TV Remote Software
H5150 64 32 1SD PXA255 400 WM2003 BT1.1 Yes Yes
H5400 64 48 1SD PXA250 400 WM2003 802.11b BT1.1 Yes
H5500 128 48 1SD PXA255 400 WM2003 802.11b BT1.1 Yes Yes

it should be nice:

h2210

  • Model : iPAQ h2210 Pocket PC
  • CPU: Intel XScale PXA255 400 MHz/32-bit
  • RAM: 64 MB
  • FLASH: ??MB
  • Slot: Secure Digital SD/IO (SD-MMC), Compact Flash I e II
  • SIZE: 115,4 x 76,4 x 15,4 mm, 144g
  • BATTERY: Lithium 900 mhA
  • LCD: Display TFT a 65.536, 240x320 pixel
  • DEVS: Bluetooth???, Sleeve???, IrDA, Headers, Mic, Uart

h5500

  • Model : HP/Compaq iPAQ h5500 Pocket PC
  • CPU: Intel XScale PXA255??? 400 MHz/32-bit
  • FLASH: 48MB
  • RAM: 128 MB
  • Slot: ???Secure Digital SD/IO (SD-MMC), Compact Flash I e II
  • SIZE: 840 x x 138 x 16 mm, 207 g
  • BATTERY: Lithium 1250 mAh
  • LCD: Display TFT 3.8" 65.536colors, 240x320 pixel
  • DEVS: Bluetooth, Sleeve, IrDA, Headers, Mic, Uart

old info @ http://www.handhelds.org/moin/moin.cgi/HpIpaqH5000

> i'd like to know if the sleeve 2xpcmcia (dual pcmcia slot) have ever worked 
> with h5***
> cause i'd like to add a pcmcia-CF2/microdrive into one slot and a 3com net
> card into the other slot. I'd like to use kernel 2.6
>
> do you confirm it's working with kernel 2.6 ?

 Unfortunately, I can't confirm much. In hho CVS there should be
sort-of support for sleeves. I tested it with dual PCMCIA sleeve, it
worked (tested with orinoco gold wifi card and some pcmcia ethernet
adapter).

wondering if to switch to modern platform

nokia n810

  • Model name: Nokia N810
  • CPU type: TI Omap 2420 @400 Mhz ---> arch arm-v11, endinaness ???
  • OS: 2.4??? 2.6??? ---> see "Maemo" Internet Tablet 2007 maemo OS2008 http://en.wikipedia.org/wiki/Maemo_(operating_system)
  • Display: 4.1" 800 X 480, LED b/l, Soft (Finger) Touch
  • RAM: 128 MB
  • Flash: 2048 MB
  • Keyboard: qwerty
  • Mouse Pointer: NO
  • Battery capacity: 5.5 (Wh)
  • Size: 128/72/14 mm, 226g
  • Physical Interfaces
    • Mini-SD slot
    • Headset i/f (Mic+Line)
  • Wireless Interfaces
    • 802.11b/g
    • BT2.0
    • No Wireless WAN (e.g. 3G cellular)


SCHEDA ARTICOLO
Sistema Operativo 	Internet Tablet 2007 maemo OS2008 basato su Linux
Tecnologia 	n.d.
Banda 	Non presente.
Bluetooth 	Specifica Bluetooth v. 2.0. +EDR o Profili supportati: HID, FTP, DUN, GAP, SPP, HSP, SAP e OPP
Wi-Fi 	Wi-Fi standard: IEEE 802.11b/g
Antenna GPS 	Ricevitore GPS integrato
Tipo Memoria 	DDR RAM 128MB
Flash 256MB
Fino a 2 GB di memoria interna
Supporto per memory card miniSD e microSD compatibili (con adattatore).
Supporto per memory card fino a 8GB. (Le memory card SD oltre i 2GB devono essere compatibili con SDHC).
Caratteristiche importanti 	Pratica tastiera QWERTY a scorrimento, integrata.
Ricevitore GPS integrato
Vivavoce stereo e microfono di qualità
Ampio display ad alta risoluzione
Supporto da tavolo integrato
Webcam VGA integrata
Tasto hardware per il blocco del touch screen e dei tasti
Sensore di illuminazione ambientale
Funzioni speciali 	Browser basato sulla tecnologia Mozilla con supporto Web standard di ultima generazione, incluso AJAX Navigazione delle pagine mediante scorrimento, panning o tramite l’uso dei tasti, per l'ingrandimento e la riduzione dei siti Web. Plug-in completo di Adobe® Flash® 9 per desktop, con streaming audio e video
Musica 	Lettore multimediale integrato per la visione e l'ascolto di contenuti multimediali scaricati, trasferiti o in streaming, e comoda gestione della libreria multimediale sul telefono cellularey Accesso diretto a media condivisi su Universal Plug and Play (UPnP) Formati di file supportati: 3GP, AVI, WMV, MP4, H263, H.264, MPEG-1, MPEG-4, RV (RealVideo) Formati audio supportati: MP3, WMA, AAC, AMR, AWB, M4A, MP2, RA (RealAudio), WAV Formati di playlist supportati: M3U, PLS, ASX, WAX, WVX, WPL
Autonomia 	Batteria: Batteria Nokia BP-4L
Utilizzo continuo (display acceso, LAN senza fili attiva): fino a 4 ore
Riproduzione di musica: fino a 10 ore
Autonomia on-line: fino a 5 giorni
Autonomia in standby: fino a 14 giorni
Display 	Display WVGA da 4,13' ad alta risoluzione (800 x 480 pixel) fino a 65.536 colori
Funzioni standard 	Visualizzazione delle immagini a tutto schermo e funzionalità presentazione Formati di immagini supportati: BMP, GIF, ICI, JPE, JPEG, PNG, TIF/TIFF, SVG, Tiny, WBMP
Dimensioni 	Lunghezza: 72 mm
Larghezza: 128 mm
Spessore: 14 mm
Contenuto della confezione 	Nokia N800 Internet Tablet RX-44
Batteria Nokia BP-4L
Auricolare stereo Nokia HS-48
Caricabatterie da viaggio Nokia AC-4
Supporto veicolare Nokia CR-89
Custodia CP-223
Cavo di connessione Nokia CA-101
Guida di avvio rapido
Manuale d’uso con informazioni su sicurezza, garanzia e maggiori dettagli sul prodotto

openpandora

Openpandora.jpg Openpandora-size.jpg

http://www.elinux.org/Image:openpandora-mobo.jpg

  • ARM® Cortex™-A8 CPU running Linux
  • 800×480 4.3″ 16.7 million color touchscreen LCD
  • OpenGL 2.0 ES compliant 3D hardware
  • Wi-Fi 802.11b/g
  • Dual SDHC card slots
  • Dual analog and digital gaming controls
  • 43 button QWERTY and numeric keypad
  • TV output
  • High Speed USB Host


Specifications
    * Texas Instruments OMAP3530 System-on-Chip with Cortex-A8 600MHz
    * 256MB DDR-333 SDRAM[15]
    * 512MB NAND FLASH memory[15]
    * IVA2+ audio and video processor (based on the TMS320C64x+ DSP Core at 430MHz) using Texas Instruments's DaVinci technology[15]
    * ARM Cortex-A8 superscalar microprocessor core[15]
    * PowerVR SGX 530 (110 MHz) OpenGL ES 2.0 compliant 3D hardware[15]
    * Integrated Wi-Fi 802.11b/g[15]
    * Integrated Bluetooth 2.0 + EDR (3Mbit/s) (Class 2, +4dBm)[15]
    * 800x480 resolution touchscreen LCD, 4.3" widescreen, 16.7 million colors (300 cd/m2 brightness, 450:1 contrast ratio)[15]
    * Dual analog nubs; 15mm diameter, concave, 2.5mm travel from center[15][19]
    * Full gamepad controls plus shoulder buttons[15]
    * Dual SDHC card slots (currently supporting up to 32GB of storage each, supports SDIO)[15]
    * Headphone output up to 150mW/channel into 16 ohms, 99dB SNR[15]
    * TV output (composite and S-Video)[15]
    * Internal microphone plus ability to connect external microphone through headset[15]
    * 43 button QWERTY and numeric keypad[15]
    * USB 2.0 OTG port (480Mb/s) with capability to charge the Pandora[15]
    * USB 2.0 HOST port (480Mb/s) capable of providing standard 500mA current to attached devices[15]
    * Externally accessible UART for hardware hacking and debugging[15]
    * Brick prevention with integrated bootloader for safe code experimentation[15]
    * Runs the Linux kernel (2.6.x)[15]
    * 4000mAH rechargeable lithium polymer battery[20][21]
    * Estimated 5-10+ hour battery life for games, 10+ hour battery life for video and general applications, and theoretically 100+ hours for music playback (with backlight off and maximum power management)[22][23]
    * Dimensions: 140x83x27mm (5.51x3.27x1.06 in)[15]
    * Weight: ~300 g[24]