Jump to content

vbhunt

EstablishedMember
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About vbhunt

  • Rank
    Newbrie
  1. Novo headers will be included by default because we encourage to use it in all projects (well in almost all projects). There definitely are more technical reasons to use it rather than not. Regards, Pavel I agree with Sparky that you should NOT enable the Novo headers as an IDE default. You may wish to encourage its usage but you should not break my code or even require me to research why I suddenly have new unusual names in my name space. I have a large project that predates the appearance of Novo and so its (somewhat hidden) inclusion was highly surprising. At least it should announce its presence with a PRAGMA message ala the icd2.h and icd3.h files. But in general, the decision to impose on my application your choice of using an operating system is well outside the bounds of providing superb compilation tools. There are many complex design decisions that elucidate the choice of what features to include in an operating system based on the application contemplated, its design life, real time requirements, memory usage and the resources needed to be managed. These choices lead to many different operating system designs even with the ever decreasing constraints of these small computers. So, how can you be so sure that you've selected the correct design tradeoffs in a single OS? I don't want to imply that there is anything at all wrong with the Novo OS; but that it has a (relatively small) specific application space that does not come close to covering the same application space that the compilers cover and so should be options just as the various library functions (e.g. <string.h>, <memory.h>, <stdlib.h> are).
  2. You link several files in your project. If you use Pro license all these files have to be built using Pro license. Regards, Pavel The entire project was developed using SourceBoostC. All of them were compiled under the SourceBoost Pro License. However, they were compiled using version 6.70 and then linked. I recompiled everything and then it all links. Thanks for the help.
  3. I have a new Windows Vista Business Professional Laptop that I'm attempting to run SourceBoost IDE 6.80 BoostC and Linker using my Sourceboost professional license. I installed as an administrator and registered both the compiler and IDE plugins. Both registered fine. I can bring up the IDE and compile but the linker fails saying that I've exceeded the license allowable ram. It works fine on my previous Windows XP box. Is there something new I need to do? -------------------------------------------------------------------------------------------------------------------------- Building... BoostC Optimizing C Compiler Version 6.80 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2007 Pavel Baranov Copyright© 2004-2007 David Hobday Licensed to V Bruce Hunt under Single user Pro License for 1 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited ADC.c <C:\Program Files\SourceBoost\include\icd2.h> @ 20: MESSAGE: "Including ICD2 declarations (icd2.h)" <C:\Program Files\SourceBoost\include\icd2.h> @ 787: MESSAGE: "Warning: ICD2 Reserved ROM address range:0x7DC0-0x7FFF (use linker -rt option)" success BoostLink Optimizing Linker Version 6.80 http://www.sourceboost.com Copyright© 2004-2007 Pavel Baranov Copyright© 2004-2007 David Hobday Warning unreferenced functions removed: resumeTimeButton in: C:\TTcode\TTcontrol\Button.c makeCommand in: C:\TTcode\TTcontrol\CmdFormat.c makeCommand in: C:\TTcode\TTcontrol\CmdFormat.c lcmd_msgStatus in: C:\TTcode\TTcontrol\ControlCmds.c rReq_MsgStatus in: C:\TTcode\TTcontrol\ControlCmds.c rRsp_MsgStatus in: C:\TTcode\TTcontrol\ControlCmds.c i2c_beIdle in: C:\TTcode\TTcontrol\I2C.c i2c_waitTillIdle in: C:\TTcode\TTcontrol\I2C.c i2c_initIdle in: C:\TTcode\TTcontrol\I2C.c writeEEprom in: C:\TTcode\Common\EEprom.c readEEprom in: C:\TTcode\Common\EEprom.c distanceStep in: C:\TTcode\Common\Turntable.c withinDelta in: C:\TTcode\Common\Turntable.c License exceeded by RAM: 754 bytes, ROM: 8180 bytes You have reached the limit of the Lite License (Unregistered) PIC18 max code size:8192 bytes, max RAM banks:2, Non commercial use only You can upgrade your license. Please visit: http://www.sourceboost.com failure "C:\Program Files\SourceBoost\boostc.pic18.exe" ADC.c -t PIC18F2520 -i "C:\Program Files\SourceBoost\boostlink.pic.exe" /ld "C:\Program Files\SourceBoost\lib" libc.pic18.lib ADC.obj Button.obj CmdFormat.obj ControlCmds.obj ControlInterrupt.obj I2C.obj LedControl.obj MsgQueue.obj RDC80.obj TTcontrol.obj TTCrc8.obj WalkRange.obj EEprom.obj Turntable.obj /t PIC18F2520 /d C:\TTcode\TTcontrol /p TTcontrol Exit code was -2. Removing target: TTcontrol.hex Failed to locate output file 'C:\TTcode\TTcontrol\TTcontrol.hex' Done Failed
  4. Thanks emte for clearing this up. Yes, we use SVN to maintain the source code. You can also browse it online too to see if it matches your needs: AT http://sourceforge.net/projects/nn3turntable select "Code">>"SVN Browse".
  5. We would like to announce the availability of Opensource BoostC Source code that may be of interest to SourceBoost Forum C programmers. This software source code is available for download now at: http://sourceforge.net/projects/nn3turntable/ At the above location you can download the complete SourceBoost projects. This embedded software system consists of two communicating applications written in SourceBoost Boost "C" for the PIC18 processor family on an I2C network. The software is the code basis for a model railroader to remotely operate auto-indexing turntables on model railroad layouts. The controller application allows a remote operator to operate a turntable several meters away by communicating with a turntable application. The turntable application accepts requests from a controller and precisely positions the turntable according to those requests. It also supplies status information for the controller to display to the operator. The controller application UI consists of status LEDs, push buttons, switches and a control knob. It communicates with a turntable via an I2C (small area) network interface. The turntable application's external apparatus consists of status LEDs, push buttons, a stepper motor, a home position detector and an I2C network interface. The turntable application supports very high precision positioning of a turntable by supporting micro-stepping of the stepper motor. It positions a turntable to any one of 7680 points on a circle. The turntable application allows operator programming of up to 80 feeder track locations. The turntable associates a knob position (on the controller) with a precise location. When the knob is turned (close) to the position, the turntable automatically steps to the memorized location. The software is organized into three groups. The common group consists of modules which contain highly reusable software for almost any interrupt driven small system. The following software modules are in the common group: ADC - Hardware driver routines to perform analog to digital conversions user PIC16,PIC18 ADC module. CmdFormat - Routines to format messages for network transmission. CmdVerbs - Definitions of network messages sent between controller and turntable. EEprom - Hardware driver routines to efficiently write to eeproms. Button - Interrupt driven routines to manage any number of switches or buttons and debounce them and measure how long they are up (or down). LEDControl - Interrupt driven routines to manage any number of LEDs to vary their intensity and/or to operate patterns (for blinking and other effects). MsgQeueue - Routines to define and manage message queues to support asynchronous network transmission. RDC80 - Routine to operate a 360 degree knob using the ALPs RDC80 sensor. TTCrc8 - Routine to calculate CRC8 polynomials for error protection of messages. I2C - Interrupt driven hardware driver in C that supports slave, master and multi-master I2C bus communication. WalkRange - Routine to psuedo-randomly walk over the entire I2C address range upon Master collision. This optimally maximizes I2C network throughput while minimizing transmission delay. Turntable - Routines and definitions common to controlling a turntable. While this software is coded in SourceBoost Boost"C" for the PIC16/PIC18 family of processors, it can also be fairly easily be ported and thus used for almost any small microcomputer. The turntable group (TTstepper) consists of many of the common modules and specific turntable modules: TTstepper - Initialization and main loop for operating the turntable. aligntable - finds the turntable hardware home position. config - defines the hardware/software module configuration for turntable. indextable - manages the knob position to turntable location table kept in EEprom. motor - Interrupt drivern stepper motor driver; runs stepper motor control hardware in micro-stepping mode (allowing upto 7680 steps per revolution. StepperCmd - formats, sends and performs local or remote commands. StepperInterrupt - Manages all interrupts for hardware including all timers. The controller group, TTcontrol, consists of many of the common modules and the following application specific modules. TTcontrol - Initialization and main loop to remotely control turntable. config - defines TTcontrol hardware/software configuration. ControlCmds - formats and queues commands to be sent from local UI, also executes remote command requests/responses. ControlInterrupt - operates all interrupt drivers including timing drivers, I2C, LED, Button, ADC, EEprom. etc. This software is written in "C" by Bruce Hunt(US) and Mark Langezaal(NL) over the past 9 months. The software is made available under the LGPL so that it can be used by anyone in the community needing (what we believe are high quality) "C" routines to operate small micro-computers. We wrote this software to support the hardware we designed to build low cost highly precise auto-indexing remotely controllable model railroad turntables applicable to many different scales including Zn3, Z, N, Nn3, H0, H0n3, S, Sn3, O, On3. The hardware is about to be made commercially available. Our goals are to: make sure that people have access to the software that controls their hardware. to allow community improvements to the software (and hardware). to assure that improvements and updates are available at low cost. to promote the use of software controllers in realistic historical miniature modeling. The code is reasonably heavily documented to facilitate ease of re-use. In particular, the Common modules such as MsgQueue and I2C routines are heavily documented. The I2C module is particularly heavily documented (and tested). This is because of the pitfalls we found in implementing interrupt driven I2C code for the MSSP module in selected PIC 16 and 18 processors. The Sourceboost IDE and the BoostC compiler have been invaluable tools to help us build this embedded application. We would like to thank Dave and Pavel for answering our questions and helping us understand how to best use the compiler and IDE -- but mostly for accelerating our ability to implement our ideas with excellent tools. Mark Langezaal and Bruce Hunt
  6. I think of a bug as actions of a computer program that differs from the claimed behavior according to the program's documention. By this criterion, this is a bug. The fact that there is a work around is very nice; but the genertion of an incorrect option is just plain wrong.
  7. Bug description: In the MPLAB SourceBoost "C" integration, using Compiler version 6.70 using the compiler option -i by selecting menu item Project>"Build Options...">"Project" with the "BoostC C Compiler for PIC18" tab. Selecting "Debug inline code" check box yields the option, "-di" where it should yield "-i". This option then causes all variables named "i" in the build to become null -- yielding many errors in the code. Steps to reproduce: In MPLAB (version 7.50 or 7.52) select "Project">"Build Options ...">"Project". Select the "BoostC C Compiler for PIC18" tab. Select "Debug inline code" check box yields the command line option, "-di" where it should yield "-i". Expected behaviour: I expect the option to generate the option, "-i" on the command line, not "-di". The work-around is to use -i option on the "additonal Command-Line Options" line so this bug is NOT fatal. Is the problem 100% reproduceable: This is 100% reproducable. IDE version: SourceBoost IDE version 6.70 Compiler: BoostC PIC18 Compiler version: Compiler version 6.70 ( for PIC18 architecture) Target device: PIC18F2520 OS: Windows XP OS version WinXP/SP2 Comments: Workaround is to use "Additional Command-Line Options" and place "-i" there.
  8. No it doesn't support such a facility.How and when exactly would you use this checksum value? (I guess it will be some kind of startup system integrity check) Regards Dave <{POST_SNAPBACK}> We have an application that user's may possibly change by re-programming part of it. To rapidly sort out "supported" from "non-supported" software, a code such as CRC-16 would be useful as a rapid means of telling similar from identical code. We would like the CRC-16 code to be placed in the program to distinguish it from configuration code permanent memory. Thus, we can build into the application simple checks at runtime to determine if the code (or subparts) is supported or unsupported. These checks would typically be done at startup and a status flag would be set potentially dis-allowing certain operatins (i.e. don't allow erase of the boot-loader unless the program is known to be good). This provides us and our users some protection from in-advertant or intentional system attack. Regards /Bruce
  9. Yes, indeed! Thanks for pointing out my bonehead mistake. It really had me going there for a good afternoon. Almost any indicator of where the error occured would be helpful. For a long time I thought it was related to the strange comment behavior. Anyway, thanks for the help. /Bruce
  10. In the previous post, the problem is that r1 should be decared "Byte r1[] = {...};" as should r2. The interesting question is why was there not a message about an invalid initializer? Cheers & Thanks. /bruce
  11. Bug description: The following program fails with "Exit code -529697949" in BoostC 6.60. The following is the smallest complete program I could make that doesn't compile. It is reduced from a larger module to compute CRC-8 values for byte strings. Steps to reproduce: #include <system.h> typedef unsigned char Byte; #define PByte Byte * // this is temporary to address the typedef bug. Byte r1 = { 0x00, 0x5e, 0xbc, 0xe2, 0x61, 0x3f, 0xdd, 0x83, 0xc2, 0x9c, 0x7e, 0x20, 0xa3, 0xfd, 0x1f, 0x41, }; Byte r2 = { 0x00, 0x9d, 0x23, 0xbe, 0x46, 0xdb, 0x65, 0xf8, 0x8c, 0x11, 0xaf, 0x32, 0xca, 0x57, 0xe9, 0x74, }; Byte cnt; PByte pBuf; Byte rn; Byte ln; Byte crc; Byte computeCRC( PByte pBuf, Byte len ) { ln = 0; crc = 0; for ( cnt = 0; cnt < len; cnt++ ) { rn = *pBuf; pBuf++; rn = rn ^ crc; asm { swapf _rn,W movwf _ln } ln = ln & 0x0F; rn = rn & 0x0F; crc = r1[ln] ^ r2[rn]; } return crc; } The result is: Expected behaviour: I was hoping for either an error message for one or more lines; or a successful compilation. I've shaved this down to the smallest workable failure. This program should compile. At one point it did compile under 6.60 This program fails 100% of the time on my Athalon 64 running Windows XP SP2 running under SourceBoost IDE Version 6.60. IDE version: SourceBoost IDE version 6.60 Compiler: BoostC Version 6.60 (for PIC18 architecture) Target device: PIC18F2520 OS: Windows XP Pro Version 2002 Service Pack 2. Computer is AMD Athlon 64 Processor (2.4GHZ, 4GB RAM) Comments: During the paring process, I observed that the result changed if standard C comments were added. That is, the failure remains; but the beginning of a comment would be flagged as: To reproduce this behavior, place a multi-line C comment with the comment opening, "/*" on a single line between the line "Byte crc;" and the function computeCRC signature. On a seperate line in the comment place " * // * " to see the behavior change. It appears that the comment state machine is not capable of handling additional comment characters. It would be great to have a work-around and/or an explanation of how to go-about debugging upon such failures.
  12. I too would like to see bit fields work as defined by ANSI C. They are extremely useful to keep data structures compact. The pics are such nice bit bangers that they beg for bit field support .
  13. In the following (using MPLAB IDE 7.52 in WinXP) notice that the ' -I "..\Common"' gets turned into "-i" which appears to be incorrect since I want to have several include file paths in the compile. Shouldn't the case of the parameter be preserved; especially when changing case changes the parameter's meaning? Or, has the parameter been changed but the documentation remains out of date? Also, is there a way to inform the compiler of the path to the source file? This appears to be needed since the source file is NOT in the same directory where the MPLAB IDE invokes the compiler. In the following, the source file, ADC.c, is in "..\Common".
  14. That seems to be a very useful workaround. It gets me over the problem. Thanks!
  15. As I read your code, your adcon0 has value 0xA1 meaning "10100001". Thus, you have a right justified result, measuring against Vss and Vref+ on channel 0 and you've turned on the A/D module. adcon1 has value 0x70 = "01110000' which means Frc (internal osc.). I think you noticed this and have set it to 0 (500KHZ with your 1MHZ clock). I recommed that you change b and c to unsigned char since they are set from 8 bit registers (adresl,adresh). Also, I think that you want the first delay above to reflect the acquisition time for the A/D module after turning it on. In my application this is 25 microseconds so for you, the delay would be: delay_us(25) instead of the 1 millisecond delay you have -- assuming you calculate the acquisition time to be 25 microseconds. Also, in my wait loop, I wait for the Analog convert time. For my 20mh part, this is, worst case 1.6 microseconds per bit or about 19 microseconds for 12 bits. So your while(adcon0&0x02 == 0x02) would have a delay_us(19); replacing the current null statement ( or the correct convert time for 12 bits at your clock speed). Finally, I immediately turn off the A/D module after reading the value so that I can reuse it immediately. (I don't think this has anything to do with your problem) I have essentially the same code you have but mine is slightly generalized for each channel and it works just fine. So, I think you are on the right track. Good luck! /bruce
×
×
  • Create New...