Jump to content

animeranger

EstablishedMember
  • Content Count

    37
  • Joined

  • Last visited

Everything posted by animeranger

  1. My previous post was directed toward jwilson, not asmallri. Sorry. - Bill
  2. asmallri, I think I understand what you are trying to do. However, your question is unclear. You seem to have made a few statements rather than any real request for help. Here's my interpretation of what you may need. As for which PIC to select, search the Microchip website. You will need one with the ability to self-write. As for reading the external eeprom/flash, most use the standard Serial Peripheral Interface (SPI), which is synchronous. You may find it useful to select a chip that has a Master Synchronous Serial Port (MSSP) built into it. Also, given that the PIC is going to modify itself, it will have to be flash based rather than OTP. Your "bootloader" is not a bootloader in the traditional sense because it doesn't simply remove the hardware between the PC and the chip. You will probably have to write your own. In your main routine, the first thing you should do is see if the eeprom is attached. I'd suggest using a timer to create a time-out. If it is attached, use the MSSP to read the version number. If it is higher, collect the new program code into RAM and use the self-write feature to overwrite the program. Remember that you have to write a certain number of instructions all at one time because it's flash memory (the page size will be written somewhere in the self-write section of the PIC's datasheet). Afterwords, make the PIC reset itself. The hard part will be that the bootloader should probably not overwrite itself while it is executing. To do this, you will probably want to know exactly where it is in program memory. I'm not sure if it is possible to specify exactly where to put a routine using the BoostC linker. I don't believe it is currently possible, but I haven't looked for that information specifically. Search the forum for more information about that. I hope this answers any questions you may have. Good luck. - Bill
  3. Thank you for doing this. I've looked around the internet and bought a copy of USB Complete, but I still haven't successfully created a USB device. Any library to do it is appreciated. Now, there'll be one for my favorite compiler. I'm excited to leave work today and try it out. - Bill
  4. I believe your problem is because of the way Timer0 works. The tmr0 register increments after every instruction cycle (not the same as an instruction in C). Since it takes 7 instruction cycles to change each of the outputs of portc and about 2 cycles for the jump, portc will not look like a binary counter, which is the behavior I'm assuming that you are expecting. Instead, it increments by 7 for each step. Using the debugger in the SourceBoost IDE, I added a watch to tmr0. tmr0 is 0 when it enters the while loop, and is 0x3A (58) by the time it reaches "portc.0 = tmr0.0" again. If you are looking to create a counter, would suggest increasing portc via an interrupt when the timer overflows. I hope this helps, - Bill
  5. I understood what the problem was, but I didn't know that alloc can take a long time. I generally don't use it. In the case of my current project, a message router, I am collecting messages from a network of devices I am building and delivering them to an interface I've created on my PC. I want to store these messages in the router if my PC is ever disconnected. When it reconnects, the router will deliver the messages. Because the messages can vary in length, I thought that dynamic memory allocation may be useful. I normally just create a giant array of whatever memory I have left over (saving some for the heap, just in case I didn't see something that may need it), and use pointers to the beginnings of messages I keep inside of it, kind of like a memory map. Because I'm delivering the entire thing to one device and clearing it, fragmentation and other such things have never been a problem whenever I've done this. I guess I'll go back to the memory map, or I'll just do everything in main and set flags in the interrupts for when main should alloc something. I'll play with both to find what is better. Thanks, Dave. - Bill
  6. There is a large pinned thread about this on the forum: http://forum.sourceboost.com/index.php?showtopic=984 (It more than one page, in case you didn't notice. I didn't the first time I looked at it.) It doesn't seem to be possible without running a full scale OS emulator like VirtualBox or VMware. - Bill
  7. When I first started with custom power supplies, this web site helped me tremendously: http://www.daycounter.com/LabBook/BoostCon...Equations.phtml http://www.daycounter.com/Calculators/Swit...alculator.phtml The first link shows the schematic and the equations needed. The second link will do the calculations for you. As for the square wave input, use can use a PIC (I used a PIC16HV785 so it could deal with overvoltage). This can let you adjust the voltage by changing the frequency. You can also use a typical 555 astable multivibrator. There's tons of info on the web about 555's if you've never used one. This site was the most helpful for me: http://www.uoguelph.ca/~antoon/gadgets/555/555.html I hope this helps. - Bill
  8. I keep getting the following error when I link my current project: Serious Warning: Possible sw stack corruption, function 'alloc' called by more than one asynchronous thread (main/Task, interrupt, interrupt low) I understand why this is. I'm calling alloc from all three locations. I know of a workaround for this for my particular project. But, I am hoping to not have to use it. I have created multiple subroutines as suggested in the manual such as function(), function_interrupt(), and function_interrupt_low() for all the other functions that have this conflict. However, to my knowledge, I can't do this for functions inside the BoostC libraries. Does anyone know how to create a function such as alloc_interrupt() ? If this is impossible, which I believe it is, I think I'll submit this as a feature request. Thanks, - Bill
  9. Rather than doing anything complicated like that, why not just use the carry bit? void main() { unsigned char x; for(x = 0; x <= 255; x++) { if (! status.C) break; // Your code here } } This works using the debugger and a target of PIC18F4550 (what I tend to use most). Note that you should use "! status.C". For why, see page 71 of the PIC18F4550 data sheet. Hopefully this will help you. - Bill
  10. Oops. This topic isn't from April 2008. It's April 2007. My mistake. Sorry about that. - Bill
  11. Maybe your computer has a permission issue or something like that. I have been using BoostC on my Vista 32-bit laptop since late December/early January with no special setup. Trying to get it to work in WINE or VirtualBox on a Fedora 8 machine, however, froze my computer a lot. That's why I still do all my chip programming on the Windows laptop. - Bill
  12. I have crawled on these forums for a few months now, debating whether I should register or not. This post was my breaking point since I know a problem similar to this all too well. I could not get my "Hello, World!" function to work with SourceBoost, but I could with MpLab. The problem was that I was still new to microcontroller programming and I didn't know about CONFIG bits. If you look in the datasheet for the PIC18F4550 on page 290, there is a bit called WDTEN. This bit is set by default, enabling the watchdog timer (WDT). The WDT constantly runs in the background of the PIC, and it resets the PIC whenever it overflows. This helps to prevent the PIC from hanging on one instruction is an error occurs or if there is an infinite loop. The WDT must be cleared manually in software. clear_wdt() does this in SourceBoost. Either add clear_wdt to your while loop, or just disable the WDT using "#pragma DATA" etc. The WDT is one of the reasons that every time I write code, I add #pragmas to the beginning to manually set every CONFIG bit my particular PIC has. SourceBoost will leave the default CONFIG bits, but MpLab tends to change them to shut everything off by default rather than using hardware defaults. This may or may not work for you because I don't kow about your bootloader. I tend not to use them. In any case, I hope this will help somewhat. - Bill
×
×
  • Create New...