Jump to content

techie

EstablishedMember
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

0 Neutral

About techie

  • Rank
    Newbrie
  • Birthday 12/18/1959

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Location
    USA
  1. Hi guys, looks intersting though maybe you should have a look at the Viniculum chip from FTDI. You can simply use a USB flash drive with it. That allows you to log giga bytes and transfer it to your PC very easily. techie
  2. Hi guys, a few things to add: After spending quite a lot of time to get USB code to run (in C) I finished implementing it in assembly. It is not tested yet... However the assmebly implementation (practicaly a verbatim copy as far as one can do that) uses little more than half the space that the C implementation did. So that leaves the necessary room to implement the bootloader. I am not complaning about the C code generation here. In fact I am impressed how compact it comes out. As for calling routines outside the application space. For these I am relying completely on the hardware stack
  3. Thanks everybody for your advise. I thought that was all included but a little digging revealed that it was not. Not it's working. It's usually the little things that get you...
  4. Hi Baixue, This problem is quite easily solved. The first thing you should do in the interrupt function is to check the various interrupt flags that are relevant for your application. Then, depending on which flags are set, you call appropriate functions. So you could have one function to turn on LED 1 and one function to turn on LED 2. Also the best place to clear the respecive interrupt flags is in the functions that service them. So for example if you have a function to service serial port interrupts, then the last operation before this function returns should be to clear the seria
  5. Hi, I am in the process of writing a USB bootloader for the PIC18F2550/4550. I would very much like to implement the following features but can't currently see how to accomplish this with BoostC. When there is no application on the chip, just the bootloader I would like to return a set of default descriptors to the host. However, when there is an application installed, I would like to use descriptors supplied by the application. One way this could be done is to have the application place its descriptors at an agreed upon ROM location (for example right after the interrupt vectors). Th
  6. Hi, I have trouble compiling with embedded assembler code. It appears like only a subset of the assembler instructions is supported. Is this so or am I doing something wrong? If not all instructions are supported, is there any documentaion of what is/is not supported? Here is an example that does not compile (for PIC16F876): asm { movlw 5 movwf _test movf _test, W rlf _test, F } The first two lines (movlw and movwf) compile fine. The last two lines (movf and rlf) give me an error (as usual in BosctC without the slightest hint of what is actually wrong). Thanks for any hel
  7. Sorry, my bad. I wasn't watching where I made the assignment.... It's working now. techie
  8. Pavel, I just tried your suggestion and it does not compile. It allows me to define the pointer variable but then produces an error when I try to assign a function to it. Seems like the entire function pointer thing is a bit orphaned… Regards, techie
  9. Pavel, Funny you should mention that. Indeed I have written rather large amounts of code in Java. So I suspect that gives me a certain way of looking at solutions for programming problems. In fact these days it’s pretty much all I am using for desktop development. However when I am programming an embedded device with all of 4k or perhaps 8k instructions total and just a few hundred bytes of RAM I feel that OO is not really called for. Try as you may, it just gets a bit more resource hungry than really needed. I like my embedded code tight, which is why I have been writing in assembler
  10. Hi Picxie, thanks for your reply. I thought about that as well but thought it decidedly non-elegant. Part of the reason far what I want to do is that I want to implement a library that calls client functions based on index. It would be very simple for the client code to initialize the rom array. Having to force the client to write the switch statement is a bit clunky.... You are right about my expectations. I was hoping a ROM function pointer array would be implemented as a list of call statements and one could use a computed offset for the PC to select the right function. Oh well, those a
  11. Hi everyone, so far I have been programming PICs exclusivley in assembler. For a bigger project that I want to take on I want to switch to C, so I am evaluating if SourceBoost is the way to go. So far I have hit a few things that a normal C compiler would support but SourceBoost does not. They are mostly minor annoyances though with easy workarounds. However I hit on a non-supported feature that I am not quite sure how to work around. At least not in a clean way. I need to work with an array of function pointers (this should be in ROM). It looks like SourceBoost does not support th
×
×
  • Create New...