ElphelWiki - User contributions [en]

Talk:10349

2008-06-05T20:18:51Z

Ekratzer:

About the plex panel for developer case: why do it transparent ? Is where a special reason ? It's not very good for image quality to have light inside the case. --[[User:Polto|Polto]] 11:36, 14 October 2007 (GMT)

Transparent? Why? Is it written anywhere?--[[User:Andrey.filippov|Andrey.filippov]] 16:29, 14 October 2007 (CDT)

Yep, in [[10349#Body_of_camera_for_developers]] --[[User:Polto|Polto]] 08:55, 15 October 2007 (GMT)

I looked at the images only, did not read the text. You are right there is no sense to have transparent cover - it will allow stray light to reach the sensor.--[[User:Andrey.filippov|Andrey.filippov]] 03:10, 15 October 2007 (CDT)

No problem, we can use black plex.
--[[User:Dimon|dimon]] 21:11, 16 October 2007 (CDT)

Will the RS323 socket fit in the camera on top of both 10353 & 10349 ?
--[[User:Polto|Polto]] 03:45, 1 November 2007 (GMT)

Should be yes. I measure distance between PCB of 10349 with 10353 to top of cover on 3D model. This is 11.5 mm. For common socket of RS232 this distance is good.

That is my comment. --[[User:Dimon|dimon]] 22:17, 31 October 2007 (CDT)

Are these boards available for purchase or testing? --[[User:Ekratzer|Ekratzer]] 15:51, 12 November 2007 (CST)

Yes, we just do not have our costs (and so the price) ready yet.

Andrey

I am trying to use CF + DMA on 10353 boards. I have tried many CF cards and they work fine under normal PIO modes, but not with DMA, even when tweaking parameters with hdparm. I have also found that some hard drives work with DMA, and some do not, leading me to believe that maybe there is some CF type that will work. Has anybody successfully use CF + DMA on the 353's ETRAX FS?

--[[User:Ekratzer|Ekratzer]] 11:41, 28 January 2008 (CST)

That is very interesting. Can you please provide links to the exact circuit diagrams how you connect CF cards as well as to the source code you are using?--[[User:Andrey.filippov|Andrey.filippov]] 13:08, 28 January 2008 (CST)

Andrey, I have uploaded our circuit diagram to [http://wiki.elphel.com/images/4/46/Rz_353_cf_interface.pdf rz_353_cf_interface.pdf]
As far as source code, we simply have a script that runs as last part of runlevel 3. It disables DMA (/sbin/hdparm -m 0 -c 1 -d 0 /dev/hda) and mounts /dev/hda1 on the filesystem. If we do not disable DMA, then the kernel just endlessly loops on dma timeouts when we try to access the CF. --[[User:Ekratzer|Ekratzer]] 17:06, 29 January 2008 (CST)

'''It seems the problem with the your board is the lack of pullup/pulldown resistors on the INTRQ, DMARQ, IORDY lines'''.
Those resistors are intentionally omitted on the [[10353]] board - the same I/O lines can be used for different purposes,
not just the IDE port.
Hmm. DMARQ and DMACK are not shown on your diagram at all. Without the pulldown resistor on the DMARQ line
the 353 camera software will not initialize IDE driver, it uses it to determine that IDE capable add-on board
is attached to the 10353--[[User:Andrey.filippov|Andrey.filippov]] 17:55, 18 February 2008 (CST).

Hmm, ok. I had disabled the check for _353_io_board_present in ide-cris.c to get past this problem (no pull down in DMARQ.) --[[User:Ekratzer|Ekratzer]] 07:22, 25 February 2008 (CST)

I see, thank you. By the end of the week I should have all the components for the 10369 board and I will put it together ans start testing with the CF cards (and SATA also). Did you try different brands/models? --[[User:Andrey.filippov|Andrey.filippov]] 17:41, 29 January 2008 (CST)

I have tested with a variety of Transcend and Kingston CF, ranging from 512MB to 8GB, and speed ratings from 45x to 266x. I have also tested 2 hard drives, both Hitachi Travelstar. Model #HTS541040G9AT00 works well with DMA (over 15MB/s sustained write throughput with little CPU load), and model #HTC424020F7AT00 behaves the same as the CF (no DMA.) I have tested all these CF and hard drives on 5 of our CF interface boards, with results being the same for each. Interesting note, the kernel always detects and tries to enable DMA in cris_ide_init(), regardless of "ide=nodma" init option. It times out once after about 8 seconds, and then I can disable DMA and mount normally with PIO modes. --[[User:Ekratzer|Ekratzer]] 14:12, 30 January 2008 (CST)

Also, I forgot to mention that I have also tried a couple IBM 4GB CF microdrives, with results being the same (no DMA.) --[[User:Ekratzer|Ekratzer]] 14:18, 30 January 2008 (CST)

I see. Hope to have some results with the 10369 next week and see if I'll get the same problem. So far I tried several HDDs (no CF yet) and they worked fine (to be honest I even do not know if the DMA is enabled) - the recording speed for large files was around 15MB/s. With the 10369 I'll get there with the oscilloscope and add some "pritnk()" to the driver - I believe it should work faster.--[[User:Andrey.filippov|Andrey.filippov]] 15:08, 30 January 2008 (CST)

----

I tried some CF card (QMemory 16GB) with 10369 (SATA HDD works just fine) and did find a problem with DMA. The CF card releases DMARQ after transferring just 1024 bytes (512 words) and does not reassert it when asked for 16 sectors to read during initialization. That leads to DMA timeout.

To fix it we need to limit number of sectors that are requested in a single DMA command.

--[[User:Andrey.filippov|Andrey.filippov]] 04:39, 17 February 2008 (CST)

''More details on the QMemory 16GB CF card''. When that data is read using DMA (and the card reports it has it) the data transferred (until the CF drops DMARQ forever) is always 1024 bytes (2*512) - equal to the reported buffer size. That 1024 does not depend on the number of sector requested - it can be 1 (so 512 bytes were expected) or >2 (i.e. 16) - still DMA dies after 1024 bytes. Next problem - this CF card does not assert INTRQ after the READ DMA, and the driver reies on it to finish READ DMA command (that IRQ is required by the ATA specifications). I tried to tweak other parameters, like multsect with SET MULTIPLE MODE (it is designed fro READ MULTIPLE only) - still no interrupts at the end of READ DMA command.

I just ordered a bunch of different brands CF cards to test, if they will exhibit similar problems (CF+DMA shows multiple problems in Google search) the solution will be to add interrupt on the DMA (internal processor DMA, not ATA DMA) that will trigger after ETRAX FS receives requested amount of data in addition to ATA interrupts (derived from the INTRQ signal of the ATA bus) and limit number of sectors during a single READ DMA command. It will require changes in both ide-cris.c and higher level ide driver, as the current one does not rely on internal DMA interrupt, only on the ATA one.--[[User:Andrey.filippov|Andrey.filippov]] 14:48, 18 February 2008 (CST)

Opening the CF card revealed SM222TF controller chip, same as for the card described [http://www.nextwarehouse.com/DS/iERP/ATA_SMB_DMA.pdf here]. It claims to support DMA, but the READ DMA/WRITE DMA commands are missing in the table of supported ones.

----

Will using the processor DMA instead of ATA require any changes to the circuit? If so, we can implement and test any changes. We will be making changes to fix INTRQ, DMARQ, IORDY, and DMACK lines shortly. --[[User:Ekratzer|Ekratzer]] 08:05, 25 February 2008 (CST)

----

Interesting page for CF statistics. Shows which cards support DMA/PIO/etc: [http://www.hjreggel.net/cardspeed/speed-cards.html CARDSPEED - Card Readers and Memory Cards] --[[User:Ekratzer|Ekratzer]] 09:19, 25 February 2008 (CST)

----

Another card Transcend 32GB has SM223TF inside - exactly the same problem. Technical support from the chip manufacturer stopped replying my emails after I described the problem. They just mentioned that "they had some DMA problems with older firmware" :-( --[[User:Andrey.filippov|Andrey.filippov]] 13:29, 7 April 2008 (CDT)

----

I am trying to move away from CF for our next board revision, since we cannot spare CPU for PIO mode transfers anymore. I have found some smaller IDE solid-state flash drives that have similar storage density to CF, like this drive from Transcend: [http://www.transcendusa.com/Products/ModDetail.asp?ModNo=184&SpNo=3&LangNo=0 1.0" IDE SSD]. I will be ordering and testing on the bench soon.. will post results here --[[User:Ekratzer|Ekratzer]] 15:10, 22 April 2008 (CDT)

----

I opened another CF card (32GB Transcend) - it had SM223 controller - same problem. So far the only one that we tried and that '''works with DMA is Sandisk Extreme(R) III 2.0GB''' --[[User:Andrey.filippov|Andrey.filippov]] 12:48, 23 April 2008 (CDT)

When working with the Sandisk Extreme III, what where the DMACK- and DMARQ- lines tied to on the CF side? I am curious because after some research, it appears that the CF standard does not require DMA operation in TrueIDE mode (just PIO.) However, some cards are known to work regardless. The [http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/IDE_To_CF_Adapter.htm ACS IDE to CF adapeter] has DMACK- tied to REG- and DMARQ- tied to INPACK- and recommends the use of Sandisk CF cards. Would you post the CF<->IDE signal mappings that worked with the Sandisk Extreme III? --[[User:Ekratzer|Ekratzer]] 15:18, 5 June 2008 (CDT)

Talk:10349

2008-04-22T20:10:10Z

Ekratzer:

About the plex panel for developer case: why do it transparent ? Is where a special reason ? It's not very good for image quality to have light inside the case. --[[User:Polto|Polto]] 11:36, 14 October 2007 (GMT)

Transparent? Why? Is it written anywhere?--[[User:Andrey.filippov|Andrey.filippov]] 16:29, 14 October 2007 (CDT)

Yep, in [[10349#Body_of_camera_for_developers]] --[[User:Polto|Polto]] 08:55, 15 October 2007 (GMT)

I looked at the images only, did not read the text. You are right there is no sense to have transparent cover - it will allow stray light to reach the sensor.--[[User:Andrey.filippov|Andrey.filippov]] 03:10, 15 October 2007 (CDT)

No problem, we can use black plex.
--[[User:Dimon|dimon]] 21:11, 16 October 2007 (CDT)

Will the RS323 socket fit in the camera on top of both 10353 & 10349 ?
--[[User:Polto|Polto]] 03:45, 1 November 2007 (GMT)

Should be yes. I measure distance between PCB of 10349 with 10353 to top of cover on 3D model. This is 11.5 mm. For common socket of RS232 this distance is good.

That is my comment. --[[User:Dimon|dimon]] 22:17, 31 October 2007 (CDT)

Are these boards available for purchase or testing? --[[User:Ekratzer|Ekratzer]] 15:51, 12 November 2007 (CST)

Yes, we just do not have our costs (and so the price) ready yet.

Andrey

I am trying to use CF + DMA on 10353 boards. I have tried many CF cards and they work fine under normal PIO modes, but not with DMA, even when tweaking parameters with hdparm. I have also found that some hard drives work with DMA, and some do not, leading me to believe that maybe there is some CF type that will work. Has anybody successfully use CF + DMA on the 353's ETRAX FS?

--[[User:Ekratzer|Ekratzer]] 11:41, 28 January 2008 (CST)

That is very interesting. Can you please provide links to the exact circuit diagrams how you connect CF cards as well as to the source code you are using?--[[User:Andrey.filippov|Andrey.filippov]] 13:08, 28 January 2008 (CST)

Andrey, I have uploaded our circuit diagram to [http://wiki.elphel.com/images/4/46/Rz_353_cf_interface.pdf rz_353_cf_interface.pdf]
As far as source code, we simply have a script that runs as last part of runlevel 3. It disables DMA (/sbin/hdparm -m 0 -c 1 -d 0 /dev/hda) and mounts /dev/hda1 on the filesystem. If we do not disable DMA, then the kernel just endlessly loops on dma timeouts when we try to access the CF. --[[User:Ekratzer|Ekratzer]] 17:06, 29 January 2008 (CST)

'''It seems the problem with the your board is the lack of pullup/pulldown resistors on the INTRQ, DMARQ, IORDY lines'''.
Those resistors are intentionally omitted on the [[10353]] board - the same I/O lines can be used for different purposes,
not just the IDE port.
Hmm. DMARQ and DMACK are not shown on your diagram at all. Without the pulldown resistor on the DMARQ line
the 353 camera software will not initialize IDE driver, it uses it to determine that IDE capable add-on board
is attached to the 10353--[[User:Andrey.filippov|Andrey.filippov]] 17:55, 18 February 2008 (CST).

Hmm, ok. I had disabled the check for _353_io_board_present in ide-cris.c to get past this problem (no pull down in DMARQ.) --[[User:Ekratzer|Ekratzer]] 07:22, 25 February 2008 (CST)

I see, thank you. By the end of the week I should have all the components for the 10369 board and I will put it together ans start testing with the CF cards (and SATA also). Did you try different brands/models? --[[User:Andrey.filippov|Andrey.filippov]] 17:41, 29 January 2008 (CST)

I have tested with a variety of Transcend and Kingston CF, ranging from 512MB to 8GB, and speed ratings from 45x to 266x. I have also tested 2 hard drives, both Hitachi Travelstar. Model #HTS541040G9AT00 works well with DMA (over 15MB/s sustained write throughput with little CPU load), and model #HTC424020F7AT00 behaves the same as the CF (no DMA.) I have tested all these CF and hard drives on 5 of our CF interface boards, with results being the same for each. Interesting note, the kernel always detects and tries to enable DMA in cris_ide_init(), regardless of "ide=nodma" init option. It times out once after about 8 seconds, and then I can disable DMA and mount normally with PIO modes. --[[User:Ekratzer|Ekratzer]] 14:12, 30 January 2008 (CST)

Also, I forgot to mention that I have also tried a couple IBM 4GB CF microdrives, with results being the same (no DMA.) --[[User:Ekratzer|Ekratzer]] 14:18, 30 January 2008 (CST)

I see. Hope to have some results with the 10369 next week and see if I'll get the same problem. So far I tried several HDDs (no CF yet) and they worked fine (to be honest I even do not know if the DMA is enabled) - the recording speed for large files was around 15MB/s. With the 10369 I'll get there with the oscilloscope and add some "pritnk()" to the driver - I believe it should work faster.--[[User:Andrey.filippov|Andrey.filippov]] 15:08, 30 January 2008 (CST)

----

I tried some CF card (QMemory 16GB) with 10369 (SATA HDD works just fine) and did find a problem with DMA. The CF card releases DMARQ after transferring just 1024 bytes (512 words) and does not reassert it when asked for 16 sectors to read during initialization. That leads to DMA timeout.

To fix it we need to limit number of sectors that are requested in a single DMA command.

--[[User:Andrey.filippov|Andrey.filippov]] 04:39, 17 February 2008 (CST)

''More details on the QMemory 16GB CF card''. When that data is read using DMA (and the card reports it has it) the data transferred (until the CF drops DMARQ forever) is always 1024 bytes (2*512) - equal to the reported buffer size. That 1024 does not depend on the number of sector requested - it can be 1 (so 512 bytes were expected) or >2 (i.e. 16) - still DMA dies after 1024 bytes. Next problem - this CF card does not assert INTRQ after the READ DMA, and the driver reies on it to finish READ DMA command (that IRQ is required by the ATA specifications). I tried to tweak other parameters, like multsect with SET MULTIPLE MODE (it is designed fro READ MULTIPLE only) - still no interrupts at the end of READ DMA command.

I just ordered a bunch of different brands CF cards to test, if they will exhibit similar problems (CF+DMA shows multiple problems in Google search) the solution will be to add interrupt on the DMA (internal processor DMA, not ATA DMA) that will trigger after ETRAX FS receives requested amount of data in addition to ATA interrupts (derived from the INTRQ signal of the ATA bus) and limit number of sectors during a single READ DMA command. It will require changes in both ide-cris.c and higher level ide driver, as the current one does not rely on internal DMA interrupt, only on the ATA one.--[[User:Andrey.filippov|Andrey.filippov]] 14:48, 18 February 2008 (CST)

Opening the CF card revealed SM222TF controller chip, same as for the card described [http://www.nextwarehouse.com/DS/iERP/ATA_SMB_DMA.pdf here]. It claims to support DMA, but the READ DMA/WRITE DMA commands are missing in the table of supported ones.

Will using the processor DMA instead of ATA require any changes to the circuit? If so, we can implement and test any changes. We will be making changes to fix INTRQ, DMARQ, IORDY, and DMACK lines shortly. --[[User:Ekratzer|Ekratzer]] 08:05, 25 February 2008 (CST)

Interesting page for CF statistics. Shows which cards support DMA/PIO/etc: [http://www.hjreggel.net/cardspeed/speed-cards.html CARDSPEED - Card Readers and Memory Cards] --[[User:Ekratzer|Ekratzer]] 09:19, 25 February 2008 (CST)

Another card Transcend 32GB has SM223TF inside - exactly the same problem. Technical support from the chip manufacturer stopped replying my emails after I described the problem. They just mentioned that "they had some DMA problems with older firmware" :-( --[[User:Andrey.filippov|Andrey.filippov]] 13:29, 7 April 2008 (CDT)

I am trying to move away from CF for our next board revision, since we cannot spare CPU for PIO mode transfers anymore. I have found some smaller IDE solid-state flash drives that have similar storage density to CF, like this drive from Transcend: [http://www.transcendusa.com/Products/ModDetail.asp?ModNo=184&SpNo=3&LangNo=0 1.0" IDE SSD]. I will be ordering and testing on the bench soon.. will post results here --[[User:Ekratzer|Ekratzer]] 15:10, 22 April 2008 (CDT)

Talk:10349

2008-02-25T15:19:05Z

Ekratzer:

About the plex panel for developer case: why do it transparent ? Is where a special reason ? It's not very good for image quality to have light inside the case. --[[User:Polto|Polto]] 11:36, 14 October 2007 (GMT)

Transparent? Why? Is it written anywhere?--[[User:Andrey.filippov|Andrey.filippov]] 16:29, 14 October 2007 (CDT)

Yep, in [[10349#Body_of_camera_for_developers]] --[[User:Polto|Polto]] 08:55, 15 October 2007 (GMT)

I looked at the images only, did not read the text. You are right there is no sense to have transparent cover - it will allow stray light to reach the sensor.--[[User:Andrey.filippov|Andrey.filippov]] 03:10, 15 October 2007 (CDT)

No problem, we can use black plex.
--[[User:Dimon|dimon]] 21:11, 16 October 2007 (CDT)

Will the RS323 socket fit in the camera on top of both 10353 & 10349 ?
--[[User:Polto|Polto]] 03:45, 1 November 2007 (GMT)

Should be yes. I measure distance between PCB of 10349 with 10353 to top of cover on 3D model. This is 11.5 mm. For common socket of RS232 this distance is good.

That is my comment. --[[User:Dimon|dimon]] 22:17, 31 October 2007 (CDT)

Are these boards available for purchase or testing? --[[User:Ekratzer|Ekratzer]] 15:51, 12 November 2007 (CST)

Yes, we just do not have our costs (and so the price) ready yet.

Andrey

I am trying to use CF + DMA on 10353 boards. I have tried many CF cards and they work fine under normal PIO modes, but not with DMA, even when tweaking parameters with hdparm. I have also found that some hard drives work with DMA, and some do not, leading me to believe that maybe there is some CF type that will work. Has anybody successfully use CF + DMA on the 353's ETRAX FS?

--[[User:Ekratzer|Ekratzer]] 11:41, 28 January 2008 (CST)

That is very interesting. Can you please provide links to the exact circuit diagrams how you connect CF cards as well as to the source code you are using?--[[User:Andrey.filippov|Andrey.filippov]] 13:08, 28 January 2008 (CST)

Andrey, I have uploaded our circuit diagram to [http://wiki.elphel.com/images/4/46/Rz_353_cf_interface.pdf rz_353_cf_interface.pdf]
As far as source code, we simply have a script that runs as last part of runlevel 3. It disables DMA (/sbin/hdparm -m 0 -c 1 -d 0 /dev/hda) and mounts /dev/hda1 on the filesystem. If we do not disable DMA, then the kernel just endlessly loops on dma timeouts when we try to access the CF. --[[User:Ekratzer|Ekratzer]] 17:06, 29 January 2008 (CST)

'''It seems the problem with the your board is the lack of pullup/pulldown resistors on the INTRQ, DMARQ, IORDY lines'''.
Those resistors are intentionally omitted on the [[10353]] board - the same I/O lines can be used for different purposes,
not just the IDE port.
Hmm. DMARQ and DMACK are not shown on your diagram at all. Without the pulldown resistor on the DMARQ line
the 353 camera software will not initialize IDE driver, it uses it to determine that IDE capable add-on board
is attached to the 10353--[[User:Andrey.filippov|Andrey.filippov]] 17:55, 18 February 2008 (CST).

Hmm, ok. I had disabled the check for _353_io_board_present in ide-cris.c to get past this problem (no pull down in DMARQ.) --[[User:Ekratzer|Ekratzer]] 07:22, 25 February 2008 (CST)

I see, thank you. By the end of the week I should have all the components for the 10369 board and I will put it together ans start testing with the CF cards (and SATA also). Did you try different brands/models? --[[User:Andrey.filippov|Andrey.filippov]] 17:41, 29 January 2008 (CST)

I have tested with a variety of Transcend and Kingston CF, ranging from 512MB to 8GB, and speed ratings from 45x to 266x. I have also tested 2 hard drives, both Hitachi Travelstar. Model #HTS541040G9AT00 works well with DMA (over 15MB/s sustained write throughput with little CPU load), and model #HTC424020F7AT00 behaves the same as the CF (no DMA.) I have tested all these CF and hard drives on 5 of our CF interface boards, with results being the same for each. Interesting note, the kernel always detects and tries to enable DMA in cris_ide_init(), regardless of "ide=nodma" init option. It times out once after about 8 seconds, and then I can disable DMA and mount normally with PIO modes. --[[User:Ekratzer|Ekratzer]] 14:12, 30 January 2008 (CST)

Also, I forgot to mention that I have also tried a couple IBM 4GB CF microdrives, with results being the same (no DMA.) --[[User:Ekratzer|Ekratzer]] 14:18, 30 January 2008 (CST)

I see. Hope to have some results with the 10369 next week and see if I'll get the same problem. So far I tried several HDDs (no CF yet) and they worked fine (to be honest I even do not know if the DMA is enabled) - the recording speed for large files was around 15MB/s. With the 10369 I'll get there with the oscilloscope and add some "pritnk()" to the driver - I believe it should work faster.--[[User:Andrey.filippov|Andrey.filippov]] 15:08, 30 January 2008 (CST)

----

I tried some CF card (QMemory 16GB) with 10369 (SATA HDD works just fine) and did find a problem with DMA. The CF card releases DMARQ after transferring just 1024 bytes (512 words) and does not reassert it when asked for 16 sectors to read during initialization. That leads to DMA timeout.

To fix it we need to limit number of sectors that are requested in a single DMA command.

--[[User:Andrey.filippov|Andrey.filippov]] 04:39, 17 February 2008 (CST)

''More details on the QMemory 16GB CF card''. When that data is read using DMA (and the card reports it has it) the data transferred (until the CF drops DMARQ forever) is always 1024 bytes (2*512) - equal to the reported buffer size. That 1024 does not depend on the number of sector requested - it can be 1 (so 512 bytes were expected) or >2 (i.e. 16) - still DMA dies after 1024 bytes. Next problem - this CF card does not assert INTRQ after the READ DMA, and the driver reies on it to finish READ DMA command (that IRQ is required by the ATA specifications). I tried to tweak other parameters, like multsect with SET MULTIPLE MODE (it is designed fro READ MULTIPLE only) - still no interrupts at the end of READ DMA command.

I just ordered a bunch of different brands CF cards to test, if they will exhibit similar problems (CF+DMA shows multiple problems in Google search) the solution will be to add interrupt on the DMA (internal processor DMA, not ATA DMA) that will trigger after ETRAX FS receives requested amount of data in addition to ATA interrupts (derived from the INTRQ signal of the ATA bus) and limit number of sectors during a single READ DMA command. It will require changes in both ide-cris.c and higher level ide driver, as the current one does not rely on internal DMA interrupt, only on the ATA one.--[[User:Andrey.filippov|Andrey.filippov]] 14:48, 18 February 2008 (CST)

Opening the CF card revealed SM222TF controller chip, same as for the card described [http://www.nextwarehouse.com/DS/iERP/ATA_SMB_DMA.pdf here]. It claims to support DMA, but the READ DMA/WRITE DMA commands are missing in the table of supported ones.

Will using the processor DMA instead of ATA require any changes to the circuit? If so, we can implement and test any changes. We will be making changes to fix INTRQ, DMARQ, IORDY, and DMACK lines shortly. --[[User:Ekratzer|Ekratzer]] 08:05, 25 February 2008 (CST)

Interesting page for CF statistics. Shows which cards support DMA/PIO/etc: [http://www.hjreggel.net/cardspeed/speed-cards.html CARDSPEED - Card Readers and Memory Cards] --[[User:Ekratzer|Ekratzer]] 09:19, 25 February 2008 (CST)

Talk:10349

2008-02-25T14:07:58Z

Ekratzer:

About the plex panel for developer case: why do it transparent ? Is where a special reason ? It's not very good for image quality to have light inside the case. --[[User:Polto|Polto]] 11:36, 14 October 2007 (GMT)

Transparent? Why? Is it written anywhere?--[[User:Andrey.filippov|Andrey.filippov]] 16:29, 14 October 2007 (CDT)

Yep, in [[10349#Body_of_camera_for_developers]] --[[User:Polto|Polto]] 08:55, 15 October 2007 (GMT)

I looked at the images only, did not read the text. You are right there is no sense to have transparent cover - it will allow stray light to reach the sensor.--[[User:Andrey.filippov|Andrey.filippov]] 03:10, 15 October 2007 (CDT)

No problem, we can use black plex.
--[[User:Dimon|dimon]] 21:11, 16 October 2007 (CDT)

Will the RS323 socket fit in the camera on top of both 10353 & 10349 ?
--[[User:Polto|Polto]] 03:45, 1 November 2007 (GMT)

Should be yes. I measure distance between PCB of 10349 with 10353 to top of cover on 3D model. This is 11.5 mm. For common socket of RS232 this distance is good.

That is my comment. --[[User:Dimon|dimon]] 22:17, 31 October 2007 (CDT)

Are these boards available for purchase or testing? --[[User:Ekratzer|Ekratzer]] 15:51, 12 November 2007 (CST)

Yes, we just do not have our costs (and so the price) ready yet.

Andrey

I am trying to use CF + DMA on 10353 boards. I have tried many CF cards and they work fine under normal PIO modes, but not with DMA, even when tweaking parameters with hdparm. I have also found that some hard drives work with DMA, and some do not, leading me to believe that maybe there is some CF type that will work. Has anybody successfully use CF + DMA on the 353's ETRAX FS?

--[[User:Ekratzer|Ekratzer]] 11:41, 28 January 2008 (CST)

That is very interesting. Can you please provide links to the exact circuit diagrams how you connect CF cards as well as to the source code you are using?--[[User:Andrey.filippov|Andrey.filippov]] 13:08, 28 January 2008 (CST)

Andrey, I have uploaded our circuit diagram to [http://wiki.elphel.com/images/4/46/Rz_353_cf_interface.pdf rz_353_cf_interface.pdf]
As far as source code, we simply have a script that runs as last part of runlevel 3. It disables DMA (/sbin/hdparm -m 0 -c 1 -d 0 /dev/hda) and mounts /dev/hda1 on the filesystem. If we do not disable DMA, then the kernel just endlessly loops on dma timeouts when we try to access the CF. --[[User:Ekratzer|Ekratzer]] 17:06, 29 January 2008 (CST)

'''It seems the problem with the your board is the lack of pullup/pulldown resistors on the INTRQ, DMARQ, IORDY lines'''.
Those resistors are intentionally omitted on the [[10353]] board - the same I/O lines can be used for different purposes,
not just the IDE port.
Hmm. DMARQ and DMACK are not shown on your diagram at all. Without the pulldown resistor on the DMARQ line
the 353 camera software will not initialize IDE driver, it uses it to determine that IDE capable add-on board
is attached to the 10353--[[User:Andrey.filippov|Andrey.filippov]] 17:55, 18 February 2008 (CST).

Hmm, ok. I had disabled the check for _353_io_board_present in ide-cris.c to get past this problem (no pull down in DMARQ.) --[[User:Ekratzer|Ekratzer]] 07:22, 25 February 2008 (CST)

I see, thank you. By the end of the week I should have all the components for the 10369 board and I will put it together ans start testing with the CF cards (and SATA also). Did you try different brands/models? --[[User:Andrey.filippov|Andrey.filippov]] 17:41, 29 January 2008 (CST)

I have tested with a variety of Transcend and Kingston CF, ranging from 512MB to 8GB, and speed ratings from 45x to 266x. I have also tested 2 hard drives, both Hitachi Travelstar. Model #HTS541040G9AT00 works well with DMA (over 15MB/s sustained write throughput with little CPU load), and model #HTC424020F7AT00 behaves the same as the CF (no DMA.) I have tested all these CF and hard drives on 5 of our CF interface boards, with results being the same for each. Interesting note, the kernel always detects and tries to enable DMA in cris_ide_init(), regardless of "ide=nodma" init option. It times out once after about 8 seconds, and then I can disable DMA and mount normally with PIO modes. --[[User:Ekratzer|Ekratzer]] 14:12, 30 January 2008 (CST)

Also, I forgot to mention that I have also tried a couple IBM 4GB CF microdrives, with results being the same (no DMA.) --[[User:Ekratzer|Ekratzer]] 14:18, 30 January 2008 (CST)

I see. Hope to have some results with the 10369 next week and see if I'll get the same problem. So far I tried several HDDs (no CF yet) and they worked fine (to be honest I even do not know if the DMA is enabled) - the recording speed for large files was around 15MB/s. With the 10369 I'll get there with the oscilloscope and add some "pritnk()" to the driver - I believe it should work faster.--[[User:Andrey.filippov|Andrey.filippov]] 15:08, 30 January 2008 (CST)

----

I tried some CF card (QMemory 16GB) with 10369 (SATA HDD works just fine) and did find a problem with DMA. The CF card releases DMARQ after transferring just 1024 bytes (512 words) and does not reassert it when asked for 16 sectors to read during initialization. That leads to DMA timeout.

To fix it we need to limit number of sectors that are requested in a single DMA command.

--[[User:Andrey.filippov|Andrey.filippov]] 04:39, 17 February 2008 (CST)

''More details on the QMemory 16GB CF card''. When that data is read using DMA (and the card reports it has it) the data transferred (until the CF drops DMARQ forever) is always 1024 bytes (2*512) - equal to the reported buffer size. That 1024 does not depend on the number of sector requested - it can be 1 (so 512 bytes were expected) or >2 (i.e. 16) - still DMA dies after 1024 bytes. Next problem - this CF card does not assert INTRQ after the READ DMA, and the driver reies on it to finish READ DMA command (that IRQ is required by the ATA specifications). I tried to tweak other parameters, like multsect with SET MULTIPLE MODE (it is designed fro READ MULTIPLE only) - still no interrupts at the end of READ DMA command.

I just ordered a bunch of different brands CF cards to test, if they will exhibit similar problems (CF+DMA shows multiple problems in Google search) the solution will be to add interrupt on the DMA (internal processor DMA, not ATA DMA) that will trigger after ETRAX FS receives requested amount of data in addition to ATA interrupts (derived from the INTRQ signal of the ATA bus) and limit number of sectors during a single READ DMA command. It will require changes in both ide-cris.c and higher level ide driver, as the current one does not rely on internal DMA interrupt, only on the ATA one.--[[User:Andrey.filippov|Andrey.filippov]] 14:48, 18 February 2008 (CST)

Opening the CF card revealed SM222TF controller chip, same as for the card described [http://www.nextwarehouse.com/DS/iERP/ATA_SMB_DMA.pdf here]. It claims to support DMA, but the READ DMA/WRITE DMA commands are missing in the table of supported ones.

Will using the processor DMA instead of ATA require any changes to the circuit? If so, we can implement and test any changes. We will be making changes to fix INTRQ, DMARQ, IORDY, and DMACK lines shortly. --[[User:Ekratzer|Ekratzer]] 08:05, 25 February 2008 (CST)

Talk:10349

2008-02-25T14:05:04Z

Ekratzer:

About the plex panel for developer case: why do it transparent ? Is where a special reason ? It's not very good for image quality to have light inside the case. --[[User:Polto|Polto]] 11:36, 14 October 2007 (GMT)

Transparent? Why? Is it written anywhere?--[[User:Andrey.filippov|Andrey.filippov]] 16:29, 14 October 2007 (CDT)

Yep, in [[10349#Body_of_camera_for_developers]] --[[User:Polto|Polto]] 08:55, 15 October 2007 (GMT)

I looked at the images only, did not read the text. You are right there is no sense to have transparent cover - it will allow stray light to reach the sensor.--[[User:Andrey.filippov|Andrey.filippov]] 03:10, 15 October 2007 (CDT)

No problem, we can use black plex.
--[[User:Dimon|dimon]] 21:11, 16 October 2007 (CDT)

Will the RS323 socket fit in the camera on top of both 10353 & 10349 ?
--[[User:Polto|Polto]] 03:45, 1 November 2007 (GMT)

Should be yes. I measure distance between PCB of 10349 with 10353 to top of cover on 3D model. This is 11.5 mm. For common socket of RS232 this distance is good.

That is my comment. --[[User:Dimon|dimon]] 22:17, 31 October 2007 (CDT)

Are these boards available for purchase or testing? --[[User:Ekratzer|Ekratzer]] 15:51, 12 November 2007 (CST)

Yes, we just do not have our costs (and so the price) ready yet.

Andrey

I am trying to use CF + DMA on 10353 boards. I have tried many CF cards and they work fine under normal PIO modes, but not with DMA, even when tweaking parameters with hdparm. I have also found that some hard drives work with DMA, and some do not, leading me to believe that maybe there is some CF type that will work. Has anybody successfully use CF + DMA on the 353's ETRAX FS?

--[[User:Ekratzer|Ekratzer]] 11:41, 28 January 2008 (CST)

That is very interesting. Can you please provide links to the exact circuit diagrams how you connect CF cards as well as to the source code you are using?--[[User:Andrey.filippov|Andrey.filippov]] 13:08, 28 January 2008 (CST)

Andrey, I have uploaded our circuit diagram to [http://wiki.elphel.com/images/4/46/Rz_353_cf_interface.pdf rz_353_cf_interface.pdf]
As far as source code, we simply have a script that runs as last part of runlevel 3. It disables DMA (/sbin/hdparm -m 0 -c 1 -d 0 /dev/hda) and mounts /dev/hda1 on the filesystem. If we do not disable DMA, then the kernel just endlessly loops on dma timeouts when we try to access the CF. --[[User:Ekratzer|Ekratzer]] 17:06, 29 January 2008 (CST)

'''It seems the problem with the your board is the lack of pullup/pulldown resistors on the INTRQ, DMARQ, IORDY lines'''.
Those resistors are intentionally omitted on the [[10353]] board - the same I/O lines can be used for different purposes,
not just the IDE port.
Hmm. DMARQ and DMACK are not shown on your diagram at all. Without the pulldown resistor on the DMARQ line
the 353 camera software will not initialize IDE driver, it uses it to determine that IDE capable add-on board
is attached to the 10353--[[User:Andrey.filippov|Andrey.filippov]] 17:55, 18 February 2008 (CST).

Hmm, ok. I had disabled the check for _353_io_board_present in ide-cris.c to get past this problem (no pull down in DMARQ.) --[[User:Ekratzer|Ekratzer]] 07:22, 25 February 2008 (CST)

I see, thank you. By the end of the week I should have all the components for the 10369 board and I will put it together ans start testing with the CF cards (and SATA also). Did you try different brands/models? --[[User:Andrey.filippov|Andrey.filippov]] 17:41, 29 January 2008 (CST)

I have tested with a variety of Transcend and Kingston CF, ranging from 512MB to 8GB, and speed ratings from 45x to 266x. I have also tested 2 hard drives, both Hitachi Travelstar. Model #HTS541040G9AT00 works well with DMA (over 15MB/s sustained write throughput with little CPU load), and model #HTC424020F7AT00 behaves the same as the CF (no DMA.) I have tested all these CF and hard drives on 5 of our CF interface boards, with results being the same for each. Interesting note, the kernel always detects and tries to enable DMA in cris_ide_init(), regardless of "ide=nodma" init option. It times out once after about 8 seconds, and then I can disable DMA and mount normally with PIO modes. --[[User:Ekratzer|Ekratzer]] 14:12, 30 January 2008 (CST)

Also, I forgot to mention that I have also tried a couple IBM 4GB CF microdrives, with results being the same (no DMA.) --[[User:Ekratzer|Ekratzer]] 14:18, 30 January 2008 (CST)

I see. Hope to have some results with the 10369 next week and see if I'll get the same problem. So far I tried several HDDs (no CF yet) and they worked fine (to be honest I even do not know if the DMA is enabled) - the recording speed for large files was around 15MB/s. With the 10369 I'll get there with the oscilloscope and add some "pritnk()" to the driver - I believe it should work faster.--[[User:Andrey.filippov|Andrey.filippov]] 15:08, 30 January 2008 (CST)

----

I tried some CF card (QMemory 16GB) with 10369 (SATA HDD works just fine) and did find a problem with DMA. The CF card releases DMARQ after transferring just 1024 bytes (512 words) and does not reassert it when asked for 16 sectors to read during initialization. That leads to DMA timeout.

To fix it we need to limit number of sectors that are requested in a single DMA command.

--[[User:Andrey.filippov|Andrey.filippov]] 04:39, 17 February 2008 (CST)

''More details on the QMemory 16GB CF card''. When that data is read using DMA (and the card reports it has it) the data transferred (until the CF drops DMARQ forever) is always 1024 bytes (2*512) - equal to the reported buffer size. That 1024 does not depend on the number of sector requested - it can be 1 (so 512 bytes were expected) or >2 (i.e. 16) - still DMA dies after 1024 bytes. Next problem - this CF card does not assert INTRQ after the READ DMA, and the driver reies on it to finish READ DMA command (that IRQ is required by the ATA specifications). I tried to tweak other parameters, like multsect with SET MULTIPLE MODE (it is designed fro READ MULTIPLE only) - still no interrupts at the end of READ DMA command.

I just ordered a bunch of different brands CF cards to test, if they will exhibit similar problems (CF+DMA shows multiple problems in Google search) the solution will be to add interrupt on the DMA (internal processor DMA, not ATA DMA) that will trigger after ETRAX FS receives requested amount of data in addition to ATA interrupts (derived from the INTRQ signal of the ATA bus) and limit number of sectors during a single READ DMA command. It will require changes in both ide-cris.c and higher level ide driver, as the current one does not rely on internal DMA interrupt, only on the ATA one.--[[User:Andrey.filippov|Andrey.filippov]] 14:48, 18 February 2008 (CST)

Opening the CF card revealed SM222TF controller chip, same as for the card described [http://www.nextwarehouse.com/DS/iERP/ATA_SMB_DMA.pdf here]. It claims to support DMA, but the READ DMA/WRITE DMA commands are missing in the table of supported ones.

Will using the processor DMA instead of ATA require any changes to the circuit? If so, we can test any changes. We will be making changes to fix INTRQ, DMARQ, IORDY, and DMACK lines shortly. --[[User:Ekratzer|Ekratzer]] 08:05, 25 February 2008 (CST)

Talk:10349

2008-02-25T13:22:02Z

Ekratzer:

Talk:10349

2008-01-30T20:18:50Z

Ekratzer:

Talk:10349

2008-01-30T20:12:10Z

Ekratzer:

Talk:10349

2008-01-29T23:09:36Z

Ekratzer:

Talk:10349

2008-01-29T23:06:45Z

Ekratzer:

Talk:10349

2008-01-28T17:41:04Z

Ekratzer:

Talk:10338

2007-12-11T17:43:25Z

Ekratzer:

--[[User:Andrey.filippov|Andrey.filippov]] 16:49, 3 December 2007 (CST)[[Image:10338-purple-image.jpg]]

Several of our 10338 sensors are producing images of this nature (single purple-ish color.)

Some of the sensors produce this type of image 100% of the time, others 50% of the time (after reboots), and still others work fine.

I have tested with 7.1.5 from sourceforge and (as of today 2007-12-03) the latest from CVS with the same results.

Is this a bad sensor? Has anyone seen this behaviour?

(note: the lens is a fisheye.)

--[[User:Ekratzer|Ekratzer]] 11:18, 3 December 2007 (CST)

What cable length are you using? It looks like the signal phase is wrong. You may try &byr=0..3 in ccam.cgi parameters, but that is just to verify the problem, to fix it you'll need to adjust that phase (see [[Adjusting_sensor_clock_phase]])--[[User:Andrey.filippov|Andrey.filippov]] 16:49, 3 December 2007 (CST)

We are using a 4inch cable. I have tried adjusting the phase.. sometimes we have success, but most of the time not. I think it is similar to the problem where the 5Mpix sensor gets confused when setting the clock frequency as described in [[Adjusting_sensor_clock_phase]]. Has there been any more discovery as to why this happens? --[[User:Ekratzer|Ekratzer]] 11:43, 11 December 2007 (CST)

Talk:10338

2007-12-03T17:18:58Z

Ekratzer:

[[Image:10338-purple-image.jpg]]

Several of our 10338 sensors are producing images of this nature (single purple-ish color.)

Some of the sensors produce this type of image 100% of the time, others 50% of the time (after reboots), and still others work fine.

I have tested with 7.1.5 from sourceforge and (as of today 2007-12-03) the latest from CVS with the same results.

Is this a bad sensor? Has anyone seen this behaviour?

(note: the lens is a fisheye.)

--[[User:Ekratzer|Ekratzer]] 11:18, 3 December 2007 (CST)

Talk:10338

2007-12-03T17:18:31Z

Ekratzer:

[[Image:10338-purple-image.jpg]]

Several of our 10338 sensors are producing images of this nature (single purple-ish color.)

Some of the sensors produce this type of image 100% of the time, others 50% of the time (after reboots), and still others work fine.

I have tested with 7.1.5 from sourceforge and (as of today 2007-12-03) the latest from CVS with the same results.

Is this a bad sensor? Has anyone seen this behaviour?

--[[User:Ekratzer|Ekratzer]] 11:18, 3 December 2007 (CST)

Talk:10338

2007-12-03T17:15:25Z

Ekratzer:

[[Image:10338-purple-image.jpg]]

File:10338-purple-image.jpg

2007-12-03T17:14:57Z

Ekratzer: Several of our 10338 boards produce images like this

Several of our 10338 boards produce images like this

Talk:Camogm

2007-11-19T17:18:59Z

Ekratzer:

Camogm seems to be very versatile.. however, is there a similar method (command line) for changing acquisition parameters (e.g., decimation, exposure time, etc.) ? I am interested in automating capture of low-rate, high-res still images and high-rate, low-res video. The ability to switch between these two without using ccam (or any web interface) would be ideal. --[[User:Ekratzer|Ekratzer]] 11:18, 19 November 2007 (CST)

Talk:10349

2007-11-12T21:51:27Z

Ekratzer:

Talk:Circbuf

2007-11-12T18:58:11Z

Ekratzer:

I have a question regarding the 353 compressor initialization. The imgsrvd program does not work after bootup because the driver has not initialized the FPGA, and not started the compressor running. The only way I can get it to work is to run ccam (via http) first. Is there a way to automatically (upon bootup) initialize both the FPGA and start the compressor running?

I have tried a few things:

I have found that just opening "/dev/ccam_img" causes the init_FPGA() to be called, so one problem solved.

However, after I open "/dev/sensorpars" and call JPEG_CMD_START and nothing happens? How do we start/stop the compressor now ?

I am using 7.1.5 from sourceforge.

--[[User:Ekratzer|Ekratzer]] 14:57, 9 November 2007 (CST)

You can just put :
wget http://127.0.0.1/admin-bin/ccam.cgi?parameter1=value1&parameter2=value2&...
into some init.d script.

We are now designing a some PHP API and [[User:Luxigo|Luxigo]] work on a C/C++ library / API. (now it's only acquisition no programming CMOS)

Or just look in the ccam.cgi source code. (I never did)

--[[User:Polto|Polto]] 23:35, 9 November 2007 (GMT)

Yep, you are right - nothing is done for that yet. So while testing I did the same - opened first image with ccam.cgi (even complete camvc.html), then started compressor with "http://camera_ip:81/compressor.php?cmd=run" and only then used imgsrv to access circbuf.

Using ccam.cgi from localhost is a solution, we used it in ftp script in our webcams, but eventually there will be a better solution. You may also try to specify the ccam.cgi parameters from PHP script - similar to [[Adjusting_sensor_clock_phase]]--[[User:Andrey.filippov|Andrey.filippov]] 14:06, 10 November 2007 (CST)

I have searched through ccam.c and found necessary code to start compressor after bootup. Some of it may not be necessary, but it works for now.
If I change sensor parameters (WOI, exposure, quality, etc.) I must stop the compressor first, and then call this code again, or user-space will lock-up (sorry about the indenting problem...)

// initialize driver
fd = open("/dev/ccam_dma.raw", O_RDWR);
if (fd != -1)
close(fd);

fd = open("/dev/ccam_img", O_RDWR);
if (fd != -1) {

// do we need to start the compressor going ?
tmp = ioctl(fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_MONITOR_SEQ ), 0);
if (tmp != CAMSEQ_RUN) {

// force update
ioctl(fd, _CCCMD(CCAM_WPARS , P_DONTCARE), 0);
ioctl(fd, _CCCMD(CCAM_WPARS , P_DONTCARE), 1);

// set parameters, not sure if all (or any) of these are required for minumum
ioctl(fd, _CCCMD(CCAM_WPARS , P_BAYER), 4);
ioctl(fd, _CCCMD(CCAM_WPARS, P_FPSLM), -1);
tmp = ioctl(fd, _CCCMD( CCAM_RPARS , P_TRIG), 0) & ~1;
ioctl(fd, _CCCMD(CCAM_WPARS , P_TRIG ), tmp);
ioctl(fd, _CCCMD(CCAM_WPARS , P_UPDATE ), 1);

// reset pointers and DMA for new clip
ioctl (fd,_IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_RESET);
close(fd);

// start compression now
fd = open("/dev/ccam_dma.raw", O_RDWR);
if (fd != -1) {
ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_CATCHUP);
ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_FORGET);
ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_GET);
while (lseek(fd,0,2)==0);
close(fd);
}

// start compressor
fd = open("/dev/sensorpars", O_RDWR);
if (fd != -1) {
lseek(fd, CSERV_SPARS_START, SEEK_END);
close(fd);
}
}
}

</verbatim>

--[[User:Ekratzer|Ekratzer]] 09:41, 12 November 2007 (CST)

Yes, it is possible but I would still recommend to use file R/W (like in the links above that I posted), not the IOCTL.--[[User:Andrey.filippov|Andrey.filippov]] 10:16, 12 November 2007 (CST)

I need to use ioctl's for an application because I have written a light-weight acquisition server that allows sensor configuration and acquisition over the same TCP/IP interface. It tries to guarantee that no frames can be lost by using an acquisition thread on SCHED_FIFO scheduler, and a condition-copy, scatter-gather queueing mechanism that buffers meta-data about an image. The buffering is important to deal with blocking I/O (TCP, disk, flash, etc) in our minimal logging system. It buffers the following data about an image:

-first 64 configuration registers at time of acquisition
-histogram
-jpeg header (zero-copy)
-jpeg bitstream (zero-copy)

I will fold the source code into the tree very soon.

Missing Frames ??

I am experiencing an acquisition problem. There appears to be some missing frames. For example, FP100S says 14.41 fps, but I can only capture 13.1. Similarly, with exposure set to 500 and FP100S reading 20.00 fps, I can only capture 17 fps. The method I am using is below, the CPU load is less than 1%.

lseek(fd, CIRCLSEEK_LAST, SEEK_END);

while(acquire) {

// image not ready
if (lseek(cfd, CIRCLSEEK_READY, SEEK_END) < 0) {

// wait for image
jpeg_wp = lseek(fd, CIRCLSEEK_WAIT, SEEK_END);
}

// we have valid image at jpeg_wp now (verified)
...

// move to next image
lseek(fd, CIRCLSEEK_NEXT, SEEK_END);
}

Has anybody experienced this problem?

--[[User:Ekratzer|Ekratzer]] 10:27, 12 November 2007 (CST)

First of all you can troubleshoot the problem with imgsrv, using /meta and /pointers and watching timestamps (you may also extract time stamps from Exif data in the images. So is the lower frame rate because of the frame drops or because it is reported wrong. If the frames are really dropped - where did it happen - on the FPGA->circbuf, or from circbuf to your application.

There was a problem in circbuf (fixed 7.1.5) that it could not read frames that were already ready - that was an ETRAX cache coherency bug. Other than that I did not notice problems with circbuf operation yet.--[[User:Andrey.filippov|Andrey.filippov]] 12:31, 12 November 2007 (CST)

I have looked at circbuf image timestamps for several minutes of capture. When FP100S reads 14.41, the image timestamp are either 0.077 or 0.076 seconds apart (average of 0.0765 is 13.089 Hz.) There are no missing frames at all. It appears that the compressor is not running at the correct frequency. This is the same for all frequencies I have tested: the compressor runs a few FPS lower than what FPS100S reads. --[[User:Ekratzer|Ekratzer]] 12:53, 12 November 2007 (CST)

Talk:Circbuf

2007-11-12T18:53:42Z

Ekratzer:

I have a question regarding the 353 compressor initialization. The imgsrvd program does not work after bootup because the driver has not initialized the FPGA, and not started the compressor running. The only way I can get it to work is to run ccam (via http) first. Is there a way to automatically (upon bootup) initialize both the FPGA and start the compressor running?

I have tried a few things:

I have found that just opening "/dev/ccam_img" causes the init_FPGA() to be called, so one problem solved.

However, after I open "/dev/sensorpars" and call JPEG_CMD_START and nothing happens? How do we start/stop the compressor now ?

I am using 7.1.5 from sourceforge.

--[[User:Ekratzer|Ekratzer]] 14:57, 9 November 2007 (CST)

You can just put :
wget http://127.0.0.1/admin-bin/ccam.cgi?parameter1=value1&parameter2=value2&...
into some init.d script.

We are now designing a some PHP API and [[User:Luxigo|Luxigo]] work on a C/C++ library / API. (now it's only acquisition no programming CMOS)

Or just look in the ccam.cgi source code. (I never did)

--[[User:Polto|Polto]] 23:35, 9 November 2007 (GMT)

Yep, you are right - nothing is done for that yet. So while testing I did the same - opened first image with ccam.cgi (even complete camvc.html), then started compressor with "http://camera_ip:81/compressor.php?cmd=run" and only then used imgsrv to access circbuf.

Using ccam.cgi from localhost is a solution, we used it in ftp script in our webcams, but eventually there will be a better solution. You may also try to specify the ccam.cgi parameters from PHP script - similar to [[Adjusting_sensor_clock_phase]]--[[User:Andrey.filippov|Andrey.filippov]] 14:06, 10 November 2007 (CST)

I have searched through ccam.c and found necessary code to start compressor after bootup. Some of it may not be necessary, but it works for now.
If I change sensor parameters (WOI, exposure, quality, etc.) I must stop the compressor first, and then call this code again, or user-space will lock-up (sorry about the indenting problem...)

// initialize driver
fd = open("/dev/ccam_dma.raw", O_RDWR);
if (fd != -1)
close(fd);

fd = open("/dev/ccam_img", O_RDWR);
if (fd != -1) {

// do we need to start the compressor going ?
tmp = ioctl(fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_MONITOR_SEQ ), 0);
if (tmp != CAMSEQ_RUN) {

// force update
ioctl(fd, _CCCMD(CCAM_WPARS , P_DONTCARE), 0);
ioctl(fd, _CCCMD(CCAM_WPARS , P_DONTCARE), 1);

// set parameters, not sure if all (or any) of these are required for minumum
ioctl(fd, _CCCMD(CCAM_WPARS , P_BAYER), 4);
ioctl(fd, _CCCMD(CCAM_WPARS, P_FPSLM), -1);
tmp = ioctl(fd, _CCCMD( CCAM_RPARS , P_TRIG), 0) & ~1;
ioctl(fd, _CCCMD(CCAM_WPARS , P_TRIG ), tmp);
ioctl(fd, _CCCMD(CCAM_WPARS , P_UPDATE ), 1);

// reset pointers and DMA for new clip
ioctl (fd,_IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_RESET);
close(fd);

// start compression now
fd = open("/dev/ccam_dma.raw", O_RDWR);
if (fd != -1) {
ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_CATCHUP);
ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_FORGET);
ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_GET);
while (lseek(fd,0,2)==0);
close(fd);
}

// start compressor
fd = open("/dev/sensorpars", O_RDWR);
if (fd != -1) {
lseek(fd, CSERV_SPARS_START, SEEK_END);
close(fd);
}
}
}

</verbatim>

--[[User:Ekratzer|Ekratzer]] 09:41, 12 November 2007 (CST)

Yes, it is possible but I would still recommend to use file R/W (like in the links above that I posted), not the IOCTL.--[[User:Andrey.filippov|Andrey.filippov]] 10:16, 12 November 2007 (CST)

I need to use ioctl's for an application because I have written a light-weight acquisition server that allows sensor configuration and acquisition over the same TCP/IP interface. It tries to guarantee that no frames can be lost by using an acquisition thread on SCHED_FIFO scheduler, and a condition-copy, scatter-gather queueing mechanism that buffers meta-data about an image. The buffering is important to deal with blocking I/O (TCP, disk, flash, etc) in our minimal logging system. It buffers the following data about an image:

-first 64 configuration registers at time of acquisition
-histogram
-jpeg header (zero-copy)
-jpeg bitstream (zero-copy)

I will fold the source code into the tree very soon.

Missing Frames ??

I am experiencing an acquisition problem. There appears to be some missing frames. For example, FP100S says 14.41 fps, but I can only capture 13.1. Similarly, with exposure set to 500 and FP100S reading 20.00 fps, I can only capture 17 fps. The method I am using is below, the CPU load is less than 1%.

lseek(fd, CIRCLSEEK_LAST, SEEK_END);

while(acquire) {

// image not ready
if (lseek(cfd, CIRCLSEEK_READY, SEEK_END) < 0) {

// wait for image
jpeg_wp = lseek(fd, CIRCLSEEK_WAIT, SEEK_END);
}

// we have valid image at jpeg_wp now (verified)
...

// move to next image
lseek(fd, CIRCLSEEK_NEXT, SEEK_END);
}

Has anybody experienced this problem?

--[[User:Ekratzer|Ekratzer]] 10:27, 12 November 2007 (CST)

First of all you can troubleshoot the problem with imgsrv, using /meta and /pointers and watching timestamps (you may also extract time stamps from Exif data in the images. So is the lower frame rate because of the frame drops or because it is reported wrong. If the frames are really dropped - where did it happen - on the FPGA->circbuf, or from circbuf to your application.

There was a problem in circbuf (fixed 7.1.5) that it could not read frames that were already ready - that was an ETRAX cache coherency bug. Other than that I did not notice problems with circbuf operation yet.--[[User:Andrey.filippov|Andrey.filippov]] 12:31, 12 November 2007 (CST)

I have looked at circbuf image timestamps for several minutes of capture. When FP100S reads 14.41, the image timestamp are either 0.077 or 0.076 ms apart (average of 0.0765 is 13.089 Hz.) There are no missing frames at all. It appears that the compressor is not running at the correct frequency. This is the same for all frequencies I have tested: the compressor runs a few FPS lower than what FPS100S reads. --[[User:Ekratzer|Ekratzer]] 12:53, 12 November 2007 (CST)

Talk:Circbuf

2007-11-12T16:27:49Z

Ekratzer:

Talk:Circbuf

2007-11-12T15:46:40Z

Ekratzer:

Talk:Circbuf

2007-11-12T15:46:05Z

Ekratzer:

Talk:Circbuf

2007-11-12T15:43:08Z

Ekratzer:

Talk:Circbuf

2007-11-12T15:41:09Z

Ekratzer:

Talk:Circbuf

2007-11-09T21:00:20Z

Ekratzer:

Talk:Circbuf

2007-11-09T20:57:15Z

Ekratzer: