Beta builds and source for the new firmware available

markqvist · 2014-12-19 01:25:42

I have uploaded the source for the new version of the firmware on Github, along with prebuilt images for both KISS and SimpleSerial flavors, and also for both 3.3v and 5v ADC reference. These are working, but beta quality, so expect a bug here and there. Please let me know if you find any! I'll post an update on the blog tomorrow sometime In other news, the new hardware design is finished and working brilliantly

https://github.com/markqvist/MicroAPRS/ … recompiled

DB1NTO · 2014-12-20 14:53:28

Hi Mark,

many many thanks for your arduino compatible source code!
This make everything easier for me

I has make a test today. But i can't use the modem Firmware and two different (one at a time) OLED Library to print something on the OLED screen.

The Screen uses I2C on A4 and A5 Port of ATmega 328p (Arduino pro mini).

I know we use the A0 for incoming audio (ADC). Is there the problem?
Should we change the definition of the DDR A?

Thank you

Taner
DB1NTO

DJ7OO · 2014-12-20 16:35:05

Hi All,
i also had a problem with new Ardiuno software, but this was different from what Taner is claiming.
In my case there always were a lot of error messages when trying to compile attached sample file: "Basic_usage" under Arduino IDE.
The problem occured, because i simply renamed the unzipped master-file into "LibAPRS" and did download it into the library folder. The correct way would have been instead, to take "LibAPRS" from INSIDE folder "LibAPRS-master" and use this for downloading into the library folder.

73 de Klaus, DJ7OO

VK5OI · 2014-12-21 01:56:00

Thanks Klaus, DJ7OO
I had exactly this problem and had no idea what I was doing wrong, I don't usually have problems with libraries.

73 de John, VK5OI

DJ7OO · 2014-12-21 11:11:52

Hi John VK5OI,
i did expect others to have the same problem. This was the reason for doing the posting and i am glad i could help.

73 de Klaus, DJ7OO

markqvist · 2014-12-21 15:13:41

DB1NTO wrote:

Hi Mark,
I has make a test today. But i can't use the modem Firmware and two different (one at a time) OLED Library to print something on the OLED screen.
The Screen uses I2C on A4 and A5 Port of ATmega 328p (Arduino pro mini).

Thanks for spotting this! Yeah, there's probably a conflict there somewhere. I will have a look at it and fix it, it's probably just the port settings for those pins not playing nice with other libraries, should be an easy fix

DJ7OO wrote:

The correct way would have been instead, to take "LibAPRS" from INSIDE folder "LibAPRS-master" and use this for downloading into the library folder.

Yes, I need to make this more intuitive, right now it's a bit hard to understand when there's a folder in a folder I'll change the GitHub repo to reflect that.

DB1NTO · 2014-12-21 22:50:12

@Mark,

I've tested two different librarys.
First: U8GLIB. A very very universal graphic LCD library for arduino that supports a ton of LCD and OLED screens.
Secondly I've tested a smaller lib especially for cheap 0.96 inch OLED screen. You can download the very small lib from my homepage: www.mailtext.de/IIC_without_ACK.zip

Both runs without the MicroAPRS code very well. The MicroAPRS code runs without a OLED lib also very well. But not together.

I read your code around the hardware part. If I understand it correctly, the parts:
AFSK.cpp->
ADC_DDR &= ~_BV(0);
ADC_PORT &= ~_BV(0);

and device.h ->
#define ADC_PORT PORTC
#define ADC_DDR DDRC

is important for I2C on port A4 and A5.

Did BV(0); means that only bit 0 on PORTC is affected which means only port A0?

The OLED Lib only adresses just A4 and A5.

I don't understand why the codes don't work together?

Hope, you can help.

Thank you!

Taner
DB1NTO

Last edited by DB1NTO (2014-12-21 22:53:59)

markqvist · 2014-12-22 10:56:54

Hi Taner
Yes, you're understanding correctly what is going on. More specifically, ~_BV(0) means "binary one complements to" 00000001, which is 11111110. When we do DDRC &= 11111110, we basically leave all bits intact as they are, except for the last bit, which we turn to zero, this defines A0 as input. Same thing for PORTC, here we just initialise it to zero, to not write out any voltage.

Yes, it's very strange, but I suspect that it hasn't got anything to do with this, but probably a TIMER issue instead. U8glib might be using TIMER1 as well, MicroAPRS uses this timer to run the ADC sampling. I am looking into it...

DB1NTO · 2014-12-22 11:12:54

Hi Mark,

i can't find any TIMER usage in the small library. It uses just I2C with SDA and SCL.
A very basic and simple library.

Taner

markqvist · 2014-12-22 11:28:13

Same here, just had a look, and you're right, it doesn't look like it's using the timer at all... Can you show me the sketch you're compiling?

