سڀني کي سلام.
ڪجھ وقت ا we اسان انهي بابت اسان ڪيئن منظم ڪيو هڪ SIP فون STM32F4-Discovery تي 1 MB ROM ۽ 192 KB RAM سان) جي بنياد تي . هتي اهو چوڻ گهرجي ته اهو نسخو گهٽ ۾ گهٽ هو ۽ ٻه فون سڌو سنئون سرور کان سواء ۽ صرف هڪ طرفي آواز جي منتقلي سان ڳنڍيل هئا. تنهن ڪري، اسان هڪ وڌيڪ مڪمل فون لانچ ڪرڻ جو فيصلو ڪيو سرور ذريعي هڪ ڪال سان، ٻنهي طرفن ۾ آواز ٽرانسميشن، پر ساڳئي وقت ننڍڙي ممڪن ياداشت جي سائيز ۾ رکو.
فون لاء، اهو هڪ ايپليڪيشن چونڊڻ جو فيصلو ڪيو ويو simple_pjsua PJSIP لائبريري جي حصي جي طور تي. هي هڪ گهٽ ۾ گهٽ ايپليڪيشن آهي جيڪا سرور تي رجسٽر ٿي سگهي ٿي، ڪال وصول ڪري ۽ جواب ڏئي سگهي ٿي. هيٺ آئون فوري طور تي وضاحت ڏيندس ته ان کي ڪيئن هلائڻ لاءِ STM32F7-Discovery.
ڪيئن هلڻ
- Embox ترتيب ڏيڻ
make confload-platform/pjsip/stm32f7cube - conf/mods.config فائل ۾ گهربل SIP اڪائونٽ سيٽ ڪريو.
include platform.pjsip.cmd.simple_pjsua_imported( sip_domain="server", sip_user="username", sip_passwd="password")جتي سرور هڪ SIP سرور آهي (مثال طور، sip.linphone.org)، کاتي جو نالو и پاسورڊ - کاتي جو نالو ۽ پاسورڊ.
- هڪ ٽيم جي طور تي ايمباڪس کي گڏ ڪرڻ ڪر. بورڊ جي firmware بابت اسان وٽ آهي ۽ اندر .
- ايمباڪس ڪنسول ۾ "simple_pjsua_imported" حڪم هلايو
00:00:12.870 pjsua_acc.c ....SIP outbound status for acc 0 is not active 00:00:12.884 pjsua_acc.c ....sip:[email protected]: registration success, status=200 (Registration succes 00:00:12.911 pjsua_acc.c ....Keep-alive timer started for acc 0, destination:91.121.209.194:5060, interval:15s - آخرڪار، اهو آڊيو آئوٽ ۾ اسپيڪر يا هيڊفونز داخل ڪرڻ لاء رهي ٿو، ۽ ڊسپلي جي اڳيان ٻه ننڍڙا MEMS مائڪروفونز ۾ ڳالهايو. اسان لينڪس کان ايپليڪيشن ذريعي سڏين ٿا simple_pjsua، pjsua. خير، يا توهان استعمال ڪري سگهو ٿا ڪنهن ٻئي قسم جي لينفون.
هي سڀ اسان تي بيان ڪيو ويو آهي .
اسان اتي ڪيئن پهتاسين
تنهن ڪري، شروعاتي طور تي سوال پيدا ٿيو هارڊويئر پليٽ فارم چونڊڻ بابت. جيئن ته اهو واضح هو ته STM32F4-Discovery ميموري مان مناسب نه هوندي، STM32F7-Discovery چونڊيو ويو. هن وٽ 1 MB فليش ڊرائيو ۽ 256 KB RAM آهي (+ 64 اسپيشل فاسٽ ميموري، جنهن کي اسين پڻ استعمال ڪنداسين). سرور ذريعي ڪالن لاءِ تمام گهڻو نه ، پر اسان ان ۾ فٽ ٿيڻ جي ڪوشش ڪرڻ جو فيصلو ڪيو.
پاڻ لاء مشروط طور تي، ڪم ڪيترن ئي مرحلن ۾ ورهايو ويو آهي:
- هلندڙ PJSIP QEMU تي. اهو ڊيبگنگ لاءِ آسان هو، ان سان گڏ اسان وٽ اڳ ۾ ئي AC97 ڪوڊيڪ لاءِ سپورٽ موجود هئي.
- QEMU ۽ STM32 تي وائس رڪارڊنگ ۽ پلے بیک.
- ايپليڪيشن پورٽنگ simple_pjsua PJSIP کان. اهو توهان کي SIP سرور تي رجسٽر ڪرڻ ۽ ڪال ڪرڻ جي اجازت ڏئي ٿو.
- پنهنجو پنهنجو Asterisk-based سرور ترتيب ڏيو ۽ ان تي ٽيسٽ ڪريو، پوءِ ڪوشش ڪريو ٻاهرين کي جيئن ته sip.linphone.org
ايمباڪس ۾ آواز Portaudio ذريعي ڪم ڪندو آهي، جيڪو پڻ PISIP ۾ استعمال ٿيندو آهي. پهريون مسئلو QEMU تي ظاهر ٿيو - WAV 44100 Hz تي سٺو ادا ڪيو، پر 8000 تي ڪجهه واضح طور تي غلط ٿي ويو. اهو ظاهر ٿيو ته اهو تعدد کي ترتيب ڏيڻ جو معاملو هو - ڊفالٽ طور اهو سامان ۾ 44100 هو، ۽ اهو پروگرام طور تبديل نه ڪيو.
هتي، شايد، اهو ٿورو وضاحت ڪرڻ جي قابل آهي ته عام طور تي آواز ڪيئن ادا ڪيو ويندو آهي. سائونڊ ڪارڊ کي سيٽ ڪري سگھجي ٿو ڪجھ پوائنٽر تي ياداشت جي ھڪڙي ٽڪري تي جنھن مان توھان کيڏڻ يا رڪارڊ ڪرڻ چاھيو ٿا اڳواٽ مقرر فريڪوئنسي تي. بفر ختم ٿيڻ کان پوء، هڪ مداخلت پيدا ٿئي ٿي ۽ عمل جاري آهي ايندڙ بفر سان. حقيقت اها آهي ته انهن بفرن کي اڳ ۾ ڀرڻ جي ضرورت آهي جڏهن ته پوئين هڪ کيڏيو پيو وڃي. اسان هن مسئلي کي وڌيڪ منهن ڪنداسين STM32F7 تي.
اڳيون، اسان هڪ سرور ڪرائي تي ورتو ۽ ان تي Asterisk لڳايو. جيئن ته تمام گهڻو ڊيبگ ڪرڻ ضروري هو، پر مان مائڪروفون ۾ گهڻو ڳالهائڻ نه چاهيندو هو، اهو خودڪار پلے بیک ۽ رڪارڊنگ ڪرڻ ضروري هو. ائين ڪرڻ لاءِ، اسان simple_pjsua پيچ ڪيو آهي ته جيئن توهان آڊيو ڊوائيسز جي بدران فائلون سلپ ڪري سگهو. PJSIP ۾، اهو بلڪل سادو ڪيو ويو آهي، ڇاڪاڻ ته انهن وٽ هڪ پورٽ جو تصور آهي، جيڪو يا ته هڪ ڊوائيس يا فائل ٿي سگهي ٿو. ۽ اهي بندرگاهن لچڪدار طور تي ٻين بندرگاهن سان ڳنڍيل هوندا. توهان اسان جي pjsip ۾ ڪوڊ ڏسي سگهو ٿا . نتيجي طور، اسڪيم هن ريت هئي. Asterisk سرور تي، مون ٻه اڪائونٽ شروع ڪيا - Linux ۽ Embox لاءِ. اڳيون، حڪم Embox تي عمل ڪيو ويو آهي simple_pjsua_imported, Embox سرور تي رجسٽر ٿيل آهي، جنهن کان پوء اسان لينڪس مان ايمباڪس کي سڏيندا آهيون. ڪنيڪشن جي وقت، اسان Asterisk سرور تي چيڪ ڪريون ٿا ته ڪنيڪشن قائم ٿي ويو آهي، ۽ ٿوري دير کان پوء اسان کي ايمباڪس ۾ لينڪس مان آواز ٻڌڻ گهرجي، ۽ لينڪس ۾ اسان فائل کي محفوظ ڪريون ٿا جيڪو ايمباڪس مان هلايو ويندو آهي.
ان کان پوءِ QEMU تي ڪم ڪيو، اسان منتقل ڪيو ويو پورٽنگ ڏانھن STM32F7-Discovery. پهريون مسئلو اهو آهي ته اهي 1 MB ROM ۾ مناسب نه هوندا آهن بغير ڪمپلر آپٽمائزيشن "-Os" تصوير جي سائيز لاءِ. ان ڪري اسان "-Os" شامل ڪيو. وڌيڪ، پيچ معذور C ++ لاء سپورٽ، تنهنڪري اهو صرف pjsua لاء گهربل آهي، ۽ اسان simple_pjsua استعمال ڪندا آهيون.
رکڻ کان پوءِ simple_pjsua، فيصلو ڪيو ته هاڻي ان کي لانچ ڪرڻ جو هڪ موقعو آهي. پر پهرين ان کي رڪارڊنگ ۽ آواز جي playback سان ڊيل ڪرڻ ضروري هو. سوال اهو آهي ته لکڻ ڪٿي آهي؟ اسان چونڊيو خارجي ياداشت - SDRAM (128 MB). توھان ھي پاڻ ڪوشش ڪري سگھو ٿا:
16000 Hz جي فريڪوئنسي ۽ 10 سيڪنڊن جي مدت سان اسٽيريو WAV ٺاهي ٿو:
record -r 16000 -c 2 -d 10000 -m C0000000
اسان وڃائي ڇڏيو:
play -m C0000000
هتي ٻه مسئلا آهن. ڪوڊيڪ سان پهريون - WM8994 استعمال ڪيو ويو آهي، ۽ ان ۾ هڪ سلاٽ وانگر شيء آهي، ۽ انهن مان 4 سلاٽ آهن، تنهنڪري، ڊفالٽ طور، جيڪڏهن اهو ترتيب نه ڏنو ويو آهي، پوء جڏهن آڊيو کيڏڻ، پلے بیک سڀني چئن سلاٽس ۾ ٿئي ٿو. . تنهن ڪري، 16000 Hz جي تعدد تي، اسان 8000 Hz حاصل ڪيو، پر 8000 Hz لاء، پلے بیک صرف ڪم نه ڪيو. جڏهن صرف سلاٽ 0 ۽ 2 چونڊيا ويا، اهو ڪم ڪيو جيئن ان کي گهرجي. ٻيو مسئلو STM32Cube ۾ آڊيو انٽرفيس جو هو، جنهن ۾ آڊيو ان پٽ SAI (سيريل آڊيو انٽرفيس) ذريعي آڊيو ان پٽ سان هم وقت سازي سان ڪم ڪندو آهي (مون کي تفصيل سمجهه ۾ نه آيو، پر اهو ظاهر ٿيو ته اهي هڪ عام ڪلاڪ شيئر ڪن ٿا ۽ جڏهن آڊيو آئوٽ شروع ڪيو ويو آهي، آڊيو ڪنهن به طرح ان جي داخلا سان ڳنڍيل آهي). اهو آهي، توهان انهن کي الڳ الڳ نه هلائي سگهو ٿا، تنهنڪري اسان هيٺ ڪيو آهي - آڊيو ان پٽ ۽ آڊيو آئوٽ هميشه ڪم ڪري ٿو (بشمول مداخلت ٺاهي رهيا آهن). پر جڏهن سسٽم ۾ ڪجھ به نه هلي رهيو آهي، تڏهن اسان صرف هڪ خالي بفر کي آڊيو آئوٽ ۾ سلپ ڪريون ٿا، ۽ جڏهن پلے بیک شروع ٿئي ٿو، اسان ايمانداري سان ان کي ڀرڻ شروع ڪريون ٿا.
اڳتي هلي، اسان کي اها حقيقت محسوس ٿي ته آواز جي رڪارڊنگ دوران آواز بلڪل خاموش هو. اهو حقيقت جي ڪري آهي ته MEMS مائڪروفونون STM32F7-Discovery تي ڪنهن به طرح 16000 Hz کان هيٺ تعدد تي سٺو ڪم نه ڪندا آهن. تنهن ڪري، اسان 16000 Hz مقرر ڪيو، جيتوڻيڪ 8000 Hz اچي ٿو. هن کي ڪرڻ لاء، جيتوڻيڪ، اهو ضروري هو ته هڪ سافٽ ويئر جي بدلي کي هڪ فريڪوئنسي کي ٻئي ۾ شامل ڪيو وڃي.
اڳيون، مون کي ڍير جي سائيز کي وڌائڻو هو، جيڪو رام ۾ واقع آهي. اسان جي حسابن مطابق، pjsip اٽڪل 190 KB گھربل آھي، ۽ اسان وٽ صرف 100 KB باقي آھي. هتي مون کي ڪجهه خارجي ياداشت استعمال ڪرڻو پيو - SDRAM (اٽڪل 128 KB).
انهن سڀني تبديلين کان پوء، مون لينڪس ۽ ايمباڪس جي وچ ۾ پهريون پيڪيجز ڏٺو، ۽ مون آواز ٻڌو! پر آواز خوفناڪ هو، بلڪل به ساڳيو نه هو جهڙو QEMU تي، اهو ڪجهه به ڪرڻ ناممڪن هو. پوءِ اسان سوچيو ته معاملو ڇا ٿي سگهي ٿو. ڊيبگنگ ڏيکاري ٿي ته ايمباڪس وٽ صرف آڊيو بفرز کي ڀرڻ / ان لوڊ ڪرڻ جو وقت ناهي. جڏهن ته pjsip هڪ فريم کي پروسيس ڪري رهيو هو، 2 رڪاوٽون بفر پروسيسنگ جي مڪمل ٿيڻ بابت واقع ٿيڻ جو وقت هو، جيڪو تمام گهڻو آهي. رفتار لاءِ پهريون فڪر مرتب ڪندڙ اصلاح هو، پر اهو اڳ ۾ ئي PJSIP ۾ شامل هو. ٻيو هڪ هارڊويئر سچل پوائنٽ آهي، اسان ان بابت ڳالهايو . پر جيئن ته مشق ڏيکاريو ويو آهي، FPU رفتار ۾ هڪ اهم اضافو نه ڏنو. ايندڙ قدم موضوعن کي ترجيح ڏيڻ هو. ايمباڪس وٽ مختلف شيڊولنگ حڪمت عمليون آهن، ۽ مون هڪ کي شامل ڪيو آهي جيڪا ترجيحن جي حمايت ڪري ٿي ۽ آڊيو اسٽريمز کي اعليٰ ترجيح تي سيٽ ڪري ٿي. اهو پڻ مدد نه ڪيو.
اڳيون خيال اهو هو ته اسان خارجي ياداشت سان ڪم ڪري رهيا آهيون ۽ اهو سٺو لڳندو ته اتي اڏاوتون منتقل ڪيون وڃن جيڪي گهڻو ڪري پهچن ٿيون. مون هڪ ابتدائي تجزيو ڪيو ته ڪڏهن ۽ ڪهڙي تحت simple_pjsua ياداشت مختص ڪري ٿي. اهو ظاهر ٿيو ته 190 Kb مان، پهرين 90 Kb PJSIP جي اندروني ضرورتن لاء مختص ڪيا ويا آهن ۽ انهن کي گهڻو ڪري نه پهچايو ويندو آهي. ان کان علاوه، هڪ ايندڙ ڪال دوران، pjsua_call_answer فنڪشن سڏيو ويندو آهي، جنهن ۾ بفرز کي پوء ايندڙ ۽ ٻاهرئين فريم سان ڪم ڪرڻ لاء مختص ڪيا ويندا آهن. اهو اڃا تائين اٽڪل 100 Kb هو. ۽ پوء اسان هيٺيان ڪيو. ڪال جي وقت تائين، اسان ڊيٽا کي خارجي ياداشت ۾ رکون ٿا. جيئن ئي ڪال، اسان فوري طور تي ڍير کي هڪ ٻئي سان تبديل ڪريون ٿا - رام ۾. اهڙيء طرح، سڀ "گرم" ڊيٽا تيز ۽ وڌيڪ متوقع ياداشت ڏانهن منتقل ڪيو ويو.
نتيجي طور، هي سڀ گڏجي ان کي لانچ ڪرڻ ممڪن بڻائي simple_pjsua ۽ توهان جي سرور ذريعي ڪال ڪريو. ۽ پوءِ ٻين سرورن ذريعي جيئن ته sip.linphone.org.
پهچڻ
نتيجي طور، ان کي لانچ ڪرڻ ممڪن هو simple_pjsua سرور ذريعي ٻنهي طرفن ۾ آواز جي منتقلي سان. اضافي طور تي 128 KB SDRAM خرچ ڪرڻ جو مسئلو ٿورو وڌيڪ طاقتور Cortex-M7 استعمال ڪندي حل ڪري سگهجي ٿو (مثال طور، STM32F769NI 512 KB RAM سان)، پر ساڳئي وقت، اسان اڃا تائين 256 ۾ حاصل ڪرڻ جي اميد نه ڇڏي آهي. KB 🙂 اسان کي خوشي ٿيندي جيڪڏهن ڪنهن کي دلچسپي آهي، يا اڃا بهتر، ڪوشش ڪريو. سڀ ذريعا، هميشه وانگر، اسان ۾ آهن .
جو ذريعو: www.habr.com