Where to build/install ADC module

[Rich]

Hi MTCAT
Nice try, but you broke the script with all the  echo  commands. For example:

Code: [Select]

if CONDITION
# echo -e "e"
then
Do this when CONDITION is true.
else
Do this when CONDITION is false.
fi
By placing a command between the  if  and  then  clauses, you altered the outcome of the test. Since the  echo  command
always returns an error code of 0 (true), the  then  clause  will always execute and the  else  clause will never execute.

I don't think the issue is in the  make_all  script, but further down the chain. That's why I suggested trying those changes
in the  driver  directory.

[MTCAT]

Hi Rich,

Oh, okay, I need to read up more on shell scripting I guess, thanks for correcting me !

I'll try your suggestions this afternoon.

Thanks,

David

[MTCAT]

Hi Rich,

I followed your instructions in reply 72 but unfortunately I'm still seeing the same errors, still in groups of 3, with either one of those modifications implemented (but not both at the same time).

I forgot to say, my little messed up make_all test did show (to me anyway) that this VortexDX can compile the source code okay, how bad would it be to just compile all the programs manually and skip the GS script completely ?...

My programming experience has been very crude I guess, mainly in Windows as well, g77 "program_name.f" -o "program_name.exe", as you can tell, I've never had to write a program (a script) to compile a program !

Thanks,

David

[MTCAT]

Hi Rich,

I also tried to comment out ALL the other kernel include statements, other than 2.6, in os_main.h, and this made things worse actually, with "Floating Point Exception" scrolling by endlessly after typing ./make_all.

It is different though, no Invalid number ' ' echoed to screen in this case.

Not sure if that helps or not.

David

[Rich]

Hi MTCAT

I followed your instructions in reply 72 but unfortunately I'm still seeing the same errors, still in groups of 3, with either one of those modifications implemented (but not both at the same time). ...

So are you saying with both changes the errors came in 2's instead of 3's?

[MTCAT]

Hi Rich,

One other thing I've noticed, in the past, on the first unpacking of the driver archive, and on the first ./make_all execution, the first thing that gets echoed back to screen is something about "analyzing dependencies", but, this is only done the first time running ./make_all after unpacking the driver tar file, on all subsequent executions of ./make_all, the build script skips this step because I think it does a check, and doesn't need to do it because it's already been done.

However, on the VortexDX, I've yet to see the "analyzing dependencies" part of the build script, despite doing "fresh" installs almost every time.

I've also noticed a file in 24dsi/driver directory called makefile.dep, but it's empty, 0 bytes....

Thanks,

David

[MTCAT]

Hi Rich,

Sorry, just saw your reply #79, no, unfortunately, I saw the same errors as before, in groups of 3's still, in either case.

Except, when I commented out ALL the #include "os_kernel.... statements EXCEPT for the 2.6 one, it was just a continuous stream of "Floating Point Exception" and in this case, there was no sh: Invalid number ' ' errors, just the "Floating Point Exception" error, over and over.

Thanks,

David

[Rich]

Hi MTCAT
I just realized there is an error in the  BuildADC.sh  script I attached in reply #59.
The line that says:

Code: [Select]

./build_all cleanShould have said:

Code: [Select]

./make_all cleanI don't know if it will fix anything, but the  clean  function should be run between builds.

You can fix it locally or download the corrected copy in reply #59.

[MTCAT]

Hi Rich,

Thanks, I noticed that before and fixed it already.

Apologies for the confusion, I can't replicate/confirm my statement in the last paragraph

"Except, when I commented out ALL the #include "os_kernel.... statements EXCEPT for the 2.6 one, it was just a continuous stream of "Floating Point Exception" and in this case, there was no sh: Invalid number ' ' errors, just the "Floating Point Exception" error, over and over"

I still do get all the errors in 3's though, I don't know what I did to get just the Floating Point Exceptions by themselves, sorry..

David

[Rich]

Hi MTCAT
It just occurred to me, you have a DX3 board you can use to build and and package the driver, library, utilities, etc.
It might make more sense to do that and copy it to the DX board rather than fighting with this. Copy the  BuildADC.sh
script to the DX3 board so it builds strict 486 compatible code.

I can think of only 2 reasons why this error is occurring:
1. The build environment installed on the DX card is different from what's installed on the DX3 card.
2. The CPU on the DX card has some incompatibility.

[MTCAT]

Hi Rich,

Thanks, I will try that, one last question though re: the DX, the VortexDX will compile the source codes okay, could we just compile and then link the individual object files ourselves to do a "DIY" build of the driver on the DX ? Easier said than done maybe, it seems very complicated, but I wonder if most of that is just catering to all the possible kernels...

I also wanted to play around in the BIOS a bit more on the DX3 to see if I can get rid of the ACPI error, the BAR errors, and increase PCI Latency timing, hoping it will to detect the card more faithfully (GSC recommends doing this).

I do also have one last option in terms of a lower power SBC, it's an AMD Geode LX800, it would be somewhere between the DX and the DX3 in terms of power consumption, but, would hopefully be a fall-back board with a "normal" CPU. Only problem, they are end-of-life and the only ones left also have only 256 MByte of RAM (Digikey), the logger program itself uses a 128 MByte buffer !

But, hopefully we can get something stable working on at least one of the Vortex boards.

