Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ppulle

  • Rank
  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
  • Create New...