Back
[03:26:20] <Levitator> Hrm. Here's something of a puzzle.
[03:26:32] <Levitator> If I write a UART character and read the echo, it works.
[03:26:49] <Levitator> But if I read a continuous stream of characters from the device, it's all garbled.
[03:27:03] <Levitator> That is, if each character write is interleaved with a read, it works.
[03:27:39] <Levitator> But if the other device replies with multiple characters and it's contiguous reads, they are junk.
[03:45:23] <Casper> Levitator: you ain't using a crystal
[03:45:48] <Levitator> Hrm, Found that it works if the data comes from the RS232 chip.
[03:46:07] <Levitator> Doesn't work if it comes from the ESP module.
[03:46:35] <Levitator> But that might be because it's an arduino and I'm fighting the integrated USB/232 chip, trying to force it low.
[03:46:49] <Levitator> But that's still strange because it works for individual characters, but not strings.
[03:50:37] <Casper> if you ain't using a crystal, that is an expected behavior
[03:53:52] <Levitator> It has a crystal.
[16:37:38] <PoppaVic> OK, I'm confused. I been all over the web and tried a dozen different sorta-work-solutions. Is there a way to ask GCC "first free {eeprom,ram,flash}"?
[16:40:11] <PoppaVic> I get to main() or a support routine: I want to know where those first bytes exist. Everything thereafter will be sans compiler, malloc/free, etc.
[16:40:57] <GeneralStupid> what "first bytes"?
[16:41:26] <PoppaVic> GeneralStupid: first FREE/unused byte
[16:41:27] <GeneralStupid> and GCC does not now anything about your eeprom, ram or flash
[16:42:07] <PoppaVic> bullshit. it knows the size and start for all of it, compiles the program within it - now: where is the end of used ram/eeprom/flash?
[16:43:11] <GeneralStupid> firs free ROM address = first address + size of program + 1
[16:43:17] * PoppaVic facepalms...
[16:43:32] <GeneralStupid> and if you use malloc, gcc does not know where the first free bytes are
[16:43:56] <aczid> gcc actually only knows about your ram size and avr core
[16:44:04] <aczid> the rest is in avr-libc
[16:44:09] <PoppaVic> I never use malloc, that's the point: so, what symbols am I supposed to use to ascertain above?
[16:44:29] <aandrew> PoppaVic: it's all in the linker script is it not?
[16:45:31] <PoppaVic> aczid: yes, libc would know - and it's part and parcel with avr-gcc -o foo.elf ... - so, I am curious who knows wtf symbol reports each?
[16:46:14] <specing> gcc does not know about ram size
[16:46:17] <specing> the linker does
[16:46:20] <specing> ask the linker
[16:46:24] <PoppaVic> within a func - or main - I want to know where free eeprom, ram and flash start. If it makes you feel better, pretend it's a bootloader.
[16:46:26] <aczid> well you can look at eeprom/flash/ram from the avr code, so it should be possible to scan it for free bytes
[16:46:47] * specing facepalms
[16:48:14] <PoppaVic> the linker is a part of gcc, and the linker is not my mission: AT RUNTIME, THE CODE WANTS TO KNOW. Ok? This is simple. There is a solution.
[16:48:30] <specing> no
[16:48:36] <specing> the linker is part of binutils
[16:48:36] <aczid> oh you're right PoppaVic... gcc doesn't know about ram size... but it knows about the number of flash segments(!)
[16:48:39] <aczid> in ./gcc-4.9.2/gcc/config/avr/avr-mcus.def
[16:49:09] * PoppaVic foot-taps..
[16:49:46] <PoppaVic> aczid: being wrong N times in a row is non-positive.
[16:50:15] <aczid> I'm correcting myself, I thought that entry specified ram size
[16:50:26] <aczid> but the comments show it to be the number of flash segments
[16:50:39] <PoppaVic> RAMSTART RAMEND FLASHEND, etc, etc
[16:52:37] <aczid> I agree there's no way to ask this of just GCC, and you can't know where the code should look at run-time without a linker script
[16:52:57] <aczid> or your own hacks to avoid using a linker script...
[17:06:09] <GeneralStupid> impolite guy
[19:03:37] <Lambda_Aurigae> heap grows from bottom up and stack grows from top down...so there really isn't a last used ram location.
[19:33:17] <Emil> I think he was trying to look for first free area to write shit to.
[19:34:41] <Emil> It is possible, but for most of it there would need to be a data structure to hold that information
[19:36:09] <Lambda_Aurigae> it would need to be done at runtime for ram.