Jump to content

ppulle

EstablishedMember
  • Content Count

    71
  • Joined

  • Last visited

Everything posted by ppulle

  1. oh well, perhaps someday. Keep up the good work on Sourceboost, it's a great compiler. As an alternative, perhaps easier...perhaps not. Would it be possible to link to libraries created with MPLAB? The idea being a blob of code such as the much desired CDC stack can be created with MPLAB then linked to a sourceboost codebase. Even a manual process of static linking would help. Surely it's just a matter of getting the right function locations, making sure sourceboost doesn't clobber MPLAB variables and getting call stack conventions right. A shim of sourceboost code could surround the
  2. Hi, Has there been any progress in implementing bit fields in the latest releases of Sourceboost. I'd basically like to drop in Microchip CDC USB stack without major surgery....ie have something like typedef union _USB_DEVICE_STATUS2 { byte _byte; struct { unsigned RemoteWakeup:1;// [0]Disabled [1]Enabled: See usbdrv.c,usb9.c unsigned ctrl_trf_mem:1;// [0]RAM [1]ROM }; } USB_DEVICE_STATUS2; compile and access it like USB_DEVICE_STATUS usb_stat; usb_stat.ctrl_trf_mem = 1;
  3. Looks OK to me too. Lets look at the asm assume the argument is greater than 3, lets say 4; MOVF test_Func_00000_arg_test, W will move 4 into W SUBLW 0x03 will subtract 3 from W, leaving 1 in W and no carry in the status register. No need to use SUBWF, we possibly save some code space by avoiding any bank switching if it were needed. BTFSC STATUS,C tests carry flag, and skips the next statement 'goto' if the flag is clear (Bit Test F, skip if Clear) GOTO label1 goto will be skipped as expected and execution will begin in the main part of the if statement ..... {if..
  4. Hi Dave, Sorry if the below sounds confused and incoherent...but I'm a little lost at the moment. I updated to version 6.96 but with the same result. Next I looked closely at the i2c_driver.h file, and noticed that some of the variable definitions were short instead of char and the #defines pointing to the variable allocations were out of order (I think this has been noted in another post). I fixed these up and the code works properly. This is a bit puzzling, as even if I don't call the i2c functions, the code fails (if I set the i2c_driver.h back to the way it was that is). I
  5. Hi Dave, I've had a close look at the asm code, and it appears that in the 'bad' project, the linker is adding all the appropriate bank switch statements to access the reshuffled variables (ie movb instructions), as well as using the different op codes for page zero vs page something else accesses. It looks like this is being done even for the few asm{ } constructs as well. In other words it appears the linker and compiler are doing their proper function. It's probable then that maybe I've looped somewhere and done a buffer overrun or equivalent. In the 'good' project the buffer may b
  6. Hi Dave, Thanks for the headsup. It saved me a fair bit of time unnecessarily rearranging my switch statement to see if I could shorten it. I found the problem, though it's a little off topic (nothing to do with switch statements or function sizes), I thought I might explain it here as the process I went through might help others. I had some hardware which basically logged accelerometer and other data to a memory chip. It has a USB connection to download these logs and control bits and pieces. I use a library of USB functions to do the USB connection, that is a compiled library linked
  7. Hi, I'm using Sourceboost 6.87 on a PIC18F4550 target. I've just started getting strange behavior that looks like a stack overflow though my stack depth is less than 8 for the functions being called. That is functions are stopping for no apparent reason. I was wondering if there is a limit on the number of case statements in a switch function, or if there is a limit on function sizes. This seems the likely culprit as the problems started occuring just after adding new functionality. In my case I have a command handler which is now 2188 bytes long with 43 case statements..... is
  8. Just to let you know letting Sourceboost do the days lookup worked well....clocks been running for several days without problems.
  9. Hi, Thanks for the suggestion on using the array. As a quick fix it should work. I must admit to forgetting that Sourceboost can now properly reference variables in asm code.....I've been using it for a while and remember having to use globals for that sort of thing (on a very old version), so have been a bit shy to do so. I'll get to it as soon as possible and come back with the result. I share your mystification on how the code works, one reason why if I get the chance I'll do a re-write. I suppose we can summarize some lessons for other users: - be wary of using PCL lookup tables,
  10. Hi IanM, Thanks for you reply. I agree the code is complex, I'd like to make it simpler which is usually important in an interrupt routine....that's what you get using cut and paste from different sources I suppose (I sloppy way of saying 'don't blame me....I didn't write it). Oops I'm sorry I forgot to mention it's a 18F4450. Interestingly the fault doesn't manifest is such a dramatic way as a reset or bus fault. I would have noticed that early on. FYI I have a logging system. The RTC chugs along quite nicely for days on end till the battery runs out, when logging events occur they a
  11. Hi, I have an interrupt servicing a RTC (real time clock) routine. However it uses a lookup table to determine the days of the month that does a call/PCL jump/retlw technique that doesn't seem to work. I'm using TMR1 to set flags to do ADC samples (polled in main code) as well as do the RTC. The samples are sub multiples of the RTC clock. On each second various variables (seconds, minutes, hours, days, months, year) are adjusted to the time. TMR0 is used to call a USB service routine. Here is the gist of the code, various flags and variables have been omitted: void days(v
  12. Hi All, I'll leave it to others to check out the method russ has come up with (I've got my solution and moved on to other stuff)...it does look interesting however. I don't think rounding (in terms of just the multiplication) will be an issue if the numbers are limited to the precision of the accumulator (ie for 16bit signed limit the additional samples to 4096 ie 16-sign bit-divisor bits)....however the division gives me a bit of a worry, as there will nearly always be a remainder...that's probably the main area where loss of accuracy will occur. Note that we're doing an average and e
  13. Thanks for the heads up on how compilers deal with signed ints.......it's sure to be a trap for the unwary. I was hoping there'd be a generic bit fiddling algorithm that'd handle that sort of thing. Anyway I've taken everyones advice, subtracting the old history value before adding the new one to quickly calculate the totals as well as converting negative ints to positive (and back again) before doing the division. Thanks to all who've helped. Below is my contribution to the sourceboost world.....a 12 bit precision, signed, eight channel, eight tap finite impulse response filter....aka
  14. Hi, I've got a nice little asm code adding sensors, performing array totals etc and doing everything up to the dividing by 8 to take the average. Rather than figure it out for myself, I thought I'd just re-use the code that sourceboost generates to do a divide by 8 on a signed int. However the results were not as expected. eg, compile and step through this in the debugger int k; int z; k = 0; z = 0; while(1) { k = k - 1; z = k / 8; } for different values of k, I get the following results for z k=-1,z=-1 k=-2,z=-1 k=-3,z=-1 k=-4,z=-1 k=-5,z=-1 k=-6,z=-1
  15. Thanks for looking into that Pavel, I've got enough to go on with....now I've got to incoorporate this into a single routine that will take a set of eight samples, making this an eight tap finite impulse response filter with two byte precision.
  16. Thanks for the responses....the idea of keeping a running track of the total sum, and removing it before adding the new value is great...saves needing code to sum over the array, plus saves time....(got plenty of RAM left, very tight on ROM). Does new value insertion and summation in one step as well. Thanks for the input Pavel, that's an interesting approach....however I'm wondering how future proof it will be. It assumes the FSR register is maintained after the array access...also you don't specify which indf register to use, indf0, indf1 or indf2 (for PIC18F4550). No biggie, could just
  17. Hi Reynard, Thanks for the response. I've been fiddling around getting my headspace back into assembler mode. Firstly, I'm not sure there is a memmove opcode for the PIC18F4450....I'd love to be wrong about this, in the meantime I'll stick with the circular buffer technique. The shift right for divisors of multiples of 2 I'm already up on.....in fact if you look at the opcode created by sourceboost it'll optimise divisions by doing multiple shifts anyway. Not sure about right shifting signed ints....I think you need to preserve the high order bit. In any case for 2 byte ints with 18F4
  18. Hi, I'm looking for a bit of help to save some time re-inventing the wheel. I'm sampling a number of sensors, three accelerometer, three magnetometer and two ADC channels. The ADC and Accelerometer channels give me unsigned int data and the magnetometer gives me signed ints. I have a PIC18F4550 I'd like to store these in a table, and do a moving average filter on them. eg: int aMagXArray[8]; //allocate arrays of 8 values each //.... //Now sample the samples, putting them in variables like SensorMagX, SensorMagY etc aMagXArray[nPos] = SensorMagX; aMagYArr
  19. I recently had the same problem, in my case I was buffering a 256 ints from the AD port which made 512 bytes....so it does happen sometimes. Got around it by being less fussy about precision but would have liked a big size array. Possibly one solution would be to write your own array access primitives (ie your own functions) using the FSR registers you've mentioned, although I haven't looked into it myself. I would suggest googling 16 bit addressing for PICs as I imagine this has been addressed before. Phil
  20. Hi, Before writing my own code, just thought I'd check to see if anyone has done this before. I'm after some routines that will take a memory image from external EEPROM and write to the program memory. The idea being that the application will receive a .hex file (or similiar), and write it to the EEPROM, do some checks to make sure its valid then write that EEPROM memory image to the flash program memory. This is so the application can be updated in the field. Note this is NOT a bootloader because: - the program data is first loaded onto onboard eeprom not directly to program
  21. Hi Ian, Thanks for writing this code.....some non Microchip (and associated licence issues) code that does CDC has been much waited for. I've been using a modified version of the Microchip CDC code for a while, and it's been quite aggravating I cannot release the code because of the Microchip license (search the forums for threads on this). I've managed to get the code to compile, though not run yet as my hardware is a little different from yours I think. If I may make some suggestions for the next release candidate to make it more general: - Have some way of turning off all serial p
  22. Hi, A long time ago Geoffrey Hopkins did an amazing job of porting the CDC code to Sourceboost and I helped in packaging it up. Unfortunately when we contacted Microchip they said we weren't allowed to publish the code....which is a real shame. You're allowed to modify the code and use it yourself or in your own products, but not publish any modified code apparently. Having said that the main problem was trying to simulate bit field structures in Sourceboost, to this day I still cannot figure out how Geoff did it, but it wasn't pretty. It also meant some version dependant code, as an e
  23. Hi all, Just been doing some sleuthing about the net and reading up on the datasheets. Here is some code fragments that may be suitable for solving the page write and acknowledge polling problem. Note that this is set for the 24LC1024....don't know what other chips page sizes are. There is more generic code out there....this is just to show a rough solution. Firstly I looked at the i2c_driver.h code....I noticed that the hardware implementation for the i2c_write function returned the error condition of the i2c transmit buffer (ie any write collisions) and not the ACK status of the i2c
  24. Hi All, I've found an issue regarding talking to one or more I2C eeprom devices using multibyte read/writes. I'm using SB6.60 with a 18F4550 and talking to four 24LC1025 EEPROM devices connected to the I2C bus. According to the 24LC1025 datasheet you cannot write across page boundaries, nor more than 128 bytes in one block write. So if first you wrote 120 bytes starting at zero, fine, and then you wrote another 20 bytes, you would not perform a successful write because in the second operation you would be writing over a page boundary. You would need to make three operations. The fi
×
×
  • Create New...