What is AR1688?
AR1688 is a programable chip, we are using it for low-cost ip phone solutions. It is the replacement chip for PA1688. The basic architecture are the same, both with 8 bit controller for voip protocol stacks and 24 bit DSP for voice compression algorithm. Compared with PA1688, it has more powerful CPU processing speed and higher integration, so the ip phone based on AR1688 has improved performance, better voice quality, more features, and the BOM is more simple, cost is lower too. Like PA1688, we will continue to provide full source code of voip protocols and user interface in our software API for third party development. Some details of the chip and solution below:
1. Controller speed at 48Mhz (PA1688 at 22Mhz)
2. DSP at 60MIPS (PA1688 at 33MIPS)
3. Integrated high-quality audio codec (PA1688 need external codec, WM9707)
4. Integrated large SRAM, no external SDRAM needed (PA1688 need 1x16 external SDRAM)
5. RoHS ready
6. ICMP response of 1472 bytes (ping xxx.xxx.xxx.xxx -l 1472): 10ms (PA1688 21ms)
7. TFTP server data put through (tftp -i xxx.xxx.xxx.xxx put filename): 140kbytes/s
8. MD5 48 bytes encryption calculation: 4.8ms (PA1688 9.9ms)
9. Software API use open source SDCC compiler (PA1688 use commercial Keil C51)

Firmware Upgrade Size
Smaller firmware upgrade size is obviously good for fast upgrade and auto-provisioning. The upgrade file size for a typical PA1688 based phone like PA168S/T is 960k bytes. With AR1688, we have reduced it to 640k bytes. The size reduce comes mostly from 3 parts:
1. SDCC do not actually support code-banking, to write code larger than 64k bytes, we have to do code-banking by hand, writing detail function call for each function in another bank. With Keil C51 for PA1688, the automatically code-banking cost us 50% code space as common code. With SDCC for AR1688, only 25% code space is used as common code.
2. DSP firmware storage structure is improved. We no longer compress DSP code any more, so the boot up time on AR1688 is also instantly, much more fast than PA1688. Actually it is a very bad idea to compress DSP code on PA1688 because of the slow booting time. With AR1688, we have put all common DSP routines like LPC calculation together in one copy of code, this is much more effective than compress!
3. Because there are none-LCD ip phones and 1-port FXS gateways design based on PA1688, we have used IVR to prompt end user necessary device informations. With AR1688, we assume that 2x16 LCD is the lowest display requirement, and we will not design gateways based on AR1688, so the IVR function is no longer there, and the corresponding file size is reduced.

Firmware Upgrade
What is the most important feature of an IP phone today? My answer is, upgrade feature. Why? Because voice over ip is changing all the time and changing quickly! H.323 is too old and not NAT friendly. MGCP is the result of telco and conflicting with internet spirit. OK, what happens to internet native SIP and open source driven IAX2? They both lost to private protocol based Skype shamefully. So if your IP phone can not upgrade easily, how long can you expect it to last?
What we have first done on AR1688 is the upgrade feature, it has all old PA1688 good upgrade features and we have tried to elimilate as much of the "bad" PA1688 upgrade features as well.
1. Whenever IP phone failed, press * key can enter "safe mode". In "safe mode", user can use "native" method to upgrade the phone again. PA1688 need to be powered twice with * key pressed to enter 192.168.1.100 ip address. AR1688 only need to be powered once with * key pressed to enter 192.168.1.200. Why not also 100? Because we are hoping to avoid a PA1688 and an AR1688 into safe mode at the same time.
2. The possibility of phone failed is much less with AR1688. Unlike PA1688, the phone will not get failed even when power lost during upgrade process. We have used difference program flash space for the currently running program and the currently writing new firmware.
3. The "native" method to upgrade changed from private protocol Palmtool to TFTP. We have been asked too many times for linux version Palmtool in the past years. Sure linux user will not need TFTP client program from us. With windows envionment, the windows command line for upgrade is like: tftp -i xxx.xxx.xxx.xxx put ar168f_sip_cn_000543.bin
4. Yes, the file name used the same format as PA1688, above file name means to upgrade an ar168f ip phone with sip protocol, Chinese resource, and 0.00.543 firmware, the current stable demo version.
5. The "native" upgrade speed is much more faster. With PA1688, Palmtool need 68 seconds to upgrade the 960k bytes upgrade file. With AR1688, TFTP only takes 16 seconds to upgrade the 640k bytes upgrade file.
6. HTTP upgrade are available on both chips, the upgrade speed improvement is even more significent.

