PIC18F27J53 and USB
Sebastien Lelong
Oliver Seitz
>- under Linux, plugging the board gives the following in /var/log/syslog
I've tried USB some time ago, and I got similar messages with too old kernels. And too old means anything before 2.6.32, I think.
Sometimes there are some messages even with newer kernels, but a device like /dev/ttyACM0 shows up, and it works.
Greets,
Kiste
Sebastien Lelong
Sebastien Lelong
mattschinkel
reserved so JALv2 knows how much ram is being used when compiling a
program with current device files.
From the post you showed, is this correct?
const USB_BASE_ADDRESS = 0x0200
or
const USB_BASE_ADDRESS = 0x0400
How big is USB RAM?
When reading over the USB generic sample, I see a direct read from
POSTINC1. This should not get called directly, it should be part of a
small buffer'get function:
function usb_buffer'get() return byte is
pragma inline
return POSTINC1
end function
I don't understand how the address POSTINC1 gets set, or how it knows
where to read memory.
I also noticed there are not enough comments in USB files. Maybe some
should be added to make it more understandable? Seb, if you have a
chance to add some comments why you look for a fix, please do!
Albert did not use PRINT library for debugging, this makes the current
implementation of debugging difficult. Again, not enough comments.
When I enable debugging, I mostly see a bunch of junk hex that I have
no clue about. I am still looking into USB MSD (mass storage), but I
have trouble sending data back to the PC. Troubleshooting methods are
limited, and so is my knowledge on USB.
Albert did make a great USB library, it seems that there are a few
small improvements that could be made.
Matt.
Oliver Seitz
> I don't understand how the address POSTINC1 gets set, or
> how it knows
> where to read memory.
It reads from the adress FSR1 points to, but in contrast to reading INDF1, FSR1 is incremented after the read. I had suggested not to use indirect adressing from a JAL program at all. If INDF or POSTINC or so is necessary, some lines of assembler should be used. This is because the compiler makes heavy use of indirect adressing, and you can never know if the pointer registers still contain the values you have loaded there.
Right now, the compiler only uses one INDF register. So using a second register on chips that have more than one is safe at the moment, but Kyle has already said that he might make use of more than one INDF register in the future.
Greets,
Kiste
Sebastien Lelong
> I don't understand how the address POSTINC1 gets set, or
> how it knows
> where to read memory.
It reads from the adress FSR1 points to, but in rcontrast to reading INDF1, FSR1 is incremented after the read. I had suggested not to use indirect adressing from a JAL program at all. If INDF or POSTINC or so is necessary, some lines of assembler should be used. This is because the compiler makes heavy use of indirect adressing, and you can never know if the pointer registers still contain the values you have loaded there.
Right now, the compiler only uses one INDF register. So using a second register on chips that have more than one is safe at the moment, but Kyle has already said that he might make use of more than one INDF register in the future.
Greets,
Kiste
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org
Rob Hamerling
Hi Seb,
On 2011/04/01 20:59, Sebastien Lelong wrote:
> During my USB "travel", I mentioned several issue regarding debug
> statement (see also issue 153). With the help of newfound from Microchip
> forums, I pointed another issue about USB base address (Rob, maybe we
> can work on this ?). I'll try to address both of these.
I would be glad to help, but you'll have to tell me more how!
Regards, Rob.
--
R. Hamerling, Netherlands --- http://www.robh.nl
mattschinkel
> previously mentioned. But, and that's my worry, I also had to switch back to
> jalv24n. Last jalv24o beta (1st Feb 2011) doesn't seem to handle properly
> print_string(serial_hw_data,str[]), producing garbage chars. I wonder if
> there's a trouble with array (wasn't it previously reported ?), and since
> USB descriptors use them extensively, it was stuck... That could be an
> explanation though I couldn't dig this more.
Matt.
Sebastien Lelong
print_string was fixed in jal 2.4o (compiled Mar 6 2011)
Sebastien Lelong
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
mattschinkel
memory USB is using.
It looks like I am making some small amount of progress on USB MSD
class. The HID generic sample was a good starting point, and I seem to
understand USB more now. The HID generic sample should be made into a
template for users to easily create new usb files of different
classes. Hmmm... maybe there's a networking class :)
Matt.
On Apr 1, 6:18 pm, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:
>
>
>
>
>
>
> > Hi Seb,
>
> > On 2011/04/01 20:59, Sebastien Lelong wrote:
>
> > During my USB "travel", I mentioned several issue regarding debug
> >> statement (see also issue 153). With the help of newfound from Microchip
> >> forums, I pointed another issue about USB base address (Rob, maybe we
> >> can work on this ?). I'll try to address both of these.
>
> > I would be glad to help, but you'll have to tell me more how!
>
> > Regards, Rob.
>
> > --
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jallib" group.
> > To post to this group, send email to jal...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jallib+un...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/jallib?hl=en.
>
> --
>
> - Show quoted text -
Sebastien Lelong
Sebastien Lelong
--
Rob Hamerling
Hi Seb,
On 2011/04/02 00:18, Sebastien Lelong wrote:
> So, to sum up:
> 1. is it possible to enrich device file with BDT memory location ?
> 2. is it possible to enrich device file with USB data memory location ?
Please open an issue for this. Keeps info together.
mattschinkel
sample):
const bit USB_EP0 = 1
const byte USB_EP0_OUT_SIZE = 8
const word USB_EP0_OUT_ADDR = ( USB_BASE_ADDRESS + 0x0010 )
const byte USB_EP0_IN_SIZE = 8
const word USB_EP0_IN_ADDR = ( USB_EP0_OUT_ADDR + USB_EP0_OUT_SIZE )
Of course, this does not reflect while compiling. Would it make sence
to reserve this memory with an array like this:
var byte ep0_reserve_memory[0x0010 + USB_EP0_OUT_SIZE +
USB_EP0_IN_SIZE] at USB_BASE_ADDRESS
I'm not sure where the 0x0010 comes from (I think it's in blogspot
somewhere). and this array would be removed by the compiler, so we
would have to use it in some way. Maybe with a dummy procedure
By reading the above, it appears that USB buffers do not take much
memory (depending on the application).
Matt.
On Apr 2, 1:03 pm, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:
> There's no hardware check about declared buffers size, if they are too big,
> behavior is unexpected. In order to know how much RAM is used you need count
> bytes in BDT.
>
> Cheers,
> Seb
>
mattschinkel
in usb_ep_data_out_callback(....,word in buffer_addr,......), we
currently have the following:
var byte src_ptr[2] AT buffer_addr
FSR1L = src_ptr[0]
FSR1H = src_ptr[1]
then each call of POSTINC1 reads one byte from the buffer
I would like to change this usage to the following:
1. Put this in the USB lib, before calling usb_ep_data_out_callback()
var byte src_ptr[2] AT buffer_addr
FSR1L = src_ptr[0]
FSR1H = src_ptr[1]
2. Create a inline usb_out_buffer'get function for POSTINC1
There is no need to change API. I will keep "word in buffer_addr" in
usb_ep_data_out_callback parameters, although it would no longer be
needed. These suggestions would not affect anyone's current code.
It took me longer then needed to figure out what these registers do
since they are not named well, and there are no comments.
Matt.
Sebastien Lelong
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
--
Oliver Seitz
>But what would be the benefits ?
>>2. Create a inline usb_out_buffer'get function for POSTINC1
If one day the compiler starts to use FSR1 internally, only this 'get function will have to be modified. Or, it can directly be written like
Increment pointer
ASSEMBLER
Load FSR with that pointer
Read back value from INDF
END ASSEMBLER
This would be safe for any additional FSRs the compiler may require. It will be a bit slower, but you can't always have maximum speed and versatility.
Greets,
Kiste
Sebastien Lelong
mattschinkel
another type of processor some day.
Matt.
Sebastien Lelong
Matt.
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
mattschinkel
usb_drv_cdc_class.jal and eventually MSD currently call those
registers, and no other registers. If we can call a procedure instead,
it will be simple to port this file to another processor if there are
usb driver files available.
So, is it ok with you Seb?
PS: I didn't actually read fully through usb_drv_cdc_class.jal to see
if it uses other registers, but I do know that I will not need any
others while writing a lib for msd class driver.
Matt.
mattschinkel
> to me
Matt.
Sebastien Lelong
Why overkill? there is no additional processing if it is inline.
mattschinkel
I am only a writer of a new class library. This should be made easy
for new writers of class libs.
alias may work.
Matt.
On Apr 3, 3:48 am, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:
> before/after. I understand your point about readability, you know how often
> I focus on this, but:
>
> - this readability occurs within an internal procedure (not exposed to
> users).
> - you'll get better readability within this procedure as POSTINC will fade
> way behind your pseudo-var, but your pseudo-var now inherits from this
> readability (you're moving the readability problem one step away
> - in any case you'll put a comment about POSTINC explaining what it does,
> so in the end, avoiding a pseudo-var for this + put a comment will bring the
> level of readability.
>
> Do you see what I mean ?
>
> Do I understand well when I say this pseudo-var would just be a getter or
> setter for POSTINC ? Why not using an alias instead, with a more human
> understable meaning ? Thinking about this, I would not recommend this too as
> it would hide the very specific usage/meaning of POSTINC behind a user
> variable (it would look like any other variable but would really be special
> as it acts on FSR).
>
> Cheers,
> Seb
>
>
>
>
>
> > > But what would be the benefits ?
>
> > readability, and standardization. Maybe we'll be running USB on
> > another type of processor some day.
>
> > Matt.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jallib" group.
> > To post to this group, send email to jal...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jallib+un...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/jallib?hl=en.
>
> --
Oliver Seitz
... Or, indeed add some overhead, like starting a new little lib like...
(untested, has to be extended to support 12 and 14bit cores, I think)
procedure dereference’put ( word in pointer, byte in value ) is
assembler
movff pointer, FSR0L
movff pointer+1, FSR0H
movff value,INDF0
end assembler
end procedure
procedure dereference’get ( word in pointer ) return byte is
var byte value
assembler
movff pointer, FSR0L
movff pointer+1, FSR0H
movff INDF0,value
end assembler
dereference=value
end procedure
This may take 15 instruction cycles where direct access to POSTINC takes only one or two, but it can be made quite versatile. It would be an approach to start using pointers without compiler support.
Greets,
Kiste
mattschinkel
example please?
This POSTINC1 sounds quite useful & fast. I wonder if it should be
used in sd & hard disk libraries with "if defined(POSTINC1)".
Matt.
Oliver Seitz
> I didn't quite understand the use of
> these procedures. Can you give an
> example please?
It's just a way of hiding the asm part from the user and access arbitrary memory locations in a clean and readable way. Example: Outputting bytes from memory locations 0x80 to 0xa0:
for 0x20 using counter loop
serial_hw_data=dereference[0x80+counter]
end loop
> This POSTINC1 sounds quite useful & fast. I wonder if
> it should be
> used in sd & hard disk libraries with "if
> defined(POSTINC1)".
It does in fact save quite a lot on execution time and also some code space, but I wouldn't use it outside ASM blocks too much as long as Kyle had not promised not to use it...
On PIC12,PIC16... there's only a INDF register for indirect memory access. PIC18 additionally has registers POSTINC, POSTDEC, PREINC and PLUSW which also do indirect memory acces, but modify the FSR value before or after that. Each INDF "module" comes in a group of all of FSRxL, FSRxH, INDFx, POSTINCx, POSTDECx, PREINCx and PLUSWx.
There are PICs that only have one INDF, and those that have three. The PICs with only one INDF do not have POSTINC, POSTDEC, PREINC or PLUSW. Kyle already said he might be using more than one INDF one day. If we did agree that INDF1 is reserved to the compiler and INDF2 is for users, great. But from what I know today, we should regard all INDF related registers as reserved.
Oliver Seitz
> Can you give an
> example please?
Here's a useful one, my favourite way of generating a random seed:
var byte randomseed
var word counter
for 65535 using counter loop
randomseed=randomseed+dereference[counter]
end loop
Some registers have definded values on startup, some don't. Those who don't contain values that may depend on...
- how long power was removed
- the speed of the supply rising
- electromagnetic interference during power-up
- cosmic radiation during power-up...
So it is highly possible that this loop will not yield the same value on each startup. I think it is the best source of entropy on startup without using additional hardware. ADC converters, where available, should be tested however, they may be even better entropy sources. Another idea would be to run ADC conversion at an out-of-spec rate. But that's another issue ;-)
Greets,
Kiste
Sebastien Lelong
mattschinkel
tested on, or maybe there is a way to detect if it is supported on the
current PIC. If it is not, use a normal array + counter method. Maybe
a lib could be created?
I'll have to test file read/write times on hard disk & sd card. If
there is a big difference, it would be worth it.
I guess I may have trouble anyways since whereis() doesn't work on
arrays or other variables.
Matt.
Oliver Seitz
> [...] or maybe there is a way to detect if it is
> supported on the
> current PIC.
As far as I know, if there is a POSTINC1, there's three sets of INDF registers with all the features.
But, to make use of a POSTINC register, you have to rely on the compiler not changing what you have written to the correspondent FSRxL, FSRxH registers. There's no way to find out but to check the contents of those registers, and this takes far more time than just setting the registers again before any access to a INDF register. For now it is confirmed that "the compiler does not use INDF1 or INDF2 yet." So, until this changes, it's no problem. But if this changes, trouble's ahead.
> If it is not, use a normal array + counter
> method.
I don't really know how the compiler handles arrays. But, if the compiler starts to use more than one INDF, array handling will probably speed up a lot.
> I'll have to test file read/write times on hard disk &
> sd card. If
> there is a big difference, it would be worth it.
If it is for copying sequential memory locations to other sequential memory locations, performance could rise a real lot, especially when using POSTINC1 *and* POSTINC2. One byte could then be copied in only 5 instruction cycles, while when only using one INDF, I think about 20 cycles are needed.
Greets,
Kiste
mattschinkel
compiler upgrade? I guess this is what you have been talking about
which I didn't quite understand.
Another thing to do is create a optional user constant for this (with
a warning comment), for USB and other libs. From previous tests, small
changes in a 512 byte array read loop made a big difference.
Personally, I would want to transfer files as quick as possible.
Matt.
Oliver Seitz
> "the compiler does not use INDF1 or INDF2 yet." So, until
> this changes, it's no problem. But if this changes,
> trouble's ahead.
>
> I see what you mean... So, this means USB could get broken
> by a
> compiler upgrade? I guess this is what you have been
> talking about
> which I didn't quite understand.
That's exactly what I meant :-)
> Another thing to do is create a optional user constant for
> this (with
> a warning comment), for USB and other libs. From previous
> tests, small
> changes in a 512 byte array read loop made a big
> difference.
> Personally, I would want to transfer files as quick as
> possible.
Of course I don't approve to slow things down just to keep a compatibility that is not needed. But again, it is perfectly safe to use these registers in an asm block, as the compiler will never interfere there.
Here some (untested) examples. The memcopy_dword procedure takes little more than three instruction cycles per copied byte. All procedures do only run on PIC18 cores.
Greets,
Kiste
procedure memcopy_bytes ( word in source_ptr, word in dest_ptr, byte in amount ) is
-- copies [amount] bytes from source memory location to dest.
-- amount=0 copies 256 bytes
var byte counter
counter=amount
ASSEMBLER
movfw source_ptr
movwf FSR1L
movfw source_ptr+1
movwf FSR1H
movfw dest_ptr
movwf FSR2L
movfw dest_ptr+1
movwf FSR2H
LOCAL copy_loop
copy_loop:
movfw POSTINC1
movwf POSTINC2
decfsz counter,f
goto copy_loop
END ASSEMBLER
end procedure
procedure memcopy_words ( word in source_ptr, word in dest_ptr, byte in amount ) is
-- copies [amount] words from source memory location to dest.
-- amount=0 copies 256 words=512 bytes
var byte counter
counter=amount
ASSEMBLER
movfw source_ptr
movwf FSR1L
movfw source_ptr+1
movwf FSR1H
movfw dest_ptr
movwf FSR2L
movfw dest_ptr+1
movwf FSR2H
LOCAL copy_loop
copy_loop:
movfw POSTINC1
movwf POSTINC2
movfw POSTINC1
movwf POSTINC2
decfsz counter,f
goto copy_loop
END ASSEMBLER
end procedure
procedure memcopy_dwords ( word in source_ptr, word in dest_ptr, byte in amount ) is
-- copies [amount] dwords from source memory location to dest.
-- amount=0 copies 256 dwords=1024 bytes
var byte counter
counter=amount
ASSEMBLER
movfw source_ptr
movwf FSR1L
movfw source_ptr+1
movwf FSR1H
movfw dest_ptr
movwf FSR2L
movfw dest_ptr+1
movwf FSR2H
LOCAL copy_loop
copy_loop:
movfw POSTINC1
movwf POSTINC2
movfw POSTINC1
movwf POSTINC2
movfw POSTINC1
movwf POSTINC2
movfw POSTINC1
movwf POSTINC2
decfsz counter,f
goto copy_loop
END ASSEMBLER
end procedure