AR1688 (woody@palmmicro.com)

Bill Gates retired a few days ago. On that day when I was playing with my 8-bit toy, I can not help to remember a programming joke about him. It was over 30 years ago, when he and the lucky Paul Allen were building BASIC on an 8 bit CPU, they were told that the memory size they could use had been increased from 4k bytes to 8k bytes. They were happy to know it and also worry about what to do with those extra spaces. 

I am 30 years behind Bill Gates, 30 years later, I am still working on 8 bit CPU and worry about memory spaces calculated in k-bytes.

Z80 has 64k bytes memory space. We are using it in the following way:

0x0000-0x1fff: AR1688 internal SRAM, used to run Z80 program.

0x2000-0x3fff: AR1688 internal SRAM, used as Z80 software global var and stack. Global var starts from the bottom and increase, stack starts from the top and decrease. So it is possible that the stack will over flow to wash away global var and make everything unpredictable.

0x4000-0x7fff: AR1688 internal SRAM, there are several "pages" sharing those address spaces. For example, the 96k bytes DSP memory is allocated into 6 pages for Z80 to access on those addresses. And there is a page of SRAM used as heap, which is, the memory managed by the malloc/free functions.

0x8000-0xffff: Address spaces for external program flash, LCD, network chip RTL8019AS and DM9003EP. Again 32k is not large enough for all those, so we have different 32k bytes "banks" to access different parts.

I was amused to know that somebody is selling some old PA1688 based IP phones in Taobao (The Chinese version of Ebay) for only 68 RMB a few days ago: http://auction1.taobao.com/auction/item_detail-0db2-9d9fba4f78d6e7b86e044aae5a61c3b4.jhtml. Since then, I have been wondering if there are better deals or not. Finally I did some search on internet tonight and found a 15 RMB case: http://club.pchome.net/topic_1_15_2727783__.html

One USD can change about 6.85 RMB today. I guess now I know how much should new AR1688 based IP phones sell to compete in the market.

 

 

Safe mode program is stored at the first 64k bytes space on the program flash. When safe mode is running, the second 32k bytes instructions are running on flash itself, using Z80 address space 0x8000-0xffff, while the first 8k bytes are copied to AR1688 internal SRAM and running there, using Z80 address space 0x0000-0x3fff.

Some functions can only run on SRAM, for example, flash writing routines.

When running TFTP upgrade, TFTP program is running on flash, saving all received data into DSP memory, when it reaches 64k bytes, we will switch to run flash writing routines in SRAM, and write one-page of program flash to its proper flash address, and then switch back to run TFTP protocol on flash.

In safe mode, users can upgrade both main program and safe mode program itself.

A recent customer report says that TFTP timed out when upgrading safe mode program under safe mode. Actually this can be expected because after the first 64k flash space written, the old TFTP program lost its way. However, the upgrade process is usually successful, even the PC side shows the error.

To avoid confusion, please always only upgrade main program in safe mode, and upgrade safe mode program when main program is running.

Make sure power supply is good when upgrade safe mode program. If safe mode is broken, we can do nothing about the device by software any more.

 

Back in year 2000, we were one of those first to put Realtek RTL8019AS 10Base-T ethernet chip into embedded systems. The first RTL8019AS driver software on PA1688 was modified from the NE2000 driver in windows DDK source code. Over the years, we have become so familiar with all those RTL8019AS registers and memory buffers. With lots of optimizations and almost none extra memory copy, the TCPIP stack and RTL8019AS driver running on AR1688 is the fastest in the world among 8-bits controllers, while using the smallest memory needed. When Z80 working at 48Mhz, the UDP throughput can get to 1.5Mbps under simple TFTP test. What is more, based on the fully control of RTL8019AS internal buffers, we have done IP fragment support without any memory copy, and a "Mini Run" method to handle RTP data first when the main program thread is held up by long time activities like MD5 calculation.

RTL8019AS was not the only player in the PC ISA bus network card market in the 1990s. Davicom DM9008 was also a major player at that time. However, DM9008 seems to be slow in internal processing and need PC_READY signal to work. We can not manage that with PA1688 nor AR1688.

In 2005, when PA1688 business at its peak time, a Davicom marketing people visited our Beijing office to promote the new DM9000 100Base-T chip. I told him that we did not need another same-price chip to replace RTL8019AS, even it has better performance, but we need a chip to have MAC and 2 ports ethernet switch together because we had to use another RTL8305 for those customers who need 2 RJ45 ports on their phones. The possibility talk was good, but when he was going to left, he told me very seriously: I did not promise you such a chip.