AR168F IP Phone Hardware Features
AR168F IP phone hardware reference design is the result of the 4th major hardware design change based on AR1688 chip. And it is the first AR1688 based IP phone hardware design available for all manufacturers. It follows the rules of the ants: when the manufacturer number grows like ants, the phone based on the design will be cheap and everywhere. Actually it is the key reason why "Made in China" is so popular in the world today. To encourage as many manufacturers as possible into the product, we do not charge any extra design fee, any one can get complete hardware reference design with small quantity of chip purchase, as small as one single chip.
We have put many documents of the design on www.palmmirco.com.cn download page. For those who do not like to read large pdf files, here is the hardware features summary:
1) Based on AR1688 SoC
2) 2M bytes program flash
3) Realtek RTL8019AS 10Base-T ethernet
4) Optional Realtek RTL8305SC 10/100Base-T ethernet switch
5) 2x16 English characters LCD, with back-light LED
6) 29 keys in total, include 12 number keys and 17 function keys
7) Loud speaker phone, with speaker mode LED
8) 2 extra software controlled LED indication (Message and Mute)
9) Support side-tone

From those features, it is clear that AR168F IP phone is an entry-level design with ultra-low BOM cost. It is going to help VOIP system to replace PSTN phone with almost the same price.

AR168F IP Phone Software Features
Beijing Palmmicro is actually almost a software company. We have been developing and debugging voice and video over IP related software all those years. It is like a game we play, we always play the same old familiar part, only in a different way each time. Again this time, AR1688 software is written from the beginning blank page. It is not based on any open source or other source software, it is not even based on PA1688 software. Everything is completely new. When we announce AR1688 as the replacement of PA1688, we only mean that it will replace the low-end market.

It is quite easy for me to write a long list of software features of AR168F.
Network
1. Automatically get network address by DHCP client
2. Auto-provisioning configuration and firmware by HTTP client
3. HTTP server for web configuration, address book, ring tone change and firmware upgrade
4. TFTP server for command line configuration, address book, ring tone change and firmware upgrade
5. Get time and date by SNTP
6. Support DNS
7. Response to ICMP ping request

Voice
8. G.711 a law and mu law
9. GSM 6.10
10. iLBC
11. G.726-32
12. Speex *
13. G.729 **
14. G.723.1 **
15. G.165/G.168 16ms line echo cancellation
16. Acoustic echo cancellation up to 200ms *
17. Voice activity detection *
18. Comfortable noise generation *
19. Automatically gain control and de-noise *
20. Adaptive jitter buffer *
21. Standard DTMF tone generation

Phone
22. Call hold, call transfer, call forward
23. 3-way conference support *
24. Up to 4 quick dial
25. Voice message check quick dial
26. Support redial
27. Support flash
28. Support mute
29. Adjustable volume for both handset and speaker phone
30. Complete on-phone menu to set all configurations on LCD by keypad
31. Upgradeable ring tone
32. 100 address book entries
33. 10 records each for dialed, answered and missed calls
34. Support hot-line
35. Support auto answer for paging and intercom
36. Support call number prefix
37. Message waiting indication LED
38. Mute indication LED
39. Speaker phone mode indication LED
40. LCD back-light LED

Protocol
41. Support IAX2
42. Support SIP

For those marked with *, the feature is not available at this moment, we are still working on it.
For those marked with **, the feature is not available for the moment, and may have extra codec license fee to its patents holder in the future.

AR168G IP phone
Digimate (www.adigimate.com) has become the 3rd company to offer AR1688 based IP phones after Yuxin (www.yntx.com) and High-Link (www.high-link.cn). We are expecting more than 10 manufacturers in the future months.

