USB and SDFileSystem memory over alocation error
Moderators: David Barker, Jerry Messina
-
- Registered User
- Posts: 26
- Joined: Sun Oct 12, 2008 11:21 pm
- Location: Utah
USB and SDFileSystem memory over alocation error
using an 18f2550
the following moduals:
sdfilesystem
usbcdc
ADC
LCD
ISRTimer
Convert
I am converting a project from USART to USBCDC.
first i had an error in the isrtimer that the interupt vector had already been enabled. I commented out the "Timer.Start" line and then recieved an variable allocation error.
There is suppose to be 2048 of ram available.
I know that the sdfilesystem takes 500 bytes just for its buffer.
Is the dual port ram for usb taking a whack out of ram too, i thought it was a seperate ram space.
Or, is there somplace else to look for over alocation of ram.
Or, do i just need a chip with more ram for this application.
RD
the following moduals:
sdfilesystem
usbcdc
ADC
LCD
ISRTimer
Convert
I am converting a project from USART to USBCDC.
first i had an error in the isrtimer that the interupt vector had already been enabled. I commented out the "Timer.Start" line and then recieved an variable allocation error.
There is suppose to be 2048 of ram available.
I know that the sdfilesystem takes 500 bytes just for its buffer.
Is the dual port ram for usb taking a whack out of ram too, i thought it was a seperate ram space.
Or, is there somplace else to look for over alocation of ram.
Or, do i just need a chip with more ram for this application.
RD
The USB RAM is part of the 2K, it isn't separate. To make matters worse, the USB hardware module requires the buffer descriptors to be at the very beginning of it. Because the compiler can't handle RAM split into two blocks, the device definition files tell it that there is only 1K of RAM available. However, the CDC module uses 616 bytes of this for buffers, and the main USB module uses another 184 bytes, so there isn't as much RAM wasted as you might think.
It is possible to make use of the remaining 224 bytes by manually telling the compiler which address to use for a variable, but this is a bit fiddly as you have to keep track of how much space each one uses to get the address for the next one. It looks like this:
Note that I haven't double checked that the value of FreeRamStart is correct!
The project that I am working on right now needs USB CDC, SD file system, graphic LCD and buffered interrupt driven serial, so I will be doing quite a bit of this RAM allocation stuff in the next few days!
It is possible to make use of the remaining 224 bytes by manually telling the compiler which address to use for a variable, but this is a bit fiddly as you have to keep track of how much space each one uses to get the address for the next one. It looks like this:
Code: Select all
Const FreeRamStart = $516
Dim MyVariable As LongWord Absolute FreeRamStart
Dim MyArray(100) As byte Absolute FreeRamStart + 4
The project that I am working on right now needs USB CDC, SD file system, graphic LCD and buffered interrupt driven serial, so I will be doing quite a bit of this RAM allocation stuff in the next few days!
-
- Registered User
- Posts: 26
- Joined: Sun Oct 12, 2008 11:21 pm
- Location: Utah
I compiled my version with USART and had 1461 bytes of ram use. My program uses some where less than 70 bytes of ram. USB ram allocation begins at $4B8 (1208). I would need a min of ~250 bytes, the 224 bytes left at the top of the ram allocated for usb is not enough. After a couple rough calculations, i think there is only about 40 bytes left at the top not 224.
I did also note that the 18f2450 does not allocate the extra 512 bytes, since it isn't available. So I assume it is not nesessary to alocate that for USB to operate correctly. If one could remove that alocation on the 2550 series, you would have and extra 512 bytes to work with. To bad that is not an option.
How would one go about removing the extra alocation for the 2550. I somehow also believe that in addition to removing that allocation if one could move the normal USB alocation to a higher "RAM_START" address that we wouln't have to use absolute addressing to utilize the available ram space. Or does USB assume that its ram starts at the begining of dual port ram.
I have only started using SF a few months ago, so am pretty much a novice as to USB and ram alocation. Do you think the above is possible?
RD
I did also note that the 18f2450 does not allocate the extra 512 bytes, since it isn't available. So I assume it is not nesessary to alocate that for USB to operate correctly. If one could remove that alocation on the 2550 series, you would have and extra 512 bytes to work with. To bad that is not an option.
How would one go about removing the extra alocation for the 2550. I somehow also believe that in addition to removing that allocation if one could move the normal USB alocation to a higher "RAM_START" address that we wouln't have to use absolute addressing to utilize the available ram space. Or does USB assume that its ram starts at the begining of dual port ram.
I have only started using SF a few months ago, so am pretty much a novice as to USB and ram alocation. Do you think the above is possible?
RD
-
- Registered User
- Posts: 26
- Joined: Sun Oct 12, 2008 11:21 pm
- Location: Utah
Forgot one other problem. Since i am using timer1 in both the ISRTimer and USB also uses timer1 there is a conflict. I am using timer1 as a pseudo rtc to keep time when in a battery backup mode. So I need timer1 to be available. I would also need to have the USB modual use a different timer.
Sounding more and more like rewriting the CDC modual.
RD
Sounding more and more like rewriting the CDC modual.
RD
-
- Registered User
- Posts: 26
- Joined: Sun Oct 12, 2008 11:21 pm
- Location: Utah
Have found a different problem,
Why would the following two lines add 329 bytes to variable useage??
DispString = DecToStr(ValSet(19),2) + "/"+DecToStr(ValSet(20),2) + "/" + DecToStr(ValSet(21),2) + " "
DispString = DispString + DecToStr(ValSet(21),2) + ":" + DecToStr(ValSet(22),2) + ":" + DecToStr(rtcsec,2)
they compile with no problem!
RD
Why would the following two lines add 329 bytes to variable useage??
DispString = DecToStr(ValSet(19),2) + "/"+DecToStr(ValSet(20),2) + "/" + DecToStr(ValSet(21),2) + " "
DispString = DispString + DecToStr(ValSet(21),2) + ":" + DecToStr(ValSet(22),2) + ":" + DecToStr(rtcsec,2)
they compile with no problem!
RD
But it is, and very easy too. At the very bottom of USBConfig.bas you will find:I did also note that the 18f2450 does not allocate the extra 512 bytes, since it isn't available. So I assume it is not nesessary to alocate that for USB to operate correctly. If one could remove that alocation on the 2550 series, you would have and extra 512 bytes to work with. To bad that is not an option.
Code: Select all
#if _device in (18F2455, 18F2550, 18F4455, 18F4550)
#define USB_EXTENDED_RAM = true
#else
#define USB_EXTENDED_RAM = false
#endif
I would suggest you move the two main SD file system structures, which occupy 576 bytes and should therefore fit. In SDFileSystem.bas you will find the following:
Code: Select all
Dim Disk As TDisk
Dim File As TFile
As for your problem with the USB module competing for timer1, that is also something that I will need to sort out for my own project, so I can solve that one for you as well if you can wait a few days. I already have a number of updates to the USB library that I have done, mainly to provide support for CDC on the 18F87J50 series. Making it possible to specify which timer to use and supporting a user created interrupt dispatcher are also on the list. It will all end up in the Wiki eventually
EDIT: Forgot to mention that you can't move the beginning of the USB RAM usage upwards as the PIC's hardware requires its buffers to be at the beginning of this block.
-
- Registered User
- Posts: 26
- Joined: Sun Oct 12, 2008 11:21 pm
- Location: Utah
I modified the USBConfig.bas to remove the 18F2550 from the choices.
I modified the SDF file system as follows:
Dim Disk As TDisk Absolute $550
Dim File As TFile Absolute $650
Still recieved the ram error. Noticed the TDisk and TFile structures are only about 40 bytes each tho.
Removed that edit and changed the below buffer to use absolute, but recieved an error.
Structure TShared
CurrentSectorBuffer($200) As Byte Absolute $550
End Structure
Isn't this buffer what i would like to have in upper memory?
I can wait on the timer1 mod. Battery back is one of those nice things at this point in development.
Thanks for the input!
RD
I modified the SDF file system as follows:
Dim Disk As TDisk Absolute $550
Dim File As TFile Absolute $650
Still recieved the ram error. Noticed the TDisk and TFile structures are only about 40 bytes each tho.
Removed that edit and changed the below buffer to use absolute, but recieved an error.
Structure TShared
CurrentSectorBuffer($200) As Byte Absolute $550
End Structure
Isn't this buffer what i would like to have in upper memory?
I can wait on the timer1 mod. Battery back is one of those nice things at this point in development.
Thanks for the input!
RD
-
- Registered User
- Posts: 26
- Joined: Sun Oct 12, 2008 11:21 pm
- Location: Utah
realized i changed the structure instead of the alocation.
did this:
Structure TShared
CurrentSectorBuffer($200) As Byte
End Structure
Dim Disk As TDisk Absolute $530
Dim File As TFile Absolute $570
Dim Shared As TShared Absolute $5F0
#if SD_SUPPORT_MULTIPLE_FILES = TRUE
Dim StoredFiles(MaxFiles) As TFile
#endif
think i got enough seperation between them all, but still get the out of ram error.
Is there any way to determine what the actual alocation is, instead of just the error. would be nice if i knew i was getting closer.
RD
did this:
Structure TShared
CurrentSectorBuffer($200) As Byte
End Structure
Dim Disk As TDisk Absolute $530
Dim File As TFile Absolute $570
Dim Shared As TShared Absolute $5F0
#if SD_SUPPORT_MULTIPLE_FILES = TRUE
Dim StoredFiles(MaxFiles) As TFile
#endif
think i got enough seperation between them all, but still get the out of ram error.
Is there any way to determine what the actual alocation is, instead of just the error. would be nice if i knew i was getting closer.
RD
Yes, lie to the compiler about how much RAM is available. In USBSystem.bas you will find:RDHeiliger wrote:Is there any way to determine what the actual alocation is, instead of just the error.
Code: Select all
#if USB_EXTENDED_RAM
#variable _maxram = $0400
#else
#variable _maxram = $0200
#endif
Look at the above a little closer, and you will realise that the change to USB_EXTENDED_RAM that I suggested doesn't help, as the buffer space is grabbed from the below 1K RAM instead. It looks like you will need to move to a part with more RAM or use less in your own program. I have the USB and SD libraries running together and using about 860 bytes of RAM ( excluding the USB buffers in higher RAM ), so it should be possible to make it fit.
-
- Registered User
- Posts: 26
- Joined: Sun Oct 12, 2008 11:21 pm
- Location: Utah
I am not sure how the 512 byte buffer is used by USB when the "USB_EXTENDED_RAM" is set true. It says it is a public buffer. If it is not declared does not USB use the smaller TX and RX buffers already declared.
Here is what I tried, with success in getting it compiled.
Changed the USBConfig back to saying there is extended ram, which there is on a 18f2550. This allows the "_maxram" variable to stay at $400, and gives normal program compile space of 1K.
I commented out the section in USBCDC that allocates the public buffers in upper dual port ram so that it remains free for the SD buffers.
Leaving the below the same sets up USB for the 18f2550. And starts using extended dual port ram at $400.
Set the buffer and set Disk and File to use the dual port ram above $600.
I do get a compile this way with 633 variable bytes used. I need to make and assemble the circuit board to do an actual test. Will this work????
RD
Here is what I tried, with success in getting it compiled.
Changed the USBConfig back to saying there is extended ram, which there is on a 18f2550. This allows the "_maxram" variable to stay at $400, and gives normal program compile space of 1K.
Code: Select all
// ***************************************************************************
// does device support extended dual port RAM
// ***************************************************************************
#if _device in (18F2455, 18F2550, 18F4455, 18F4550)
#define USB_EXTENDED_RAM = true
#else
#define USB_EXTENDED_RAM = false
#endif
Code: Select all
// Public buffers - these are just mapped onto USB RAM space, thus saving
// program RAM. You can use a large 512 byte buffer, or two separate 256
// RX and TX buffers. Using WriteArray() with the large 512 byte buffer
// can give tranfer speeds of approximately 420KBytes/second (3.4 Mbits/second)
// although this figure will be affected by factors such as bus loading. Note
// that these buffers are only available for USB devices that have extended
// dual port USB RAM...
'#if USB_EXTENDED_RAM
'public const
'BufferRAM = $600,
'TXBufferRAM = BufferRAM,
'RXBufferRAM = BufferRAM + 256
'public dim
'Buffer(512) as byte absolute BufferRAM,
'TXBuffer(256) as byte absolute TXBufferRAM,
'RXBuffer(256) as byte absolute RXBufferRAM
'#endif
Leaving the below the same sets up USB for the 18f2550. And starts using extended dual port ram at $400.
Code: Select all
// see above...
#if _device in (18F2450, 18F4450)
#define _RAM_START = $498
#define _RX_SIZE = 32
#else
#define _RAM_START = $4B8
#define _RX_SIZE = 64
#endif
Code: Select all
Dim Disk As TDisk Absolute $530
Dim File As TFile Absolute $570
Dim Shared As TShared Absolute $5F0
#if SD_SUPPORT_MULTIPLE_FILES = TRUE
Dim StoredFiles(MaxFiles) As TFile
#endif
RD
-
- Registered User
- Posts: 26
- Joined: Sun Oct 12, 2008 11:21 pm
- Location: Utah
After poking around in the USBCDC modual, decided that the Public "BufferRAM" is not used internaly in the USB modual and is free to be used by user program.
I returned to using the USBCDC modual without any modifications. I only changed the buffer address in the SDFileSystem to absolute adress $600.
Compiling my entire program still leaves me with ~200 free bytes of ram.
I also solved the TMR1 error. It was just that both the USBCDC modual and ISRTimer modual trying to set high priority interupts. The USBCDC modual does not use timer1. There is one declaration for TMR1 but it is never used. Think it is left over from a prior version.
Added the below option to the my project:
RD
I returned to using the USBCDC modual without any modifications. I only changed the buffer address in the SDFileSystem to absolute adress $600.
Code: Select all
Structure TShared
CurrentSectorBuffer($200) As Byte
End Structure
Dim Disk As TDisk
Dim File As TFile
Dim Shared As TShared Absolute $600
#if SD_SUPPORT_MULTIPLE_FILES = TRUE
Dim StoredFiles(MaxFiles) As TFile
I also solved the TMR1 error. It was just that both the USBCDC modual and ISRTimer modual trying to set high priority interupts. The USBCDC modual does not use timer1. There is one declaration for TMR1 but it is never used. Think it is left over from a prior version.
Added the below option to the my project:
Code: Select all
//isrtimer options
#option TIMER_PRIORITY = ipLow