In 2007, DM9003 is ready with MAC and 2 ports switch. But it was too late for PA1688. And we were very busy with the new AR1688 chip and did not have time to test it.

Finally we have made DM9003 work with AR1688 on this disaster year 2008. The result is very positive. With faster bus and hardware calculation of IP/UDP check sum, the UDP throughput reached 2.2Mbps, a 50% gain compared with RTL8019AS under the same test condition. It is time to say goodbye to the ancient RTL8019AS now.

Next time, I am going to ask Davicom: Can you provide me a DM9003-plus with hardware MD5 calculation?

 

 

Palmmicro's IP-PBX is now ready for public test of AR1688 based devices. Please use information below.

System: standard asterisk downloaded from http://www.asterisk.org/

Server: palmmicro.ddns.us

IAX2 server port: 4569

SIP server port: 5060

Message service number: *98

Echo test number: *43

Beijing office test number: 420

My number: 418

Public IAX2 test account 1: 422/1234 (number/PIN)

 

A typical upgrade file name for AR1688 device looks like xxxxxxxxxxxxxxx_yyyy_zz_vvvvvv.bin. In some special cases, it may be like xxxxxxxxxxxxxxx_yyyy_zz_ooooooooooooooo_vvvvvv.bin. Different part between under score '_' has different meanings.

 

xxxxxxxxxxxxxxx: This is the hardware type, or "Board Name" as we call it. Although based on the almost same AR1688 chip, different manufacturer has different hardware board designs, which need different software.

It is true that we can do hardware detection like most PC software does, and help all different hardware boards to use the same software. However, it will be a considerable waste of code and memory spaces of the resource limited low-cost AR1688 system.

Usually "AR168X" hardware type is used for standard designs for everyone. In most cases every manufacturer will likely to pick up their own hardware types because of products difference. For example, DigitMat choose "GP1266" and "GP2266" board names for their IP phones.

Hardware type can be as long as 15 combination of characters and numbers. Like other parts of the file name, hardware type is NOT case sensitive, and can NOT use under score inside it. For example, "BT_2008" name need to be changed to "BT2008N", and "DX_DT" name need to be changed to "DXDT".

 

yyyy: This is the protocol type. It is limited to 4 bytes, for example "SIP" or "IAX2". The string "none" is used as the indication of safe-mode upgrade file, which is only 64k bytes. The size is much less than normal upgrade files.

 

zz: This is the resource type. It is limited to 2 bytes, for example "cn" for Chinese and "fr" for French. We are following ISO 3166 for country code. The obvious problem is that we did not consider the case of a country using multiple languages from the beginning. So it will be a little tricky for a French speaking Canadian to compile a Canada French version for IP phone.

 

ooooooooooooooo: This is OEM type, all the name rules are the same as hardware type. Again, do NOT use under score in OEM names. OEM type is used when same hardware type product is used for different OEM customers. Special settings and feature implementations can then be included into different software binaries. We also use different OEM names for different testing purposes in our development stage.

 

vvvvvv: This is the version part. It is always 6 numbers. The first 3 numbers are major version, and the last 3 numbers are minor version. For example, 033007 stands for 0.33 version 007 build. We will use even major version number for official release, and make minor version number all zero. As an example, 032000 is the most recent software release.

 

We started to use those name rules a few years ago following OBWAN's advice. He was an active PA1688 user at that time. We are keep learning from all customers and partners today, please send us your advice today!

 

Attached here. Original high resolution copies can be required from support@digitmat.com, support@digitmat.com.cn

The most simple way to explain why VOIP is a bad business, is to compare it with mobile phone. In an age when Nokia is planning to put GPS in every mobile phone, just as digital camera feature, we still have frequent questions about how to display short text message on IP phone!

Here is the answer for all AR1688 based device with a LCD:

1. SIP protocol, server can send text to AR1688 in standard MESSAGE request

2. IAX2 protocol, Asterisk has standard command SendText("Hello, world!"), we can understand the command and will display the text.

 

Video:

1 - H.264 main profile compression, CIF (352x288) resolution, 30 frames per second.

 

Voice:

2 - Two-way full duplex, one-way or none.

3 - Open source Speex compression, support both normal and wide-band mode.

 

Network:

4 - Asterisk native IAX2 protocol for communication.

5 - uPnP for auto UDP port mapping within NAT.

6 - DDNS for point to point usage.

7 - HTTP server for configuration and software upgrade

 

System:

