Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About HP-65

  • Rank
  1. One of my open source projects requires a custom PIC18 libc. Am I allowed to share a compiled libc binary?
  2. It is really a pity to see that the config bits editor in MPLabX is not working with Sourceboost ("unsupported toolchain"). Will this feature be implemented in a future version?
  3. Yes, mine is exactly the same... Well, although my login has administrator rights, I tried the following: runas /user:administrator goodies.exe This did not crash, but brought up: Guess what ".\" means... ;-)
  4. I just upgraded to 7.04 and (as usual) tried to unpack the library sources and Novotos, but goodies.exe crashes with an access violation, right after the license agreement (WinXP, SP3). Is anybody else having this problem?
  5. Can anybody point me to a more in depth explanation of "-idx 2"? Obviously, the new two byte index does not work in all cases: reduced example, BoostC 7.02, PIC18: typedef struct { unsigned char doesntwork[300]; } tester; This gives a "No remaining memory block (on target) with suitable start address" error. Obviously, a structure is still limited to one bank? What else should I know At least, I already figured out that libc needs to be recompiled with "-idx 2" to make use of it ;-)
  6. Dave, I dropped by 2-3 days ago and did not manage to find a 16F1823 in the device list. Maybe you should pin this at the top... Is this a preliminary test release or a "production grade update"? BTW.: Do you (or Sourceboost ;-) make use of the "new" instructions ADDWFC, ASRF, MOVLP/LP, BRW, MOVIW/WI, ...?
  7. You can indeed fill the PIC16/12 flash that way, but you will never be able to read it back, because these devices lack the instructions to do so... WRONG!See section 3.5 of the PIC16F88 data sheet Ouch, my eyes! Incredible! After almost 15 years of hacking through the 12/16 series, I must admit that I totally missed these devices! As of today, I will recall you as "IanMemory" Incredible... Well, actually this limit was the reason for me to cancel my, already placed, SourceBoost order... And this is exactly one of the n reasons why people usually switch over from asm to C. While coding in asm is pretty straightforward and easy on 12/16 PICs, it is getting more "complicated" (time consuming) if large amount of >8 bit types and storage classes are involved... Except for this limitation, SourceBoost has the right price and performance between SDCC and HiTech's PRO version. BTW.: For arrays <256 bytes nothing would change. The original, limited implemenation could still be used... Ok, I'll wait ;-)) HP
  8. You can indeed fill the PIC16/12 flash that way, but you will never be able to read it back, because these devices lack the instructions to do so... The only way obtaining a value from flash is a look-up table with a retlw <c, 8bit> instruction, which has the opcode (e.g. 12f...) 11 01 xx cccccccc. If you change the upper bits, this will result in a different opcode than RETLW, which will probably not do what you want it to do ;-) I discovered the SourceBoost compiler just ~2 days ago and came here to find out more about why the developers built in the 255 byte array limitation... Probably laziness? ) This is somehow confusing. Even a 12/16 PIC can use >8 (13) bit lookup tables by combining PCLATH and PCL and every other compiler I know (HiTech, SDCC, CDC, ...) has this already built in. HP