DB1NTO · 2014-12-22 11:32:50

Here: https://codebender.cc/sketch:69627

Just uploaded the both libs as zip into my account

I only added the followed lines to your example!

#include <IIC_without_ACK.h>
#include "oledfont.c"

#define OLED_SDA A4
#define OLED_SCL A5

IIC_without_ACK OLED(OLED_SDA, OLED_SCL);//9 -- sda,10 -- scl

In Setup:
OLED.Initial();
delay(10);

In Loop:
OLED.Char_F6x8(0,0,"TEST TEXT");

That's all

With this code wether the APRS lib neither the OLED lib works.

markqvist · 2014-12-22 13:03:39

I found a bug in the OLED library. There is incorrect usage of PROGMEM, so the font was not getting placed in flash, but in RAM! I also forgot I had enabled large packet buffers in LibAPRS (620 bytes), which made LibAPRS use a lot of RAM. These two things combined, and the CPU is out of RAM = sketch not working. The total RAM usage of your compiled sketch was about 2300 bytes. Now, with the fixed OLED lib, and smaller packet buffers, total RAM usage is only 1375 bytes. To fix the OLED lib, change:

#include <avr/pgmspace.h>
#define PROGMEM

/* Standard ASCII 6x8 font */
const char PROGMEM font6x8[] = {

To:

#include <avr/pgmspace.h>

/* Standard ASCII 6x8 font */
const char font6x8[] PROGMEM = {

There was incorrect placement of the PROGMEM keyword, and someone just thought it needed to be defined to "fix" the error, but by just #define PROGMEM, it was defined and declared to nothing, which made the placed PROGMEM, just "disappear" and do nothing, so the entire font was placed in RAM!

Let me know if it all works out for you!
I have also changed the large packet buffer to a size of 330 bytes and uploaded to GitHub.

Your sketch now compiles fine, and seems to be working, even though I can only test the APRS functionality, and not the OLED, since the only OLED display I have is in use for something else

DB1NTO · 2014-12-22 13:16:10

Hi Mark,

with your changes the APRS part works. But the OLED shows only some grabled pixels...

markqvist · 2014-12-22 13:22:15

Might be a timing issue due to the AFSK interrupts running while trying to send data to the display. Try to disable interrupts while updating the display, like this:

noInterrupts();
OLED.Char_F6x8(0,2,"TEST TEXT");
interrupts();

DB1NTO · 2014-12-22 15:47:40

Hi Mark,

if I change

#include <avr/pgmspace.h>
#define PROGMEM

/* Standard ASCII 6x8 font */
const char PROGMEM font6x8[] = {
To:
#include <avr/pgmspace.h>

/* Standard ASCII 6x8 font */
const char font6x8[] PROGMEM = {

The lib won't work anymore. Also without the APRS lib. I think, the lib was correct in original version.

That means:
When i change what you described, the OLED won't work with or without MicroAPRS lib.

Also

noInterrupts();
OLED.Char_F6x8(0,2,"TEST TEXT");
interrupts();

Won't help

Taner

markqvist · 2014-12-22 20:50:42

Ah, I'm a fool, of course it not enough just to make the font reside in PROGMEM, it also needs to be read in the correct way...! Sorry, I didn't think about this, even though it is obvious. When you use progmem, you can't just read the array like font[x]. So in IIC_without_ACK.cpp, you also need to change:

for(i=0;i<6;i++)
    {
      Write_IIC_Byte(font6x8[c*6+i]);
    }

To:

for(i=0;i<6;i++)
    {
      char data = pgm_read_byte(&(font6x8[c*6+i]));
      Write_IIC_Byte(data);
    }

That's probably why you are getting garbled pixels, because the program is just reading random data from weird places in memory

markqvist · 2014-12-22 20:52:40

By the way, if you manage to get this working, you should definitely put up the library on Github or something, depending on where you got it from and what license it came under. It would be nice with a library like that, with those errors corrected. Of course, if you already got it from someone who actively maintains it, I guess you should just commit the fixes back to that person

DB1NTO · 2014-12-22 21:50:30

Yay!

It Works. Thank you Mark!

This helps.
But this is a very basic demo lib for the OLED.

With the very popular U8Glib similar problems.

If you wish, please take a look to the implementation of the code on:
https://codebender.cc/sketch:70103

The problem is not the same. APRS lib works "partially".
When i use APRS_printSettings();

it prints:

Setting to: 
LibA <Settings:
Callsign:     NOCALL-1
Destination:  APZMDM-0
P <:        WIDE1-1
Path:<      WIDE2-Setting to: 
LibA <Settings:
Callsign:     NOCALL-1
Destination:  APZMDM-0
P <:        WIDE1-1
Path:<      WIDE2-2
Message dst:

Maybe memory collision?
The OLED does nothing!

The font data is stored as followed:

const u8g_fntpgm_uint8_t u8g_font_5x8[1693] U8G_FONT_SECTION("u8g_font_5x8") =
{
	1, 5, 8, 0, 255..........

Thank you again!

Taner

markqvist · 2014-12-22 23:23:24

Great that got it working! I'll have a look at U8glib compatibility as soon as I get time, it is probably easy enough to solve, and probably just some memory issues as you say

I'll let you know!

Cheers,

Mark

markqvist · 2014-12-23 14:08:15

I fixed a lot of stuff and optimised some things in the library Could you download the newest version from github and give it a try with this sketch:

http://pastebin.com/vtxA3qcK

I think it's all working now. The APRS stuff is working fine now, but as I said, I don't have an OLED to test with, so if you wanna give it a try it'd be great!

DB1NTO · 2014-12-23 15:27:20

Mark!

You are a hero

It works!
YAY!

THANK YOU THANK YOU THANK YOU!

Can i make a donation for your great work?
let me know!

The serial Output is:

LibAPRS Settings:
Callsign:     NOCALL-1
Destination:  APZMDM-0
Path1:        WIDE1-1
Path2:        WIDE2-2
Message dst:  AA3BBB-0
TX Preamble:  350
TX Tail:      50
Symbol table: Normal
Symbol:       n
Power:        2
Height:       4
Gain:         7
Directivity:  0
Latitude:     5530.80N
Longtitude:   01143.89E
Free RAM:     659

Taner

Last edited by DB1NTO (2014-12-23 15:28:39)

markqvist · 2014-12-23 16:14:13

Brilliant! I'm very happy to hear that it's working!
You really don't have to send a donation. If you want to support the work, you are welcome to buy a modem sometime, or just spread the word to others that might want to buy one, for that I would just be very very grateful! I'm just happy that the library is moving forward!

PE1AGO · 2015-01-19 23:30:39

Hello, I have downloaded microaprs-simple-serial-latest.hex and uploaded into a Arduino Nano328p.
Connected with a terminal program @ 9K6 8 n 1 and can receive packets but,
I can only give the commands with the capital letters like H not the small like c so no configuration possible.
What am i doing wrong please?

PA3BAS · 2015-01-20 07:48:01

I think you aren't doing anything wrong. The firmware is just written to only accept capitals i guess.

markqvist · 2015-01-20 11:28:07

Hi PE1AGO! The SimpleSerial firmware should accept the "c" command. What terminal program and OS are you using?

Unsigned.IO Forum

#1 2014-12-19 01:25:42

Beta builds and source for the new firmware available

#2 2014-12-20 14:53:28

Re: Beta builds and source for the new firmware available

#3 2014-12-20 16:35:05

Re: Beta builds and source for the new firmware available

#4 2014-12-21 01:56:00

Re: Beta builds and source for the new firmware available

#5 2014-12-21 11:11:52

Re: Beta builds and source for the new firmware available

#6 2014-12-21 15:13:41

Re: Beta builds and source for the new firmware available

#7 2014-12-21 22:50:12

Re: Beta builds and source for the new firmware available

#8 2014-12-22 10:56:54

Re: Beta builds and source for the new firmware available

#9 2014-12-22 11:12:54

Re: Beta builds and source for the new firmware available

#10 2014-12-22 11:28:13

Re: Beta builds and source for the new firmware available

#11 2014-12-22 11:32:50

Re: Beta builds and source for the new firmware available

#12 2014-12-22 13:03:39

Re: Beta builds and source for the new firmware available

#13 2014-12-22 13:16:10

Re: Beta builds and source for the new firmware available

#14 2014-12-22 13:22:15

Re: Beta builds and source for the new firmware available

#15 2014-12-22 15:47:40

Re: Beta builds and source for the new firmware available

#16 2014-12-22 20:50:42

Re: Beta builds and source for the new firmware available

#17 2014-12-22 20:52:40

Re: Beta builds and source for the new firmware available

#18 2014-12-22 21:50:30

Re: Beta builds and source for the new firmware available

#19 2014-12-22 23:23:24

Re: Beta builds and source for the new firmware available

#20 2014-12-23 14:08:15

Re: Beta builds and source for the new firmware available

#21 2014-12-23 15:27:20

Re: Beta builds and source for the new firmware available

#22 2014-12-23 16:14:13

Re: Beta builds and source for the new firmware available

#23 2015-01-19 23:30:39

Re: Beta builds and source for the new firmware available

#24 2015-01-20 07:48:01

Re: Beta builds and source for the new firmware available

#25 2015-01-20 11:28:07

Re: Beta builds and source for the new firmware available

Board footer