Printable View
OK, I feel a bit stupid here.
if all variables are word and word arrays why temp does not get the value of valid[0]?
mem_index takes values from 1 to 15
after I run this code, temp has different value of valid[0]Code:temp var word
valid var word[4]
mem_index var byte
temp=valid[0]
write mem_index,temp
write 0,mem_index
read mem_index,temp
hserout ["get ",#mem_index," ",#temp," ",#valid[0],13,10]
and thats drives me crazy...
Ioannis
I think it's because WRITE defaults to BYTE variables. Sine you're using WORDs you need to tell it to write WORDs. Same thing with READ.
/Henrik.
That's correct Henrik.
WRITE Address,{WORD}{LONG}Value
WRITE mem_index, WORD temp
Hmm, OK, it was in front of me... Reading again and again...
I was sure that my var's were WORD sized so I felt OK.
Have not tried it yet, but seems obvious now.
Thanks a lot.
Ioannis
Well I for one don't see where mem_index is being set. Also the commands
write mem_index,temp
write 0,mem_index
would by default be writing over the contents of memory location 0 if mem_index is not set.
Dave thanks for the reply. It is been set previously, I just did not paste that part too.
Ioannis
i was not aware of the write command to do words, its not in the online help file for the instruction , that i can see
The help file in MicroCodeStudio was generated years ago and has, as far as I can see, not (ever?) been updated. You really should refer to the .pdf manual instead.
/Henrik.
yep your right hedrik , you think by now they would have done an update on the online ver though
I would have expected an updated online help file when I paid for MCSP v5 along with PBP v3.
Robert
Attachment 8225
Yeah, that would be nice (and shouldn't be hard to do) but I'd rather have them look into the issue with the damn thing (mcsp) crashing randomly. But, nope, not happening...
Problem, as I see it, (but I'm speculating and can obviously be wrong) is that the IDE is written by a third party (Mecanique) so Melabs has no "control" over it and would have to contract Mecanique to do work on it. Finding and fixing the crashing issue is hard because it apparently only happens to people outside of MeLabs and Mecanique. Well, it happened to Darrel too but that's not going to help us now :-(
/Henrik.
yes i have noticed a higher amount of crashes since i updated to win 10 , and it be nice if it were sorted
but the online manual updating is purely something they have not attempted to address
it would not be hard task to update the online manual , even if it was outsourced ,
The general feeling is that the product is left to its own fate...
Although in a short discussion with Charles (in Melabs forum http://support.melabs.com/threads/11...f-PBP-Compiler), he insists that he is still full supporting the compiler.
I see a decay and that makes me sad... I love that compiler, I'd hate see it die.
Ioannis
Yeah, but the compiler is one thing, the IDE is another.
With the apparently limitied resources they (MeLabs) have they need to (IMO of course) focus on the compiler, obviously and then EITHER on the MCSP or MPLAB(X). At this point neither really does the job properly. MCSP is easy and straight forward (and it's been what I've been using since it was made available) but it lacks hardware level debugging and some nice to have editor features and it's crashing all the time which really sucks. MPASMX is vastly a more complicated beast and although PBP is supposed to work with it it's a bitch to setup and it's not fully integrated with the IDE (syntax highlighting). But it does support hardware level debugging but that too is not 100% there since MPLAB apparently doesn't know about PBP's 16 and 32 bit variables - or so I've understood.
Anyway, yes, updating the online help in MCSP would seem like an easy thing to do or get done but really, it's not like current documentation isn't available - it's all in the manual after all.
/Henrik.
yes i read that thread on melabs site , and Ioannis/ richard brought up some valid points about the proposed approach to get a new compiler for f24 , $1000usd seems a high bench mark for limited support for such chips and not even 32bit