MikroElektronika Forum

Very nice! Thanks.

The library should work on any controller with sufficient amount of RAM and program memory

Please, could you give more enlightment about this? What would be the way to measure ram requirements (even in an approximative way)?


Thanks to mikroE team for this great work.

Regarrds

Hi,

octal wrote:

The library should work on any controller with sufficient amount of RAM and program memory

Please, could you give more enlightment about this? What would be the way to measure ram requirements (even in an approximative way)?

Ram usage depends on user code and library features/functions that are used as well as the user settings for maximum number of simultaneously opened files
and as such is not likely to be easily calculated.
The sentence from your quote was suppose to point out that there are no special requirements for the MCUs (any MCU can be used),
just enough ram and flash (to hold whole user code of course) and appropriate hw interface (if needed, such as SPI).
Maybe badly said. Subject to a change if you have an alternative solution

Hi srdjan,
thank you for your answer. I know that the amount of ram/flash will of course depend on the used features. But at least, could you give the footprint of each simultanious opened file (number of ram bytes needed), the amount of ram systematically reserved by the lib, ... could you also point out the functions that can be memory hungry and how to save ram when using them (what would be for example the better number of bytes to write simultaniously to a file???).
this kind of information can be very very useful for users.

And on all that, I insist mainly on RAM, because we can easily switch to a PIC with bigger flash, while RAM is a real constraint in Microchip PIC (especially in 8bit arch PICs).

octal wrote:Hi srdjan,
thank you for your answer. I know that the amount of ram/flash will of course depend on the used features. But at least, could you give the footprint of each simultanious opened file (number of ram bytes needed), the amount of ram systematically reserved by the lib, ... could you also point out the functions that can be memory hungry and how to save ram when using them (what would be for example the better number of bytes to write simultaniously to a file???).
this kind of information can be very very useful for users.

And on all that, I insist mainly on RAM, because we can easily switch to a PIC with bigger flash, while RAM is a real constraint in Microchip PIC (especially in 8bit arch PICs).

I agree on ram constraints issue, we could place some minimum ram requirements in default library configuration.
As for now, users can easily take demo example and see ram consumption.
Also, all type definition such as file descriptors and user relevant global definitions such as file descriptor array are made public and can be found in __Lib_FAT32_Types and __Lib_FAT32_Defs files (uP, uB) or __Lib_FAT32.h and __Lib_FAT32_Defs file (uC).

Hi,

About the Network Ethernet Library,

I need to communicate at the Data Link Layer,
either LLDP or CDP protocol.

For that I must send packets to a certain mac address.

Is that possible with this new library?

regards peter

Hi,

with this version of library user can work with higher layer then Data Link Layer. So you can not explicit define destination MAC address.

Best regards
Darko

Hello
I would like to use the fat32 library.
How do I unpack or use the MPKG file ?
Sjors

Hi,
you should open MPKG file using Package Manager (www.mikroe.com/eng/products/view/591/package-manager), and install library into appropriate compiler.

Best regards
Darko

Ok, the most important thing for me is that it is necessary that the code works in the micro

Will the FAT32 library be available anytime soon for STM32?

Good morning,
I tested the new library, and I have to say it works very well.
I just have a problem with the function fat32_format:

error in compilation:

0 139 All files Compiled in 250 ms
0 360 Unresolved extern 'FAT32_Dev_SectorCount' __ Lib_FAT32.c
0 360 Unresolved extern 'FAT32_Dev_SectorCount' __ Lib_FAT32.c
0453 Unsuccessful linking 'DNR.mbppi' Unsuccessful linking 'DNR.mbppi'
0 102 Finished (with errors): 06 Sep 2012, 21:22:31 DNR.mbppi

pic 18f46j50
MIKROBASIC Pro 5.61

Could you help me?

Hello,

I apologize for the inconvenience.
I have confirmed it and we will inspect this matter and provide solution as soon as possible.
Thanks for reporting this.

We will provide FAT32 for STM32 controllers very soon.

Best regards.

Hello, I have a big problem with the library fat32
I've tried almost all of the commands, and I found a problem in the command FAT32_Rename

example
DIM NAM_FILE_REC AS STRING[12] ABSOLUTE 0X46C
DIM RENAME_FILE_REC AS STRING[12] ABSOLUTE 0X47B
dim TEMP_RESULT as SHORT

NAM_FILE_REC="luca1.txt"
RENAME_FILE_REC ="luca2.txt"

TEMP_RESULT = FAT32_Rename(@NAM_FILE_REC,@RENAME_FILE_REC)
IF TEMP_RESULT <> 0 THEN
'ok
end if


The result is that the function returns me "0" but if I'm going to put the sd memory in a PC, the file that previously existed no longer exists, as if it had been deleted.
The sd is empty

I need to use this function for a project at work, and I can not turn back on fat16. Help me please? I am aware that the library is in beta test, but there were no changes for several months and I need

Hello,

I have tested your code on PIC32MX460F512L and it works well.
I was not able to reproduce reported behavior.

Please can you tell me more details regarding this?
Which controller do you use?
And if you can please test it with minimal code (just init and rename function).

Best regards.