Thanks, I'll try what you suggest, run BuildADC.sh on the DX3, make a new extension I guess, and then try loading that new extension when booting the DX ?

Thanks,

David

[Rich]

Hi MTCAT

... Thanks, I'll try what you suggest, run BuildADC.sh on the DX3, make a new extension I guess, and then try loading that new extension when booting the DX ?

Yes. The instructions for creating the extension were in reply #26 and #35. I believe I also mentioned somewhere you
could copy the  start  script to  package/usr/local/bin.  Just rename it to something less generic like 24dsiStart or start24dsi.

[MTCAT]

Hi Rich,

I don't know how I can ever repay you, I owe you big time for all your help, I hope I can pay it back somehow.

I'm so excited, with your help (aka spoon feeding !), I was able to build the driver for both 486 (VortexDX) and 686 (VortexDX3) architecture's.

I then made two new extensions,

1) 24dsi-2.6.33.3-tinycore-486.tcz
2) 24dsi-2.6.33.3-tinycore-686.tcz

Only "catch", in both cases (486 and 686 builds) there were two permission errors, one related to linking lib24dsi_api.so and another for inserting 24dsi.ko.

I built the drivers in home/tc as regular user, I hope I don't have to re-do both builds as root ?

After I did the 686 build (for the DX3), I was able to load the driver on the DX3, but I had to be root, i.e., had to type sudo ./start (I copied start to package/usr/local/bin/start24dsi).

But, after that, I was able to play around with the board in full !

Was awesome, everything worked, I did the throughput test and the DX3 was able to chug through 54,525,952 bytes in 5.684917 seconds, or 2,397,834 samples/second !, max throughput of the ADC is 200 kHz on 12 channels, or 2,400,000 samples/sec, so the DX3 is pretty much keeping up with the ADC "as is", this is very exciting ! ! 

I'm very embarrassed (and sorry) that I think the previous week or more of thrashing with the DX3 was simply due to me not having the 24DSI12 not fully inserted into the PCI bus connector, I hope anyway...when I first threw it together today I wasn't seeing the board at all, then I took a breath, slowed down, and re-assembled it with some standoffs and tightened it down a bit, and everything went perfectly. The connectors on the DX3 are a bit annoying in that they partially bind with the 24DSI12 analog input connector, if only hand tight like I had before, I think this was the problem. The DX is much better in that regard, connectors and layout are better designed I would say, and of course the DX hasn't given me any problems in that way, so, stupid mechanical error is all I think (with the DX3). I need to put bus extender connectors on the 24DSI12 if I end up using the DX3 as the preferred choice.

So, I've got the tcz's in place in /mnt/sdb1/tce/optional and now I can load whichever tcz file I need ! Now I can hopefully see if I can get the driver to load and do some tests on the DX !

Although, I technically have yet to load and start the driver successfully with the .tcz file, so need to do that on the DX3 as well.

Thanks so much, I think it will be a great weekend now !, some hope finally !

David

[Rich]

Hi MTCAT

... After I did the 686 build (for the DX3), I was able to load the driver on the DX3, but I had to be root, i.e., had to type sudo ./start (I copied start to package/usr/local/bin/start24dsi). ...

That's normal. Loading kernel modules (drivers) is a privileged operation requiring root (sudo) access.

I then made two new extensions,

1) 24dsi-2.6.33.3-tinycore-486.tcz
2) 24dsi-2.6.33.3-tinycore-686.tcz

As a point of reference, with very few exceptions, everything for Tinycore is compiled to be 486 compatible.

... Was awesome, everything worked, I did the throughput test and the DX3 was able to chug through 54,525,952 bytes in 5.684917 seconds, or 2,397,834 samples/second !, max throughput of the ADC is 200 kHz on 12 channels, or 2,400,000 samples/sec, so the DX3 is pretty much keeping up with the ADC "as is", this is very exciting ! ! ...

It would be interesting to load the  24dsi-2.6.33.3-tinycore-486.tcz  extension on the DX3 and run the throughput test
again. You may find compiling for 686 isn't buying you anything.

[MTCAT]

Hi Rich,

Still playing around with the DX3, and will need the next few days it seems to get caught up on my TinyCore journal ! I'm trying to keep track of all the things you helped me do to get to this point.

By the way, for some reason, Lubuntu 16.04 (4.4.6) doesn't do near as well in the data transfer test, it fails to do "block-mode" DMA and therefore can't do more than ~ 430,000 samples second aggregate, on the other hand, TC3.8.4 was able to do the full 2,400,000 samples/sec pretty much (with block mode DMA), go TinyCore !

But, I'm still kind of confused about the extension for the 24dsi, do I really need it since I've built both 486 and 686 packages in /home/tc (which is already persistent) ?

Just wondering, to automatically load the 24dsi driver, I'm thinking I could add the following to bootlocal.sh ?

For the 686 driver (for the DX3),

sudo /home/tc/24dsi.linux.4.11.91.32.0/24dsi/driver/start

OR

sudo /home/tc/package/usr/local/bin/start24dsi

And for the 486 driver, in bootlocal.sh I would have,

sudo /home/tc/package486/usr/local/bin/start24dsi


However, for the extension that's being loaded, either the 486 or 686 package, as specified in onboot.lst, where are the files associated with that package being placed ?

Thanks,

David