Hands up, do you use the Mini Robomind BSP (MRM332)?

[groups]

Hi all,

The Mini Robomind is a board that was available through the Seattle Robotics 
Society that used the Motorola MC68332 processor. The BSP is called MRM332.

I was wondering if anybody uses this BSP, either for a Mini Robomind or as a 
basis for some other MC68332 board?

Why? I was talking with Joel and Chris during the RTEMS6.1 ticket review and 
asked if they knew if anybody used MRM332 anymore. I have not seen any 
discussion of this BSP or the ‘332 for years and figured that it may be time to 
sunset the BSP rather than continue to keep it up to date if nobody is using it.

I’m putting together an email to the Seattle Robotics Society to see if they 
have any interest, but please speak up if you use this BSP.

Thanks,

Andrei Chichak (from The Great White North (where it is going down to -33C 
tonight))
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Hands up, do you use the Mini Robomind BSP (MRM332)?

[groups]

Hi all,The Mini Robomind is a board that was available through the Seattle Robotics Society that used the Motorola MC68332 processor. The BSP is called MRM332.I was wondering if anybody uses this BSP, either for a Mini Robomind or as a basis for some other MC68332 board?Why? I was talking with Joel and Chris during the RTEMS6.1 ticket review and asked if they knew if anybody used MRM332 anymore. I have not seen any discussion of this BSP or the ‘332 for years and figured that it may be time to sunset the BSP rather than continue to keep it up to date if nobody is using it.I’m putting together an email to the Seattle Robotics Society to see if they have any interest, but please speak up if you use this BSP.Thanks,Andrei Chichak (from The Great White North (where it is going down to -33C tonight))___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS_FATAL_SOURCE_EXCEPTION during startup

[groups]

It’s bombing in printf. It’s so early that the stack hasn’t been set up yet, 
and it’s found an error and it’s trying to poot a message out on the console, 
which is also not set up yet.

Umm, what could be wrong? Lemme think… (I’ve worked wth this bsp in RTEMS4.11, 
and a version in RTEMS5)  

I had problems with that BSP blowing up just like this because portions of it 
weren’t compiled with the proper instruction set, and when the startup code 
called memset (I think), it would call memset in newlib/libc that was compiled 
for the wrong architecture, do the wrong thing, end up in printf and die a 
horrible death.

Let’s see if I can find the thread on Discord…

around August 19/2021

run:

rtems-exeinfo -O blah.exe

and make sure that all of the functions have the same architecture specified. 
Mine had a mix of -mcpu=cortex-m4 and -mcpu=arm7tdmi which are incompatible.



Andrei Chichak
(from The Great White North)


> On 2021-December-31, at 18:48, Петр Борисенко  wrote:
> 
> Hello and Happy new year!
> I am getting an error during startup:
> RTEMS_FATAL_SOURCE_EXCEPTION
> Catching it in _ARM_Exception_default.
> The bsp is `arm/stm32f4`.
> Here is contains of CPU_Exception_frame:
> register_r0 uint32_t 0x80139bc
> register_r1 uint32_t 0
> register_r2 uint32_t 0
> register_r3 uint32_t 76
> register_r4 uint32_t 0
> register_r5 uint32_t 0
> register_r6 uint32_t 0
> register_r7 uint32_t 0
> register_r8 uint32_t 0
> register_r9 uint32_t 0
> register_r10 uint32_t 0
> register_r11 uint32_t 0
> register_r12 uint32_t 0
> register_sp uint32_t 536909088
> register_lr void * 0x80001c3 
> register_pc void * 0x8013f08 <_svfprintf_r+8152>
> register_xpsr uint32_t 16777216
> vector uint32_t 3
> vfp_context const ARM_VFP_context * 0x0
> reserved_for_stack_alignment uint32_t 3522771716
> _Port_Minor rtems_device_minor_number * 0x20006988
> 
> *_Port_Minor rtems_device_minor_number 1363452156
> 
> What could it be? Any common reasons? Or what additional info should I
> provide?
> 
> Also it would be really appreciated if someone will help me export/build
> bsp as a debuggable source tree.
> 
> Best regards.
> Peter Borisenko
> Awesome Technologies, Ltd.
> http://awsmtek.com
> hardw...@awsmtek.com
> +79062165482
> ___
> users mailing list
> us...@rtems.org
> http://lists.rtems.org/mailman/listinfo/users

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: The compiler settings for Cortex-M4

[groups]

Good day Sebastian,

I was able to step through the boot process and see memset working properly 
this time. Then I was able to reach Init();

Now back to my BSP for the F767 and the ultimate goal of ethernet and mdns.

Thanks for your help,

Andrei

> On 2021-September-13, at 23:56, Sebastian Huber 
>  wrote:
> 
> Hello Andrei,
> 
> I modified the flags, could you please check if this fixed the problem?
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Having a problem with an out of the box setup for STM32F4

[groups]

I spent a bunch of time conversing with Chris Johns on Discord about this issue 
and Chris, with infinite patience, helped me find a possible issue.

Using rtems-exeinfo -O we noticed an issue

  | __atexit.c: -mcpu=arm7tdmi -marm -march=armv4t
  | __call_atexit.c   : -mcpu=arm7tdmi -marm -march=armv4t
  | __gettod.c: -mthumb -mcpu=cortex-m4 -march=armv7e-m
  | __usrenv.c: -mthumb -mcpu=cortex-m4 -march=armv7e-m
  | _free_r.c : -mthumb -mcpu=cortex-m4 -march=armv7e-m
  | _isatty.c : -mcpu=arm7tdmi -marm -march=armv4t


Some of the routines are compiled for an arm7tdmi, and they are the ones in 
libgcc. Other routines are compiled for cortex-m4, which is appropriate for the 
STM32F4 family.

I tried to figure out where in the building of the compilers/libraries/RTEMS6 
this was happening, and Chris, Gedare, and Joel were chanting MULTILIB MULTILIB 
MULTILIB. 

I worked hard to understand the local vernacular “what is this MULTILIB thing 
they speak of?”, figured out that a set of functions got compiled 15 different 
ways for 15 ARM sub-architectures and stored in a single library (I think), but 
it started to make sense. If my code is linked with the wrong ARM variant arm 
of multilib, then my thumb processor could branch into a function that uses ARM 
instructions instead of thumb, or some thumb dialect that it doesn’t 
understand, that would be bad.

Doing an objdump of a test program came up with a different set of instructions 
than what I was seeing in gdb/eclipse.

From objdump, the first two instructions of memset are:

   9a04:   e313tst r0, #3 
   9a08:   0a40beq 9b10 

became (from gdb/eclipse)

9a04: movs r3, r0 
9a06: b.n 0xa02a  

The hex values at location 0x9a04, in the second case, were the same as shown 
in the first case.

This is what I’ve been seeing. Memset quickly branches to the middle of strcmp, 
then culminates in printk.

And memset is one of the routines that is compiled with -mcpu=arm7tdmi.

I’m not sure how to control what arm of the multilib gcc should use. Can you 
help?

Thanks,
Andrei



> On 2021-August-12, at 11:37, gro...@chichak.ca wrote:
> 
> 
> 
>> On 2021-August-12, at 03:36, Sebastian Huber 
>>  wrote:
>> 
>> On 11/08/2021 18:22, Mr. Andrei Chichak wrote:
>>> On 2021-August-11, at 01:06, Sebastian 
>>> Huber  wrote:
 On 10/08/2021 23:48, Mr. Andrei Chichak wrote:
> From what I can figure out, there seems to be a problem with the 
> out-of-the-box build of newly that the STM32F4 uses.
> memset() goes for a few ARM instructions and then seems to intentionally 
> branch into, what the map file indicates is, the middle of fflush().
 When does this happen, during the system start or later?
