Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by ppulle

  1. Hi Andrew, Thanks for the advice, your comment on simply creating the file using the PC and navigating along that will do fine for my initial application. Noted are the licencing requirements for commercial implementation, didn't think of that. Fortunately at the moment I'm using banks of eeprom chips (for size, SD/MMC are too big) for my commercial apps, just exploring the use of SD/MMC right now. Also noted are your comments on the AN1003 implementation. From a cursory read I had thought that they were simply passing/re-interpreting SCSI commands from the PC to the card, from your advice it looks like they are not using a file system on the card. Bit of a pointless app note in that regards. One question, on the schematic, it's clear that you're level shifting the signal lines to the SD card because your processor is running at 5V.....is this necessary if I'm running my processor at 3.3V (I'm guessing not)? Thanks Phil A contradition in terms. Would you like FAT or Simple? You can download working reference schematics from my web site on the projects page. AN1003 does NOT implement FAT. You cannot pull the card out of the AN1003 hardware implementation and read it on a PC. The PC must read the card via the AN1003 code implemented on the PIC. I have implementations of SD/MMC card utilities and SD/MMC card file system for CCS and Microchip C18 compilers. They are not free but they are are not expensive considering it is around 5000 lines of code (with sample data logger application). An alternative you might consider is to format an SD/MMC card on a PC and then create a single file of nothing of the desired length (1G for example). What this will do is create a file of contiguous sectors on the media. With this scenario, you do not really need a full fat implementation, you have to be able to discover the start sector of the file but after that you just keep going from sector to sector. There is no need to keep and maintain file system data structures, instead you need to maintain some simple pointers. PC software will be able to read the file. <{POST_SNAPBACK}>
  2. Hi, I'm looking for any examples of implenting a simple FAT file system on a SD/MMC card connected to 18F2550/18F4550 device, including schematics if possible. I know of Microchips AN1003, which is a little too complex, I'm after something to do some simple data logging, pull the card out and read it in a PC. I've also read EPE mags November 2006/Decemeber 2007 Pic'N'Mix columns which show something like what I'm after, all in assembly though....I was wondering if anyone has done a Sourceboost version. Thanks Phil
  3. I'm having the same non incrementing of TMR1 as the original post. I noticed this thread when searching for a solution. I copied the code above into SB6.60, set my target to 18F2550 and compiled/simultated. The registers in the register view have the correct changes (ie the inital values+TMR1ON bit set when configured).....however no matter how long you wait (or at least a good 5 mins anyway)...the timer registers dont increment. Could be a simulator bug (if the code works under the MPLAB sim, then that implies the compiler is OK. Or else is there some configuration bit that needs to be set to make Timer1 work? Phil
  4. Hi, Heres a little enhancement that might be handy. I was shifting bits around a few watch variables in binary mode and when there was a leading zero the value would jump about because the watch window is left justified....made things a little difficult to follow. Could you sneak in an enhancement to either right justify the watch window or put leading zeros in so that a value of say '1010' appears as '00001010'? Phil
  5. I just had an idea that may be workable, and applicable to all the other Microchip code for USB (eg mass storage etc). Could we create a library file in C18, not modifying the Microchip code at all and then simply link it into a Sourceboost project? Is this possible, or are the library formats incompatible? Phil PS: In trying to verify my system could handle the Microchip CDC virtual comm port I used the firmware from this project: http://www.instructables.com/id/EV9KA88GBMEQZJJOR5/ in my 18F2550 proto board. Unfortunately it didn't work with an old IBM R31 system (USBv1.1). The device enumerated, and showed up as a Microchip device in the 'Other' section of device manager, but no virtual comm port was created. Still not sure if I've installed the driver correctly, if anyone has a link to a known good and complete driver package that'd be appreciated.
  6. Hi All, Unfortunate news with regards to the CDC port to Sourceboost. Just got word from Microchip Legal dept and apparently you're allowed to use the code in products you make yourself that use Microchip chips....but because the code is not open source/freeware we're not allowed to open the port to anyone else, ie publish the port publically. Sorry about that...but that's the word from Microchip. Phil
  7. Hi, Just to report on our cdc port. We've gotten the device to connect, get enumerated and Geoff managed to even get a virtual comms port connection (but accidentally stepped on a loose bit of code and jumbled things a bit). Some memory/rom allocation issues need to be sorted. Almost there. I've updated my WinXP to SP2....a question. My PC is an old IBM R31 laptop, with only USB 1.1 ports. The upgrade to SP2 put usbser.sys on my system, which wasn't there before. This system driver is mentioned in the microchip app notes. The CDC port specifies a USB2.0 configuration. What happens when you connect a USB2.0 device into a USB1.1 system, is it simply a slow down in data rate, or are there protocol issues related to the CDC that might prevent me from getting a virtual comm port? IE is a virtual comm port via usbser.sys only available in a usb 2.0 system. If so, is there a way to do virtual comm ports on a USB 1.1 system?. I have a usb/rs232 converter, but it uses a vendor specific driver (and the interface configuration thusly specifies a vendor specific protocol).... Phil
  8. Hi, Sounds like you're having the fun of a CDC port. Myself and Geoff are making an effort at this, we've compiled the code and got it to the stage where it gets an address from the host, but are having mystery problems at the moment. Check out the porting forum and PM either of us, maybe another set of eyes can help. Phil
  9. >Read the licence agreement - the problem is not the porting it is the sharing of code. >Effectively you are sharing code that is copyrighted (is owned by) a third party. The >problem is solvable. CCS make available a ported version of the stack to their >registered users however bundled into the package file is the Microchip licence >agreement which must be accepted befoe the software will install. > Well any advice on making this all nice and legal much appreciated....perhaps an email from Pavel or Dave to Microchip?? Would love to make contribution a part of the sourceboost package, particularly if we can figure out how to compile it as a lib. As an aside, could the Microchip CDC package get compiled using PICC18....then reused as a lib in Sourceboost.....that'd be another way of getting USB into Sourceboost.....or at least a set of instructions on compiling/library making and using from another compiler would be very handy. I've tried half heartedly to get the PICC18 CDC code going, but am stumbling on it's bootloader configuration...anyone done a PICC18 CDC compile for standalone/non bootloader use? What would I need to reconfigure, fuses certainly, but also execution startup/reset vectors etc. Anyway the port is still chugging along. The codebase is now connecting to the host and there is some IRB exchanges, the device gets assigned a USB address...however is not going beyond the addressing stage to configuration. A question to USB experts. After the device is addressed, how can I check if the configuration information is being transmitted...any ideas on a usb analyser that goes deep or other ways to check. I'm using USB Monitor from HDD and USB Trace from SysNucleus...but am not getting details from the device showing up on the trace.... Assuming the worst and that my microchip usb driver is not installed properly, will these packages show the device/config decriptors being transmitted before the driver or host sends the device into suspend? Does the device descriptor get transmitted, checked and rejected (if it doesn't match a usb driver) before config descriptor or do they go together even if the device will be rejected? I'm trying to guess if I am tranmitting the config/descriptor data, but because of some driver issue, maybe these analysers are not showing it. I'm guessing that they hook into the driver system a bit higher up than low level data tracing, if the driver doesn't load I would imagine in this case the high level hooks wouldn't work. Of course if I can't get the usb device to work properly...I can't tell if the driver will load properly....got a little chicken and egg situation at the moment. Phil
  10. >I looked at porting this code to source boost a few months ago. However after reading >the terms and conditions of the Microchip licence agreement and pursuing it with >Microchip I came to the conclusion it was not viable to do this to be able to share code >with other forum members. Any attempt to share code with other team members in a >usable way would be in violation of the Microchip licence agreement. Oh dear....well just a quick status report, we've made a lot of progress. Geoff has done an astounding job at getting the codebase to compile, sorting out issues like anonymous unions and the like. We've still got a ways to go with regards to function pointers and some mechanical stuff...but it's looking good. It'd be a pity not to be able to share it. Phil
  11. >>Memory Usage Report >>=================== >>RAM available:2048 bytes, used:475 bytes (23.2%), free:1573 bytes (76.8%), >>Heap size:1573 bytes, Heap max single alloc:127 bytes >>ROM available:32768 bytes, used:3427 bytes (10.5%), free:29341 bytes (89.5%) Well you've gotten futher than me to the point where it links! I've PM'd you with email details. Just point me to any areas you want me to work on and I'll get to it. Phil
  12. Hi, I'm trying to get a Sourceboost version of the Microchip CDC RS232 emulator going. Trying a couple of ways, this question is on porting the CDC source tree to Sourceboost. In the various typedefs used by the Microchip code, there are unions defined similiar to this: typedef union _CTRL_TRF_SETUP { /** Array for indirect addressing ****************************************/ struct { byte _byte[EP0_BUFF_SIZE]; }; /** Standard Device Requests *********************************************/ struct { byte bmRequestType; byte bRequest; word wValue; word wIndex; word wLength; }; ///and many more Where different parts of the code will refer to the same piece of memory as either the array ._byte[] or .bmRequestType and so on. In memory bmRequestType would be the same as _byte[0]. This isn't quite what Sourceboost is expecting. It requires a name to the structure: For example from usbdefs_ep0_buff.h typedef union _CTRL_TRF_SETUP { /** Array for indirect addressing ****************************************/ struct { byte _byte[EP0_BUFF_SIZE]; } b; /** Standard Device Requests *********************************************/ struct { byte bmRequestType; byte bRequest; word wValue; word wIndex; word wLength; } request; ...etc So an access to a variable of _CTRL_TRF_SETUP would be avariable.b._byte[0] == avariable.request.bmRequestType Source code will have to be modified to add the extra reference to the structure of the union you are referring to. I realise this is 'proper C' from K&R. I can live with this...but it is a bit tedious. Is there no way to have sourceboost use the union without the reference?? Another question is on the bit fields eg (another part of the union above): struct { unsigned Recipient:5; //Device,Interface,Endpoint,Other unsigned RequestType:2; //Standard,Class,Vendor,Reserved unsigned DataDir:1; //Host-to-device,Device-to-host unsigned :8; byte bFeature; //DEVICE_REMOTE_WAKEUP,ENDPOINT_HALT unsigned :8; unsigned :8; unsigned :8; unsigned :8; unsigned :8; } endpoint; //I've added the endpoint union structure reference here. Now the unused or 'blank' definitions can easily be dealt with as struct { unsigned Recipient:5; //Device,Interface,Endpoint,Other unsigned RequestType:2; //Standard,Class,Vendor,Reserved unsigned DataDir:1; //Host-to-device,Device-to-host unsigned char n0; byte bFeature; //DEVICE_REMOTE_WAKEUP,ENDPOINT_HALT unsigned char n1; unsigned char n2; ...... and so on How to handle the bit fields? Will instances of code using these bit field references have to be re-written to use a whole unsigned char: eg: aVariable.Recipient = 0x03; //as it would have been called in PICC18 or aVariable.endpoint.Recipient = 0x03; //with union reference be written with a declaration and all code instances as below: struct { unsigned char RecipTypeDir; //combining all above bit fields unsigned char n0; byte bFeature; //DEVICE_REMOTE_WAKEUP,ENDPOINT_HALT unsigned char n1; ....and the rest } endpoint; aVariable.ReciptTypeDir = (aVariable.ReciptTypeDir & 0x07) | (0x03<<3) //mask old bits, and assign new ones yuk.....any better ideas? Any handy macros or methods to catch and deal with lots of instances of these, or will I be doing a line by line port? Phil PS: I might have got my bits around the wrong way in the last example....but you get the drift.
  13. Cool. I've begun a bit more research myself. Looks like I need to do more work with the handling of comms class devices. At the moment I'm trying to convert the Microchip source detailed in their AN956 app note to work with Rob Langs mouse example on the SourceBoost site. A couple of questions: The AN956 code defines endpoints EP2 and EP3....is it reasonable to assume that their corresponding driver will also talk to these, and that not defining EP2/EP3 will mean the thing won't work. Simple reason for this actually, in the Lang code buffers are allocated in the 18F2550 dual port ram. Currently I've left the definition for EP0 as is, I've given EP1 a teeny buffer and define proper size buffers for EP2/EP3. The Lang code as it stands seems to use EP0 for starting the USB connection, sending the usb descriptor and configuration information etc......is there a requirement in the USB spec to use EP0 for this? To start things off below is the descriptor table ported from the Microchip code for use with a RS232 emulator...note some defines need to be taken from the Microchip code...it won't compile as is. Just copy/paste from that code tree when a symbol doesn't compile. This descriptor defines two interfaces, three endpoints and four function descriptors. All I've done really is de-structure the Microchip structures into the single array used in the Lang code. Next I need to know how to implement the CDC RS232 functions....time to rummage through Microchips code again. Phil PS: anyone with experience in the comms class for usb...feel free to join in! // The following descriptors are based on the example given by // Thorsten Klose on the internet char DeviceDescriptor [] = {18, // 18 bytes long DEVICE, // descriptor type 0x10, 0x01, // USB specification release (1.1) 0x00, // class code 0x00, // subclass code 0x00, // protocol code 64, // maximum packet size 64 0xD8,0x04, // vendor id (04d8) microchip 0x0A,0x00, //product id (000A) 0x00,0x01, // bcd device release number 1.00 0x01, // index to string that describes vendor 0x02, // index to string that describes product 0x00, // index to string that describes serial number (none) 0x01 // number of possible configurations }; //CONFIG DESCRIPTOR ============================ const char ConfigDescriptor [] = {0x09, // 9 bytes long CONFIGURATION, // descriptor type 0x43, 0x00, // total length of config, interface, and endpoint descriptors 0x02, // number of interfaces, one for configuration, the other for data transfer in/out 0x01, // configuration number, only one configuration in this USB device 0, // index to string that describes configuration (none) 0x80, // configuration attributes +check+ 50, // current consumption in 2mA units (100 mA) /* Interface Descriptor for first interface, configuration of the serial channel*/ INTERFACE, //descriptor type 9, // Size of this descriptor in bytes including this byte INTERFACE, // INTERFACE descriptor type 0, // Interface Number 0, // Alternate Setting Number 1, // Number of endpoints in this intf COMM_INTF, // Class code ABSTRACT_CONTROL_MODEL, // Subclass code V25TER, // Protocol code 0, // Interface string index /* CDC Class-Specific Descriptors will be used by system to invoke functions on the USB device*/ /* by interface one */ // sizeof(USB_CDC_HEADER_FN_DSC),CS_INTERFACE,DSC_FN_HEADER,0x0110, 5, //size of cdc header function descriptor CS_INTERFACE, DSC_FN_HEADER, 0x02, 0x00, // sizeof(USB_CDC_ACM_FN_DSC),CS_INTERFACE,DSC_FN_ACM,0x02, 4, CS_INTERFACE, DSC_FN_ACM, //Abstract control management function 0x02, //sizeof(USB_CDC_UNION_FN_DSC),CS_INTERFACE,DSC_FN_UNION,CDC_COMM_INTF_ID,CDC_DATA _INTF_ID, 5, CS_INTERFACE, DSC_FN_UNION, CDC_COMM_INTF_ID, CDC_DATA_INTF_ID, // sizeof(USB_CDC_CALL_MGT_FN_DSC),CS_INTERFACE,DSC_FN_CALL_MGT,0x00,CDC_DATA_INTF_ ID, 5, CS_INTERFACE, DSC_FN_CALL_MGT, 0x00, CDC_DATA_INTF_ID, /* Endpoint Descriptor for interface one*/ //sizeof(USB_EP_DSC),DSC_EP,_EP02_IN,_INT,CDC_INT_EP_SIZE,0x02, 7, //length ENDPOINT, //dsc type in this case an endpoint descriptor EP2IN, //a magic number for OS to identify the EP with _INT, //Interrupt transfer...an attribute of this EP CDC_INT_EP_SIZEL, //note the size was defined in Microchips code as a word (16bit) CDC_INT_EP_SIZEH, //its been split for this code 0x02, //interval /* Interface Descriptor for data transfer, it has two endpoints, one in one out*/ 9, // Size of this descriptor in bytes INTERFACE, // INTERFACE descriptor type 1, // Interface Number 0, // Alternate Setting Number 2, // Number of endpoints in this intf DATA_INTF, // Class code 0, // Subclass code NO_PROTOCOL, // Protocol code 0, // Interface string index /* Endpoint Descriptors for interface 2*/ //sizeof(USB_EP_DSC),DSC_EP,_EP03_OUT,_BULK,CDC_BULK_OUT_EP_SIZE,0x00, //outgoing EP 7, ENDPOINT, EP3OUT, _BULK, CDC_BULK_OUT_EP_SIZEL, CDC_BULK_OUT_EP_SIZEH, 0, //sizeof(USB_EP_DSC),DSC_EP,_EP03_IN,_BULK,CDC_BULK_IN_EP_SIZE,0x00 //incoming EP 7, ENDPOINT, EP3IN, _BULK, CDC_BULK_IN_EP_SIZEL, CDC_BULK_IN_EP_SIZEH, 0 }; // end of class specific descriptors
  14. Well, I'm going to push this till we get somewhere. I've managed to get a small board to be enumerated by Windows, for both the irritating mouse demo and Robert Langs usb/midi interface. I had a silly problem where my board doesn't use MCLR, yet it was enabled in the config statements. If anyone has experience with USB please correct me if I'm wrong: - I need a USB descriptor that is of a comms class - I will need at least two end points defined in that descriptor, one for data being received and one for data being transmitted. - I can use the Microchip CDC comms class driver. So a couple of questions...what is the descriptor I should be using. I can't for the life of me decypher the Microchip CDC classes.....at least to the level of getting a simple array of values to substitute into Robert Langs code. Also is there a specific endpoint class (and what is the format of the descriptor) that is needed when implementing comms for setup and configuration? In this case a minimum of three endpoints would need to be written????? I've written an EP write function I think might work: unsigned char PutEP1 (unsigned char bytes, unsigned char *buffer) { unsigned char * tobuffer; unsigned char i; ddrb=0; //setup b for output if ((BDT[EP1IN].EPStat & 0x80) == 0) /* do we own the buffer? UOWN=0*/ { Flash_Led(); // indicate activity on ep1 BDT[EP1IN].Bytes = bytes; for (i = 0; i < bytes; i++) { bd1ie_buf = buffer; } BDT[EP1IN].EPStat &= 0x40; /* save only the Data 1/0 bit */ BDT[EP1IN].EPStat ^= 0x40; /* toggle Data 0/1 bit */ BDT[EP1IN].EPStat |= 0x88; /* release buffer */ return BDT[EP1IN].Bytes; } return 0;/* Buffer not available, return 0 */ } Does this look reasonable?? Any help in getting a simple terminal working with USB would be greatly appreciated. The end application is to hook a PIC device into a PC via USB, then change operating parameters and upload/download data via Hyperterminal (or any comms program) and PIC generated text menus rather than some specific program. Thanks, Phil PS: If Robert Lang is reading these forums, I'd greatly appreciate some help.
  15. Hi All, Anyone have working code for a non trivial example of USB comms using a 18F2550 or similiar 18Fxxxx PIC? If I can get to the point where I can connect it up, fire Hyperterminal and have two way (eg a menu/parameter select) comms that'd be great. I've seen the circling mouse pointer demo....but cannot get arbitary two way comms. Are there special drivers that need to be installed? Which ones? Thanks, Phil
  16. " I am working at the University of Victoria in a 4th year mechatronics engineering class. We are using boost C and would like to have a system for using the USB port on the 18F4550 chip for running our robots." Hi, Same sort of problem, I'm using sourceboost but want to use USB with a 18F2550 (and later on the 18F4550)....I've got a set of code, modified from a project that appeared to do some sort of RS232/Midi/USB interface (not the CDC code). All the RS232/Midi stuff has been ripped out and I'm hoping to get a simple terminal program...you plug in the USB device, fire up Terminal and you can get characters typed on the PC returned....that'll move to a menu/parameter setting system later...just for now I want to get a simple serial terminal going. Only problem is I haven't got it working. Don't know if my wiring is wrong, I haven't installed the correct drivers etc or simply that the code in the 18F2550 doesn't work. If you pm me with your email, I'll send you the code and a PCB (in Eagle format) that implements it, perhaps with two sets of eyes we can put the sourceboost/USB issue to rest and get our names in Pavels example code next release. Phil
  17. Hi, I've modified a sample project (which the example in the sourceboost pages is based on I think) that was some sort of MIDI/USB/RS232 converter by ripping out all the serial/midi stuff until only the USB code was left. The program is meant to simply echo back characters received via USB to the host (again via USB), using terminal. Eventually I want to make a terminal menu program to control other functions....but I'm just starting with an echo program. Unfortunately it doesn't work and I was wondering if anyone could have a look at it, it's all zipped up and ready to go, but I don't have a place to post it....any ideas. Incidentally, if you have a K149/K150 PIC programmer and want to program these new devices google about for a program called DonkeyProg. It is very basic, but you program up a 16F628 to replace the existing one in your K149/K150 programmer and you can program 18F2550 and other 18Fxxx usb devices. Just make sure you do the 3 resistor modification. Phil
  18. A bit more research has come up with some stuff that might help: http://pic18fusb.online.fr/wiki/wikka.php?wakka=WikiHome again this has the C18 code...but a range of examples including a mass storage example and this thread on a CDC port to HITECH C which also might be useful http://www.htsoft.com/forum/all/showflat.p...801/an/0/page/0 I haven't started the task of porting CDC to Sourceboost,looks a little scary....but if anyone has started already we might be able to help each other out. Phil
  19. I've been having a look at the code, but it seems to be code for sending USB data only.....I don't suppose anyone has ported the receive part of Microchips code yet? It'd be handy to have a USB terminal program to simply plug your system in and interact with it. Phil
  20. Hi Pavel, Thanks for posting this code, was looking for the same thing since an article in another magazine showed me these things exist. The October 2005 edition of Everyday Practical Electronics has a simple USB/RS232/Midi interface....by Robert Lang again! Phil
  21. Hi Alvarro, I just noticed your post after asking the same sort of question. I don't have anything directly for SourceBoost however Microchip have a library written for their C18 compiler called the CDC framework or Communication Device Class here http://www.microchip.com/stellent/idcplg?I...&param=en022625 I was sort of hoping someone else had done a port to SourceBoost or compiled it to a library for various chips. The C18 compiler can be downloaded from Microchip as well for 60day trial. If the port is too difficult, it might be possible to compile a library in C18 and link it with Sourceboost but I'm not sure. The Microchip Design Center section looks to be a good source of information. Phil
  22. Has anyone done a port of the Microchip CDC code for the 18F2455/18F2550 controllers to enable USB functions on these chips using Sourceboost? Phil
  23. SB is looking pretty good... here's a suggestion for a future release. Often I want to use the logic analyser to look at some waveforms, but at a specific point usually at a break point. Currently I've got to set the stop watch at the start, read the time to the breakpoint and then enter that value into the analyser to start the analyser going from that breakpoint. It'd be great if I could: - run my program, wait for the breakpoint - fire up the analyser then press a button that would start it from the current run point. - enter a period, preferably in uS/mS for the analyser to run for from this start time, rather than having to figure everything out in ticks. Phil
  24. OK, Had a little time to have a quick look with WinDiff.... As a first pass, the bigger code seems to be because of a different allocation of variables between 6.03 and 6.14...leading to additional BCF/BSF status,RP0/RP1 statements. It may have been luck that the 6.03 code worked out to be smaller. Another factor though is that my code has all of its page 0 registers pre-allocated by me and much of the page 1 registers (In order so that the interrupt code didn't need to do it's own). Don't know if having a large number of pre-allocated variables has thrown the compiler. There is a knot of code that is markedly different, but I'll tackle that another day. Phil
  25. Hi all, Just saw the new optimisation options in Sourceboost and decided to do a controlled test of 6.14 vs 6.03. Using the same codebase in each compile I got: Sourceboost 6.03 with -O0 option: failed, overfilled by 1 location Sourceboost 6.03 with -O1 option:....baseline fully operational code 293/368 ram 75 bytes(20.2%) free 3918/4096 rom 178(4.3%) free Sourceboost 6.14 with -O0 option: failed, overfilled by 190 locations Sourceboost 6.14 with -O1 option: 297/368 ram 71 bytes(19.2%) free 4051/4096 rom 45(1%) free Sourceboost 6.14 with -Oa option: 294/368 ram 74 bytes(20.1%) free 4002/4096 rom 94(2.2%) free Sourceboost 6.14 with -O1p option: 297/368 ram 71 bytes(19.2%) free 4051/4096 rom 45(1%) free Sourceboost 6.14 with -Oap option: 294/368 ram 74 bytes(20.1%) free 4002/4096 rom 94(2.2%) free Sourceboost 6.14 with -Op option: 297/368 ram 71 bytes(19.2%) free 4051/4096 rom 45(1%) free So for now gone back to 6.03 for development...although I like the new optimisation pragmas and options. A bit about the code (sorry I can't release it). Target is a 16F88, it is a 15 channel PWM pattern program for RGB LEDs (5 RGB channels)....it has an highly optimised PWM interrupt on T0 running at 200Hz(PWM cycle) and an infra-red remote control receiver (RC5) being bit banged on timer 1 interrupts at a regular 100uS (please Micrchip...lets have multiple interrupt vectors, arbitration is costing me precious uS!). The code has about 1/3->1/2 lines in asm { } statements for all PWM stuff, IR receiver and EEPROM handling and some pattern stuff. All the rest in 'C'. For the tests I didn't change to the new _asm { } statement, only thing that changed was the compiler option. All compilations on the Sourceboost 6.14 version failed to operate correctly in terms of the PWM signal, although the IR remote code and pattern generation code worked perfectly. I got non-linear responses in a PWM sweep, leading to flickering of the LEDs. Probably the tight PWM interrupt has been disrupted in some way....or possibly my lookup table generation that it feeds upon. Another alternative is that the asm code relied on some optimisation in the -O1 option for V6.03.....and all I'll need to do is put in a _asm {} statement or do it manually. However, all this is reasonably good news, 6.10 didn't work at all! Because the error is consistant, observable and has a definable result I can work on finding out what has changed in a systematic way. A question, can I install 6.14 and register it in one folder whilst simultaneously having 6.03 installed in the default folder and operational. Would this make the registration program have a fit?....it'd save me installing and re-installing versions and more likely to have a dig at figuring out the differences. Phil
  • Create New...