The worst programmer ever to grace this forum - ME!

[HankMcSpank]

Thanks once again.

I have to hold my hand up & say I'm getting a little forgetful nowadays....

it's been a bit of a long journey & during the many twists & turns, I'd forgot that a few weeks ago, I was actually using the HSEROUT command, with my PIckit2 programmer as the 'glue' between my PIC & my PC (http://www.picbasic.co.uk/forum/showthread.php?p=73184 ...though in that thread, you'll see for that particular 'moment in time' I aborted the HSEROUT route in favour of using DEBUG...but I can't use DEBUG anymore due to the high number of interrrupts my program is having to handle - also, I never did get to the bottom of why the command hserout ["Hello World", 10,13] only line feeds intemittently!

This HSEROUT/Pickiit2 method obviously does use hardware to get data out of the PIC (as opposed to the software based DEBUG command method), so I'm hoping that revisiting that aspect tonight will yield good results with the heavy amount of encoder wheel black stripe interupts!

[ShaneMichael]

I had the same trouble when I used "Debug" and interupts, using the HSEROUT worked great. You can read about it in a thread I had
"DT Interrupt and Elapsed Time Running Slow"

http://www.picbasic.co.uk/forum/showthread.php?t=11056

hope that helps,

Shane

[HankMcSpank]

Hi Shane...thanks for the info.

Just to report that my PC onscreen text from my PIC is no longer garbled with (heaps) of interupts ...using the HSEROUT command (9600 baud) coupled with the PICKit2 Uart tool - not a MAX232 chip in sight :-)

The last thing I now need to achieve is user input!

Essentially, when my program first starts, I need to prompt the user for input (using the HSERIN or SERIN command)- the input will always be three characters long - terminated with a CR.

I've googled a fair bit on this one (HSERIN & SERIN), but surprisingly, I've not find anything that a newbie like myself can latch onto easily!

Could anyone be so kind to help out?

[Jumper]

Just because the lid is on doesn't mean that the box is emplty.. there might not be a max232 chip, but something similar is inside the pickit2 providing the same function..

[HankMcSpank]

Just because the lid is on doesn't mean that the box is emplty.. there might not be a max232 chip, but something similar is inside the pickit2 providing the same function..

I realise that.

The thrust of my joy being, that as a newbie who has already outlayed for a Pickit2 starter kit...that I can actually use that to 'glue' my PIC to my PC (h/w serial comms wise)...ie I don't have to buy extra IC hardware, veroboard etc! (nor have my time sumped having to figure out how to connect it all together - I have enough on my plate as it is with PICs!)

