Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 05:01pm 01 Nov 2017
Copy link to clipboard
Print this post
Hi there.
Test code:
Result with S declared:
Result with S NOT declared:
Both ways generate an error, so what gives? MMBASIC 5.04.05, UNIO C-Function 30/07/2017, 063552
Reading works fine, but I can't write anything.
QUESTION: In PDF for the UNIO driver, the syntax is given as 'status=' blah, blah, blah. Is this 'status' variable name mandatory? IE: Does the command HAVE to use 'status=' in the command, or can you use any dummy variable name - which I thought you could?
EDIT: It appears that it IS mandatory. If I change my 'S' to 'status', everything works fine. Perhaps this needs noting in the PDF, if it is in fact the case... Edited by Grogster 2017-11-03Smoke makes things work. When the smoke gets out, it stops!
OA47 Guru Joined: 11/04/2012 Location: AustraliaPosts: 986
Posted: 05:20pm 01 Nov 2017
Copy link to clipboard
Print this post
Grogs, where can I find a description of the UNIO C-Function?
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 05:25pm 01 Nov 2017
Copy link to clipboard
Print this post
@ OA47 - Link to driver. PLEASE NOTE that you must use the code from the post by Geoff in PAGE THREE of that thread. The original post had some bugs, so don't play with that one!
No, it does not matter - same error again when I changed the code and re-run:
Edited by Grogster 2017-11-03Smoke makes things work. When the smoke gets out, it stops!
OA47 Guru Joined: 11/04/2012 Location: AustraliaPosts: 986
Posted: 05:33pm 01 Nov 2017
Copy link to clipboard
Print this post
Looking at the code I am unsure about the last STRING as from Geoff's description:
DATA The variable holding data to be read/written. This can be a variable or an array . In the case of a write it can also be an expression.
OA47Edited by OA47 2017-11-03
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 05:41pm 01 Nov 2017
Copy link to clipboard
Print this post
See PDF, page 2:
...unless the PDF is wrong?Smoke makes things work. When the smoke gets out, it stops!
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 07:47pm 01 Nov 2017
Copy link to clipboard
Print this post
Yes. If I DIM status AS INTEGER, then that is when I get the error about 'Incompatible type'.
IE: If you DIM status, I get an 'Incompatible type' error. If I DON'T DIM status, I get an 'status not declared' error, so one error fights the other, and you can't win no matter what you do. Smoke makes things work. When the smoke gets out, it stops!
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283
Posted: 08:42pm 01 Nov 2017
Copy link to clipboard
Print this post
Can you go back to the code you had working when we first started playing with these chips. You had success with my code from the link you posted earlier. That will confirm the hardware.
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 09:07pm 01 Nov 2017
Copy link to clipboard
Print this post
OK, this is getting interesting. Original code works. New code does not, but the only change was my slowing the CPU to 30MHz and clearing the variable table(as I was getting errors from that), which is still 10MHz above what the PDF states is the minimum, so I figured I would be just fine at 30.....
Test1: 'Original code - THIS WORKS. Dim D$,E$ As String Dim A As Integer Input "DATA:";D$ Input "ADDR:";A status=UNIO(14,02,A,Len(D$)+1,D$) Print status Print "Done. Attempting readback..." Pause 1000 status=UNIO(14,01,A,Len(D$)+1,E$) Print status Print E$ Print "Done." End
Test1: 'New code - THIS DOES NOT WORK Clear CPU 30 Dim D$,E$ As String Dim A As Integer Input "DATA:";D$ Input "ADDR:";A status=UNIO(14,02,A,Len(D$)+1,D$) Print S Print "Done. Attempting readback..." Pause 1000 status=UNIO(14,01,A,Len(D$)+1,E$) Print S Print E$ Print "Done." End
I will now tinker a little more....
EDIT: Makes no difference at all. I can change the speed to 48MHz, or leave it at 30MHz, and the test1 routine now works just fine - before it would not - EXACT SAME CODE.
WTF?!
The problem seemed to be cleared by NEW then XMODEM R a new copy of EXACTLY THE CODE THAT WAS NOT WORKING ABOVE. This is REALLY weird, and makes no sense - at all....
EDIT: Nope. As a test, I issued NEW, then XMODEM R the exact same code, now we are back to the same exact error as above. I really don't get this at all.... *scratching head*Edited by Grogster 2017-11-03Smoke makes things work. When the smoke gets out, it stops!
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 09:23pm 01 Nov 2017
Copy link to clipboard
Print this post
OK, here is a bit more information. The test1 routine will run OK at the command prompt from the point of XMODEM, but as soon as you RUN the code, the code falls over at the first UNIO read command, then if you try to run test1 at the command prompt again, it falls over forever from that point on.
If you study the flow of this command-line test, you can see that from the first XMODEM transfer, it works fine. As soon as you RUN the code, it falls over. From that point, it won't even run test1 at the command prompt, whereas before RUN, it DID.
....I'm lost, sorry...... Smoke makes things work. When the smoke gets out, it stops!
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292
Posted: 03:03am 02 Nov 2017
Copy link to clipboard
Print this post
This is strange. Firstly, you should be able to use any valid integer variable for "status" (eg s% = UNIO(14,01,A,Len(D$)+1,E$))
Why you are having problems is a mystery. I presume that you do not have OPTION EXPLICIT or OPTION DEFAULT in you program or in code saved to the library?
I will run some tests over the next couple of days and report back.
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 12:27pm 02 Nov 2017
Copy link to clipboard
Print this post
YES I DO HAVE OPTION EXPLICIT at the top of the code. I always program code with that as the very first step these days to help in debugging.
I did not try the percentage sign though, just a plain 'S' or whatever.
UNIO C-function is just in the main code NOT in the library. This is simply cos there is plenty of room for the C-function in the code listing, but perhaps this one HAS to be saved in the library do you think?
NOTHING in the library - the library is not used at all in this code.Smoke makes things work. When the smoke gets out, it stops!
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292
Posted: 02:21pm 02 Nov 2017
Copy link to clipboard
Print this post
Well, that would explain the "not declared" error. Use DIM INTEGER status to declare the variable.
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 04:59pm 02 Nov 2017
Copy link to clipboard
Print this post
No, it doesn't. If you re-read my earlier posts, the problem I am having is that if I DO DIM status as integer, I get the 'Incompatible type' error.
If I don't DIM status as integer, I get the 'Status not declared' error.
One error fights the other, and you cannot win. Smoke makes things work. When the smoke gets out, it stops!
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292
Posted: 07:31pm 02 Nov 2017
Copy link to clipboard
Print this post
OK, the real problem seems to be the 'Incompatible type' error. I will go back to plan A and setup a test environment to try it out. Stay tuned.Geoff Graham - http://geoffg.net
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1003
Posted: 02:38am 03 Nov 2017
Copy link to clipboard
Print this post
Hi Grogs, your code works for me. I am on pin 26 of an E28 chip.
Have you tried a different pin. Pin 14 is SPI IN on an E28 so I did not try it.
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 11:33am 03 Nov 2017
Copy link to clipboard
Print this post
Can't try different pin - PCB is already made, and uses an SSOP 28-pin MM2, so very difficult to change that now. I wonder if that could be a possible cause though?
Yes, the code works fine - until it doesn't. When it is running OK, everything is fine, but then I get those errors, which would seem to center around the 'Incompatible type' error. I only hope Geoff can replicate the error at his end.
Here is a COMPLETE CODE listing as I have it now. I don't see how anything I am doing outside of the UNIO could be causing this, but just in case I had better post the whole code. This will also allow anyone else who wants to, to experiment and see if they get the same errors. This is NOT final yet, but this is what I have and am working on as of now:
Smoke makes things work. When the smoke gets out, it stops!
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1003
Posted: 01:43pm 03 Nov 2017
Copy link to clipboard
Print this post
Hi Grogs, Probably not much to do with your issue, but I notice these three reads appear to trample on each other. Starting at 7 and reading 3+1 takes it up to 10 (7,8,9,10),so next starting point would be 11 (not 10) for the next 16 bytes you read.The 15+1 read also takes you past the current start point for 10+1 read.
Print "READING SMC..." status=UNIO(SMC,01,11,15+1,FNI$) 'Read 15 bytes from SMC - Unit index reference status=UNIO(SMC,01,7,3+1,TIMEOUT$) 'Read auto-repeat timeout from SMC - Three bytes status=UNIO(SMC,01,28,10+1,FLAGS$) 'Read control flags from SMC - ten bytes(not all are used) CPU 5 'All ahead dead-slow....
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1003
Posted: 04:10pm 03 Nov 2017
Copy link to clipboard
Print this post
Hi Grogs,
I think I have found whats happening here, good news is pin 14 is OK. I think the previous mentioned overlapping of your data in the eeprom made it look like it won't read. Correcting the offsets like below and it seems to work nicely.
Print "Writing SMC..." status=UNIO(SMC,02,11,15+1,"123456789") 'Read 15 bytes from SMC - Unit index reference status=UNIO(SMC,02,7,3+1,"999") 'Read auto-repeat timeout from SMC - Three bytes status=UNIO(SMC,02,28,10+1,"YYYYYNNNNN") 'Read control flags from SMC - ten bytes(not all are used) Print "READING SMC..." status=UNIO(SMC,01,11,15+1,FNI$) 'Read 15 bytes from SMC - Unit index reference status=UNIO(SMC,01,7,3+1,TIMEOUT$) 'Read auto-repeat timeout from SMC - Three bytes status=UNIO(SMC,01,28,10+1,FLAGS$) 'Read control flags from SMC - ten bytes(not all are used)
The confusion comes when you try to debug with the test1 routine.
The joker here is the CLEAR statement. Not sure what is does that is unexpected (maybe loses the reference to the CFunction) but if you don't use it all is well.
I made test1 into a sub and used local varaible. This means you can just type test1 at the command line for debugging.
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610
Posted: 04:49pm 03 Nov 2017
Copy link to clipboard
Print this post
Interesting. I will try that and let you know.
I did not figure that there was any problem piling up multiple calls to UNIO, as the Cfunction would only do one at a time, and so therefore, would not return until it had a result from the first one, BEFORE it tried to do the next one, but perhaps that is wrong interpretation on my part?
I also did not think there would be any problem with jumping around in the memory, as you specify the start address as part of the command, so who cares if you read ahead then jump back and read before?
Not neat I grant you, but I did not think there would be a problem with doing it that way.
I tried putting test1 into a sub with local variables, but was still getting the error, so put it back.
Your example should not change anything. The PDF for the UNIO says that that extra byte is just used by MMBASIC to keep track of the length of the string, but I fully expected that to mean that this was only for MMBASIC's purposes hopping in and out of the Cfunction, and that this extra byte is NOT written in ANY WAY to the UNIO memory itself at all.
IE: Write 10 bytes status=UNIO(14,02,10,10+1,"1234567890") will write TEN bytes and NOT eleven bytes, as you are only writing 10 bytes, and the extra byte is used by MMBASIC(not the UNIO) to keep track of the length of the string.
Do I have that totally wrong? Geoff?Edited by Grogster 2017-11-05Smoke makes things work. When the smoke gets out, it stops!
Page 1 of 2
Print this page
The Back Shed's forum code is written, and hosted, in Australia.