} dumpBlk;
u16_t RxData;
switch (head.id)
{
case PKTID_CHANGE_MODE:
m_status=CSystemBurner:UMP;
len=CreatePacketOrder(TxBuffer, PKTID_SYS_DUMP, NULL,0);
Send(TxBuffer,len);
printf("change mode OK.\nstart dumping....% 3d/%
3d",m_small_blk_cnt+1,m_small_blk_num);
m_small_blk_cnt++;
m_CodeOffset+=SMALL_BLK_SIZE-2;
break;
//keep dump or do next step-checksum
case PKTID_SYS_DUMP:
if (m_small_blk_cnt>=m_small_blk_num) { //finish dump
printf("\ndump done(OK).\n";
m_status=CSystemBurner::CHECKSUM;
len=CreatePacketOrder(TxBuffer, PKTID_SYS_CHECKSUM, NULL,0);
Send(TxBuffer,len);
printf("do check ...\t";
}
else {
dumpBlk.U.S.offset=m_small_blk_cnt;
memcpy(dumpBlk.U.S.code,m_pCode+m_CodeOffset,SMALL_BLK_SIZE-2);
m_status=CSystemBurner:UMP;
len=CreatePacketOrder(TxBuffer, PKTID_SYS_DUMP,
dumpBlk.U.full,SMALL_BLK_SIZE);
Send(TxBuffer,len);
printf("\b\b\b\b\b\b\b% 3d/% 3d",m_small_blk_cnt+1,m_small_blk_num);
m_small_blk_cnt++;
m_CodeOffset+=SMALL_BLK_SIZE-2;
}
break;
//checksum correct then do BURN
case PKTID_SYS_CHECKSUM:
memcpy((unsigned char *)&RxData,cBuffer+sizeof(struAnswerHead),sizeof(u16_t));
printf("checksum OK. ----- value=%04x\n",RxData);
m_status=CSystemBurner::BURN;
len=CreatePacketOrder(TxBuffer, PKTID_SYS_BURN, NULL,0);
Send(TxBuffer,len);
printf("do burn ...\t";
break;
//last receive before burning!
case PKTID_SYS_BURN:
m_status=CSystemBurner::BURN_CONFIRMED;
printf("received PKTID_SYS_BURN.\n";
break;
//cancel command be confirmed.
case PKTID_SYS_CANCEL:
m_status=CSystemBurner::CANCEL_CONFIRMED;
break;
default:
printf("unknown echo: %08x\n",head.id);
break;
}
return TRUE;
}
ERROR_HANDLER_RETURN("OnSocketReceive",TRUE)
}
(漢字錄入好慢啊,今天實在寫不動了,下次再聊.)
//----------------------------------------------------------------------
啊,不會吧?!這么多人瀏覽
好久沒有敲這么多中文了, 不好意思,上次寫的很亂,純粹是隨寫,有些地方讓大家摸不著頭腦(我不是學文的料---我
上中學的時候最恨語文了,尤其是文言文!),比如連中文標題都有語法問題!
上面的最后兩個范例為VC寫的Windows寫例程代碼片段(不是for MSP的),由于此部分剛實現(xiàn)功能,還沒有集成到
Service部分中,程序中有好些臨時定義(隨想隨寫的陋習,如struDumpBlk_XXX的定義,希望大家不要見笑).
這個星期天天忙于Allegro,沒有時間照顧tcp/ip stack, 不過在這段時間我特別看到系統(tǒng)升級的另外好處(初期只考
慮到實際應(yīng)用中的需要),特別在批量生產(chǎn)的調(diào)試和配置功能上:
我的前端Sensor芯片在PCB板上元件完成后,需要精確設(shè)置參數(shù)(每個板子由于元件參數(shù)誤差原因而須單獨設(shè)置),原來
的傳統(tǒng)想法是在測試床上完成測試,計算,再編程,再調(diào)整的方法,方法繁瑣,數(shù)據(jù)不安全,有了這個在線升級功能后,到
時只要交給加工單位兩個目標文件即可,一個為第一次編進去的帶tcp/ip的專用測試代碼,第二個為最終的應(yīng)用代碼文
件(特別格式),測試代碼完成外圍芯片參數(shù)設(shè)置固化等加工調(diào)試功能,完成后在線升級替換應(yīng)用代碼,整個過程只有一
次BSL編程,自動化程度高,大大節(jié)省人工(你們不知道這里人工費好高啊!!), 嘿嘿, 想不到我的這個idea在公司得到
重視(又自找事做了,不知道隔段時間好久可得到漲工資,新移民總是吃虧啊--語言,關(guān)系,開始的薪水,...... )
//--------------------------------------------------------------------------------------------------
DHCP Client
前段時間客戶提出新要求,要實現(xiàn)DHCP客戶端以支持動態(tài)IP(原因很簡單,設(shè)備可能被要求運行在一個沒有任何PC機,只
有多個該設(shè)備和一個硬件Router的LAN環(huán)境內(nèi)--現(xiàn)在的硬件Router都含DHCP-Server,使得那些技術(shù)員不用對每個設(shè)備
配置IP),很啃了一陣資料,終于實現(xiàn)了(原來想偷懶的,想用RARPD來實現(xiàn),但一聽說整個LAN環(huán)境沒有一臺PC,僅通過一
個Router與WAN連接,用RARPD方式就沒戲了).
其實現(xiàn)在看來DHCP客戶端很簡單,只是原來沒有深入研究過而覺得可能復(fù)雜. 對MSP430上的實現(xiàn)有幾個特點:
1. 標準DHCP的MSG長度必須大于xx+64+128+308>500bytes,而其中的sname和file段就用掉了192BYTES,而這兩個字段
基本上是為了兼容BOOTP的,大大浪費內(nèi)存.我用以下來減少: (注:其中chaddr也只分配了6個字節(jié),發(fā)送區(qū)由于自己定
義不多的option,所以options取大概16字節(jié)就可以了,而接收區(qū)為了保證完整的要求,options大小為308,基本保證了
各種DHCP server的要求(除非還有溢出而使用了file的古怪的DHCP server),實際上我測試的十來種軟硬DHCP server
都沒有用上這么多,不過還是保留著,萬一呢....再說我下面提到共用另外的一個緩沖區(qū),所以該大小也并不可怕)
typedef struct dhcpTxMessage {
u8_t op; // Packet opcode type: 1=request, 2=reply
u8_t htype; // Hardware address type: 1=Ethernet
u8_t hlen; // Hardware address length: 6 for Ethernet
u8_t hops; // Gateway hops
u32_t xid; // Transaction ID
u16_t secs; // Seconds since boot began
u16_t flags; // RFC1532 broadcast, etc.
u32_t ciaddr; // Client IP address
u32_t yiaddr; // 'Your' IP address
u32_t siaddr; // Server IP address
u32_t giaddr; // Gateway IP address
u8_t chaddr[6];//u8_t chaddr[16]; // Client hardware address
//u8_t sname[64]; // Server host name
//u8_t file[128]; // Boot file name
u32_t cookie; // magic value
u8_t options[16]; // not more than 16???? (optionS is ENOUGH)
} dhcpTxMessage;
typedef struct dhcpRxMessage{
u8_t op; // Packet opcode type: 1=request, 2=reply
u8_t htype; // Hardware address type: 1=Ethernet
u8_t hlen; // Hardware address length: 6 for Ethernet
u8_t hops; // Gateway hops
u32_t xid; // Transaction ID
u16_t secs; // Seconds since boot began
u16_t flags; // RFC1532 broadcast, etc.
u32_t ciaddr; // Client IP address
u32_t yiaddr; // 'Your' IP address
u32_t siaddr; // Server IP address
u32_t giaddr; // Gateway IP address
u8_t chaddr[6];//u8_t chaddr[16]; // Client hardware address
// u8_t sname[64]; // Server host name
// u8_t file[128]; // Boot file name
u32_t cookie; // magic value
u8_t options[308]; // Vendor-specific area 312 - cookie = 308
} dhcpRxMessage;
2. 共享TCP中的Fram1[]和RxTCPBuffer[], 因為DHCP Client通常在上電調(diào)用(另一種情況是Lease快到期了), 所以我
協(xié)調(diào)了把TCP應(yīng)用中的Fram1和RxTCPBuffer拿來共用, 如下:
extern u8_t TxFrame1[ETH_HEADER_SIZE + IP_HEADER_SIZE + TCP_HEADER_SIZE +
MAX_TCP_TX_DATA_SIZE];
extern u8_t RxTCPBuffer[MSP_MAX_TCP_RX_DATA_SIZE]; // space for incoming TCP-data
dhcpTxMessage *dhcpTxMsg;//USE RxTCPBuffer[], NOTE: *RX* NOT *TX* IN TCP
dhcpRxMessage *dhcpRxMsg;//USE TxFrame1[], NOTE: *TX* NOT *RX* IN TCP
//malloc memory, reuse-buffer
dhcpTxMsg=(dhcpTxMessage *)&RxTCPBuffer[0];
dhcpRxMsg=(dhcpRxMessage *)&TxFrame1[0];
注意我的DHCP Client的收發(fā)緩沖區(qū)和TCP的收發(fā)緩沖區(qū)剛好對調(diào)! 原因是TCP應(yīng)用中發(fā)出的數(shù)據(jù)多,接收的數(shù)
據(jù)少,而dhcp client的剛好相反.
3. 幾個函數(shù):
void DHCP_Discover(void)
{
u8_t *op;
DHCP_Init_Header(DHCPDISCOVER);
op = &dhcpTxMsg->options[3];
*op++ = DHCP_REQUESTED_IP; //當然希望DHCP Server最好能分配給我上次使用的IP地址了!
*op++ = 4;
memcpy(op,&Net.MyIP[0],4);
op+=4;
*op = DHCP_END;
DHCP_Transmit();
}
void DHCP_Request(void)
{
u8_t *op;
DHCP_Init_Header(DHCPREQUEST);
op = &dhcpTxMsg->options[3];
//option requested_ip
*op++ = DHCP_REQUESTED_IP;
*op++ = 4;
memcpy(op,(u8_t *)&dhcpRxMsg->yiaddr,4);
op+=4;
//option server_id ......
// but The RFC 2131 4.4.5 say:
// ...in RENEWING state ... client MUST NOT include a 'server identifier' in the DHCPREQUEST
message.
// is that serious?
*op++ = DHCP_SERVER_ID;
*op++ = 4;
memcpy(op,(u8_t *)&dhcpRxMsg->siaddr,4);
op+=4;
*op = DHCP_END;
DHCP_Transmit();
}
void DHCP_IfConfig(void)
{
u8_t *ptr;
struNetInfo newNet;
DHCPRetryTimer=0;
DHCPLeaseTime=0x7fffffff; //2147483647 sec= 68 years
//malloc memory, reuse-buffer
dhcpTxMsg=(dhcpTxMessage *)&RxTCPBuffer[0];
dhcpRxMsg=(dhcpRxMessage *)&TxFrame1[0];
DHCP_Discover();
while (1)
{
if (DHCPOFFER==DHCP_Receive())
{
DHCPRetryTimer=0;
DHCP_Request();
while (1)
{
if (DHCPACK==DHCP_Receive())
{ //this is what we want.
//re-set Lease Time
ptr=DHCP_GetOptionData(DHCP_LEASE_TIME);
if (ptr) {
memcpy(&DHCPLeaseTime,ptr,4);
ntohl((u8_t *)&DHCPLeaseTime);
}
if (memcmp(&dhcpRxMsg->yiaddr,&Net.MyIP[0],4)) { //new MyIP
memcpy(&newNet.MyIP[0], &dhcpRxMsg->yiaddr,4);
memcpy(&newNet.GatewayIP[0], DHCP_GetOptionData
(DHCP_ROUTER),4);
memcpy(&newNet.SubnetMask[0],DHCP_GetOptionData
(DHCP_SUBNET),4);
memcpy(&newNet.MasterIP[0], &Net.MasterIP[0],4);
...
}
return;
}
if (DHCPRetryTimer>5) //timeout for ACK listen
{
DHCPRetryTimer=20; //ready for next DHCP_Discover
break;
}
}
}
else
{
if (DHCPRetryTimer>5) //timeout for OFFER listen
{
DHCPRetryTimer=0;
DHCP_Discover();
}
}
}
}
//---------------------------------------------------------------
花絮 2004.9.2 RichardL 再次光臨ZOGLAB BBS時的留言
Hi, you guys!
Long Long time not see you here, I just back Montreal from my 2-weeks' vacation(I am tired). sorry I
cann't type any chinese this time.
I am still working on MSP430 sometimes. I am trying to move my 430/ip-stack part into 'uip' when I
have spare time(it's not easy since I have done a lot of stuff on it). Hope I can write something
later.
//-----------------------------------------------------------------------------------------
花絮 20051.31
真的好久好久沒有來這里了, 謝謝大家的問候(其中的一個奉承我可受不起哈)
工作的時候一會忙硬件,一會忙軟件的, 總是跟著感覺走(有啥法呢, 市場需要嘛). 閑話少說, 還是回到MSP這塊吧:
我一直有強烈的愿望移植ip-stack到uIp的體系中. 所以一直在空閑時默默地修改系統(tǒng). 前段時間用戶提出了PPP支持
, 終于找到一個好的借口有時間做移植工作了.
最近基于uIP的情況改進了不少, 里邊最大的增強可能就是那個Contiki了, 其中的ek部分我比較欣賞,(GUI部分我目
前用不著, 以后看來移到某些低檔的ARM芯片可能是個選擇方案之一). Contiki中的特性我就不多說了(常見其網(wǎng)站即
可), 這里我也僅僅談?wù)劜糠謶?yīng)用體會:
1. 基本支持TCP/IP的框架, 所以標準的和你我自定義的基于TCP/IP應(yīng)用協(xié)議應(yīng)該很簡單就可實現(xiàn)支持, 目前我僅測
試過我自己的TCP應(yīng)用協(xié)議部分和telnet等, 確實好用, 大大彌補了原系統(tǒng)很多的不足(通訊效率也提高不少, 最重要
的是結(jié)構(gòu)清晰, 很便于移植, 添加多種協(xié)議同時支持).
2. UDP支持部分要自己擴充一些, 原來的部分對此的代碼支持不很深入. (下次我找到代碼, 貼一些出來), 總的來說
這部分也不復(fù)雜的.
3. 范例中的DHCP部分感覺不太好(PThread), 我重新用了自己的代碼來實現(xiàn), 和uIP集成的話不消耗任何全局內(nèi)存(4
字節(jié)的DHCP_Lease_Time例外------如果你要用這個量的話), 只是代碼多些而已(約1KROM-----我用MSP430F149, 無
太大關(guān)系啦).
4. 終于實現(xiàn)了PPP撥號支持! 這是我花時間最多的地方, 因為必須重新PCB-Layout(保留CS8900A和4MFlashMemory,添
加Modem模塊插座), 等待實物Modem模塊, 然后由開始深入AHDL,LCP,PAP,IPCP的了解及測試, 一步一步, 由于目前
Adam好像也還沒有完成PPP部分(從他最近的一些相關(guān)信息中看出好像他目前也在花時間忙MSP430這塊呢), 從公開的
代碼來看,有好幾個地方的不足和Bug(至少針對MSP430系列,特別是PPP部分):
a. 要一些小改動來移植到IAR,(我開始費了好大的勁來用MSPGCC, 從有些方面看還是IAR方便些).
b. 沒有Modem接口范例,雖然基本上AT命令就可以了, 不過還是需要一些跟硬件有關(guān)的范例才顯得更完整.(我用的
是WinTech的SL2456,串口方式,提醒使用這個模塊的是用這個模塊的時候, 最好用CTS/RTS控制, 不要只CTS流控制方
式, 否則在接收緩沖中數(shù)據(jù)大大延遲, 很影響LCP,PAP消息的響應(yīng))
c. ADHLC中有一個重要Bug:
//if((c & 0x1) && (ahdlc_flags & AHDLC_PFC)) {
//NOTE: not c but ppp_rx_buffer[0]!!!
if((ppp_rx_buffer[0] & 0x1) && (ahdlc_flags & AHDLC_PFC)) {
// Send up packet
ppp_upcall((u16_t)ppp_rx_buffer[0],
(u8_t *)&ppp_rx_buffer[1],
(u16_t)(ahdlc_rx_count - 1));
}
else {....
估計這個錯誤還沒被發(fā)現(xiàn)的原因是Adam目前只測試了最簡單的情況下(無ACFC壓縮,無PFC壓縮), 但實際的電話線
要求帶寬很緊張,當然是能壓縮就壓縮啦, 在Linux下PPPD的默認設(shè)置里就可以看到.
d. UIP_LLH_LEN的定義是個常量, 我的實際情況是同時使用CS8900A(ethernet)和Modem(slip), 所以需要將這個
常量改成變量,實時中根據(jù)不同的接口用不用的值(14或0)
目前的問題PP可以連接通了, 不過感覺速度慢多了(當然也可理解: 31Kb如何能跟10Mb比呢), 我Ping的響應(yīng)慢到
了約120ms! 分析下來最大瓶頸在AHDLC的數(shù)字處理上, 完全是每個字節(jié)每個字節(jié)的處理--盡管我改進了用塊模式,
CRC算法也改成了最快的查表法,......-----要是MSP430能接上50MHz的工作頻率多好啊.
//----------------------------------------------------------------------------------------------
未完續(xù)待：）
