こんにちは
ソフトな道をほのぼのと今日も歩きます。
今日は2020/04/28です。
在宅の営業マンから今日の午前中にソース解析してLAN対応できそうか返事をくれと
言われました。
そのソースは昨日の夜に送られてきたというもので、どこから手を付けたものかと
思案しました。
中身見ても良くわからないし、OSは実績のないものだし、という状況での判断です。
結論としては、やれることだけやろう。。。。
出来ること：
1. グローバル検索で単語"LAN"、"Ether"で検索する。
2. 検索でヒットしたソースパスをメモしておく。
3. "2"でヒットしたパスのフォルダ内のソースファイル名を見てみる。
また、ファイル内を見てみる。
4. コメント、関数名をみていく。
これである程度は内容は理解できた気になれました。
営業さんには、見積もり条件を惜しげもなく出すようにすることで
対応できると回答しました。
--------------------------------------------
以上です。
こんにちは
ソフトな道をほのぼのと今日も歩きます。
今回は、現在行っている案件でエージングするとたまに
応答待ちになる現象ことについて自問自答したいと思います。
今回は、あくまで自問自答で、解決はしていません。
さて、現象の出る頻度としましては、２日に１度の状態です。
音声案内をしていると、音声の区切りで音声案内がストップしてしまうのです。
また、ユーザーの環境で出るのですが、私のところでは全く出てませんでした。
操作が異なるので、とりあえず同じ操作にしようと思ったのですが、、、
エージング環境に敷居が高い！
ユーザからどういったときに現象が出るのかを詳細を聞いて
同じような操作をテスト関数として、
つらつら書いてみましたが、全く現象が出ず。
スレッド３種もガシガシわざと入れるようにして、MAINプログラムを
いじめるかのようにしてみたのですが全く現象が出ませんでした。
(スレッドは全部で３種あります。GPIO、通信２系統)
もしかしたら、通信やセンサ類をもっと発生させないといけないのかもしれません。
ソフト的だと、まさかのタイミングを作り出すのが難しいのかもしれませんね。
ハード的なものを入れることで意図しないタイミングで送受信やら
スレッド発生等させていこうと思います。
--------------------------------------------
以上です。
在宅期間が5月末までになりました。
まだ給料が出るからよいものの、流れは悪い方向に行っているように思えます。
今後、お店のレジは店員さんがしゃべるのではなく、ロボットが対応してくれると感染率も少なくて
私は安心します。。。。やはり悪い方向にしか行かないな。
こんにちは
ソフトな道をほのぼのと今日も歩きます。
今回は、ハードウェアの回路図が私宛に送られてきた時に
いつも何気なく行っている内容について記載したいと思います。
それは、Excel表に、GPIOの番号とその機能の割り当てをまとめるということです。
この表があると何がうれしいのか？
GPIOの入出力が正しいかどうかハードの人に聞くことができる
通信に使用しているマルチプレクスされたポートを確認できる。
ソースを組むときにGPIO番号がすぐに分かる
ポートの制御し忘れを防止できる。
記憶喪失になっても、文書化されているので大丈夫。
・・・
その他、沢山あります。
書き方はCPU毎に異なるので適切に書けばよいのですが、最近の案件だと
以下のような内容(例)です。
ボール配置、端子名、機能１、機能２、機能３、信号選択、I/O、GPIO番号、備考です。
こちらを列の箇所に記載します。
例を挙げると、以下です。
--------------------------------------------
ボール配置:D18
端子名:EB0_DATA18、
機能１:―
機能２:PIN1[2]
機能３:―
1つのGPIOに対して複数の機能があったりする（マルチプレクス、マルチファンクションなど、CPUのマニュアルによって用語が異なります。）ので、
その機能として何があるのかを
書き込みます。
用途:UART0_RXD
I/O: CPUから見て初期値のgpio入出力情報
GPIO番号: LinuxだとGPIO2_6などだと、70で扱ったりします。
(32*2+6=70)
備考: 説明です。
--------------------------------------------
以上です。
在宅中ですが、残業は申請しずらいようになり、
給料は減らされる。しかし、仕事は納期守れといわれる。
仕事も大事ですが、個人の市場価値を高める方にシフトしましょう。
こんにちは
ソフトな道をほのぼのと今日も歩きます。
今回は、Linux アプリ(C言語)でファイルリードする際、
ファイル最後に達したかどうか判定するのですが
その処理で、もしかすると、正しく判断できていないのでは？と思ったので
調べてみました。
これによって引き起こされていた現象は、
数十時間はアプリは動作するが、いきなりアプリがハングといった動作です。
推測している動作。
アプリ実行
→ファイルリード実行
→ファイル最後を超えるが、リードなのでそれとなく動いてしまう。
→スレッド動作が割り込んでくる。
→絶妙なタイミングでたまたま入って、リードしていたデータが変わる。
→スレッド処理から復帰する。
→データが化けた状態で処理を続行する為、リードデータを使用したサウンドなどの処理で誤動作
→アプリハング
下記参考までにサンプルです。
(一部、抜粋し、加工したものですので、動作するかは保証いたしかねます。)
===============================================================
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#define NORMALEND 0
int test(UCHAR* name, UINT line, char *result, UINT maxsize)
{
FILE *fp;
int i= 0;
UCHAR chr[2];
UINT length= 0;
int count;
struct stat statbuf;
if(stat(name, &statbuf) != 0)
{// error
printf("[file] Error: stat() (%s %d) \n", __FILE__ , __LINE__ );
}
printf("[file] file size: %d (%s %d) \n ", (int)statbuf.st_size, __FILE__ , __LINE__ );
//---------
// ファイルリードの都度 countと比較していく
fp = fopen(name, "rb");
if (fp == NULL) {
return ERROR_OPEN_FILE;
}
count= 0;
/* ファイルの終端まで文字を読み取り表示する */
for (i= 0; i< 0x1000; i++)
{
while(1)
{
if(count>= statbuf.st_size)
{// サイズを超えたか？
fclose(fp);
return -1;
}
chr[0] = fgetc(fp);count++;
if(count>= statbuf.st_size)
{
fclose(fp);
return -1;
}
chr[1] = fgetc(fp);count++;
if(chr[0]== 0 && chr[1]==0)
{// ファイルの最後に到達(指定行見つかりませんでした。)
// UTF-16だったので、2バイト分で見ています。
fclose(fp);
return -1;
}
else if(chr[0] == LF_CODE && chr[1] == 00)
{// 改行コード検出
break;
}
}
}
…
return NORMALEND;
}
[環境]
私の使用環境は VMware 上でUbuntu14.04を使用しています。
コンパイラ: arm-linux-gnueabihf-gcc
近くの商店街は大繁盛でした。
（私は遠くから確認しただけです。）
先進国なので、
ソーシャルディスタンス系の開発とか、やりようがあるんじゃないかと
思いました。
・店を検索した時に人がいないところを教えてくれる。
・お弁当を自動販売機にする。
どうですか？
こんにちは
ソフトな道をほのぼのと今日も歩きます。
今回は、Linux アプリでSDカード上のファイルへライトした直後に
SDカードを抜くと、SDカードライトしたデータが反映されない
現象になっていました。
ライトしたはずのデータが、文字化けしたり、
途中からごっそりなくなっている。そういうような状態でした。
こちらの現象を解決できたのでアップします。
以下、非常に役に立ったリンク先になります。
http://oswald.hatenablog.com/entry/20101223/1293064800
ポイントはfwrite()した後に、以下3つを行うことでした。
1. fileno()より"fdatasync()"用の番号を取得する。
2. fflush()を行う。
3. fdatasync()を行う。
です。
下記参考サンプルです。
===============================================================
#include <unistd.h>
#define NORMALEND 0
int test(void)
{
FILE *fp; //ファイルポインター
unsigned char buf[30];
int rtc;
memset(buf, 0, sizeof(buf));
fp = fopen("/var/test.log","a"); //ファイルを開く
int fp_num = fileno(fp);
sprintf(buf, "dummy data %d \n", 1 );
length= strlen(buf);
fwrite(buf, length, 1, fp);
rtc = fflush(fp);
rtc= fdatasync(fp_num);
fclose(fp); //ファイルを閉じる
return NORMALEND;
}
[環境]
私の使用環境は VMware 上でUbuntu14.04を使用しています。
コンパイラ: arm-linux-gnueabihf-gcc
在宅ワークを開始しました。
残業代は出ないし、出るにしても非常に面倒な手続きが必要のようです。
ただ、外食もせず、子供の塾代やお稽古事もない状態なので
収支としてはトントンだと思います。
政府の30万円愚策はやらなくていいから、
所得税を控除してもらいたいです。
僕らの税金を返してください。
こんにちは
ソフトな道をほのぼのと今日も歩きます。
今回は、前回の逝ってしまう原因調査の続きです。
スレッドがsnd_pcm_writei()実行中に”-EBADFD”が入ってくると、
そのエラーに対する処理は入っていない為
リトライ発生という無限ループに入っていました。
調査したところ、そもそも、EBADFD自体でるのがNGということが分かりました。
スレッド内でクローズ処理をしていたのですが、
オープン失敗に対してもクローズ処理をしているところがありました。
要するにnullに対してのクローズ処理。
お恥ずかしい限りですw
また、FDファイルディスクリプタ自体が不定な箇所がありました。
fopen()とopen()のエラー判定は違うことに対処できていなかったです。
fopen()の失敗はNULL(0)
open()の失敗は-1
です。
FDはそれぞれ1以上、0以上となるので、エラー判定はしっかりしないと、数百回に一回の不具合につながります。
今回は以上です。
[環境]
私の使用環境は VMware 上でUbuntu14.04を使用しています。
コンパイラ: arm-linux-gnueabihf-gcc
今日から新入社員が入ってきます。
電車内でおしゃべりしているが、飛沫感染させないようにしてもらいたいですね。