>>> This is happening at startup.
>>> bsp_start_hook_1 calls bsp_start_copy_sections and the required sections 
>>> are copied properly. I can trace this code and watch the regions get copied 
>>> when needed.
>>> bsp_start_hook_1 then calls bsp_start_clear_bss (in start.h) which calls 
>>> memset with a valid pointer and size, but within a few instructions my 
>>> processor (STM32F407G-DISC1 board) has, according to the stack, gone 
>>> through rtems_fatal, _Terminate, all the way down to items_putc, and the 
>>> bus doesn’t get cleared.
>> 
>> Is the memory of the memset() initialized?
> 
> No, it is random before the call and doesn’t get altered.
> 
>> Is it the right area?
> 
> I believe it is.
> 
> The call to memset is being called with a destination address of 0x28A0 
> and a length of 28396, so the region being zero’d would be 0x28A0 - 
> 0x2000778C.
> 
> According to the map file:
> bsp_section_bss_begin == 0x28A0
> bsp_section_bss_end == 0x2000778C
> bsp_section_bss_size = 0x6EEC
> 
> From what I can see, memset is being called with the proper start address and 
> length
> 
>> Does it overlap the stack?
> 
> From reset, the initial stack pointer is 0x200097A0  (as seen at location 0x0 
> and observed in the sp register in the debugger), so the region being cleared 
> is well below the stack (the stack pointer at the point of the memset call is 
> 0x200097A0)
> 
> From the map file:
> bsp_section_rtemsstack_begin == 0x200077A0
> bsp_section_rtemsstack_end == 0x200097A0
> bsp_section_rtemsstack_size == 0x2000
> 
> So that checks out too.
> 
> Also if, from the debugger, I modify RAM around the bss region, it is 
> writable, readable, and survives a reset.
> 
> And I was originally working on a BSP for the STM32F767 (very similar to the 
> 407 and my BSP was based on your 407 BSP), have been running RTEMS5 on that 
> processor on a commercial product for a few years now, and I encountered this 
> exact same issue on my ‘767 boards when I switched over to RTEMS6. (767 has 
> more RAM starting at the same location)
> 
> 
> Andrei 
> 
> 
> 

Re: Having a problem with an out of the box setup for STM32F4

[groups]

> On 2021-August-12, at 03:36, Sebastian Huber 
>  wrote:
> 
> On 11/08/2021 18:22, Mr. Andrei Chichak wrote:
>> On 2021-August-11, at 01:06, Sebastian 
>> Huber  wrote:
>>> On 10/08/2021 23:48, Mr. Andrei Chichak wrote:
 From what I can figure out, there seems to be a problem with the 
 out-of-the-box build of newly that the STM32F4 uses.
 memset() goes for a few ARM instructions and then seems to intentionally 
 branch into, what the map file indicates is, the middle of fflush().
>>> When does this happen, during the system start or later?
>> This is happening at startup.
>> bsp_start_hook_1 calls bsp_start_copy_sections and the required sections are 
>> copied properly. I can trace this code and watch the regions get copied when 
>> needed.
>> bsp_start_hook_1 then calls bsp_start_clear_bss (in start.h) which calls 
>> memset with a valid pointer and size, but within a few instructions my 
>> processor (STM32F407G-DISC1 board) has, according to the stack, gone through 
>> rtems_fatal, _Terminate, all the way down to items_putc, and the bus doesn’t 
>> get cleared.
> 
> Is the memory of the memset() initialized?

No, it is random before the call and doesn’t get altered.

> Is it the right area?

I believe it is.

The call to memset is being called with a destination address of 0x28A0 and 
a length of 28396, so the region being zero’d would be 0x28A0 - 0x2000778C.

According to the map file:
bsp_section_bss_begin == 0x28A0
bsp_section_bss_end == 0x2000778C
bsp_section_bss_size = 0x6EEC

