A.S 2: Processortype is undefined 18F25K80

[basparky]

Hi,

Positron 8 Ver 4.0.5.8. Somehow it gives me the error A.S 2: Processortype is undefined for a 18F25K80 PIC.

This exact program has been succesfully compiled a few months ago with a previous version (i think).

Does anyone know how to solve this issue please?

Thanks

[John Lawton]

Maybe post some of the code so it can be checked?

John

[Maxi]

hi, the latest version is 4.0.5.9 and the 18F25K80 compiles properly.

[Fanie]

If another 18F25Kxx is supported you can substitute that one if the one you want to use doesn't have a specific function you need to use.

[basparky]

Thanks all for helping! I found that is was the google drive folder location which causes this error. I tried by placing the project in the local PDS folder and fixed. The compiling time also reduces 50% or more when doing this.

Perhaps i need to move my projects to a different folder closer to C:.

Any experiences with this kind of problems by using google drive or onedrive and PIC projects?

[Stephen Moss]

Any experiences with this kind of problems by using google drive or onedrive and PIC projects?

I have place my files on both Google Drive and Dropbox and do not recall having any problems doing so, but kept all the sample and other install files in hte default locations on my PC.

There was a time several years ago where I had some issues but although it was not clear that the issue was I put it down to the PC being too busy (i.e., background OS update) to service the compiler and that was creating some problem.

I have had issue where the file path has been too long, certainly with VB so maybe it was too far down in the file structure. On my Google/Dropbox my structure is...
PDS (Root - store single file programs + Projects folder)
    Projects (Store Programs requiring multiple file, i.e. Primary + includes)
       Individual Project Folders (One folder for each specific project holding all the required files for that project)

and try to keep the folder and Filenames short to try and avoid having issues with file paths that are too long.

As for it slowing compile time, obviously with the files being in a remote location it take more time to fetch and compile them compared to having them on the PC hard drive and that time can be further slowed if there is high demand for access to the relevant servers or bad/no network connection.

[top204]

The compilers, and the assembler and linker were not designed for cloud based drives, and they do have a built-in timeout.

On the compilers, I can control (to a certain extent because of windows), the timeout of each file when it is created or fetched, but with the assembler and linker I have no control.

For each compile, the loader scans the code listing, and combines any include files into it, which are read from the drive, and it also creates intermediate files for an include file's parameters and lines and name etc... It then writes a file for the pre-processor to scan and create a new file for the loader to re-scan. Then this is passed to the compiler that also creates intermediate files for certain aspects of the process, then passes the assembler file to the assembler program, which also creates/deletes multiple files for swapping, then, with the Positron16 compiler, it is passed to the linker that does the same. Then the linked file is passed to the ObjToHex file to be made into a HEX file, and while this is going on, with both compilers, unrequired files are deleted, and files renamed etc... So the compiler relies on the drive very much.

For example... The "A.S" file is actually the assembler file passed to the assembler program, and gets renamed to the BASIC code listing's name after a successful compile, or a recognised compile error.

It all looks quite invisible with the gauge line moving on the window when compiling, but in the background, all hell is let loose on the drive. :-)

[Fanie]

It all looks quite invisible with the gauge line moving on the window when compiling, but in the background, all hell is let loose on the drive. :-)

I can imagine if you have a mechanical drive it can become an issue, especially if you have a variation of unknown variables and you try to find the right combination by trial and error and compile the same over and over.  It will make a groove in the drive I'm sure and the magnetic head arm develops play in it too, that krrr krrr sound is the bearings knocking. 
The SSD's are faster and quieter, and so is the DDR4 ram too...

[top204]

The FAT and NTFS mechanisms do not work like that Fanie. The clusters will always be moved around, hence the requirement for a defragment every now and then. They are actually, extremely wasteful protocols, as are most things developed, or 'promoted' being the politically correct word, by micro$oft.

There were much better file system mechanisms around in the 1980s, but the FAT12 onwards systems were used by misro$oft DOS, and then windows, so the FATx is now used as a standard, even though it wastes a lot of disk space.