[En-Nut-Discussion] NutRegisterDevice().....
PragmaLab
info at pragmalab.nl
Thu Apr 10 11:26:35 CEST 2008
Not sure if someone took the trouble responding to my question below, but I
did figure it out already. My conclusion is that only (re-)mounting the
volume after a card was removed and inserted again indeed should be enough.
The low-level card reset and initialisation is also done in the
mount-function (PhatVolMount()). That was the clue I was looking for. So
when registering the blockdevice driver, the card is reset and initialised,
and shortly after this is done again in when mounting the volume.
The reason why my code failed when previously mounting the volume was the
fact that I was checking against a wrong return value. All works fine now.
Talking about SD/MMC cards (FAT16/FAT32), did somebody use the phat-file
system when dealing with large amounts of files (>200)? I ask since I will
have to optimize some parts of the code for large capacity cards (1GB and
above). Mounting a 1 GB FAT32 card takes ages in our application, just
because the PhatCountFreeClusters() routine needs to check 243345 clusters
to see if they can be used for writing later on. The most obvious
optimisation would be to cache the FAT32-table and only update the sectors
that were modified (during the flush). But that would take away way too much
RAM. Another optimisation might be to avoid reading the sector again for
each clusterentry (Phat32GetClusterLink()). You might as wel read a complete
sector and check the cluserentries in that one. But that would only speed up
the 'PhatCountFreeClusters()' routine, and not eg deleting a file that was
scattered around 400 clusters.
Since dealing with large capacity SD-cards is not unusual anymore, I suppose
we have to look for optimisations in the existing filesystem.
By the way, SD-HC cards use the SD specifications 2.0. I'm having to
re-design the mmcard.c for that as well. Only SD-HC cards have a capacity >2
GB
Any suggestions for optimisations?
Thanks,
best regards,
Rob van Lieshout
> Hello all,
>
> I'm currently busy implementing the NutOS phat-filesystem in
> our streaming audio application. Since we don't use the
> Ethernut 3 platform but some platform that comes close to
> Ethernut 1, I created a new blockdevice that deals with the
> AVR-SPI iso the nplmmc blockdevice driver. It seems to do the
> job (although I have to solve a speed issue). We need the
> filesystem to read and write songs from a SD/MMC card.
>
> My question is about the way to register the 2 devices that
> are involved when using the filesystem and the blockdevice driver.
> When starting the application, I will:
>
> 1) register devPhat0 (filesystem)
> 2) register devAvrMmc0 (block device driver)
> 3) mount the volume (first partition)
>
> That works OK and I can read and write from/to the card. But
> now if I remove the card and put it back, then what should I
> do? I cannot register the same device twice, so
> NutRegisterDevice will fail. Ofcourse I need to mount the
> card again since it might be a new or modified card. I would
> expect in that case only to do
>
> 3) mount the volume
>
> again. But that always fails. I do call "_close(g_hVolume)"
> when the card is removed (unmount).
>
> In general, since there is no NutUnregisterDevice(), I would
> expect that registering device drivers indeed only needs to
> be done once. But that implies that the initialisation
> function of the device driver is not allowed to read the
> fysical device and/or store info related to the device.
> Otherwise the initialisation needs to be done each time a new
> device is present (eg a new card is inserted), which (like I
> said) is not possible when using NutRegisterDevice.
>
> The reason that mounting the volume fails when called without
> registering the devices first, is probably because the
> SD-card is not reset/initialised again. This low level
> reset/initialisation is done in MmCardInit() but that one is
> in the device-init function.
>
> Anyone got an idea how to deal with cards that are
> re-insterted? Should I just call '(*dev->dev_init)(dev) ' ?
>
> thanks.
>
> Best regards,
>
> Rob van Lieshout
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 9 Apr 2008 10:47:06 +0200
> From: Szemz? Andr?s <saam at kometa.hu>
> Subject: Re: [En-Nut-Discussion] unreliable tcp
> To: "'Ethernut User Chat (English)'" <en-nut-discussion at egnite.de>
> Message-ID: <001501c89a1e$4aca56d0$0a01000a at saamnote>
> Content-Type: text/plain; charset="iso-8859-2"
>
> Hi,
>
> It seems increasing the lower boundary of the tcp
> retransmission time from 200ms to 2sec solved the problem, as
> the modul is online after 17h, without a single reconnect,
> compared with the 10-30min, without this modification in
> NutTcpCalcRtt() in tcputil.c
>
> Regards,
> Andras
>
> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de
> [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of
> Szemz? Andr?s
> Sent: Tuesday, April 08, 2008 5:29 PM
> To: 'Ethernut User Chat (English)'
> Subject: Re: [En-Nut-Discussion] unreliable tcp
>
> Hi guys,
>
> I captured the error situation and made a picture about it,
> maybe it will help somebody with better tcp/ip knowledge than
> I have to track down what is going on here :)
>
> http://www.esh.hu/nut_err.jpg
>
> (blue is the nut board, red is the linux server app)
>
> Thanks a lot
> Andras
>
> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de
> [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of
> Szemz? Andr?s
> Sent: Tuesday, April 08, 2008 2:44 PM
> To: 'Ethernut User Chat (English)'
> Subject: Re: [En-Nut-Discussion] unreliable tcp
>
>
> Harald, thanks your answer.
>
> Ok, it seems my english was not enough good to explain my
> problem completly
> :)
>
> Here is a connect handler,log sender and reader part of the
> main() thread:
>
> // Disconnected state, try to connect to Server
> if ( Timer.Num[TIMERCONNECT] == 0 ) {
> if ( SkyConnect(NetStatus.UsedServer) ==
> SKY_CONNECT_OK ) {
> NetStatus.TCPConnectCount=0;
>
> Timer.Num[TIMERCONNECT] = -1;
>
> Timer.Num[TIMERLOGALIVE] =
> MainConfig.TcpTestTime;
> NetStatus.TcpConnectionState =
> TCP_CONNECTED;
> if ( NetStatus.UsedServer != 0 ) {
>
> Timer.Num[PRIMARYIPRESTORE] = 900;
> } else {
>
> Timer.Num[PRIMARYIPRESTORE] = -1;
>
> }
> } else {
>
> NetStatus.TCPConnectCount++;
> Timer.Num[TIMERCONNECT] =
> CfgTCPConnectWaitTime;
> }
> }
>
> ....
>
> // Log sender
> if ( NetStatus.TcpConnectionState == TCP_CONNECTED ) {
> rc = SendELogPacket();
> if ( rc == -1) {
> Timer.Num[TIMERRESENDLOG] =
> CfgTCPResendLogTime; // reload timer
> NetStatus.TCPResendCount++;
> #ifdef _MODUL_DEBUG_
> puts("LOG_SEND_ERR");
> fflush(stdout);
> #endif
> }
> if ( rc == 1 ) {
> #ifdef _MODUL_DEBUG_
> puts("LOG_SEND_OK");
> fflush(stdout);
> #endif
> Timer.Num[TIMERRESENDLOG] = -1;
> NetStatus.TCPResendCount = 0;
> }
> if ( StatusSend == ENABLED ) {
> StatusSend = DISABLED;
> SkySendStatus(TCP_PACKET_STATUS_NEW,
> GetRandomNum());
> #ifdef _MODUL_DEBUG_
> printf("Statussend\r\n");
> fflush(stdout);
> #endif
> }
> }
>
> // TCP reader
> if ( NetStatus.TcpConnectionState == TCP_CONNECTED ) {
> tmo=100;
> NutTcpSetSockOpt(sock, SO_RCVTIMEO,
> &tmo, sizeof(tmo));
>
> rc = NutTcpReceive(sock, receivebuff,
> sizeof(receivebuff)); // see if we get
> something
> if ( rc == 16) {
>
> NetStatusIn(receivebuff);
> } else {
> if ( rc == -1) {
> // Cannot read socket
> #ifdef _MODUL_DEBUG_
> printf("READ ERROR,
> Disconnected\n"); fflush(stdout);
> #endif
> SkyDisconnect();
> NetStatus.TcpConnectionState =
> TCP_DISCONNECTED;
> Timer.Num[TIMERCONNECT] =
> CfgTCPConnectWaitTime; // set
> reconnect timer
> Timer.Num[TIMERLOGALIVE] = -1;
>
> }
> }
> tmo=2000;
> NutTcpSetSockOpt(sock, SO_RCVTIMEO,
> &tmo, sizeof(tmo));
> }
>
>
> I have about 38K free heap, so I think not that's the
> problem. I have no problems with app level reconnects, this
> code will deal with that.
> As I cannot post pictures, I put a retransmission debug to here:
> http://www.esh.hu/nut.jpg ( the blue is the nut board ) In
> this case, the nut board doesn't reconnect, becouse after a
> couple of retransmission it gets answered.
>
> In the case of error, the situation is that, after the
> retransmission (sending started by the
> SkySendStatus(TCP_PACKET_STATUS_NEW,
> GetRandomNum()); ), the server not send answer (PUSH ACK)
> back, but it send a FIN tcp packet, and this is why nut abort
> the socket.
>
> And after that,
>
> rc = NutTcpReceive(sock, receivebuff, sizeof(receivebuff));
> // see if we get something
>
> Return -1, what is ok, becouse the socket died.
>
> I'll make some debug picture about the disconnect evening.
>
> The question is, what can be wrong, as a very similar logic
> used ethernut based GPRS board can keep alive 2 days on this
> server, With the same code in local net this board can keep
> alive weeks, but on an adsl line this happens.
>
> Regards,
> Andras
>
> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de
> [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Harald Kipp
> Sent: Tuesday, April 08, 2008 1:22 PM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] unreliable tcp
>
> Hi Andr?s,
>
> Szemz? Andr?s wrote:
> >
> > I tried to use Commview to capture packets, and I see the sam7x
> > doesn't get answer within a time. Normally it sends a PUSH ACK, get
> > answer PUSH ACK, and send ACK. I see when there are
> problems, it tries
> > to send PUSH ACK with retransmission, and if it gets answer
> it doesn't
> reconnect.
> > My app's loop send a packet if it needs, than read back the answer,
> > and with 100ms RECV timeout tries to read to see, if he got some
> > incoming
> packets.
> > I see when there are reconnects, the NutTcpReceive() will
> return with
> > -1, wich means socket is disconnected. (sock->so_state will be 0 in
> > this case)
>
> The reconnect _must_ have been initiated by your application.
> The stack by itself will not reconnect. Probably because of
> the -1 returned by NutTcpReceive().
>
> NutTcpReceive will return -1 only in case of fatal errors (e.g. out of
> memory) or if it receives a connection close (FIN) or
> connection reject (RST).
>
> What does NutHeapAvailable() return?
>
>
> Harald
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>
> _____________ NOD32 3009 (20080408) Inform?ci? _____________
>
> Az ?zenetet a NOD32 antivirus system megvizsg?lta.
> http://www.nod32.hu
>
>
>
> ----
> Kometa 99 ?lelmiszeripari ZRt.
> Sz?khely: 7400 Kaposv?r, P?csi u. 67-69., Levelez?si c?m:
> 7401 Kaposv?r, Pf.
> 58
> C?gsz?m: Somogy Megyei B?r?s?g mint C?gb?r?s?g 14-10-300239
> Ad?sz?m: 13749619-2-44
> Telefon: 82/502-400, Fax: 82/502-415
> http://www.kometa.hu
> http://www.kemencessult.hu
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>
> _____________ NOD32 3009 (20080408) Inform?ci? _____________
>
> Az ?zenetet a NOD32 antivirus system megvizsg?lta.
> http://www.nod32.hu
>
>
>
> ----
> Kometa 99 ?lelmiszeripari ZRt.
> Sz?khely: 7400 Kaposv?r, P?csi u. 67-69., Levelez?si c?m:
> 7401 Kaposv?r, Pf.
> 58
> C?gsz?m: Somogy Megyei B?r?s?g mint C?gb?r?s?g 14-10-300239
> Ad?sz?m: 13749619-2-44
> Telefon: 82/502-400, Fax: 82/502-415
> http://www.kometa.hu
> http://www.kemencessult.hu
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>
> _____________ NOD32 3010 (20080408) Inform?ci? _____________
>
> Az ?zenetet a NOD32 antivirus system megvizsg?lta.
> http://www.nod32.hu
>
>
>
> ----
> Kometa 99 ?lelmiszeripari ZRt.
> Sz?khely: 7400 Kaposv?r, P?csi u. 67-69., Levelez?si c?m:
> 7401 Kaposv?r, Pf. 58
> C?gsz?m: Somogy Megyei B?r?s?g mint C?gb?r?s?g 14-10-300239
> Ad?sz?m: 13749619-2-44
> Telefon: 82/502-400, Fax: 82/502-415
> http://www.kometa.hu
> http://www.kemencessult.hu
>
>
>
> ------------------------------
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>
> End of En-Nut-Discussion Digest, Vol 54, Issue 14
> *************************************************
More information about the En-Nut-Discussion
mailing list