Jump to content
M-atthias

Bit-Bang USB on MSP430G2452

Recommended Posts

just curious... @oPossum, @JWoodrell

 

the original "as" code has a lot of local near jumps that has the +, -, ++, -- local label syntax.

 

i found out that "gas" has 1:, 2:, ... with jmp 1f, 2f, 1b, etc. (for forward and backward).

 

are there equivalents for CCS and how do they do like?

Share this post


Link to post
Share on other sites

No exact equivalent in CCS. See section 3.8.2 of SLAU131 for an explanation of local labels. Those are the only label that work in macros and can also be used elsewhere. Right now I am using some outside of the macros, but will change that eventually to make the code more portable.

Share this post


Link to post
Share on other sites

C code has been written for everything that can be done in C - and it still is working.

 

Should compile with GCC with few if any changes,

 

The assembly code that remains will require some changes to work with GAS. Probably less than an hour of work.

 

Hope to post the code tomorrow. Have a few things to clean up.

Share this post


Link to post
Share on other sites

I will wait for OPossum's code rather than recoding the whole project myself.  I will look at improving what I can where I can.  I am not at good at coding as Opossum, and doing double work doesn't seem productive

Share this post


Link to post
Share on other sites

happy holidays. a quick report.

 

i had oPossum's code compiled and run on windows 7 via cygwin.

 

i wrote a short perl script to convert .asm files to .S files, again, apart from the "." / dot directives, the main differences are the local label / jumps.

 

i do need to manually "relocate"  ;-)  port1 interrupt by writing the address of USB_Sync() to the jump table directly.

 

the CCS relocation is done w/

 

 

 

    .sect ".int02"                      ;
    .short  USB_Sync                    ; 03: 0FFE4  Port 1
                                        ;
    .end                                ;

 

i tried w/ ld, supplying

 

 

--gc-sections,--section-start=.int02=0x0ffe4
 
but ld not happy, so i "vi"ed the hex file (also need to correct checksum)
 
from
 

 

...
:10FF2E000020003400330030003405010902A10125
:10FF3E000901A100050919012903150025019503E1
:10FF4E00750181029501750581030501093009319D
:0EFF5E0009381581257F950375088106C0C0FE
:06FF6C003A024B00C30045
:10FFE00012F912F912F912F912F912F912F912F9B9
:10FFF00012F916F912F912F912F912F912F900F8B8
:040000030000F80001
:00000001FF

 

 
to
 

 

...
:10FF3E000901A100050919012903150025019503E1
:10FF4E00750181029501750581030501093009319D
:0EFF5E0009381581257F950375088106C0C0FE
:06FF6C003A024B00C30045
:10FFE00012F912F936FC12F912F912F912F912F992
:10FFF00012F916F912F912F912F912F912F900F8B8
:040000030000F80001
:00000001FF

 

:10FFE00012F912F936FC12F912F912F912F912F992

i found out the address from a .lst file and force it into 0xffe4 (port1 interrupt)

 

now someone tell me how to do this properly via the gcc tool-chain.

 

so now am off the work bench for two days, will clean-up / write-up at end of this week.

 

 

 

/EDIT....

btw, i had it on f2012

footprint w/ gcc

 

 

   text    data     bss     dec     hex filename
   1932       6      72    2010     7da bbusb.elf
   1932       6      72    2010     7da (TOTALS)

footprint w/ as (original from mercrimus)

 

 

P2HEX/C V1.42 Beta [Bld 85]
© 1992,2012 Alfred Arnold
Mecrimus-B-32768Hz.p==>>Mecrimus-B-32768Hz.hex  (1890 Bytes)
46008faeb0189c1fa1f9b8a966b29673 *Mecrimus-B-32768Hz.hex

remember oPossum's enhancements had made it 'C' friendly (the DCO adjustment and protocol handling already in C).

 

 

 
 
 
 

Share this post


Link to post
Share on other sites

I have written USB transmit code that does on-the-fly CRC calculation. Seems to be working, but have some more testing to do.

 

This eliminates the need to call CRC() in bbusb_packet.c and makes the software SIE behave more like a hardware SIE that handles the CRC for you.

 

Preliminary code attached for anyone interested in studying it.

bbusb_tx_crc.zip

Share this post


Link to post
Share on other sites

I will implement my version of the code to save code size once I can get the interface to work...  it compiles and "runs" but it s not talking to the pc...  I am troubleshooting my setup to figure out what doesn't like what

Share this post


Link to post
Share on other sites

i guess this would reduce the size?

 

No, it is larger due to the use of a CRC table. I tried to write a smaller tx, but couldn't find enough clock cycles to make it work, The 4 cycles required for output and the lack of conditional execution (like PIC) is a real killer,

Share this post


Link to post
Share on other sites

the CCS relocation is done w/

    .sect ".int02"                      ;
    .short  USB_Sync                    ; 03: 0FFE4  Port 1
                                        ;
    .end                                ;

i found out the address from a .lst file and force it into 0xffe4 (port1 interrupt)

 

now someone tell me how to do this properly via the gcc tool-chain.

 

 

ok, answering myself. for gcc / gas the .sect ".int02" is ignored.

 

i asked gcc to produce an assembly file and peek into it and learn the trick.

 

if we are to use "USB_Sync" as the interrupt entry point (port1) we just need to place this two lines in front.

 

ie. label the location as __isr_2 and make it global for linking. i guess __isr_2 is the position for port1 in the interrupt table. we can find out from datasheet.

 

 

.global __isr_2
__isr_2:
USB_Sync:                               ; Entry point of interrupt^M
    push    r9                          ;^M
    push    r10                         ;^M
    mov     #usbin, r9                  ;^M
                                        ;^M
USB_Quick_Resync:                       ;^M
    mov     #usbminus, r10              ;^M

 

bbusb_gcc.tgz contains oPossums code (the one w/o the immediate crc calc). i changed the .asm files to .S files so that it can be built in mspgcc. there is also a "build" script to do that and u need to change some path / MMCU device name for your purpose, i am using f2012.

 

if everything goes well, u will find a "Mouse 430" HID device.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×