8 - Auto-answering voice and video over IP client device, can be used in point to point with only DDNS service support needed.

9 - Open source Asterisk system ready to go.

10 - Open to be integrated with all voice and video over IP system and instant messagers like MSN, need further integration efforts with special service providers.

 

 

Although the IP phone reference design based on AR168M VOIP module and an external MCS8051 UI controller is for demo purpose, it actually can be used in real production and still maintain a very low BOM cost, because the MCS8051 we used is also very cost-effective. Here listing some details of the open source software in SDCC\mcs51.
1. Compile with open source SDCC compiler, using small memory mode.
2. Can NOT be upgraded by software on board, need a programmer to make change if needed.
3. Interface with 2x16 LCD, 8x6 keys and 4 LEDs.
4. Extra 4 LEDs if P4 port is available (on those Winbond devices we are testing).
5. Used 141 bytes of data and idata (means that we actually need a standard 8052 which has 256 bytes internal RAM).
6. Used 2797 bytes of code space, including extended ISO-8859-1 fonts for 2x16 LCD (a 4K ROM 8052 is enough, cost about 0.5 USD).
7. UART at 19200 bps, 8 bit data, 1 stop, no parity check.
8. Oscillator at 22.1184Mhz.

With the release of recent 0.30 software, our AR168M VoIP Module is fully ready in both hardware and software. We can ship it in small quantity now. (See also: http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!310.entry)

To test the module, we have used an external MCS8051 controller to work with the module to build a complete IP phone reference design. The MCS8051 hardware schematics is available with all other standard AR1688 hardware designs. And the software is open source too, located in SDCC\mcs51, and is compiled with SDCC too. Software API users can use the same SDCC\bin\sdcc.exe to compile both the AR1688 software and MCS8051 software.

To complete the MCS8051 based IP phone reference design, we have to define high level UI protocols over the original UART implementations (See more UART details in: http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!296.entry, The high level protocols are based on the "string" implementation for easy debugging), the well organized MCS8051 source code is a good point to start with this article, most of the detail UI handling is located in SDCC\mcs51\ui.c.

There are currently 5 kind of string based controls:

1. Key. Format "KEY x", where 'x' comes from mcs51\hook.c and mcs51\key.c, indicate a key or a hook event occurs on MCS8051 side and send it to handle in AR1688 functions.c function UI_HandleKeys().

2. Lcd. Format "LCD lxxxxxxxxxxxxxxxx", where 'l' stands for display lines, '0' to display on the first line, '1' on second, possible '2' and '3' on third and fourth. "xxxxxxxxxxxxxxx" is the string to display, transferred from AR1688 to MCS8051.

3. Lcd Cursor. Format "LCDClps", 'l' for line number same as above, 'p' for cursor position, '0' as first. 's' for show or hide cursor, '0' to hide, '1' to show. Same as 2, this command is also from AR1688 to MCS8051.

4. Led. Format "LED ts", 't' is the LED type listed below, 's' for status, '0' - On, '1' - Off, '2' - Blink. LED type (mcs51\led.c, inc\bank1.h):

    '0' - LCD
    '1' - KEYPAD
    '2' - MESSAGE
    '3' - MUTE
    '4' - HOLD
    '5' - TRANSFER

    This command is from AR1688 to MCS8051 too.

5. Loop test, Format "LOOPXXXXXXXXXXX", indicate peer to loop back "XXXXXXXXXXX".

Welcome to comment and make changes, we are open for all suggestions.

 

 

In early 1999, Dr Wang founded Palmmicro in Santa Clara and began to use www.palmmicro.com.

In late 2002, Palmmicro changed its name to Centrality. Palmmicro.com registration expired in 2003.

A domain trading company owned palmmicro.com from Dec 25, 2003 to Dec 25, 2007. During this period, Centrality discontinued its VoIP business and later merged with SiRF, we founded Palmmicro again in Beijing, continue our small VoIP business with a new chip.

On Feb 5, 2008, the expired domain name came into "Redemption Period".

On March 6, the domain name became "Pending Delete".

On March 13, the domain was strangely registered by an Oregon domain trading company. I was so disappointed at that time.

On today, March 26, I tried who is search again, and found palmmicro.com available. I registered it under my name at once.

 

 

Changes from previous 3rd edition (http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!305.entry):

 

 

 

Inspired by the UART work done by two customers based on AR168F hardware design, we are releasing AR168M VOIP module (with 0.28 software version) for those who need quick and easy VOIP solution in a large system. AR168M does not have keypad and LCD, it uses simple UART to communicate with external CPU. Except for user interface, AR168M provides all other IP phone features including various standard voice codec and VOIP protocols like SIP/IAX2.

