build with NONOS-SDK-V2.0.0
Avoncliff opened this issue · 16 comments
Hi - great project - well impressed with the make credentials.
I am having problems with the telnet logging out after 20-30secs, and I have not yet got the TV to see the signal, but to help understand what is going on I have tried to rebuild the code with some debug.
And that is where I hit problems, I am using ESP8266_NONOS_SDK-V2.0.0.0 _16_08_10 for another project so I have tried tat bhut get error:
"region `iram1_0_seg' overflowed by 2536 bytes"
I believe this is related to the ICACHE_FLASH_ATTR directive, can you advise?
Thanks.
I've encountered a similar issue also with ESP8266_NONOS_SDK_V2.0.0_16_08_10.
For me the message is:
region iram1_0_seg' overflowed by 2064 bytes`
I also see this message:
./esp-open-sdk/sdk/lib/liblwip.a(espconn_buf.o): In function ringbuf_head':
(.text+0x1cc): undefined reference to memchr'
and
../esp-open-sdk/sdk/lib/liblwip.a(espconn_buf.o): In function ringbuf_findchr':
(.text+0x253): undefined reference to memchr'
The undefined ref to memchr can be fixed by adding -lc to the LDFLAGS_CORE.
LDFLAGS_CORE:=-nostdlib -Wl,--start-group -lmain -lnet80211 -lcrypto -lssl -lwpa -llwip -lpp -lphy -Wl,--end-group -lgcc -lc -T$(SDK)/ld/eagle.app.v6.ld
But I have not been able to fix the overflow, if I add ICACHE_FLASH_ATTR to some of the functions the size of the overflow reduces. But I am not sure how to add it to the 6502 functions where there is a function pointer lookup table.
@Avoncliff. Thanks for the hint with -lc. Works for me. But the overflowed problem is still there. After some googling, it seems, that the code is to big. By using the compiler option -Os instead of -O3 the size in the error message was reduced to 1112 in my case. Some people suggest to tweak the linker file (see here: kaa-example-too-big-to-fit-esp8266 ) but this did not work for me. Another suggestion was to replace libgcc.a by the version from the SDK.
The ICACHE_FLASH_ATTR directive is explained here.
Thanks for the feedback, everyone. I compiled with SDK 1.3.0 because I've found later revisions use too much RAM. By using -Os instead of -O3 you will shrink the code, but then the 6502 wasn't fast enough to do real time emulation and still leave room for other tasks. -O3 flag makes the compiler do a lot of loop unrolling and other optimizations to make the code run fast enough. Maybe the 6502 core could be further optimized, but sadly I didn't have time to go down that road (job, exams, family)...
I have to point out I'm no expert in ESP8266, this is my first project with it :)
Please try using SDK 1.3.0 and let me know if you get it to compile successfully. I'll help you out to the best of my knowledge.
Cheers!
I prefer to stick with the SDK I have loaded on my system, having 2 versions is going to catch me out sooner or later, but I will try it.....
Now feeling dumb, can you give me a link to where to get it, the espressif site is full of do not use old version.
I think you could try:
http://bbs.espressif.com/download/file.php?id=664
I also didn't like the idea of using 1.3.0 since newer versions have several bugs fixed, but I didn't manage to squeeze the whole code in and make it fast enough to run 6502 real-time otherwise.
The pre-modulated Signetics video ROM lookup table could probably be reduced to a smaller byte array which references the 32 bit values from a tiny lookup table, and might just still be fast enough to run the 6502 routines.
In theory, with some big-banging you need just 2 bits and one more lookup to replace current array elements which could perhaps be done in ~380 bytes. Now I'm curious and will try this as soon as I find some spare time. I'm sorry about the telnet logging you out, that was actually a silly connection timeout put in with a ridiculously low value. It's on my bug list for the project :)
@Avoncliff Ok, could finally compile with SDK version 1.3.0: I used esp-open-sdk and changed VENDOR_SDK in the top-level Makefile from 2.0.0 to 1.3.0. A few changes in esp-open-lwip/lwip/app/dhcpserver.c were necessary to get it compiled:
- remove comments from line that contains static bool dhcps_lease_flag
- replace dhcps_lease.enabled with dhcps_lease_flag
I've checked out the esp-open-sdk parallel to espple, so that I only had to change the paths in the top-level Makefile of espple to
GCC_FOLDER:=../esp-open-sdk/xtensa-lx106-elf SDK:=../esp-open-sdk/sdk
Have not flashed the self-compiled code yet, but I hope this helps you in order to get it compiled.
I can compile it now, using 1.3.0, it still was too big for i_ram1_0 but only 296 bytes and a couple of ICACHE_FLASH_ATTR fixed that. - Thanks all.
Now I get a the flashing cursor OK on the TV with my esp8266-12E but it fails to find the wi-fi.
[19:08:46:885] scandone␍␊
[19:08:47:824] state: 0 -> 2 (b0)␍␊
[19:08:48:825] reconnect␍␊
[19:08:48:825] state: 2 -> 0 (0)␍␊
[19:08:48:825] f 0, no buf for probe, ie len 0␍␊
But if I reload another esp project the wifi works fine,
And with my esp8266-01 I can telnet to it no problem, but the TV will not lock to the signal, I can see the signal is there but spread in diagonal lines all over a flashing screen. And this is after much tweaking of ancient TV to get the 12E picture steady.
I think Signetics array already runs from dram0:
eagle.app.v6.ld defines:
dram0_0_seg : org = 0x3FFE8000, len = 0x14000
and objdump says that it goes to 3ffe8000
3ffe8000 g O .data 00001800 Signetics_2513_Modulated_Video_ROM
ESP is a Harvard architecture and iram space should have been designed a little bigger. Few bytes could be gained in fake6502.c, removing the extra cycle penalties code as accuracy vs. size trade-off.
I've disabled the TCP connection timeout so Telnet shouldn't throw you off now. What are your WPA settings? From what I've seen, ESP can be really buggy. Also, jitter when pinging is through the roof in every SDK I've tried to compile with. There has to be some catch, but I'm still unable to find it. I'll update you when I learn more, I'm very sorry it doesn't work for you out of the box.
Cheers!
@hrvach: Thanks. Your latest patch improves a lot, but I still have some issues with telnet: my telnet client - standard linux command line - seems to send more bytes at once and it seems that I've to press enter in the client before bytes are sent.
So my question is: What telnet client are you using (e.g. PuTTy on Windows) and which settings are you using for telnet?
@eska-muc I'm using plain Linux telnet binary. After you connect, press ^] (Ctrl and right square bracket together) and type "mode character". Then it will send char by char instead of line by line.
I've added another patch which sends escape codes to client, instructing it to use character mode. Please try again and see if this improved. I've tested it on Linux telnet client and it works, I'm not sure how PuTTy would respond, but hopefully it will also work. Feedback is welcome! 👍
@hrvach I think my problem with getting wifi connected on the 12E is related to signal strength. The TV is in a weak wifi area. Everything connects OK there if the espple is not running, and if espple is running away from the TV in a stronger area it will also connect. I will test this a bit more.
Which compiler are you using, I have xtensa-lx106-elf-gcc-4.8.5 and still see a few too many bytes in iram.
I wish I understood makefiles how did you use objdump?
@Avoncliff I'm also using the xtensa-lx106 gcc version 4.8.5.
You can use objdump like this: xtensa-lx106-elf-objdump -t image.elf , you'll find it in the same bin folder where your xtensa gcc is.
This only applies after you successfully built the image.elf (which is not the case if you are over the iram quota, an error is thrown instead). My 12E does not have stellar wi-fi range so I guess you need to be a little closer. I guess that's one of the few benefits of living in a small apartment! :-)
If you wish to further reduce the memory footprint, you can remove all references to penaltyop and penaltyaddr in fake6502.c, this will not be cycle-accurate anymore but should result in smaller code.
Thanks for all your help, it is now running fine.
https://avoncliff.eu/nextcloud/index.php/s/iUhGCpzRAcyMjVj
I am impressed with the picture quality, although the telnet is very flaky, dropping char. I am guessing this is the TV transmission signal interfering with the wifi. I had to get a much stronger wifi to get any connection. I have moved the testi2s_init from user_init to the reset with control C, and I have a good wifi connection till the TV starts. Maybe a ground plane, or some grounding of the 0v would help.
Can you explain how the video works in a little more detail, the slc_isr is only called for picture lines? the sync lines are stored?
@Avoncliff it's good to hear you got it working. Telnet is indeed flaky, and ping is also very jittery with some packet loss. I have yet to figure out why, still didn't find enough time to do a more detailed analysis.
The video works through magic of DMA - you feed it chunks of memory and it "empties" them serially by spitting out bit by bit. When it's done, it generates the interrupt and the interrupt service routine gets called (the isr part), and in the isr routines you provide another chunk. Everything that can be calculated in advance is stored in advance since efficiency is mandatory to perform all of the required operations in time. Chunks are linked in a circular fashion and each chunk corresponds to one line. If the current line is outside of picture lines, slc_isr is still fired, but no picture data is imprinted on the current output buffer chunk, it's left as-is and sent out with the proper current horizontal/vertical sync information.
When drawing a line, you look up the terminal character buffer to see which characters you need to show, and since characters are made of several rows, you need to know which row / line you're currently drawing. Then you look it up in the signetics character array which contains the pre-modulated signals for that exact character row and copy it to the picture segment of the output buffer. Horizontal and vertical sync signals are stored in advance since they are defined for the target video standard.
I don't know if any of this makes sense. I supposedly suck at explaining things, but at least I tried. :)