GP1260 IP phone from Digimate is based on our AR168G reference design. Unlike no-charge AR168F, AR168G is provided with extra supporting fee. It uses 132x64 dot matrix display, the software can be more fancy than 2x16 char lcd display, and can support Chinese and other special chars not included in standard ascii table. AR168G also support more keys, for example, max 10 speed dial.

Why support ADPCM G.726 32k codec?
AR1688 software development is slow. It took us 4 weeks to move from software version 0.06 to 0.07 and still failed to provide iLBC codec support in version 0.07. Instead, we added ADPCM G.726 32k codec support in this version. We have never supported G.726 in PA1688 before because we never think it is important. And we do not think G.726 is important neither with AR1688. The reason we added it, is because we met so many unexpected problem with iLBC, and we have to run something simpler to test the DSP core inside AR1688. With G.711, GSM 6.10, ADPCM G.726 32k and a LMS based echo cancellation algorithm running on AR1688 steadily. We have least found 3 problems related with DSP instructions:
1. af = reg + const instruction will not give correct answer and will not set flag correctly
2. m register can not be set to negative value when used with circle buffer
3. cntr will be pushed immediately on to counter stack instead of waiting for "do" instructions executed, not consistent with standard ADSP 21xx

Hopefully, all bad news are over and we can release iLBC support soon. The good news is, most people reporting that AR1688 voice quality is greater than PA1688. And with our internal test, it not only has better quality, it also has less hardware delay and runs more steadily.

iLBC Codec Ready
Finally we made it, after month by month promising, iLBC codec is running correctly on AR1688 chip today. We will release 0.08 version of firmware after development clean-up and internal testing. Hopefully we can put it on website this weekend.

I was asked why we put iLBC ahead of G.729 in our development plan. The most important reason is that iLBC is royalty free. As AR1688 chip price does not including any royalty, it is manufacturer's responsibility to pay G.729 and G.723.1 codec royalty if user's is making use of those two famous ITU-T standard codecs. And in turn it will add to the price of the IP phone itself. Our AR1688 IP phone design goal is almost the same as IAX2 protocol itself, to make the terminal as simple as possible, so to create a good and easy to use IP phone with the cheapest price in the world, to compete the price of a normal PSTN phone. To pay various codec royalty is the last thing we like to see it happen. We will still keep working to provide G.729 and G.723.1 support in the near future, but will make it as an option, removable from standard firmware. And we will also add support for Speex, which is another royalty free codec.

Of course there are other reasons to do iLBC first. G.729 is an 12 years old standard, it is originally designed for circuit switch system, to make more usage of the standard 64k pcm channel. G.729 does not consider IP network communication, while iLBC is the codec built for internet voice communication, iLBC will work better when there are IP packet lost.

G.729 is used widely in trunking gateway today to exchange PSTN calls and IP calls. We fully realized this before we make decision because we know Cisco has also put iLBC support in their trunking gateway last year. However, we still received a lot of complaint about iLBC can not make call to PSTN. As a frequently upgrade firmware developer, I certainly under-estimated the difficulty of upgrade a cisco trunking gateway firmware.

Digit Maps
We used to support seven different communication protocols in PA1688. Many of them never bring in serious revenues. MGCP is among one of those losers. However, the work on MGCP has lead to function for other protocols. SIP and IAX2 are protocols currently supported in AR1688, both have digit maps functions supported similar with MGCP.
In RFC 3435 section 2.1.5, there is detail digit maps explanations. Digit maps are used to decide when user on the phone has finished dialing by matching rules defined in digit maps. In MGCP case, digit maps in IP phone are from server messages. In our implementation of SIP and IAX2, digit maps are stored together with settings, pre-defined by user or system, and can be automatically updated with settings in auto-provision. From our API, using "sdcc\bin\getopt.bat xxx.xxx.xxx.xxx", options.txt will pop up, with 2 different section of [settings] and [digitmap]. Digit maps are listed under [digitmap]. User can also use internet browser to view and modify digit maps by simply visiting the ip address of IP phone.
SipPhone (www.sipphone.com) is one of my most frequently tested sites. Part of test number below:

**	Hear your SIPphone number repeated back to you.
*0	Test your router's SIP compatibility.
411	The voice-activated Tellme information service.
1-747-474-ECHO 1-747-474-3246	Echo Test - Repeats back whatever you say.
1-747-474-5000	SIPphone welcome recording
1-747-XXX-XXXX	Call any SIPphone user

The corresponding digit maps for those numbers are:

*x	for ** and *0.
4xx	for 411.
1xxxxxxxxxx	for 1-xxx-xxx-xxxx number.
x.T	for other numbers.

If digit maps are not used, user must press "call" key after finished dialing, just as with a mobile phone. In the early days of voice over IP, many software and hardware device use "#" key for dial out. As VOIP is merging with PSTN today, because # key is heavily used in PSTN system supplementary services, it is not a good idea to use # key for "call" function any more.

The following example illustrates the above. Assume we have the digit map:
(xxxxxxx|x11)
and a current dial string of "41". Given the input "1" the current dial string becomes "411". We have a partial match with "xxxxxxx", but a complete match with "x11", and hence we send "411" to the Call Agent.
The following digit map example is more subtle:
(0[12].|00|1[12].1|2x.#)
Given the input "0", a match will occur immediately since position (".") allows for zero occurrences of the preceding construct. The input "00" can thus never be produced in this digit map.
Given the input "1", only a partial match exists. The input "12" is also only a partial match, however both "11" and "121" are a match. Given the input "2", a partial match exists. A partial match also exists for the input "23", "234", "2345", etc. A full match does not occur here until a "#" is generated, e.g., "2345#". The input "2#" would also have been a match.
Note that digit maps simply define a way of matching sequences of event codes against a grammar. Although digit maps as defined here are for DTMF input, extension packages can also be defined so that digit maps can be used for other types of input represented by event codes that adhere to the digit map syntax already defined for these event codes (e.g., "1" or "T"). Where such usage is envisioned, the definition of the particular event(s) SHOULD explicitly state that in the package definition.
Since digit maps are not bounded in size, it is RECOMMENDED that gateways support digit maps up to at least 2048 bytes per endpoint.

Our Business Model
AR1688 IP phone solution has been in the market for over half a year now. I have personally answered quite a lot of business model related emails since that time. This article is the collection of all those questions and answers.
We are not part-time open source software developers. Our income comes from the sales of AR1688 chip and related design fees.
We use open source SDCC compiler to build the software and release software API under GPL license, in the hope of helping end users make more out of their IP phones. For me, it is fun to modify the software and see it working immediately, and I believe it is true for others too. When everyone can modify something with his or her own IP phone, we also hope that this will reduce our supporting work of customizations. And most important, with so many gifted programmers keeping an eye on our software and make improvements, we are more likely to do a better job than keep all the coding to ourselves.
We have not included everything in the free distributed API source code. DSP part are provided in binary .dat file and low-level register control, ethernet mac layer, IP layer and basic UDP and TCP connection implementations are provided in SDCC object .o files. We will be glad to provide all those source code with reasonable price, if some big guy really believes it is necessary.
It is true that we do not charge any design fee for basic IP phone reference designs. In the case of AR168F IP phone design, it is provided with any chip purchase. Pay us 76 RMB (about 10 USD) for a single chip and we will provide everything, including free shipping in China. This policy is used to help manufacturers to pick up IP phone business with almost no investment. In this way, we hope to encourage as many manufacturers as possible into this business, making IP phone cheap enough to compete with PSTN phones.
However, AR168F IP phone hardware reference design is for turn-key IP phone production only. It is not very possible for hardware developers to add or modify something based on it, and we will also not support those kind of development. We will charge extra design fees for request like dial-up, GSM module, FXS/FXO, LCD change. I will try to make it more clear by telling the birth story of AR168G IP phone below.
Originally in mp3/mp4 business, DigiMate is new to VOIP. It does not like our AR168F design mostly because of the poor 2x16 char LCD. In mp3 business, it has been a long time to use dot-matrix displays. So DigiMate paid development fee to us for none-exclusive support of dot-matrix display. Today, AR168G IP phone hardware reference design with 132x64 display support is also for every manufacturer, with the request of 80,000 RMB (about 10,336 USD) upfront design fees.

Regional and Language Options
With PA1688, we have supported over 30 different language firmware. None of us understand language except Chinese and English, volunteers all over the world helped us to do the entire localization works. I believe that we can do this again with AR1688, hopefully even better because it is well planned from the beginning.
We are going to release version 0.10 firmware today. After 0.09 finalized all SIP/IAX2 protocol implementations, in this version we have finalized all UI implementations. Of course we will continue to improve it and fix bugs, however, developers can do regional and language customization based on this version without worrying future huge changes.
Based on 0.10 software API, please following steps below to add your own native language support:
1. Starting from SDCC\inc\version.h, find the RES_XX sections, check if your regional code is in the list or not. The 'XX' code is following ISO 3166 (http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html). If it already exists, you can jump to step 4 directly. If it is not, please add it. You can then choose to move on to next step, or send an email to support@palmmicro.com.cn, tell us about your change, and ask us to do step 2 and 3, you can jump to step 4.
2. Add your regional DTMF frequency and interval to SDCC\src\dtmf.c, search for "RES_US" in files if you need guide for changes.
3. Check SDCC\src\res, based on web_us, translate the English web pages into your native language.
4. Translate strings in SDCC\src\ui_str.c. There is Chinese strings already in it, you might not be able to read it. Just add your own language translation in your native coding. With 2x16 LCD, the display will still be English, but we can add other language font display with dot-matrix LCD.
5. Open SDCC\src\time.c, change time and date display format accordingly. If your region use day light saving time, be sure to add it, or send request to support@palmmicro.com.cn. China does not use day light saving today. Currently only USA day light saving is implemented. Make sure "Automatically Adjust Clock for Daylight Saving Changes" option is checked in settings.

How to Change MAC Address
The MAC address of PA1688 based device can be easily changed by Palmtool, and we spent a lot of technical support effort to help manufacturers and end users to get rid of the duplicated MAC problem. When we began to design AR1688 software, we tried to avoid the problem from the beginning, the MAC address is not allowed to be changed in most situations. But still there is request of MAC address changing request that we feel not easy to refuse, the result is this guide. However, this is not a simple guide, and you must be an advanced user to follow this guide. If you do not know how to upgrade by TFTP, do not know how to enter safe-mode, or do not know what MAC address is, you can skip the rest.
1. Make sure you have most recent AR1688 API in hand, feel free to write to support@palmmicro.com.cn for a copy if you do not have it.
2. Also write to support@palmmicro.com.cn saying that you need special firmware to change your MAC address. Please provide information like hardware type, protocol and language for us to send you the correct firmware.
3. Press * while power up to set your AR1688 IP phone into safe-mode.
4. Use the command line tool in API SDCC\bin, "getopt 192.168.1.200", when it finishes, an options.txt file will pop up.
5. In options.txt, find the line like "mac_address=0x00,0x18,0x1f,0x10,0xa0,0xb8", change whatever MAC address you like to use.
6. Save options.txt, use "setopt 192.168.1.200", the phone will reboot after change
7. Use command line to upgrade the special firmware we sent in email in step 2, usually like "tftp -i xxx.xxx.xxx.xxx put ar168f_sip_us_017037.bin". The file is 640k in size.
8. Use command line to upgrade the safe-mode firmware we sent in email in step2, usually like "tftp -i xxx.xxx.xxx.xxx put ar168f_none_us_017037.bin", the file is 64k in size. After those steps, you can use and upgrade normal firmware in the future with MAC address changed.

Debug FAQ
We are ready to support customers in many ways, including phone, MSN and email. Phone calls work well as long as it is made in Chinese. But most of us speak English not as good as American or Indians. I got a few calls from India yesterday, more than half of the time I was guessing what the other side is talking about, and the other half time, I guess the other side was guessing what was my idea too! I like MSN because I grow up with Microsoft software, but I can see many others hate M$ every time my suggestion of using MSN is turned down. How lucky we are, still have email as an effective communication tool, please feel free to send email to support@palmmicro.com.cn as much as possible. Please include the following in all debug email request:
1. Hardware type, like GP1260/1266 from DigiMate, GF302 from High-link, YWH201/601 from Yuxin
2. Software version, we have 0.16 as most recent steady version at present
3. Protocol, SIP or IAX2
4. Language, cn, us, fr, it and many others
5. OEM tag, if the phone has an OEM tag
6. Phone settings in .html format. Users can use their internet browser's "Save As..." function to save web settings into a .html file. The file saved may not be able to view in whole by web browser because of security reason, but we can read it in html edit tools like Microsoft Word
7. Detail problem description and best with test accounts for us to repeat the problem.
8. Other software and hardware used in the test. Please send us any software used in test as possible to help us repeat the problem
9. Ethernet packet captured in any format
10. Palmtool debug message output. Must enable AR1688 setting's debug option. Send to us in plain text.
11. In some special case, we will request users to run the following command and sent the files page0.dat and page1.dat to us:
Firmware 0.16 Debug FAQ:
1. No audio in call: Check CODEC options and make sure G.723.1 and Speex are not selected.
2. No outgoing audio in call:
a. Check RTP port setting to be none-zero, change protocol from IAX2 to SIP will set RTP port to 0
b. Check Audio Frames per TX value between 1-7

Frames per TX
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.

RTP First
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.

Regional and Language Options - 3rd Edition
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.
2. Add your regional DTMF frequency and interval to SDCC\src\dtmf.c.
3. In SDCC\src\time.c, change time and date display format accordingly, and add day light saving time support if your region uses day light saving.
4. Translate the English web pages in SDCC\src\res\us into your native language, put them in the new SDCC\src\res\xx directory.
5. Translate SDCC\src\res\us\menu.h, time.h and str.h into your native language, keep the original coding as it is in the file. For example, keep ISO-8859-1 coding for French special chars and ISO-8859-9 coding for Turkish special chars.
6. Add necessary ISO-8859-X font in SDCC\src\font.c, or update Unicode font in the 256k bytes font data flash storage space.
Currently we have supported Chinese, English, French, Spanish and Italian. For users with less programming experience, only step 4 and 5 are necessary, we will do the other works after we have received the translations for step 4&5.
Here are the links of the earlier 2 editions of Regional and Language Options:
http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!233.entry
http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!219.entry

Fonts Resources
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.

Detail Steps to Add ISO-8859-9 Fonts to AR1688 Software
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

Detail Steps to Add ISO-8859-2 Fonts to AR1688 Software
Simplified steps compared with previous article, based on AR1688 0.28 software release:
1. Download http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz , copy 5x8.bdf, 7x14.bdf and MAPPINGS\8859-2.txt to SDCC\bin
2. Run command line SDCC\bin\font.exe 5x8.bdf -t5. Generate array.txt file.
3. Run command line SDCC\bin\font.exe 8859-2.txt -i. Generate font.txt, this is the 5x8 fonts for 2x16 LCD extended CGRAM display.
4. Run command line SDCC\bin\font.exe 7x14.bdf -t7. Generate array.txt file.
5. Run command line SDCC\bin\font.exe 8859-2.txt -i (again). Generate font.txt, this is the 8x16 fonts for dot-matrix display.

AR168M VOIP Module
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.

Regional and Language Options - 4th Edition
Changes from previous 3rd edition (http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!305.entry):
Currently we have supported Chinese, English, French, Italian, Romanian, Russian, Spanish and Turkish. What is more, Alex also added extended char input method in Romanian and Russian version. So we have step 7 now with 0.29 test software, find SDCC\src\res\us\inputmap.h, change it to your own native language. SDCC\src\res\ro\inputmap.h is Romanian example and SDCC\src\res\ru\inputmap.h is Russian example. Different inputmap.h is included with RES_XX define in SDCC\src\menu.c.

AR168M VoIP Module High Level UI Protocols
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.

MCS51 Software Details
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.

AR168N Network Camera Features
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.

Short Message Display
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.

Name Rules
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!

A Farewell to RTL8019AS
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?

Safe Mode Upgrade
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.

Good Bargain
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.

AR1688 Z80 Memory Map
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.

Program Space and Data Space
Z80 follows the Von Neumann architecture. The 64k bytes memory space can be used as both program and data. In our AR1688 case, 0x0000-0x1fff are used as program space only (C language const data array in the program are also compiled into program space). 0x2000-0x7fff are used as data space only. The Harvard architecture DSP has separated program and data space, but from Z80 point of view, they are just 6 pages of data mapped in 0x4000-0x7fff. 0x8000-0xffff are used as both program and data, depending on the actually mapped banks:
2Mx8bit program flash is connected to chip select signal 0 (CE0).
Program flash address 0x000000-0x00ffff (mapped as bank0 and bank1), safe mode program
Program flash address 0x010000-0x01ffff (mapped as bank2 and bank3), settings, speed dial, digit map and other data
Program flash address 0x020000-0x04ffff, ring tone data in g.711 mu law format
Program flash address 0x050000-0x07ffff, hold music data, same format as ring tone
Program flash address 0x080000-0x0bffff, font or IVR data
Program flash address 0x0c0000-0x0fffff, first copy of main program
Program flash address 0x100000-0x10ffff, first copy of HTTP data
Program flash address 0x110000-0x15ffff, first copy of DSP data
Program flash address 0x160000-0x19ffff, second copy of main program
Program flash address 0x1a0000-0x1affff, second copy of HTTP data
Program flash address 0x1b0000-0x1fffff, second copy of DSP data
Network chip, RTL8019AS or DM9000 (http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!365.entry), is connected to chip select signal 1 (CE1), used as data space in Z80 point of view.
LCD, 2x16 char or 128x64 dot-matrix, is connected to chip select signal 2 (CE2), used as data space in Z80 point of view.
Chip select signal 3 (CE3, http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!298.entry) is not used for entry-level phone designs, but used as keypad extension for IP phones need a lot of keys, also used as data space in Z80 point of view.
As program can only run on address 0x0000-0x1fff and 0x8000-0xffff, when 0x8000-0xffff are mapped as some data listed above, the program then can only run on internal SRAM 0x0000-0x1fff. In other words, when we need to read and write flash, control network chip and LCD, or use CE3 signal, we need to put those program running on internal SRAM.
And there is bank-switch code need to run on internal SRAM, when program is running on certain bank (which mapped to 0x8000-0xffff), and need to call functions on another bank (which also mapped to 0x8000-0xffff), we need to call a function in internal SRAM (0x0000-0x1fff) to do bank-switch.
Well, I do not think someone will really read this article to this point. Maybe I should write those in Chinese, which may be better for all of us. "My English sucks" is the only good English I can speak proudly.

AR168M VoIP Module Example
Steven Young is an undergraduate student from Beijing University of Posts and Telecommunication. He had done an Atmel AVR mega 128L hardware board and related software to work with AR168M VoIP module earlier this year. The full hardware and software design is now for open download in http://www.palmmicro.com.cn/download/documents/IpPhone-Mega.zip.
The mega board has connected a 2x16 LCD and 4x4 keypad to make a fully working IP phone. The hardware schematic is in OrCAD format. The open source software is compiled using WinAVR2004.
Steven can be reached by email warmbupt@gmail.com. He will be glad to make more development based on the mega-AR168M system upon request.
For more information of AR168M VoIP module, please also read:
http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!310.entry
http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!317.entry
http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!318.entry

Dog Food 2 - Conference
Due to DSP processing power limitation, AR1688 can not handle 2 channel of voice at the same time, so it can not hold a 3-way conference call. But this does not prevent it to take party in conference with Asterisk PBX.
In our Beijing office Asterisk PBX (http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!364.entry), a conference call can be held by everyone calling into a same 8xxx number. For example, I at extension 418 can pre-schedule Kingon (412) and Shanshan (420) to call into 8418 at 12:00pm today. Or, at 12:00pm, I can first call 412, transfer it into 8418 and ask Kingon to wait there, then call 420, transfer it into 8418 too, and finally, I call 8148 myself, so the 3 of us can have a conference together then.

Serial Communication Templates
Matthias Siegele added first version of serial communication template in AR1688 0.26 software release (as described in http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!297.entry). From 0.26 to 0.34, we just kept it as it was in a separate example file serial_template.c. It was not included in the make process. In 0.30 release we added AR168M VoIP Module high level UI protocols (http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!317.entry) based on interrupt driven UART read method (http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!296.entry). Since then, API user needs to remark a lot of code related with the UI to use the simple none-interrupt driven UART template. We fixed this difficulty and also added other serial communication templates with recent 0.35 test versions, those changes will be included in the 0.36 software release due in this month:
1. sdcc\src\serial_template.c is removed, the none interrupt driven UART template is merged into serial.c under SYS_UART_POLL define, and can be compiled if SYS_UART_POLL is defined in sdcc\include\version.h and SERIAL_UI is not defined in the same time.
2. A new interrupt driven UART loop back template is added in serial.c under SYS_UART define, and can be compiled if SYS_UART is defined and SERIAL_UI is not defined.
3. High level UI protocol and UI implementation will be used if SERIAL_UI is defined in sdcc\include\version.h
For AR168M users who wish to build their own UART protocol, please use SYS_UART template as a start point of coding.

Default Settings
AR1688 device settings are stored in program flash address space 0x10000-0x13fff (http://aredfox.spaces.live.com/blog/cns!D39D5CB681D148C0!378.entry). And factory default settings are stored in address 0x14000-0x17fff. Software API file sdcc\include\ar168.h is a good start point to know more detail mapping of those settings. The files in sdcc\src\settings are used to build different factory settings for different manufacturers and OEMs, change of those files will not affect upgrade binary files. Actually, it should be always to avoid change settings or default settings by upgrade software.
Many Asterisk system builders like to have their own default settings in those IP phones. The best way is to give a sample .txt settings file to IP phone manufacturers, we can help to put those setting values into the proper space before manufacture process. For existing IP phones, there are 3 ways to change default settings:
1. In safe mode, use #5*1 to store current settings as default settings. Check sdcc\doc\key_test.txt for details.
2. In normal mode, use Menu->Phone Settings->Store Defaults to save current settings as default settings.
3. For programmers, use API functions UI_StoreDefaults() and UI_LoadDefaults() to save current settings as default settings.

Router, PPPoE and DM9000
Many users like to ask, do you support PPPoE? It seems to be a simple and processional question, but now I understand it in a different way. When someone asking PPPoE, you can be sure that what he really like to know is, do your IP phone has router functions?
The answer is no, AR1688 do not have router functions and we can not add it in future software due to Z80 processing power limitations.
However, we now do support PPPoE after so many false feature request on it. You can put AR1688 IP phone in the place of your router, for example, connecting to an ADSL modem by RJ45 cable. AR1688 knows how to dial up by PPPoE and make itself online, but it can not make other device like your PC (on the other RJ45 port of the phone) online.
With RTL8019AS, the extra support of PPPoE will slow down a little network performance in theory but it can hardly be measured. Both PPPoE and none PPPoE show almost the same performance.
One of DM9000's advanced feature is that it can compute IP, UDP and TCP checksum by hardware. It is especially useful for processing power limited controller like AR1688. However, DM9000 hardware can not recognize PPPoE packets and compute checksum correctly for them. We have to disable hardware checksum compute when PPPoE is enabled. Because of this, the PPPoE network performance with DM9003 is obviously worse than none-PPPoE performance.
The performance difference do not have really impact with voice over IP functions. But with video support in the near future, we will see the difference soon.