From what I can see, memset is being called with the proper start address and 
length

> Does it overlap the stack?

From reset, the initial stack pointer is 0x200097A0  (as seen at location 0x0 
and observed in the sp register in the debugger), so the region being cleared 
is well below the stack (the stack pointer at the point of the memset call is 
0x200097A0)

From the map file:
bsp_section_rtemsstack_begin == 0x200077A0
bsp_section_rtemsstack_end == 0x200097A0
bsp_section_rtemsstack_size == 0x2000

So that checks out too.

Also if, from the debugger, I modify RAM around the bss region, it is writable, 
readable, and survives a reset.

And I was originally working on a BSP for the STM32F767 (very similar to the 
407 and my BSP was based on your 407 BSP), have been running RTEMS5 on that 
processor on a commercial product for a few years now, and I encountered this 
exact same issue on my ‘767 boards when I switched over to RTEMS6. (767 has 
more RAM starting at the same location)


Andrei 


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Having a problem with an out of the box setup for STM32F4

[groups]

Sorry, I put in newlib and this stupid mail program put in newly.

> On 2021-August-10, at 15:48, Mr. Andrei Chichak  wrote:
> 
> From what I can figure out, there seems to be a problem with the 
> out-of-the-box build of newly that the STM32F4 uses.
> 
> memset() goes for a few ARM instructions and then seems to intentionally 
> branch into, what the map file indicates is, the middle of fflush().
> 
> newly would have been built with this command (from the quick start section 
> of the RTEMS user manual)
> 
> ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
> 6/rtems-arm
> 
> Help. I’m drowning.
> 
> Andrei

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Guidance on constructing an RTEMS6 BSP

[groups]

Hi Sebastian,

So far there is no code. The BSP won’t build. The only code is:

../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
--target=arm-rtems6 --with-rtems-bsp=stm32f4 --with-rtems-tests=yes 
6/rtems-kernel


Andrei



> On 2021-August-10, at 00:20, Sebastian Huber 
>  > wrote:
> 
> Hello Andrei,
> 
> sorry, I am a bit busy at the moment. I would try to share as much code as 
> possible (not easy with the STM source code organization) and use BSP options 
> to customize for the variants.
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de 
> 
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/ 
> 

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Interest in Virtual RTEMS Workshop

[groups]

Hi Joel,

About two weeks ago, a lady from Seattle organized a kite makers workshop, but 
virtual, over Google Meet. 3 sessions Friday afternoon, 8 Saturday, and 8 on 
Sunday.

With very little fore notice, she managed to get people from Germany, England, 
Australia, Columbia, Argentina, as well as Canada and the US. It was awesome.

The general format was that the guest speaker gave a talk on some topic that 
was a bit off of the mainstream, where a more hands on approach would be 
helpful, but nothing to niche. After their intro/video the floor was opened for 
questions to cover the details that were missed and so forth.

The biggest issue was getting the various watchers to mute their mics when not 
talking, and Google Meet tended to screw up  for the presenter, even though it 
had been working perfectly for the previous two days. It’s like there was a 
maximum possible aggravation sensor got installed that was able to detect who 
was going to present at the next session.

Yes, I’m very interested.

Andrei (from The Great White North)

-
Andrei Chichak

Systems Developer
CBF Systems Inc.
Suite 225 
8215 112 St NW
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak










___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Purpose of _Copyright_Notice?

[groups]

On 2020-May-05, at 06:37, Joel Sherrill  wrote:
> 
> The original intent wasn't as much a copyright notice as to just 
> leave some breadcrumb the system was based on RTEMS. I don't
> know that even when it was introduced, there was any guarantee
> it would be there.
> 
> Any ideas on how to leave a string that says "RTEMS is here"?
> 
> --joel

Mark them volatile const.

I tend to leave copyright notices in my code. Boards can be copied at will but 
software, including firmware, is copyrighted. You don’t need a copyright 
notice, but it is sometimes nice to leave it in there if only to say “RTEMS at 
work”.

