PropDNA+RTC Board and SimpleIDE
Rsadeika
Posts: 3,837
Because this board has a built in RTC and some expanded RAM, I am trying to see what I can do with it. The question I have is, I noticed that SimpleIDE comes with dna.cfg and dna-nway.cfg preloaded, why doesn't it come up as a selection for board type? What is dna-nway.cfg? What can I do to make that visible for selection? I do not remember seeing any instructions in the documentation.
Ray
Ray
Comments
Board Types on page 32 of the user guide mentions adding board types to boards.txt.
Look at the heading Special Clock Boards. Item 3 says:
Ray
Ray
You need to be admin to change the file.
The alternative is to copy the dna.cfg file to your project folder.
I am not sure if everybody is going to rush out and buy one of these boards, some reminders:
For the SD usage, when using Simple View - 'int DO = 0, CLK = 1, DI = 2, CS = 3' is needed to access the SD.
I tried doing a simple blinker program in CMM mode, DNA-NWAY Board Type, which worked as expected. I also tried doing the blinker in XMMC External Flash Code... DNA-NWAY, which also worked as expected. The one thing that got my attention was the Code Size, it stayed the same as the CMM mode. On the Activity Board when you switched to the XMMC... mode, the program size increased by a substantial amount, I was expecting to see the same thing with the DNA board. Is there an inconsistency with the Code Size reporting with the DNA board?
Back some time ago I wrote a program for accessing the RTC for this board, I will have to see if I still have the program somewhere, bring it up to today's standards, and see if it functions as expected in Simple View.
Ray
Thanks for your notes on the board.txt file.
XMMC is essentially stored as LMM with some extra code.
I'm not sure about dna.cfg -vs- dna-nway.cfg sizes. SimpleIDE just reads the fields generated by propellergcc.
Ray
In this program I also added SD support, and with that added in, and using the XMMC mode: Code Size 35,104 bytes (36,040 total). This is no problem because of the 1 megabyte flash ram, but I wonder if the program speed really starts to slow down when the program really gets big.
As for the RTC, on this board, I am still trying to figure out what is the best approach for resolving this issue.
Ray
Ray
Andy does not provide xmm-single and xmm-split libraries in Simple Libraries. You can't use them with just flash anyway.
Post your xmmc sd code please. I'll look at it this evening.
I found my original program for setting the clock for this board, and it is still working as expected considering it was develop well over a year ago, not sure what version of SimpleIDE I used. Now I have a starting point, the main RTC program, and the necessary I2C part. I noticed that there is a libsimplei2c in the Simple library; I believe I did a spin2cpp on Dave Hines version of I2C, wonder if simplei2c is a good substitute?
Ray
Which BoardType are you using for XMMC? DNA, DNA-HI, DNA-SQI, or DNA-SQIHI?
Also, where is your Flash Chip? U9 or U12?
Can you run any program at all like Welcome.side using XMMC?
I had no problems using the SDCard with XMMC on my DNA board.
It has this configuration:
- Quad SPI Flash in U12 next to XTAL
- SDCard on pins 16,17,18,19 - DO jump to P16, CLK to P17, etc...
- Use DNA:SQIHI board type
Ray
For your configuration, you need to use board type DNA:SQI (not DNA:SQIHI). I'll change my board and test this morning.
The solder bridges can be removed by heating them and tapping the board on a table on the reset button side. Cutting is not necessary.
In some ways this board is too flexible.
However apparently it doesn't matter if DNA:SQI or DNA:SQIHI is used - presumably because of the explicit sd_mount.
I would still choose DNA:SQI for the SD Card pins on 0,1,2,3 though.
Ray
I recommend however that you always close a file before reopening it. Your latest code doesn't.
Ray
Eric
I think I had a similar problem that I was working on, but it never got resolved, so this is not my first encounter. I tried replicating the problem in a smaller program, but the problem only shows up in the larger program, maybe it is a lack of available memory, but I have no way too confirm that. If that is the case, the subtlety of this, is kind of alarming.
Ray
Ray
I was also thinking that I might have a better chance of success of this idea using threads, but I think that would even be more complicated than trying to deal with COGs. But, I am not absolutely sure about this.
Ray
The easy rule is: do not try to use the same pin from 2 different COGs.
Ray
Why not just do this?
Ray
Ray