Simple example of I2c code " My World" request

[basicchip]

You have lost the connection to the Coridium board. Power down, check connections repower, restart BASICtools...

[jmcdougall]

Have done that several times including rebooting PC. Have checked everything in Device manager and everything is good on the PC side.

It is as if after the first example program ran, the firmware in the SuperPro was wiped out and only the example code was there. It ran automatically after doing a reset button fine. Things went south as soon as I tried to compile another program.

It seems like the SuperPro is no longer communicating on the TX/RX on J5 which is where the USB dongle connects.

I do have another new SuperPro that I can try but will not try the 1st example program again, although it is possible that something has gone south on the USB adapter. SupePro's are not the cheapest thing to blow up!

I may pin up a Prostart and try with it. At least its a cheaper board to trash.

Appreciate the help! Maybe once I get through this, I can create a full documented example of how to do I2C to displays including ones with GPIO.

[basicchip]

For lost communication--

While it is possible to write a program to brick a device, it is not easy to do and there are ways to get it back. Though I doubt that is what you did.

First are the LEDs lit on the USB dongle and SuperPRO (if not no power or shorted power)

Does the USB dongle show up in the list of COMs and it should be in capital letters (not necessarily COM10 -- depends on your computer). If not disconnect the SuperPRO and see if it reappears.

coms.jpg (28.56 KiB) Viewed 921 times

If it does show up can you connect to the ARM (even without firmware)

coms2.jpg (60.47 KiB) Viewed 921 times

If all that passes, follow directions for a runaway program in the help files.

[jmcdougall]

Plug USB dongle with Superpro attached into computer USB port. Computer dings recognizes dongle and led is lit on dongle and led is lit on Superpro. Start Basic tools. There is a spurt of flashes on second led on dongle.
BasicTools shows the following


ser-open
stopButton
toggleReset
stopButton
toggleReset

Options -> Serial Port shows COM3 selected which is the FTDI connection

Select Options - connections display shows ser-close
2nd led does a series of flashes for a minute or two, then I get this message.

Error: Copyright 2020, Coridium Corp., my be used anywhere with this notice
No answer on '?'
Fail
Copyright .... as above

No answer on '?'
FAIL
"exec idLPC $::comport"
(menu invoke)

So I tried the following based on the runaway prg in help

Deselected the com port. Unplugged the SuperPro. Pugged the SuperPro back in.
Immediatelt the 1st example programs shows running and waiting for the"^" to be entered to continue
Checked options -> Serial port and COmm3 has been auto selected.

Tried loading the 1 line print prg - I get the "Unable to communicate" error block. Exited out and tried Reload for the Print pgm

Here is what the console shows

ser-open
stopButton
toggleReset
ü

Probing available I2C devices...
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
====================================================

Coridium Break:

@ hex [yy] - dump at hex yy words
! hex yy - write yy to hex
^ to continue
Analyzing F:/Enterprise Processor/print1.txt
get addresses
stopButton
toggleReset

Analyzing F:/Enterprise Processor/print1.txt
get addresses
stopButton
toggleReset

Finally after plying around with entering "^" a couple of times, I finnaly got to ..... program done

And then

Welcome to ARMbasic Kernel[8.40a] with Floating Point Copyright 2017, Coridium Corp.
for the SuperPro

WARNING: RTC NOT RUNNING
and

nalyzing F:/Enterprise Processor/print1.txt
get addresses
stopButton
toggleReset
<= done

bpp.exe -DLPC1756 -I"F:/Enterprise Processor" -I"C:/Users/Jim McDougall/Documents/Coridium/BASIClib" "C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/_includeAll.bas" >C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/print1.bpp 2>C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/__errors.tmp
...
Compiling C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/print1.bpp
ARMbasic.exe <C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/__temp.bas >C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/print1.hex
ARMbasic[9.60c] on the PC Copyright 2021, Coridium Corp.

-ERROR F:/Enterprise Processor/print1.txt: 1: Label Declaration Error
Main
-First ERROR at line :1
Main
Compilation failed no Hex file generated

So it looks like I have killed the 1st example prg at last.

[jmcdougall]

basicchip
I tried running your last post -= won't compile so I did add a main statement.
Still won't compile
Analyzing F:/Enterprise Processor/basicchip1.txt
get addresses
stopButton
toggleReset
<= done

bpp.exe -DLPC1756 -I"F:/Enterprise Processor" -I"C:/Users/Jim McDougall/Documents/Coridium/BASIClib" "C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/_includeAll.bas" >C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/basicchip1.bpp 2>C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/__errors.tmp
...
Compiling C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/basicchip1.bpp
ARMbasic.exe <C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/__temp.bas >C:/Users/JIMMCD~1/AppData/Local/Temp/Coridium/basicchip1.hex
ARMbasic[9.60c] on the PC Copyright 2021, Coridium Corp.

-ERROR F:/Enterprise Processor/basicchip1.txt: 8: Label Declaration Error
MAIN
-ERROR F:/Enterprise Processor/basicchip1.txt: 12: Expected string variable
print I2CIN(10,11,80,2,LCD_CMD,1,LCD_DATA)
-ERROR F:/Enterprise Processor/basicchip1.txt: 12: expected element(expression)
print I2CIN(10,11,80,2,LCD_CMD,1,LCD_DATA)
-ERROR F:/Enterprise Processor/basicchip1.txt: 12: expected element(expression)
print I2CIN(10,11,80,2,LCD_CMD,1,LCD_DATA)
-ERROR F:/Enterprise Processor/basicchip1.txt: 12: Expected Operand
print I2CIN(10,11,80,2,LCD_CMD,1,LCD_DATA)
-ERROR F:/Enterprise Processor/basicchip1.txt: 12: Expected End Of Line
print I2CIN(10,11,80,2,LCD_CMD,1,LCD_DATA)
-First ERROR at line :8
?? print I2CIN(10,11,80,2,LCD_CMD,1,LCD_DATA)
Compilation failed no Hex file generated

Here is the code I tried to run

#define I2Cspeed50
#include <I2C.bas>
' #include <LPC17xx.bas>

DIM LCD_CMD(8)
DIM LCD_DATA(16)

MAIN

LCD_CMD(0) = 254
LCD_CMD(1) = 54 ' get the version number
print I2CIN(10,11,80,2,LCD_CMD,1,LCD_DATA) ' if this does not show 1, then the display is not responding
print LCD_DATA(0) ' unless the previous number is 1, then this is meaningless

[jmcdougall]

WHOOOOOOOO Hooo.
Have it working now including turning on the leds!
Only thing to work through now is handling button presses on the keyboard.

Thank you both for your help!!!!!!

[basicchip]

Great.

FYI about the sample I sent https://www.coridium.us/coridium/blog/w ... gram-start

[jmcdougall]

On the display, there are 7 buttons. They send a lowercase character when depressed and the Upper case version when released. According to the manual, on each event the character is send immediately as per I2C recommendations. Five buttons are the 4 compass directions with a center button(Select) and 2 aux buttons. The 4 will be used for menu navigation and the center for select. The two aux will be for special functions. I am presuming that once I display the menu, I need to monitor the 2C In functions for the button release. I don't think there is any point in testing for button push and button release is less likely to be a debounce problem.
When i get a character returned then I can branch out of the monitor loop and use a Select Case to determine the action to take based on the char returned or put the select case conditioned on a value returned and use the Select case to perform an action.

Since there is a series of branches that can be followed, the loops and cases weould be in the main program and the actions would be in Subs (scroll menu lines, present secondary and/or tertiary menu. Confirm select, etc)

Does this logic make sense from an efficiency perspective?

Does it make sense to do the I2CIn in a very tight loop to monitor for input or put a wait(x) in the loop?

This is one of the last few communications/logic questions. I will have several SuperPro type interface circuit related questions as I move forward. The board I am upcomputing has a lot of 8v circuitry that is dropped or buffered down to 5v to feed the original 6522 and two 6821s. Their is a DOC08 that appears to feed reference voltages to a set of LM339a and is used as an offset to voltage feeds coming from temp sensor . DAC08 feeds - in sensors feed + in ---- output is going to PA inputs on 6522 with 10k resistors to +5. Notes on drawing indicate 0-3v toggling = cold, 0V + Ok or Hot. I am thinking that I should be able to do away with the DAC08 and the LM339 and use a dropping resistor to take the line that was the + input to the LM339 and feed it directly into the Analog inputs of a ProStart. There are a bunch of uln2003s, a few 4049B, an the odd other uln chip. Since all chips were socketed, I can use DIP headers or insert posts into the existing sockets to pick up the appropriate lines. About 90% of the lines trace back to the 6522 or the 6821s.

The good news is that I have both a working unit that I can measure actual voltages and a spare unit(so far not functional but will work on it) and another set of spare parts to work with. Once I have the I2C issues dealt with, I will start posting in the projects forum. Based on what I have read in the forums, what I am doing is similar to what many other posters do with the boards.

[basicchip]

I believe the display has a multi-character keypad buffer so you shouldn't need to read it in a tight loop. But really you'll need to experiment with that.

[jmcdougall]

While I work on that, I have another question that is I2C.
I will have several datasets that would be stored and then retrieved when the running the program.

Since these datasets are relatively simple one dimensional arrays, I was thinking of storing them on an I2C EEprom
either something like
https://www.amazon.com/dp/B091K81CP2/?c ... _lig_dp_it
or
https://www.adafruit.com/product/5146

I would create a simple program to write the data to the eeprom one time and then from that point forward unless changes were required, the functional program would just read this data as required.

All of the data is decimal numbers and I looked at the sample code that the adafruit referenced. I am not a bit and bytes and address maps person so this will be a challenge. Are there easier ways to store data once and retrieve it on an ongoing basis?
The unit will spend a good part of its life powered off so it has to be in a form of non-volatile storage.

Thank you for you help