The very last thing I'll probably do, after *all* the code is finished, is to add a supervisor that performs a hard hardware reset in the case of timeout errors. I haven't had any, but if I did, the current code would try to limp on, probably unsuccessfully.

Does the MCU you're using support a watchdog timer?

 

Does the MCU you're using support a watchdog timer?

And that would help, how?

The BT code is written to be non-blocking. In other words, there is no place for it to lock up if anything goes wrong. The main app will keep running along oblivious to the fact that the BT state machine got out of whack.

I *did* plan for this. All states that require a response from the BT are timed. If the timer expires prior to the response being received, an error message is sent to the main app. Right now, it is just flagged and ignored. Later, I'll have the BT code force a hard reset on the module to get it back into a known state in the event of a time out.

 

Oh, and currently, my shutdown code doesn't appear to be working. The module continues to operate the radio, even after dropping the hardware lines and sending the 'dormant' command. In all honesty, I guessed as to the proper shutdown procedure -- the documentation does not detail this at all.

Anyone have any experience with this?

Or, maybe I just need a new set of eyes on the User's Guide. Anyone got some free time this Memorial Day?

 

Or, maybe I just need a new set of eyes on the User's Guide. Anyone got some free time this Memorial Day?

I can see few options beside 'dormant', such as disconnect(K) or reboot(R).

 

I can see few options beside 'dormant', such as disconnect(K) or reboot(R).

WADR, @NorthGuy, unhelpful. You will see in my code that I actually use these commands. But they don't relate to power management, unless you can show me otherwise.

Next.

 

This power problem is annoying me. Apparently, I am not the only one.

I've tried all of the suggestions, with no impact whatsoever. The module simply doesn't want to go dormant.

I think it's stupid.

I know a transistor that can fix this.

 

I was going to make a comment about the ASM vs C but I knew that was like trying to talk my kids into eating candy instead of vegetables... Whoa, wait a minute. I think I got that right but.. Never mind.

I know your comment is a few days old. I've been so busy coding and testing that I haven't had a chance to reply.

I wish you would comment. And let loose!

What I am doing here is a *supreme* example of the benefits of .asm over C for *small*, inexpensive embedded systems. I promise you, you will never write faster, smaller code in C than what I've shown here, probably by a factor of 5 at least, unless you inline-code .asm into C.

If you only knew what else was running parallel to this code in the app, you'd be impressed that such a small chip can do so much.

As I've said before, I develop commodity products. Pennies count. If not, I'd probably be coding C too.

 

you will never write faster, smaller code in C than what I've shown here, probably by a factor of 5 at least, unless you inline-code .asm into C.

I too, am a big fan of .asm . Thanks for sharing this project with us, btw.
I'm curious, when was the last time that you coded something in C ?

 

I too, am a big fan of .asm . Thanks for sharing this project with us, btw.
I'm curious, when was the last time that you coded something in C ?

I do it all the time for PC apps. I can write C as well, or better, than anyone, but .asm is my preference for small embedded system. It's like breathing for me -- it just comes naturally.

 

.asm is a tool, as is C. I choose the best tool for the job -- for me. And I've been writing .asm since 9 years old. Considering I'm closing in on 100, that's a lot of experience.

 

I know your comment is a few days old. I've been so busy coding and testing that I haven't had a chance to reply.

I wish you would comment. And let loose!

What I am doing here is a *supreme* example of the benefits of .asm over C for *small*, inexpensive embedded systems. I promise you, you will never write faster, smaller code in C than what I've shown here, probably by a factor of 5 at least, unless you inline-code .asm into C.

If you only knew what else was running parallel to this code in the app, you'd be impressed that such a small chip can do so much.

As I've said before, I develop commodity products. Pennies count. If not, I'd probably be coding C too.

Come on! I was waiting for a comment on my analogy.

I don't make anything for commercial sale -only little personal projects or on-offs to fix things for people. I may commercialize one of them some day but, as of now, I have never been too concerned with code size. I just pick a PIC with higher capacity/functionality and run with it. For a one-off, the dollar or two extra isn't going to change anything.

 

I've tried all of the suggestions, with no impact whatsoever. The module simply doesn't want to go dormant.

Have you tried post #21 from the thread you linked? Although, the firmware could've changed since then.

It is not necessarily related to software. If you only judge by power, then power loss might not be from radio, but from floating pins and such. How much power does it consume when you try to make it dormant?

 

Have you tried post #21 from the thread you linked? Although, the firmware could've changed since then.

It is not necessarily related to software. If you only judge by power, then power loss might not be from radio, but from floating pins and such. How much power does it consume when you try to make it dormant?

#21, yes. And the radio & uart function -- they shouldn't in dormant.

 

#21, yes. And the radio & uart function -- they shouldn't in dormant.

Perhaps you accidentally wake it up?

 

And the best part is, I wrote it as a module that I can include in any existing 18F project -- another notch in my library belt. Bluetooth in minutes!

A bit of elaboration:

One of the "big deals" of C is that it allows the incorporation of libraries relatively easily, and therefore supports natively the efficient reuse of code.

Many, many years ago, I developed a methodology and framework for writing .asm code that supports quick and easy insertion of "modules" that have specific functions, like driving a particular device, or performing a specific set of functions. All of the production code I write today is built around this framework, and allows the accelerated development of new products. I just simply pull a .asm and .inc into my main program and, wallah!, new and tested functionality.

Here is what the main code looks like for the app I am working on now. As you can see, Bluetooth, in this instance, is automatically installed into the existing application simply by defining BLUETOOTH, after which the code installs itself automatically during build.

    include    "config.inc"        ;PIC configuration
    include    "ports.inc"          ;Port Definitions
    include    "macro.inc"        ;general purpose macros
    include    "gensub.inc"       ;general subroutine definitions
    include    "memory.inc"     ;system memory configuration
    include    "app.inc"             ;application specific definitions
    include    "eusart.inc"        ;eusart driver definitions for sound and bluetooth
    include    "dsspi.inc"          ;SPI I/O definitions
    include    "floatlib.inc"      ;floating point library definitions
    include    "lcd.inc"              ;lcd mappings and definitions
    include    "keypad.inc"      ;keypad definitions
    include    "error.inc"         ;error definitions

#ifdef BLUETOOTH
    include "bluetooth.inc"     ;bluetooth driver definitions
#endif

;Reset Vector

    org    H'0000'

#ifdef ICD
    nop                ;required for ICD
    goto    start            ;initialize program
#else
    movlb    0x00            ;set bank 0 ram
    clrf    pclatu            ;ensure upper pclat is clear
    goto    start            ;initialize program
#endif

;Support Libraries

    include "interrupts.asm"    ;interrupt handlers
    include "main.asm"             ;main program
    include "adhip.asm"            ;a/d hi-p interrupt handler
    include "lcd8xj90.asm"      ;on-chip LCD library for PIC8xj90
    include "dsspi.asm"             ;for SPI interface
    include "eeprom.asm"        ;for off-chip SPI eeprom
    include "11AA16x.asm"       ;UNI/O interface
    include "memory.asm"       ;memory management
    include "gensub.asm"         ;general subroutines
    include "keypad.asm"         ;keypad processing
    include "floatlib.asm"         ;floating point library
    include "calculations.asm" ;app specific calculations
    include "statistics.asm"       ;poly fit library
    include "states.asm"            ;state processing
    include "power.asm"           ;power management
    include "sound.asm"           ;sound processing
    include "backlight.asm"      ;backlight processing
    include "error.asm"             ;error processing

#ifdef BLUETOOTH
    include "bluetooth.asm"     ;bluetooth processing
#endif

And don't dare say that the other advantage of C is portability. To me, portability should encompass not just code, but devices, tool chains, and libraries. This is simply not the case for small MCUs.

 

Perhaps you accidentally wake it up?

Confirmed no.

 

The main program loop looks like this. Each call is non-blocking, so the module does the minimum processing necessary and returns as fast as possible (cooperative multitasking). Things that take a long time are handled via state machines abstracted away from the main application. If one module needs to communicate with another, it is done through custom, application-specific callbacks defined in yet another .asm file. A true black-box approach.

;*******************************
;** MAIN -- Main Program Loop **
;*******************************

main    call    gettim            ;get system time
    call    getkey            ;process keypad

    bbs    minboot,msd        ;minimal processing if minimum boot

    call    prowarm            ;process ds a/d warm-up
    call    gettd            ;process sensor data
    call    prokey            ;process keypresses        (keypad.asm)
    call    prostate        ;process states            (states.asm)
    call    propwr            ;process power management    (power.asm)
    call    polllcd            ;poll lcd device        (lcd84j90.asm/lcdcb.asm)
    call    prosnd            ;process sound            (sound.asm)
    call    pollbl            ;poll backlight device        (backlight.asm)

#ifdef BLUETOOTH
    call    pollbt            ;poll bluetooth device        (bluetooth.asm)
#endif
 
    call    proee            ;save record if necessary    (eeprom.asm)

msd    bbs    sdok,shutdown        ;shutdown system?

    bra    main            ;and do it all over again

;******** END MAIN ********

 

Each call is non-blocking, so the module does the minimum processing necessary and returns as fast as possible (cooperative multitasking)

Are you using more than one MCU in your application? Or are you referring to the way things are being processed in parallel in the BT module and the MCU? ... just trying to learn here ...

 

Are you using more than one MCU in your application? Or are you referring to the way things are being processed in parallel in the BT module and the MCU? ... just trying to learn here ...

I said cooperative "multitasking", not "multiprocessing".

Though, in the case of Bluetooth, I am communicating with another MCU.

 

Perhaps you accidentally wake it up?

Solved. No, not accidentally woken, just never allowed to sleep (dormant).

Undocumented, although mentioned, I believe in the above mentioned thread:

The device will not go into sleep if the RX line is low. My code defaulted to a low RX when the EUSART is disabled.