Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Writing Array fails #33

Open
kscheff opened this issue Nov 11, 2016 · 10 comments
Open

Writing Array fails #33

kscheff opened this issue Nov 11, 2016 · 10 comments

Comments

@kscheff
Copy link

kscheff commented Nov 11, 2016

Hello,

I understand that this repro is kind of "dead" since Tim has left the project. However this is the only place to "hope" for exchange of experience... maybe someone is reading here.

Writing an array to a file works, however after the write command the execution stalls.
Here is my program list

10 OPEN 0, READ "A"
15 FOR I = 1 TO 10
20  READ #0, B
30  PRINT I,",",B
40 NEXT I
60 RETURN 
100 OPEN 0, TRUNCATE "A"
110 DIM U(10)
120 WRITE #0, U
140 CLOSE 0
150 RETURN 

goto 100
Bad expression
>> 140 CLOSE 0

I can read the file successfully by walking to its elements via:

run
1,0
2,0
3,0
4,0
5,0
6,0
7,0
8,0
9,0
10,0
OK

The issue I am fighting is that I wanted to implement an IoT data logger for solar cells mounted on the camping car. Therefore I need a way to store and access some historic values. Doing by writing single vars wastes a lot of memory, e.g. each var occupies 8 bytes (examine the reported memory). So I was looking to write an array instead. It looks like that each array element consumes 1 byte.

I have tried to write different array sizes since I suspected an alignment requirements, but this fails, too. I tried array sizes of 1, 2, 3, 4, 5, 8, 16. Also I checked different file name "A" or "F".

Is there anybody out there that have successfully used these functions?

Thanks
Kai

@kscheff
Copy link
Author

kscheff commented Nov 15, 2016

I found a workaround for the issue by not closing the file after WRITE and instead place a RETURN after it. My write routine runs then in a timer interrupt.

Update 30-Aug-2017: This issues is present for all READ and WRITE commands using an array variable as an argument since parse_variable_address() expects braces behind the array name. This leads to an ERROR_EXPRESSION to the following command.

Workaround: After such an command assign an expression with no evaluation requirement. This clears the previous error. See below example line number 30 for such a fix.

10 DIM V(2)
20 READ # SERIAL, V
30 E = E
40 PRINT V(0)
50 PRINT V(1)

It can be fixed in the BlueBasic_Interpreter.c extending the function parse_variable_address() to avoid parsing the index in such cases.

@kaiateic
Copy link

kaiateic commented Jan 3, 2017

Hi Kai,

I think, in some cases, the interpreter goes on to the next command before it is finished with the current command. File IO might be one of them. Try putting DELAY 1000 before your CLOSE command and see if that fixes it.

BTW, we are considering porting BlueBasic to a more modern platform (cc2650). TI seems to be pushing that micro. Do you want to get involved?

Cheers,
Kai

@kscheff
Copy link
Author

kscheff commented Jan 3, 2017

@kaiateic this might be a test worth...
be aware there are other issues with the DELAY command when in a GOSUB during a GATT access.

I have looked into the cc2650 for some projects, so far ready modules with this device are rare and expensive (thus I can imagine TI is more interested in pushing this device to get out of the low margin cc2541 modules). However the cc2650 has some nice features like lower power and more processing.

I have the dev kit in my drawer.... so there is interest on my side.

Cheers
Kai

@kaiateic
Copy link

kaiateic commented Jan 3, 2017

Great!

Let's take this conversation off line. Email me at kai@eic.nu

@ozarchie
Copy link

ozarchie commented Jan 7, 2017 via email

@kaiateic
Copy link

kaiateic commented Jan 8, 2017

Hi Ozarchie
Email me at the address above and lets take this offline.
Kai

@kscheff
Copy link
Author

kscheff commented Jan 8, 2017

@ozarchie
I couldn't find a module with the CC256x device. Currently I am getting CC2541 modules JPY-8 for < $2.30 in quantities of 10. If you a link for a CC256x device please send it to me.

TX Kai

@ozarchie
Copy link

ozarchie commented Jan 9, 2017 via email

@kaiateic
Copy link

kaiateic commented Jan 9, 2017

Looks like there are a lot more FCC certified modules available using Nordic chips than TI. (If it doesn't have shielding, it's not fully certified.) Might be a better idea to port to Nordic instead?
Kai

@kscheff
Copy link
Author

kscheff commented Aug 30, 2017

Bugfix see here:
kscheff@447765a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants