Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Benj

  • Rank
  1. Hello Tim ECIOs are essentially a USB enabled microcontroller device complete with USB bootloader and capable of supplying power to other devices from the USB power.
  2. Jac your a star, Many thanks for looking into this. Dave, sorry for blaming the compiler I was sure I had been through and taken our all the hardcoded addresses. Obviously I missed these ones hidden away inside a function. You should receive an ECIO in a couple of days so hopefully this will help you to forgive me. Also it will work fine with the PICpack or Flowcode so feel free to have a play. Thanks for everyones responces and help to get this problem under control. USB is now finally available for all USB PIC targets using BoostC
  3. Hi Dave Thanks for the reply. Im sure you can see that adding USB support is great for both your compiler and for your customers. Also theres really not that much to the USB software driver, Its just Microchips USB stack that can be a bit of a mental challange. I can provide you with one of our ECIO 18F4455 devices and a Flowcode implementation of the USB software if you require. This seems to be able to replicate the problem quite well as memory space is available at 0x400 and 0x500. If you PM me with your address then I will arrange to send the hardware and software out to you.
  4. Can anyone see any reason why this wouldnt work correctly at 0x0480 when it does work at 0x0500? #define USB_EP0_OUT_SIZE 8 #define USB_EP0_OUT_ADDR 0x0480 uns8 buffer_0_out[uSB_EP0_OUT_SIZE]@ USB_EP0_OUT_ADDR; Im not going to give up on this. At least not yet Ben Embedded Engineer Matrix Multimedia
  5. Hello Tim Thats great news glad you've got it working. Also glad you've managed to replicate my problem. Anyone at Sourceboost up for giving this a go? Like I said the code all looks correct so it is my opinion that it is somehow the compiler that is at fault.
  6. Hello Tim I think that your problem is this line. #pragma DATA _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC4_PLL6_1L & _USBDIV_2_1L I think it should be like this. #pragma DATA _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L But I can never really tell with these word things. Much better to assign a number in my opinion. Much less hit and miss. This should work a lot better with your 20MHz crystal. #pragma DATA 0x300000, 0x24 #pragma DATA 0x300001, 0xf #pragma DATA 0x300002, 0x3f #pragma DATA 0x300003, 0x1e #pragma DATA 0x300004, 0x0 #pragma DATA 0x300005, 0x83 #pragma DATA 0x300006, 0x81 #pragma DATA 0x300007, 0x0 #pragma DATA 0x300008, 0xf #pragma DATA 0x300009, 0xC0 #pragma DATA 0x30000a, 0xf #pragma DATA 0x30000b, 0xE0 #pragma DATA 0x30000c, 0xf #pragma DATA 0x30000d, 0x40
  7. Hello Tim You should be able to use these configuration settings to get your device up and running.... You can use the following crystal speeds: 4, 8, 12, 16, 20, 24, 40, 48MHz Your configuration settings should then match these settings to get the USB to run correctly. USB Clock Selection - clk src from 96MHz PLL/2 CPU Sys CLK Select - no divide OCS Select - Match the value of your crystal Oscillator - HS: HS+PLL, USB-HS USB Voltage Regulator - Enabled Watchdog timer - Disabled Other options can be enabled or disabled at will. However be careful with the protect options and ensure that they are all set to disabled otherwise you can lock up your chip so it cannot be reprogrammed. If you get it working try adjusting the buffer address to an address under 0x500. You will notice that this causes the program to fail for no apparent reason.
  8. Hello Ok my code to assign the buffer addresses looks like this. As soon as I take an endpoint adress below 0x500 I get 0's returned. #define USB_EP0_OUT_SIZE 8 #define USB_EP0_OUT_ADDR 0x0500 #define USB_EP0_IN_SIZE 8 #define USB_EP0_IN_ADDR 0x0508 #define USB_EP2_IN_SIZE 8 #define USB_EP2_IN_ADDR 0x0510 #define USB_EP3_OUT_SIZE 8 #define USB_EP3_OUT_ADDR 0x0518 #define USB_EP3_IN_SIZE 8 #define USB_EP3_IN_ADDR 0x0520 typedef struct _buffer_descriptor { uns8 stat, count; uns16 addr; } buffer_descriptor; buffer_descriptor bd0out@0x400; buffer_descriptor bd0in @0x404; buffer_descriptor bd1out@0x408; buffer_descriptor bd1in @0x40C; buffer_descriptor bd2out@0x410; buffer_descriptor bd2in @0x414; buffer_descriptor bd3out@0x418; buffer_descriptor bd3in @0x41c; buffer_descriptor bd4out@0x420; buffer_descriptor bd4in @0x424; buffer_descriptor bd5out@0x428; buffer_descriptor bd5in @0x42C; buffer_descriptor bd6out@0x430; buffer_descriptor bd6in @0x434; buffer_descriptor bd7out@0x438; buffer_descriptor bd7in @0x43C; uns8 buffer_0_out[USB_EP0_OUT_SIZE]@ USB_EP0_OUT_ADDR; uns8 buffer_0_in [USB_EP0_IN_SIZE] @ USB_EP0_IN_ADDR; #ifdef USB_EP1_IN_SIZE uns8 buffer_1_in [USB_EP1_IN_SIZE] @USB_EP1_IN_ADDR; #endif #ifdef USB_EP1_OUT_SIZE uns8 buffer_1_out [USB_EP1_OUT_SIZE] @ USB_EP1_OUT_ADDR; #endif #ifdef USB_EP2_IN_SIZE uns8 buffer_2_in [USB_EP2_IN_SIZE] @ USB_EP2_IN_ADDR; #endif #ifdef USB_EP2_OUT_SIZE uns8 buffer_2_out [USB_EP2_OUT_SIZE] @ USB_EP2_OUT_ADDR; #endif #ifdef USB_EP3_IN_SIZE uns8 buffer_3_in [USB_EP3_IN_SIZE] @ USB_EP3_IN_ADDR; #endif #ifdef USB_EP3_OUT_SIZE uns8 buffer_3_out [USB_EP3_OUT_SIZE] @ USB_EP3_OUT_ADDR; #endif The odd thing is that the buffer descriptors at 0x400 work ok its just the buffer arrays that seem to fail.
  9. Hi Dave It seems that variable arrays under 0x500 have a problem. The code is all dynamic so I assign a array of data with the address 0x500. This works fine. I then change the address to 0x480 for example and the code stops working and returns 0's. (obviously I can only do this on the devices with USB RAM above 0x500, devices without USB RAM over 0x500 do not work at all) If you like I can wrap the code up into a sourceboost project and this way you might be able to spot the problem. Mainly this topic is seeing if anyone has got the USB working with a 18F2450, 4450, 14K50 using BoostC? Hi Tim The 18F2550 devices do not exhibit the problem as they have USB RAM memory above 0x500 hex. Seems your problem could be a incorrect configuration setting or crystal value.
  10. Hi Reynard The descriptors should be at 0x400 for the 18F2450 and the 18F4450 but the 18F14K50 has its USB RAM starting from location 0x200.
  11. Hello Ok I am having a very strange problem using the USB library from PICpack when used with any of the following 18F2450, 18F4450, 18F14K50. http://embeddedadventures.blogspot.com/200...1-released.html I am changing the addressing to match the USB RAM space. Here is the .map file that shows the USB descriptors in the correct memory space. 00000200:00000020 gbl_bd0out bd0out 00000204:00000020 gbl_bd0in bd0in 00000208:00000020 gbl_bd1out bd1out 0000020C:00000020 gbl_bd1in bd1in 00000210:00000020 gbl_bd2out bd2out 00000214:00000020 gbl_bd2in bd2in 00000218:00000020 gbl_bd3out bd3out 0000021C:00000020 gbl_bd3in bd3in 00000220:00000020 gbl_bd4out bd4out 00000224:00000020 gbl_bd4in bd4in 00000228:00000020 gbl_bd5out bd5out 0000022C:00000020 gbl_bd5in bd5in 00000230:00000020 gbl_bd6out bd6out 00000234:00000020 gbl_bd6in bd6in 00000238:00000020 gbl_bd7out bd7out 0000023C:00000020 gbl_bd7in bd7in 00000280:00000040 gbl_buffer_0_out buffer_0_out 00000288:00000040 gbl_buffer_0_in buffer_0_in 00000290:00000018 gbl_buffer_1_in buffer_1_in I am also able to replicate the problem with a 18F2455. Basically if the USB buffers are located at position 0x500 of memory then everything works fine. If I change the location to anything lower then 0x500 then the USB stops working and I simply get sent 0's as the USB descriptor. Is there a problem with referencing locations below 0x500? Has anyone got the BoostC compiler working with the USB peripherals on the 18F2450, 18F4450, 18F14K50 devices? Microchip fixed this problem in their stack by removing the line stating that code started at location 0x500. I am sure my settings are correct because I have done lots of work previously with USB and am now certain that all of my settings are correct. This leads me to beleive that the problem is with the compiler itself. I have also tried compiling with optimisation set to off but this resulted in the same problem. Any help would be appreciated.
  12. Hello Reynard Yes V6.95 of the compiler solved the problem. Many thanks. Ben
  13. Hello I am having a strange problem when compiling a program using BoostC v6.90 and a 16F device. I am compiling via Flowcode but the C code that is being generated is correct. If I compile the following then my program works fine. FCV_OUT = 1; for (FCLV_LOOP1=0; FCLV_LOOP1<8; FCLV_LOOP1++) { FCD_LEDarray0_LEDOn(FCV_OUT); delay_ms(150); FCD_LEDarray0_LEDOff(FCV_OUT); FCV_OUT = FCV_OUT + 1; } However if I change this to the following then I get the problem. FCV_OUT = 0; for (FCLV_LOOP1=0; FCLV_LOOP1<8; FCLV_LOOP1++) { FCD_LEDarray0_LEDOn(FCV_OUT); delay_ms(150); FCD_LEDarray0_LEDOff(FCV_OUT); FCV_OUT = FCV_OUT + 1; } From looking at the CASM file I can see what is causing the problem. Here is a section of the CASM file without the problem. FCV_OUT = 1; 00BE 3001 MOVLW 0x01 00BF 1283 BCF STATUS, RP0 00C0 00BE MOVWF gbl_FCV_OUT for (FCLV_LOOP1=0; FCLV_LOOP1<8; FCLV_LOOP1++) 00C1 01BF CLRF gbl_FCLV_LOOP1 00C2 label24 00C2 3008 MOVLW 0x08 00C3 023F SUBWF gbl_FCLV_LOOP1, W 00C4 1803 BTFSC STATUS,C 00C5 28BE GOTO label23 00D1 0ABF INCF gbl_FCLV_LOOP1, F 00D2 28C2 GOTO label24 { FCD_LEDarray0_LEDOn(FCV_OUT); 00C6 083E MOVF gbl_FCV_OUT, W //<----- Working correctly 00C7 00C0 MOVWF FCD_LEDarr_00049_arg_WhichLED 00C8 2078 CALL FCD_LEDarr_00049 And here is the same section of the CASM file with the problem. FCV_OUT = 0; 00BE 1283 BCF STATUS, RP0 00BF 01BE CLRF gbl_FCV_OUT for (FCLV_LOOP1=0; FCLV_LOOP1<8; FCLV_LOOP1++) 00C0 01BF CLRF gbl_FCLV_LOOP1 00C1 label24 00C1 3008 MOVLW 0x08 00C2 023F SUBWF gbl_FCLV_LOOP1, W 00C3 1803 BTFSC STATUS,C 00C4 28BE GOTO label23 00D0 0ABF INCF gbl_FCLV_LOOP1, F 00D1 28C1 GOTO label24 { FCD_LEDarray0_LEDOn(FCV_OUT); 00C5 3000 MOVLW 0x00 //<----- Problem occurring 00C6 00C0 MOVWF FCD_LEDarr_00049_arg_WhichLED 00C7 2078 CALL FCD_LEDarr_00049 As you can see instead of the FCV_OUT variable being loaded into the W register the constant value 0 is being loaded. If I change the for loop to a while loop then the problem also dissapears. Is this a bug in the optimiser or something similar. Here are my compiler and linker parameters. Compiler: -v -t PIC%p "%f.c" Linker: -ld "C:\\Temp\\Flowcode v4\\BoostC\\lib" libc.pic16.lib flowcode.pic16.lib float.pic16.lib "%f.obj" -t PIC%p -d "%d" -p "%f" Thanks.
  14. Hello I have a customer that is trying to use a 12F510 PICmicro device. I notice that there is not a .h file for this PICmicro in the BoostC directory. Is it a simple case of creating a header file for this PICmicro or are there further complications. (such as the device not having a tris register) If so then is this device ever likely to be supported by BoostC. Thanks
  15. The latest librarby build of the floating point libs is included in the lastest SourceBoost software package.Download it from here:http://www.sourceboost.com/CommonDownload.html Regards Dave Thanks Dave. Once again you have sorted me out. Many Thanks
  • Create New...