Andrei
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: V5.x porting guide or prototypical example?

[groups]

Thank you Seb and Joel.

I’ll do it. 

One of our customers Flock Audio (flockaudio.com) has a product on the market, 
PATCH, that uses an STM32F767 and RTEMS. The product is a replacement for a 
professional audio studio patch bay that is used to route microphones, 
instruments, compressors and the sort. The Flock unit is a digitally controlled 
unit but the audio signal path is completely analog. Instead of using 1/4” mono 
patch cables, we do the patching of inputs to outputs using a crossbar 
multiplexer  controlled by the processor.

The processor is overkill, and is under clocked to <100MHz for ease of FCC 
compliance, and uses USB to talk to the desktop app. Future versions will use 
ethernet, so I’ll have to figure out how to get a network stack going on the 
‘767.

Thanks again for the pointers, and sorry to post this in the dev list, I was 
aiming for the user list but Mail decided otherwise.


Andrei

> On 2020-February-03, at 15:25, Joel Sherrill  wrote:
> 
> 
> 
> On Sun, Feb 2, 2020 at 11:39 PM Sebastian Huber 
>  > wrote:
> Hello Andrei,
> 
> - Am 3. Feb 2020 um 4:14 schrieb  gro...@chichak.ca 
> :
> 
> > \Good day,
> > 
> > A while back I put together a BSP for STM32F7 based on the STM32F407 BSP 
> > for an
> > early version of RTEMS 5.
> > 
> > Now that RTEMS 5 became 5.0, the BSP structure has moved around quite a bit 
> > and
> > I need to redo my BSP.
> > 
> > Is there a porting guide for 5.0 yet, or is there a shining example of a BSP
> > that I should emulate?
> 
> unfortunately, there is no porting guide available. We discuss currently the 
> introduction of a new build system. If it is not very urgent, then I would 
> wait a bit with the porting.
> 
> You can also start right now and use the stm32f4 BSP as an example. The 
> relevant directories are:
> 
> bsps/arm/stm32f4 (sources)
> 
> c/src/lib/libbsp/arm/stm32f4 (build system)
> 
> It isn't too bad Andrei. libcpu and libchip are now in bsps/shared. There is 
> a single
> bsps/include and the Makefile.am just lists files.
> 
> If you have questions, just ask.
> 
> --joel
>  
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel 
> 

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

V5.x porting guide or prototypical example?

[groups]

\Good day,

A while back I put together a BSP for STM32F7 based on the STM32F407 BSP for an 
early version of RTEMS 5.

Now that RTEMS 5 became 5.0, the BSP structure has moved around quite a bit and 
I need to redo my BSP.

Is there a porting guide for 5.0 yet, or is there a shining example of a BSP 
that I should emulate?

Thanks,

Andrei
>From the Great White North, where it is snowing again.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: devel.rtems.org down?

[groups]

Thanks Chris and Amar.

Andrei

> On 2019-September-02, at 19:04, Chris Johns  wrote:
> 
> On 3/9/19 10:48 am, Mr. Andrei Chichak wrote:
>> Poking around, I find that devel.rtems.org  isn’t
>> answering.
> 
> We are suffering a sustained load on Trac that is overloading the server. Amar
> is looking into but it is a long weekend and there is only so much time he has
> to sort it out. We hope it will be back and running soon.
> 
> Thank you for your patience and understanding.
> 
> Chris

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RTEMS Project] #3240: cpukit/libmisc/stackchk/check.c stack addresses formatted incorrectly.

[groups]

Joel,

I followed all of Chris’ instructions as much as I understood:

> On 2017-November-16, at 21:21, Chris Johns  > wrote:
> 
> On 17/11/2017 15:05, gro...@chichak.ca  wrote:
>> 
>> (I don’t know how to proceed with getting this reported/fixed.)
>> 
> 
> Please head to the wiki (https://devel.rtems.org/ ) 
> and select the link in the
> "Reporting a bug" column of the Releases Table for the release you are 
> reporting
> the bug against. You will need an account.
> 
> - Clone the git repo and select the branch.
> - Make the change and test.
> - Commit the change with a summary as the first line and then if
> you need more detail add a body. End the commit message with
> "Close #12345." with the ticket number.
>   eg git commit
>libmisc: Fix formatting in Stack_check_Dump_threads_usage
>Close #12345.
> - Enter 'git format-patch -1'
> - Attach the patch to the ticket.
> 

I guess I didn’t understand. I thought I needed to attach the diff to the 
ticket and some god-like person would do the final vet and push into the repo. 
No?

A





> On 2017-December-05, at 14:17, RTEMS trac  wrote:
> 
> #3240: cpukit/libmisc/stackchk/check.c stack addresses formatted incorrectly.
> --+-
> Reporter:  Andrei Chichak|   Owner:  (none)
> Type:  defect|  Status:  new
> Priority:  normal|   Milestone:  5.1
> Component:  lib   | Version:  5
> Severity:  normal|  Resolution:
> Keywords:  rtems_stack_checker_report_usage  |
> --+-
> 
> Comment (by Joel Sherrill):
> 
> Wasn't a fix for this committed? Is there work left to do? Either close or
> state actions left. Please
> 
> --
> Ticket URL: 
> RTEMS Project 
> RTEMS Project

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Desirable Application Stacks (Add-On Library Collections)

[groups]

> On 2017-January-03, at 13:38, Christian Mauderer 
>  wrote:
> 
> - Ursprüngliche Mail -
>> Von: "Joel Sherrill" 
>> An: "RTEMS Devel" 
>> Gesendet: Dienstag, 3. Januar 2017 19:41:14
>> Betreff: Desirable Application Stacks (Add-On Library Collections)
> 
>> Hi
>> 
>> Chris has put a lot of effort into the RSB and one of its
>> under-utilized capabilities is building add-on libraries.
>> Chris and I have long had a vision of add-on stacks which
>> provide a robust foundation for applications.
>> 
>> With this in mind, what third party open source packages
>> do people use with RTEMS?
>> 
>> To get the discussion started, what would make a good
>> collection of IoT and mathematical packages?
>> 
>> Suggestions, thoughts for application stack categories
>> or individual packages?
>> 
>> --joel
>> 
> 
> Hello Joel,
> 
> some time back I had a discussion on the mailing list regarding the civetweb 
> web server (MIT licensed mongoose successor). The discussion stopped 
> somewhere when we couldn't agree on a method on how to handle the test for 
> this packet and I don't really want to start the discussion again. But I 
> think that civetweb would be interesting for IoT applications. Especially if 
> it is accompanied by libressl (which works quite well too).
> 
> Just think of a RTEMS light bulb with it's own https server. You could switch 
> your light on or off without anyone listening. (To be honest: There might be 
> some better applications for it but you know what I mean.)

Recently, I needed to, approximately, do this. Though the lightbulb was 
actually the controller for a variable pitch radiator fan on a piece of farm 
equipment.

I needed to put in a web server to provide a method to help the end customer 
set a few configuration parameters. I ended up using an ESP8266 as a WiFi 
station. You associate with it, fire up your web browser, and you get a 
configuration page and a status page.

If I had used some sort of BTLE device, I would have had to write a Windows 
app, a Mac app, an iPhone app, 16 versions of Android apps, and when WWDC 
happens, start all over again. WiFi and HTML just made so much more sense, let 
the browser companies to the client side.

At one point I figured that there must be a way to use the httpd server that 
comes with LwIP, but it is pretty ingrained with the IP and ethernet stack and 
there wasn’t a clean interface that could be exposed quickly.

I ended up writing my own web page server. It sucks, I wish there was a better 
way, and I’m certain that it’s going to bite me really soon now.


Andrei
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel