Jump to content

John_E

EstablishedMember
  • Content Count

    22
  • Joined

  • Last visited

Community Reputation

0 Neutral

About John_E

  • Rank
    Regular
  1. BoostC directly supports integer values only, no doubt you know this already. Floating point is not so easy, and I'm not saying how to do it here. However, what you are asking for seems to be a method to output a fixed point value, which is much easier than floating point, particularly if you are starting with integer calculations. For these, just scale them up as required. For instance, (42/9) for three places after the point is just ((1000*42)/9), with a decimal point to be inserted before the last three digits when it is viewed as decimal. Do the calculations as long integers if this is required. Look up the 'Conversion Functions' in the manual for ways to convert the result to a readable form. (For example, convert to an ASCII string, then output all but the last three digits, output a point, then the remaining digits.) If you are actually starting with an arbitrary floating point number, you'll have to write an expansion routine to convert it to fixed point. Since if you haven't got an output routine, I assume it that you do not have a input routine either. So it is likely you are starting with integer or fixed-point values anyway. Floating point is essential at times, but can mostly be avoided, I find. People use it out of habit. HTH John
  2. Yes, it does stand for Integrated Development Environment. But to be pedantic (or just accurate ) this does not mean it is a compiler, builder, and editor. It is an integrated _environment_ for those parts. It is perfectly possible for them to exist separately. So, in accordance with this pedantry, the removal sofware should at least tell you that you are going to lose the whole lot. SourceBoost has boostbasic.pic16.exe, boostc.pic16.exe and so on as separate files in the directory, and since they executables and not DLLs they can be invoked directly, rather than through a parent program such as the IDE. Page 22 of the BoostC manual gives the command-line details. I've not run them directly myself. Mind you, experience shows that compiler and linker command lines can be quite unpleasant. Enough to want an IDE to do all this stuff for you. But if you run the compiler on its own (perhaps from your favourite editor), then the IDE can surely just be ignored, it doesn't need to be actually removed. Regards, John
  3. Well, I sent that reply, then - Doh! (or D'oh!, opinions differ). The PIC16 16-bit timer, the two bytes are accessed in isolation. You have to do a bit of a dance to read them on the fly, unless you stop the clock to prevent an increment mid-read. The datasheets give some assembler rouines to assist. But I see on the PIC18F25252, there is means of full access to the timer1 16bit value without this. It just requires that the bytes are read in the low byte, high byte order. You probably knew this, but I had to look. I assume your part has this type of counter too. I haven't checked, but does BoostC have the timer for your PIC18 declared as a 16 bit value? If so, there's no need to assemble the tmr1l and tmr1h bytes, otherwise you'll have to read the bytes individually in the correct order to ensure the correct value. I don't think the code (uTimer*65536 + tmr1l + tmr1h*256) can specify the order, the compiler can do what it likes here. Which might, of course, be just in that order. You might consider a union of a long TIMER value with a struct of an int uTimer, char tmr1l_copy and char tmr1h_copy. In whatever order BoostC expects, big endian or little-endian (can't find this in the manual). Then you just have assignments, no calculation. The simplest way is assembler. Hope this also helps, John
  4. The asm required to do this is not tricky, just copying bytes - a very reasonable occasion to try writing in assembler! Give it a go... Looking at: #define TIMER (uTimer*65536 + tmr1l + tmr1h*256) this is just assembling a longer value by chaining component bytes together. But you know that, it's what you want to do. Strictly speaking, uTimer*65536 will not produce uTimer shifted left 16 bits, unless uTimer is greater than 16 bits in length. Since it is type 'int', which the manual says is 16 bits, the result of this shift should always be zero. uTimer should really be a long int. (Rather, a long unsigned int). This has an impact on the interrupt routine execution time, of course. With uTimer declared a long unsigned int, then tmr1 interrupt should add 65536u to it rather do uTimer++. This avoids a shift or multiply when TIMER is calculated, since the uTimer value is already scaled up. Again, in (uTimer*65536 + tmr1l + tmr1h*256), tmr1l and timer1h will probably be promoted to the uTimer length before they are used. Sometimes you can gain a bit by factoring and casting, so (uTimer + (long int)(tmr1l + tmr1h*256)) might (MIGHT!) be quicker. In your code, uTimer is accessed during the tmr1 interrupt routine. Usually when you share multi-byte values with an interrupt you will need to disable the interrupt during the non-interrupt access. You need not do that if the multi-byte is atomic in hardware, so that access cannot be split by an interrupt and is treated as a single read or write event. That isn't the case with uTimer, so this needs protecting from tmr1 interrupts while TIMER is calculated. Hope this helps, John
  5. Header files are used to tell the compiler where all the features of a micro reside on the chip. All of the internal registers, etc. are defined in the header file, and each registers bit definitions are also listed. You should not need to create a header file, as Sourceboost comes with quite a lot of header files. You will find them in the "include" folder under "Sourceboost", i.e x:\Program Files\Sourceboost\include (where x is your local drive where SourceBoost is installed). If you are a beginner in C programming, I'd advise you to stay well away from creating your own header files. I've done it, and believe me, it's a lot of work. Rather use the included header files and save yourself a real headache. Have fun! This is really a general question about C, rather than BoostC. Any reasonable book on C will cover header files. This sounds like a homework question! Firstly, header files have nothing in them that cannot be in a C file. They are C files ending in '.h' rather than '.c' . It is just a useful convention to separate some things out into 'header files'. If your project has only one file of C code, you don't _need_ a custom header file for it, but it can still be useful to have one. By putting constant definitions (such as '#define MagicNumber 42') and global function prototypes into a separate file (the header file), these can be shared between many other C files during compilation. Files which need them will have a line like '#include "whatever.h" '. Then "whatever.h" needs to be available, of course. In C, all the declarations in a file are globally visible through out the project unless they are declared as 'static' (such as 'static int afunc_in_2(int x) { some code here}'), when they can be seen only in the file which holds them. So at link time, they will be found even without the prototype being given in a header file. But at compile time, when the other files which need to refer to them have not been given them as external references, the compiler will (or should) complain it doesn't know what to do. So, if your project has several C files, and file_1.c needs to refer to a function in file_2.c, then all it needs for compilation is the file_2.h which has the prototype to the function (such as 'int afunc_in_2(int x);'). In this case, the actual code defining afunc_in_2() is in file_2.c, and file_1.c has no need to know what it is. The alternative is to put 'extern int afunc_in_2(int x);' separately in each file that refers to it, other than the one the actual code is in. Then, if you change the code for afunc_in_2() you don't have to do anything with file_1.c unless you change the 'int afunc_in_2(int x)' declaration part. You can change '#define MagicNumber 42' to '#define MagicNumber 3142' in one place, the header file, and all other files which #include this header will have the new definition, without having to poke around and change it in each file. It helps prevent mysterious results due to multiple #defines of the same thing with different values in different files by putting them in one obvious place. Note with most compilers file_2.c does not have to be present just to _compile_ file_1.c. The output of a compiler is not usually the executable code, but just a step on the way. The pre-processor, the bit that deals with the #define statements, has a rather crude behaviour, and just piles everything it comes across in all the files into one big table. No '#define' is private. If there is any duplication, the last definition wins! You can't hide them. If MagicNumber gets #defined in one file as 42 and another as 3142, you might have odd results depending on the order in which the files are compiled, since the second one found will replace the first. Hope this helps, but Get A Book! John
  6. Sorry Dan, thats a pretty unfortunate set of circumstances, with it being the beginning of term at so many colleges and having heard so many stories before (ranging from "dog ate homework", "sister died", "I am an eminent professor and I need to check my answers before I set these questions to my students") I tend to be a little sceptical. A forum is not going to be the best place to get this resolved, forums are better suited to answering specific questions about a problem. BTW I believe Dave and Pavel who wrote SourceBoost do contract work, maybe the can help! See http://www.sourceboost.com/ But not for $12.50 an hour, I imagine! For the venture's key product, at that. Dan, use a spellchecker, at least on your website if not your letters. Typo's do not impress. I think this must be your first business venture. Basic advice: don't make your problems public. Those that could help will stay away, only the sharks will swim up to you. If you cannot judge the work you are paying for, you need to find someone who can. You will need to pay for that knowledge. Chase 'Jon' as you have stated you will; you have to do that. But you have confused the sanctions: he has the option of completing the work or refunding you, but you are seeking someone else to it at the same time. Just go for the money, or you might end up paying for duplicated work. Generally, though, pay upfront only when absolutely unavoidable. It still sounds fishy to me, but after 30 years in business you get a suspicious mind. John (not Jon!)
  7. You cannot use the rs232_driver.h for two UARTS without quite a bit of modification. You could duplicate the code (including constant definitions) and change the names to suit each channel, which would allow two UARTS. Watch out for clashes with port pins. You could then interleave transmission through either as you wished, but receive is a different matter, since attention would stay with the one UART until it succeeds or the WDT expires, and the other then might miss a start-bit (if s/w) or overrun (if h/w). Receive could work if you only care about attending to one channel at a time, expecting nothing on the other. If the two receivers do not need to interleave at any time, it would work, probably. If they do need to interleave, then this scheme could not do it, you would need interrupt-driven UARTs. IMHO. Regards, John
  8. The PICsimulator from http://www.oshonsoft.com/index.html has a terminal capturing the output from the simulated chip. The IDE will load assembler programs, and I have found his simulated peripherals work well. ( Pity it's a non-optimising compiler and somewhat eccentric editor.) I haven't tried putting BoostC generated assembler into the PICsimulator, but you never know, it MIGHT work. I have a licence, but there is a free trial anyway. John
  9. I agree with you, the situation seems improbable! Maybe they were not $USA... An electronics engineer who cannot execute a very simple program for the PIC using high-level tools? Who gives $10,000 IN ADVANCE for this! It's his school project, isn't it
  10. It's a mnemonic to remember the current and voltage relationship for inductors and capacitors in AC circuits. see: http://www.physicsforums.com/showthread.php?t=111419 Righto. I was taught CIVIL: Capacitor I leads V / V leads I Inductor I cannot post the mnemonic we were taught for the resistor colour code, it is not pleasant! John
  11. If nothing in C turns up, you might find this man's project useful: http://jap.hu/electronic/irtx_pic.html He has a program in assembler. John
  12. I have not tried the build-in terminal yet. I will check if I can help you. Can't see a reason why it should not work. << snip >> According to the 16F876 datasheet I just have to hand here, the UART polarity is normal for this chip - that is, the idle level is high, the start bit is low. This is opposite to the _RS232_ logic polarity, which is supposed to be -12V for 1 or 'mark' and +12V for 0 or 'space' (when loaded), with the idle level being 'mark'. The RS232 level not being a 0 to 5V signal, of course. Is the datasheet wrong? Like you, I always have to check what someone intended when they label a serial connector. The signal names are _supposed_ to be as viewed on the computer (aka 'Data Terminal'), even when it's the modem (or PIC) you are looking at. That is, 'TX' is the signal from the computer to the modem. This is still 'TX' at the modem end of the cable, although it's an _input_ to the modem. This is often ignored, with 'TX' being always being used for a signal entering the cable. This is correct for a null-modem cable, though, because the signals have been crossed over. Regards, John John: Ok, it sounds like you're OK the stuff I mentioned. I just added the comment because those things always seem to creep up on me when I am not looking. In any case, the output TTL of the 87X PIC seems inverted from the RS232 levels. I got hung on this when I tried to hook up a little RF modem that had a TTL input -- which of course 'complied' with the RS232. Nothing is ever easy. If you remember the old Lucky Strike motto, LSMFT, "Lucky Strike Means Fine Tobacco", we could remember TTY loop levels by "Low Space Means Fine Teletype". The high mark kept the selector magnets engaged. ---but then that was long ago and far away so most don't remember it. Kinda like ELI the ICE man......although I understand that's still true. As Einstein said, it's all relative. Rye That was a mnemonic no one told me about! But then, Lucky Strike meant little in Britain 35 years ago! Doesn't mean a lot now... substituting 'Woodbines' doesn't work. At the risk of going way OT, what's ELI the ICE man? Over the years people have taken 'rs232' (or V24, or EIA - something) to be the UART NRZ output format, not the physical connection scheme. Or protocol, PHY, whatever. Just as ASCII is really a 7 bit code, not 8 bit. Lost causes. I know there are some PIC BASICS which give a choice of NRZ polarity for their software UARTs. It's handy; two resistors, you have RX & TX connected to a PC, no MAX232 required. Or TX & RX OK for the bench. John
  13. I have not tried the build-in terminal yet. I will check if I can help you. Can't see a reason why it should not work. If I am not mistaken, the terminal in the Debugger can't be hooked into the program that is being debugged -- it just talks to comm ports on the computer that supports the Debugger. But maybe I'm wrong on this .... In another (more jugular) vein ---. From painful experience I have noted that on the 16F87x series of chips, the TTL output is inverted from normal 232 polarity. The Max232 type chips provide the necessary inversion to make everything OK at their outputs. Also, make sure you understand the DCE/DTE wackiness. The RX or TX designations change from inputs to outputs depending on which type of device you are using. I still have to go to the book on this. I won't attempt to confuse the issue any further. See http://www.betterbox.co.uk/acatalog/RS%20232.pdf According to the 16F876 datasheet I just have to hand here, the UART polarity is normal for this chip - that is, the idle level is high, the start bit is low. This is opposite to the _RS232_ logic polarity, which is supposed to be -12V for 1 or 'mark' and +12V for 0 or 'space' (when loaded), with the idle level being 'mark'. The RS232 level not being a 0 to 5V signal, of course. Is the datasheet wrong? Like you, I always have to check what someone intended when they label a serial connector. The signal names are _supposed_ to be as viewed on the computer (aka 'Data Terminal'), even when it's the modem (or PIC) you are looking at. That is, 'TX' is the signal from the computer to the modem. This is still 'TX' at the modem end of the cable, although it's an _input_ to the modem. This is often ignored, with 'TX' being always being used for a signal entering the cable. This is correct for a null-modem cable, though, because the signals have been crossed over. Regards, John
  14. Hello ganavash Maybe these snips from the datasheet will help: "Note: If the global interrupts are disabled (GIE is cleared), but any interrupt source has both its interrupt enable bit and the corresponding interrupt flag bits set, the device will immediately wake-up from SLEEP. The SLEEP instruction is completely executed." "5.6 Timer1 Operation During SLEEP Timer1 can only operate during SLEEP when setup in Asynchronous Counter mode. In this mode, an external crystal or clock source can be used to increment the counter. To setup the timer to wake the device: • Timer1 must be on (T1CON<0>) • TMR1IE bit (PIE1<0>) must be set • PEIE bit (INTCON<6>) must be set The device will wake-up on an overflow. If the GIE bit (INTCON<7>) is set, the device will wake-up and jump to the Interrupt Service Routine on an overflow. " I am using the 12F625 with SLEEP, woken by the WDT, without trouble. But I am not using Timer1 interrupts. Hope these help anyway. John
  15. Reinvent the wheel? That is a commonly quoted glib phrase, and of course can reinvention can only be done by someone who doesn't know the wheel exists already. In which case, of course, it's not re-invention for _them_, but possibly an act of genius. The wheel is frequently _redesigned_, however, and there are many manufacturers even of very similar wheels. Regards
×
×
  • Create New...