To speed up customer development, we provide ready-made and low-cost AR168M VOIP module as well as AR1688 chip with design schematics. User can make the choice, either to put the AR168M design into its own hardware board, or simply to put the module in the system with less hardware work.

For more information of AR168M, please visit www.palmmicro.com.cn to download detail document.

 

Simplified steps compared with previous article, based on AR1688 0.28 software release:

 

1. Compile SDCC\tool\font project, generate SDCC\tool\font\release\font.exe

2. Download http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz , copy 5x8.bdf, 7x14.bdf and MAPPINGS\8859-9.txt to SDCC\tool\font\release

3. Run command line SDCC\tool\font\release\font 5x8.bdf -t5. Generate array.txt file.

4. According to 8859-9.txt, find the 6 different chars from 8859-1, modify SDCC\src\font.c _cFont in the !defined DISPLAY_DOT part, where 8 bytes make a font line, this is the 5x8 fonts for 2x16 LCD extended CGRAM display.

5. Run command line SDCC\tool\font\release\font 7x14.bdf -t7. Generate another array.txt

6. According to 8859-9.txt, find the 6 different chars from 8859-1, modify SDCC\src\font.c _cFont in the defined DISPLAY_DOT part, where 16 bytes make a font line, this is the 8x16 fonts for dot-matrix display

 

When we to add ISO-8859-2, where a lot of chars are different from 8859-1, steps 4&6 will be too much work. We are going to add more option in font.exe to generate 8859-2 fonts directly from 5x8.bdf, 7x14.bdf and MAPPINGS\8859-2.txt

 

We were using ISO-8859-1 8x16 ASCII fonts and GB2312 16x16 Chinese fonts before recent Turkish support. AR1688 Turkish software version brings us some good questions. For example, what should we do with the 6 different chars' fonts in ISO-8859-9 for Turkish? What if we need other ISO-8859 fonts for other languages later? How to find those self-defined 5x8 CGRAM fonts data used in general 2x16 LCM?

The answer, of course, is to find those resources on the internet, where pictures of CGX are flooding those days. I found Markus Kuhn's page:

http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html and downloaded all those Unicode fonts for X11, converted the 5x8 fonts for 2x16 LCM, and 7x14 fonts for dot-matrix display.

To avoid upgrade font every time user changes different language software version, we added SDCC\src\font.c for ISO-8859 fonts data, linked it with the upgrade binary file. In this way, ISO-8859-1 font is together with French or English software version, and ISO-8859-9 font is linked with Turkish software version.

There is one thing we do not like so far, the X11 fonts use small '+' for '.', makes the dot-matrix display looks strange.

During the work, I also found the page http://www.cs.tut.fi/~jkorpela/iso8859/, which is a perfect place for ISO-8859 information.

 

Inspired by recent Ferhat's work on Turkish support on his 4x20 char LCD with special Turkish char font data in self-defined LCD CGRAM space, we improved our regional and language support features in current 0.27 test software. Here is the steps to add your own native language support in AR1688 firmware, for both dot-matrix and character based LCDs:

1. Add RES_XX in SDCC\inc\version.h, 'XX' code based on ISO-3166 (http://www.iso.org/iso/country_codes). Use RES_US related implementations as example all the time.

 

 

 

 

Two years passed quickly since we started working on AR1688. It looks like a good job so far, with better voice quality and lower BOM cost than previous PA1688 chip. However there are haunted problems all the time. The running speed of Z80 is one of them.

I wrote 48Mhz running speed in the first AR1688 article http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!144.entry, but this speed is never used in mass production software because we found a certain percentage of IP phones can not actually run correctly in 48Mhz clock. Every software release so far is using 24Mhz Z80 running speed to ensure 100% working of the IP phones. We call it low-speed software all those months.

Detail check of the reason for low-speed is very complicated, seems related with almost every part of the phone, including AR1688 chip difference, flash chip difference, LCD difference and even the PCB layout difference.

In current 0.27 test software, SetHighSpeed() function call is added in software API. It can only be called once in function.c UI_Init() function, or never be called. If it is never called, the software will keep running on 24Mhz, after it is called, the software will run on 48Mhz. End users can try this function call for their own special hardware, most IP phones can run on 48Mhz. If one is unlucky to have a slow hardware, the IP phone can be upgraded with standard low-speed software in safe mode. Safe mode always runs with low speed at 24Mhz.

After upgrading the high-speed software, using windows command line "ping xxx.xxx.xxx.xxx -l 2952" to confirm the high speed is actually working. It takes about 19ms for the ping in high-speed, and about 33ms for the ping in low-speed. Watch carefully for those signs of high-speed problem:

1. LCD display error

2. New upgrade operation failed with very fast speed, like 9 seconds

3. Strangely changed or corrupted IP phone settings after change of settings or upgrade

Safe mode will always work, users can use #5*5 and #5*0 to restore factory settings and upgrade low-speed working software in safe mode when anything is wrong.

 

 

I feel so lucky that we did not put all multi-purpose and unused pin definitions in standard AR1688 IP phone hardware reference design. Our customers can always think out of pin usage we never planned before.

We added UART support in software API because many customers found from schematics that UART pins is used as keypad, which means it can actually be used as UART.

And today we added CE3 support in software API because a customer found the chip select pin is not used, and this customer used it to drive more LEDs. I am expecting that more creative usage of CE3 pin will come out soon from different customers.

The specification describes a non interrupt driven serial communication for AR1688.

 

Hardware UART:

 

8 bytes FIFO in transmit direction

8 bytes FIFO in receive direction

Ability to detect errors:

• Receive error
• Receive FIFO error
• Transmit FIFO error
• Error bits are saved for each byte received, all errors are automatically cleared

 

Software API:

 

void UART_Init(UCHAR iBaudRate);

The function initializes UART to 8 bit data, 1 bit stop, no parity. Baudrate can be selected by following table: 13[115200], 26[57600], 39[38400], 52[28800], 78[19200], 104[14400], 156[9600], 208[7200]

Use interrupt handling when baudrate set more than 19200.

 

BOOLEAN UART_SendByte(UCHAR chr);

The function checks if there is enough space in the transmit FIFO .

If there is enough it puts the byte in the buffer and returns TRUE. Else it return FALSE. The byte should be transmitted immediately without using any interrupt.

 

UCHAR UART_RecvByte(UCHAR * chr);

The functions checks if there is something in the receive FIFO .

If there is something it returns 0 and the received byte in "chr". Else it returns status flags.

flags :

Bit7 -      1 = Empty FIFO

Bit5 -      1 = Receive FIFO error

Bit4 -      1 = Receive error

 

Because of increasing interest to use AR1688 UART pins for non-standard VOIP applications and even none IP but voice related applications, we added UART software support in current 0.25 test software.

The UART in AR1688 is the simplest, only a RX pin and a TX pin, no hardware flow control nor status pins. Hardware 8-level by 8-bits FIFO are used to buffer receiving and sending data.

 

There is no real-time operating system with AR1688 software, everything is being performed inside a "while (1) { do_everything(); } type loop. To make things worse, the 8 bits Z80 processor is slow for task like MD5 encryption, typically takes 5-10 milliseconds. We use same FWD test account to test IAX2 and SIP protocol. IAX2 protocol needs 12ms to do a register with 1 MD5 calculation. SIP protocol needs 80ms to do a register with 3 MD5 calculation. Within the 80ms of SIP register, all in-coming and out-going RTP packets are held unhandled, thus cause a lot of RTP jitter during a call.

The problem was pointed out by customer on pa1688 mailing list, the customer suggested that the usage of RTOS is the only solution. However, AR1688 resource indeed can not afford an extra RTOS. Instead, we implemented a RTP first method in 0.25 software and solved this problem perfectly.

When inside a SIP message handling process, we will call "TaskMiniRun()" a few times to handle out-going and in-coming RTP packets in time. The function acts sort of like an interrupt routine, it will save necessary information of the SIP message process, send and receive RTP data, and restore SIP message handling.

Nothing is impossible.

 

In AR1688 option settings, Frames per TX can be set from 1 to 7, which means user can specify 1 to 7 voice frames in an out-going ethernet packet. There is no limitation regarding in-coming voice packet.

When we calculate Speex actual bandwidth usage in http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!287.entry, we only listed frame 1 to 4 in an ethernet packet. This is because we only allow max frames 4 in an ethernet packet for codec like Speex which has 20ms as voice frame time. And we only allow max frames 3 for codec like iLBC in 30ms frame mode. It is to prevent unexpected delay in conversation. Because we can not tell which codec will be actually used after codec negotiation. When frames 7 selected, if G.729 is being used, the delay is 70ms, but if iLBC 30ms mode is being used, the delay will be 210ms, so we add the limitation to control total sending out delay within 90ms.