How can I convert my three character string (which will always be numbers) into an actual number that my program can use - I guess what i need is a way of converting a string into a number? (or perhaps a way of taking the input as raw number vs the string method I'm using?)

My input doesn't work as a number wrt my program, as when I run it my counter starts at a different number to what I input (if for example I input 0032, the count below starts decrementing at 48, in fact it starts at 48 no matter what number I input!!)[/I]

Here's what I'm doing .....

turns_required VAR BYTE[3]
counter var byte
counter = 0
pause 800
HSEROUT [13,10]
HSEROUT ["Enter Number of turns required (with a leading 0)>>>", 13,10]

Main
HSERIN 5000,finish,[WAIT("0"),STR turns_required \3]
HSEROUT ["Number of turns will be.... ", STR turns_required \3,13,10]

counter = turns_required ' this is the key bit that isn't working as turns_required is a string

count_loop:
counter = counter -1
HSEROUT [DEC COUNTER,13,10]
pause 200
GOTO count_loop

[HankMcSpank]

Oops, that last posting of mine missed a middle bit out! It should have read more like below...


I've kludged the following code taken from here & there (plagiarism is alive & well!), towards getting the HSERIN working to fit my needs.


I'm using HSERIN to take 3 characters (which always will be numbers), input from my PC keyboard into my PIC. I'd then like to use these three separate numbers & combine them into a variable. All my serial end to end connectivity is is now working (no gobbledegook etc)...I'm happy with the signal flow aspect, fuses etc - ddata is moving to & fro fine - my query is now a basic simple programming one!

With HSERIN, I'd read that's it's best to have a 'trigger' character, followed on immdeiately by the actual data. So this is what I've done, when my PIC sees a leading 0, it takes in the folloiwing three bytes as a string. I need my 3 byte input string to be 3 actual numbers that my PIC program can act upon.


Here's what I'm doing .....

turns_required VAR BYTE[3] ; this is the user input for how many turns of a motor
direction_change var byte[3] ; again, user input for when the motor should change direction.

turns_required VAR BYTE[3]
counter var byte
counter = 0
pause 800 ; let things settle
HSEROUT [13,10]
HSEROUT ["Enter Number of turns required (with a leading 0)>>>", 13,10]

Main
HSERIN 5000,finish,[WAIT("0"),STR turns_required \3] ; wait for 3 bytes following the character '0;
HSEROUT ["Number of turns will be.... ", STR turns_required \3,13,10] ' oyutput it to screen to confirm

counter = turns_required ' this is the key bit that isn't working as turns_required is a string

count_loop:
counter = counter -1
HSEROUT [DEC COUNTER,13,10]
pause 200
GOTO count_loop


How can I convert my three character 'input' string (which will always be numbers) into an actual number that my program can use - I guess what i need is a way of converting a string into a number? (or perhaps a way of taking the input as raw number vs the string method I'm using?)

When I run the program, I can see the counter starts decrementing from a different number to that what I input (if for example I input 0032, the count below starts decrementing at 48, in fact it starts at 48 no matter what number I input!!)

[HankMcSpank]

ok, I've kludged it...but there's *got* to be an easier way than this...


'set up some variables....

turns_required VAR BYTE[3] ; the main input
UNITS VAR BYTE ' will use this to extract units from above
TENS VAR BYTE ' will use this to extract tens from above
HUNDREDS VAR word ' ' will use this to extract hundreds from above
TURNS_INPUT VAR WORD ' this will be used for the final goal - a useable number!!

pause 200 ' let things settle down a bit

HSEROUT ["Enter Number of turns required (3 digits + leading 0)>>>", 13,10] 'prompt for input.

Main
HSERIN 5000,finish,[WAIT("0"),STR turns_required \3] 'read in a 3 character string preceded by a '0'
UNITS = turns_required(2) - 48 'extract the last character (units) & revert it down to a true decimal
TENS = (turns_required(1) - 48) * 10 'extract the middle character (tens) & revert it down to a true decimal
HUNDREDS = (turns_required(0) - 48) * 100 ''extract the first character (tens) & revert it down to a true decimal

TURNS_INPUT = UNITS + TENS + HUNDREDS ' add them all together.


Using the above, I've turned my keyed in '3 character ASCII code' based string into its numeric equivalent, (that I can use later in the PIC program) ...but like I say, there's got to be an easier way?

[ShaneMichael]

Instead of reading the HSERIN as STRING, read it as a DEC in to your WORD variable. Also you can use an interupt to know when you have data. If you got the interupt to work on your counter, you are close to getting it to work on data input. Darell Taylor interupts make it pretty easy. What you need is something like this at the begining:

 
    INCLUDE "DT_INTS-18.bas"     ; Base Interrupt System
    INCLUDE "ReEnterPBP-18.bas"     ; Include if using PBP interrupts
    INCLUDE "Elapsed_INT-18.bas"  ; Elapsed Timer Routines

  ASM
INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
            INT_Handler    TMR1_INT,  _ClockCount,   PBP,  yes
            INT_Handler    TMR0_INT,  _ToggleLED1,   PBP,  yes
            INT_Handler    RX_INT,     _Check_Command, PBP, yes  
        endm
        INT_CREATE               ; Creates the interrupt processor
    ENDASM
    
   T0CON = %10001000         
@ INT_ENABLE    TMR1_INT     
@ INT_ENABLE    TMR0_INT
@ INT_ENABLE    RX_INT

When the Pic recieves data it will set the RX_INT flag and jump to the _Check_Command Sub, the pic will save a some data in the UART, so you don't need to be waiting for the data to come, just need to get it when it does. The Check_Command sub looks like this:

Check_Command:
        
    hserin 10,No_Cmd,[Dec In_Val]

        
'*******************************************************
'Cool code goes here, I was reading single digit numbers and had
'if statements to reply with different information, FYI calling another sub
'in an interupt sub was breaking the code.  So be carefull jumping out
'and expecting things to work as normal on return.         
'********************************************************
@ INT_RETURN
'******************************************
'Shouldn't make it to No_Cmd, since there was data on RX to get into
'this sub. The Int_Return above should jump you back to your code
'after you get your command
'******************************************

No_Cmd:
    HSEROUT [10,"Made it to No_Cmd: I'm broke",10]

'***************************
'Don't know if disabling the RX_INT and enabling is needed
'I was trying to fix the issue of calling a sub from an interupt sub
'and thought this might help.
'***************************

@ INT_DISABLE   RX_INT
@ INT_ENABLE RX_INT
    
@ INT_RETURN

I have seen examples of reading strings if data on a single HSERIN command, I haven't ventured that far myself, but you should find examples if you search this forum, I'm sure that's where I saw it.

Just to summerize, I used this to read single numbers 1-9 and had if statements for the code to react to, I didn't do math, so I might just be lucky that it worked.

Have Fun
Shane

[HankMcSpank]

Instead of reading the HSERIN as STRING, read it as a DEC in to your WORD variable. Also you can use an interupt to know when you have data. If you got the interupt to work on your counter, you are close to getting it to work on data input. Darell Taylor interupts make it pretty easy. What you need is something like this at the begining:

Shane

Hi Shane,

Thanks for the reply.

So all I need to do (sorry for the overly noob line of questioning), is instead of...

turns_required VAR BYTE[3]
HSERIN 5000,finish,[WAIT("0"),STR turns_required \3]

I could just do this

turns_required VAR WORD[2] '(which gives me 4 bytes? ...I actually only need 3 bytes), then this ? .....
hserin 10,No_Cmd,[Dec turns_required\3]

I've bolded the bits I'm uncertain about. Presumably the DEC part means the PIC reads the HSERIN info as Decimal (as opposed to a string). But what about where it places the 3 bytes? (I declared 2 words)...how do I pull the individual bytes out again?


Re the interupts...I actually used DT's interrupt routines to get my PIC counting some 'black stripes triggering a phototransistor' - superb results. As it goes, I don't actually need interupts for my HSERIN, as the PIC will only be asking for user input at the very beginning of its program.

I would however like a more graceful way of having to enter the data in rather than using a preceding 'trigger' character (in my case a '0'), as per this line though....

HSERIN 5000,finish,[WAIT("0"),STR turns_required \3][/I]

ie I'd like my program to start running, then a user just inputs data when prompted & without having to key that extra 0 at the front - it's really a bit cack having to do that!

[ShaneMichael]

Try it withouth making an array :

turns_required VAR WORD

a BYTE = 8 bits = 0 to 255
a WORD = 16 bits = 0 to 65535

so my understaning is that turns_required would hold a value up to 65535 without issue.

You can do some testing by reading the value in as a DEC with HSERIN and "echo" it back with HSEROUT as a DEC or read the value and blink an LED = to the number you entered. I wouldn't test that at 65535 LED blinks. If you do use an array "turns_required VAR WORD[2]" then you would save and retrieve data from turns_required[1] and turns_required[2]. I don't think you need to do that...

Hope this helps, Good Luck.
Shane